Hi!
> > > 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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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
Hi!
> 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.
> 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.
Another disadvantage is that you need to hack into PAM infrastructure,
that your suspend password needs to be same as someone's login
password, and that it will really only work with single-user machine.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hello,
On Sat, May 5, 2007 11:16, Pavel Machek wrote:
>> 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.
>
>
>
>> 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.
>
> Another disadvantage is that you need to hack into PAM infrastructure,
> that your suspend password needs to be same as someone's login
> password, and that it will really only work with single-user machine.
The first two are only true if you want to integrate it with user login, so
that a user only needs to sign in once, which seems like a convenient thing.
But if you don't want to integrate with the existing login infrastructure,
then just don't. And those disadvantages are true for any system that wants
users to login once.
Then the disadvantage is reduced to a user needing to provide the password
at suspend if the system wasn't booted from a snapshot. But no need for
users to generate any files, just to choose a resume password.
If the resume key is stored per user instead of a single global instance, it
will work with a multi-user system too. A more interesting question is what
should happen when one user did the suspend and the other wants to resume.
Throw away the snapshot? Refuse booting? Or boot and switch "active user"?
If you don't want people to resume each other's suspends then a key per user
works. If you want them to, then it becomes a bit tricky, especially if you
don't integrate with the login system. You don't want that a user can resume
someone else's snapshot and have access to everything that other user left
open. Nor do you want users to give a password twice.
If you want users to be able to resume each other's snapshots, you probably
also want the system to switch users after the resume. No matter what scheme
is used, this becomes hairy and hard to get watertight. (Perhaps "impossible"
is more realistic: how to be able to read the suspend image and copying it
to RAM again, without having access to all data within?)
But if it's an "us" against "them" case, and you want users to resume each
other's snapshots, you're right that the scheme I proposed will fall apart.
In which case it needs to be adjusted a bit to handle this case:
Have one global suspend/resume key, and for each user store it on disk,
encrypted with that user's password. Also store the key in memory as
before. Now when the system is suspended any user needs to have provided
his password once for everyone to be able to suspend without giving a
password. Also everyone can resume, if they have access to the file with
the list of encrypted keys and provide the right password. (Notice that
this looks more like the current scheme, where the private part of the
RSA key is encrypted with a passphrase and all stored in a file.)
Though it seems that using suspend to disk on a real multi-user system is
always asking for problems, because the suspend image may contain valuable
data which shouldn't be thrown away, but easily can by other users. Nor do
you want users to claim the machine, so it's a lose/lose situation. Also
with resume every user effectively gets root access, because of all the
memory access. So inter-user security is down the drain anyway.
Only sane usage I can see is when the users trust each other, in which case
they can as well agree on one resume password. ;-)
Greetings,
Indan