Re: Back to the future.

On Thu, May 3, 2007 14:06, Pavel Machek wrote:
The kernel can already do compression and encryption.

Yes, if we all could agree on _which_ compression and encryption

Any of those available in the kernel. Where's the problem?

gzip is too slow for this. lzf works okay. Oh and swsusp wants rsa
crypto.

Then port lzf to the kernel, or help with the lzo port.

Swsusp might want RSA crypto, but it doesn't really need it. Currently
it only uses it to be able to suspend without asking for a passphrase.

So the current sequence is:

1) Generate RSA keys + ask for a passphrase. (Once)

...

2) Suspend. (Encrypt snapshot with public RSA key).

...

3) Ask for the passphrase.

4) Resume.

RSA is used so that the passphrase can be thrown away between 1 and 2.


But the same functionality can be achieved by doing:

1) Define a user password (e.g. /etc/shadow thing). (Once)

2) When a user logs in: get random data and encrypt it with the password,
this becomes the AES key. Store both the data and key in a secure way in
memory, e.g. using the existing kernel key infrastructure.

...

3) Suspend.
(Encrypt snapshot with the AES key and store the random data.)

...

3) Ask for the passphrase.
(To get the AES key, encrypt the stored random data.)

4) Resume.

Variants are possible of course, but this is the main idea.


This is secure because the key infrastructure is secure, and even if
it isn't the system must be compromised to get the suspend key before
the suspend is done. But at that point the attacker already has all
information that can be found in the suspend image, and could have done
all kind of things to inflict damage (like installing a key logger).

Advantage of this scheme is that it only need AES and can be done (mostly)
in kernel space. It's also faster and simpler than the current RSA scheme.
Disadvantage is that it wastes at least 32 bytes of memory when the system
is running, to store the data and key.

Only thing that needs to be done in userspace is setting the random data
and AES key, but there exist a suitable interface for that (the key system).
As user login is already done in user space, this can be integrated with
that in a nice way.

Greetings,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Asp.net 2.0 deployment with encryption
    ... I guesss I will create a rsa key on the production server. ... Export the public xml/key to a common location on some server. ... As for the ASP.NET 2.0 configuration section protection, ... encryption which use a single shared session key to encrypt and decrypte ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: What is exponent?
    ... For simple description of RSA algorithm ... I also have the receiver's certificate (public key only). ... Use RSA to encrypt the session key ...
    (microsoft.public.dotnet.security)
  • Re: Decrypt RSA using D
    ... We are planning on using RSA with WSE, so it only uses RSA to encrypt the symmetric key used for the SOAP body--the same scenario you outlined below. ... owner of the private key can decrypt it. ... always embedded inside the CSP key container and never passed out into the ...
    (microsoft.public.dotnet.framework)
  • Re: Java, MSCAPI interoperability - newbie
    ... A good solution (analogous to enveloped email) is to have the two parties have ... Then you can leverage RSA key-exchange protocol very easily. ... data with random symmetric key and encrypt the symmetric key with their local private RSA key ...
    (microsoft.public.platformsdk.security)
  • Re: Back to the future.
    ... When a user logs in: get random data and encrypt it with the password, ... The first two are only true if you want to integrate it with user login, ... at suspend if the system wasn't booted from a snapshot. ...
    (Linux-Kernel)