Hi!
Thanks to Rafael's great work, we now have working encrypted suspend
and resume. You'll need recent -mm kernel, and code from
suspend.sf.net. Due to its use of RSA, you'll only need to enter
password during resume.
[Code got some minimal review; if you are a crypto expert, and think
you can poke a hole within it, please try to do so.]
Pavel
--
205:class M4PStream
Pavel Machek wrote:
> Thanks to Rafael's great work, we now have working encrypted suspend
> and resume. You'll need recent -mm kernel, and code from
> suspend.sf.net. Due to its use of RSA, you'll only need to enter
> password during resume.
so, how does it work? what is new? how is it different from alternative?
with suspend2 and dm-crypt I have encrypted supend too:
- one boot partition (plain), one root partition
- root partition is on dm-crypt. initramfs has tools to set it up.
- swap file on root parition
- suspend to that swap file.
- initramfs could first ask for the passphrase to an rsa key,
the key decrypts a binary file, the decrypted binary is the
dm-crypt key.
- resume could be triggered once the new root was mounted and
in place.
- usb access etc. should work as well in the initramfs, so I
could move the rsa key to my smart card as well.
haveing something similar in mainline would be a huge help.
Andreas
On Mon, 2006-03-20 at 09:04 +0100, Pavel Machek wrote:
> Hi!
>
> Thanks to Rafael's great work, we now have working encrypted suspend
> and resume. You'll need recent -mm kernel, and code from
> suspend.sf.net. Due to its use of RSA, you'll only need to enter
> password during resume.
>
> [Code got some minimal review; if you are a crypto expert, and think
> you can poke a hole within it, please try to do so.]
> Pavel
Thats pretty interesting - we really need a featureful suspend
implementation
in mainline. But there doesn't seem to be much documentation for it.
suspend.sf.net takes me to the Suspend 2 site: http://www.suspend2.net (a
virtual
server?). Which code from this site is needed for the mainline suspend?
Peter
Hi!
> > Thanks to Rafael's great work, we now have working encrypted suspend
> > and resume. You'll need recent -mm kernel, and code from
> > suspend.sf.net. Due to its use of RSA, you'll only need to enter
> > password during resume.
> >
> > [Code got some minimal review; if you are a crypto expert, and think
> > you can poke a hole within it, please try to do so.]
> > Pavel
> Thats pretty interesting - we really need a featureful suspend
> implementation
> in mainline. But there doesn't seem to be much documentation for it.
> suspend.sf.net takes me to the Suspend 2 site: http://www.suspend2.net (a
> virtual
> server?). Which code from this site is needed for the mainline suspend?
suspend.sf.net works for me , can you check again?
Anyway, all the code that is needed is here:
cvs -z3 -d:pserver:[email protected]:/cvsroot/suspend co suspend
Installation is little tricky, but there's HOWTO file in repository.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
On Monday 20 March 2006 19:35, Peter Wainwright wrote:
> On Mon, 2006-03-20 at 09:04 +0100, Pavel Machek wrote:
> > Hi!
> >
> > Thanks to Rafael's great work, we now have working encrypted suspend
> > and resume. You'll need recent -mm kernel, and code from
> > suspend.sf.net. Due to its use of RSA, you'll only need to enter
> > password during resume.
> >
> > [Code got some minimal review; if you are a crypto expert, and think
> > you can poke a hole within it, please try to do so.]
> > Pavel
> Thats pretty interesting - we really need a featureful suspend
> implementation
> in mainline. But there doesn't seem to be much documentation for it.
> suspend.sf.net takes me to the Suspend 2 site: http://www.suspend2.net (a
> virtual
> server?). Which code from this site is needed for the mainline suspend?
cvs -z3 -d:pserver:[email protected]:/cvsroot/suspend co suspend
and please read the HOWTO. Unfortunately the RSA-related part hasn't been
documented yet, but it's pretty straightforward.
First, you need to generate the RSA key pair using suspend-keygen and save
the output file as /etc/suspend.key (or something else pointed to by
the "RSA key file =" configuration parameter of suspend). This file contains
the public modulus (n), public exponent (e) and Blowfish-encrypted private
exponent (d) of the RSA key pair.
Then, the suspend utility will load the contents of this file, generate a random
session key (k) and initialization vector (i) for the image encryption and use
(n, e) to encrypt these values with RSA. The encrypted k, i as well as the
contents of the RSA key file will be saved in the image header.
The resume utility will read n, e and (encrypted) d as well as (encrypted) k, i
from the image header. Then it will ask the user for a passphrase and will
try to decrypt d using it. Next, it will use (n, e, d) to decrypt k, i needed
for decrypting the image.
Greetings,
Rafael
Rafael J. Wysocki wrote:
> and please read the HOWTO. Unfortunately the RSA-related part hasn't been
> documented yet, but it's pretty straightforward.
Hello,
I don't understand why you are working so hard on this... If
you want encryption, you should care about all of your data!
And if you encrypt all your data, you automatically get a
suspend image encryption...
Please have a look at
http://wiki.suspend2.net/EncryptedSwapAndRoot
I use loop-aes in order to do the job... I know... I know...
You don't like suspend2... But it should be basically the
same with swsusp1/2/3/N.
Best Regards,
Alon Bar-Lev.
On Mon, 2006-03-20 at 19:44 +0100, Pavel Machek wrote:
> suspend.sf.net works for me , can you check again?
>
> Anyway, all the code that is needed is here:
>
> cvs -z3 -d:pserver:[email protected]:/cvsroot/suspend co suspend
>
> Installation is little tricky, but there's HOWTO file in repository.
>
> Pavel
You're right: my brain copied suspend.sf.net but my fingers did
swsusp.sf.net - force of habit; anyway, I've found your site
and pulled the CVS repository - will check it out.
Peter
Hi,
On Monday 20 March 2006 20:11, Alon Bar-Lev wrote:
> Rafael J. Wysocki wrote:
> > and please read the HOWTO. Unfortunately the RSA-related part hasn't been
> > documented yet, but it's pretty straightforward.
>
> Hello,
>
> I don't understand why you are working so hard on this... If
> you want encryption, you should care about all of your data!
I hope you realize there may be sensitive data in the suspend image
that are not stored in filesystems (eg. crypto keys, passwords etc.).
Greetings,
Rafael
On Po 20-03-06 21:26:23, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday 20 March 2006 20:11, Alon Bar-Lev wrote:
> > Rafael J. Wysocki wrote:
> > > and please read the HOWTO. Unfortunately the RSA-related part hasn't been
> > > documented yet, but it's pretty straightforward.
> >
> > Hello,
> >
> > I don't understand why you are working so hard on this... If
> > you want encryption, you should care about all of your data!
>
> I hope you realize there may be sensitive data in the suspend image
> that are not stored in filesystems (eg. crypto keys, passwords etc.).
If you have your swap partition on encrypted filesystem, that may
actually work okay.
OTOH uswsusp _destroys_ data after resume. Even if you are forced to
reveal your passphrase later, it should not be possible to recover
data from swsusp image.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
On Monday 20 March 2006 21:35, Pavel Machek wrote:
> On Po 20-03-06 21:26:23, Rafael J. Wysocki wrote:
> > On Monday 20 March 2006 20:11, Alon Bar-Lev wrote:
> > > Rafael J. Wysocki wrote:
> > > > and please read the HOWTO. Unfortunately the RSA-related part hasn't been
> > > > documented yet, but it's pretty straightforward.
> > >
> > > Hello,
> > >
> > > I don't understand why you are working so hard on this... If
> > > you want encryption, you should care about all of your data!
> >
> > I hope you realize there may be sensitive data in the suspend image
> > that are not stored in filesystems (eg. crypto keys, passwords etc.).
>
> If you have your swap partition on encrypted filesystem, that may
> actually work okay.
Yes, but that's why you may want to encrypt suspend images even if you
don't need to encrypt your filesystems. :-)
Rafael
On Po 20-03-06 22:22:13, Rafael J. Wysocki wrote:
> On Monday 20 March 2006 21:35, Pavel Machek wrote:
> > On Po 20-03-06 21:26:23, Rafael J. Wysocki wrote:
> > > On Monday 20 March 2006 20:11, Alon Bar-Lev wrote:
> > > > Rafael J. Wysocki wrote:
> > > > > and please read the HOWTO. Unfortunately the RSA-related part hasn't been
> > > > > documented yet, but it's pretty straightforward.
> > > >
> > > > Hello,
> > > >
> > > > I don't understand why you are working so hard on this... If
> > > > you want encryption, you should care about all of your data!
> > >
> > > I hope you realize there may be sensitive data in the suspend image
> > > that are not stored in filesystems (eg. crypto keys, passwords etc.).
> >
> > If you have your swap partition on encrypted filesystem, that may
> > actually work okay.
>
> Yes, but that's why you may want to encrypt suspend images even if you
> don't need to encrypt your filesystems. :-)
Of course, agreed. Encrypting filesystem is stupid thing from
data-recovery standpoint; and I care about my data; it is also hard to
backup. For some uses it is of course neccessary, but it has lots of
disadvantages, too.
Encrypted swsusp has basically no disadvantages.
[I believe we should encrypt swap with random key generated on boot by
default. That should be also very cheap, and has no real
disadvantages].
Pavel
--
Picture of sleeping (Linux) penguin wanted...
Pavel Machek wrote:
> Of course, agreed. Encrypting filesystem is stupid thing from
> data-recovery standpoint; and I care about my data; it is also hard to
> backup. For some uses it is of course neccessary, but it has lots of
> disadvantages, too.
Pavel, you keep doing the same basic mistake...
Understand your client!
Suspend is a feature that is most used by the mobile community.
Disk encryption is also common for most of this community.
Putting them to work together should be your interest...
Calling your clients stupid is not wise!
> Encrypted swsusp has basically no disadvantages.
>
> [I believe we should encrypt swap with random key generated on boot by
> default. That should be also very cheap, and has no real
> disadvantages].
Well... Good thinking... But how do you plan to encrypt the
swap? There are about 1000 ways to do this...
Jari Ruusu had written the loop-aes which was not merged...
>From a similar reason suspend2 was rejected by you.
I hope you don't think that file-system encryption should be
implemented in user mode too...
The dm-crypt is weak... So we left with specific encryption
implementation of swsusp... And now you offer a specific
encryption for swap as well... Why not realize that there
should be one encryption solution for block devices in kernel?
As a result of this mess the mobile community uses external
solutions.
Best Regards,
Alon Bar-Lev.
On ?t 21-03-06 00:05:27, Alon Bar-Lev wrote:
> Pavel Machek wrote:
> > Of course, agreed. Encrypting filesystem is stupid thing from
> > data-recovery standpoint; and I care about my data; it is also hard to
> > backup. For some uses it is of course neccessary, but it has lots of
> > disadvantages, too.
>
> Pavel, you keep doing the same basic mistake...
> Understand your client!
>
> Suspend is a feature that is most used by the mobile community.
> Disk encryption is also common for most of this community.
> Putting them to work together should be your interest...
> Calling your clients stupid is not wise!
Are you trying to flame me or is it that you can't understand english?
I never claimed my users are stupid. Read that sentence again.
> > Encrypted swsusp has basically no disadvantages.
> >
> > [I believe we should encrypt swap with random key generated on boot by
> > default. That should be also very cheap, and has no real
> > disadvantages].
>
> Well... Good thinking... But how do you plan to encrypt the
> swap? There are about 1000 ways to do this...
Yep, but one good enough way is ... well ... enough.
> Jari Ruusu had written the loop-aes which was not merged...
> >From a similar reason suspend2 was rejected by you.
suspend2 was never submitted in the first place.
> I hope you don't think that file-system encryption should be
> implemented in user mode too...
Don't put words into my mouths.
> The dm-crypt is weak... So we left with specific encryption
> implementation of swsusp... And now you offer a specific
> encryption for swap as well... Why not realize that there
> should be one encryption solution for block devices in kernel?
Why not working on that solution instead of flaming me? Last time I
seen, it was not quite easy to work with Jari.
Pavel
--
Picture of sleeping (Linux) penguin wanted...
On 2006-03-20, Alon Bar-Lev <[email protected]> wrote:
> Pavel Machek wrote:
> > Of course, agreed. Encrypting filesystem is stupid thing from
>> data-recovery standpoint; and I care about my data; it is also hard to
>> backup. For some uses it is of course neccessary, but it has lots of
>> disadvantages, too.
>
> Suspend is a feature that is most used by the mobile community.
> Disk encryption is also common for most of this community.
And it still is a PITA backup wise. There's nothing wrong with the stuff
Pavel said.
> Calling your clients stupid is not wise!
He hasn't done that.
>> [I believe we should encrypt swap with random key generated on boot by
>> default. That should be also very cheap, and has no real
>> disadvantages].
>
> Well... Good thinking... But how do you plan to encrypt the
> swap? There are about 1000 ways to do this...
* natively in the swap implementation (easier for end-users)
* distributions should do this through initramfs and dm-crypt (as long
as this is done by distributions it is still easy for end users)
> Jari Ruusu had written the loop-aes which was not merged...
> From a similar reason suspend2 was rejected by you.
>
> I hope you don't think that file-system encryption should be
> implemented in user mode too...
I don't think that you followed the discussion or understand the reasons
behind uswsusp. If there's a (performance-wise) sane way to put
encryption (only the data translation) into userspace without copying of
buffers and too many context switches why not? But this won't happen.
> The dm-crypt is weak...
If you mean the IV schemes: as I understand it, this was mostly done to
stay compatible to cryptoloop. You are free to submit a patch that adds
another mode to dm_crypt.
> So we left with specific encryption implementation of swsusp... And
> now you offer a specific encryption for swap as well... Why not
> realize that there should be one encryption solution for block devices
> in kernel?
As well as swsusp-encryption is concerned this should be _userspace_ and
they can reuse libopenssl or such.
> As a result of this mess the mobile community uses external solutions.
I'm quite happy with dm_crypt + pam_mount. Works transparent and like a
charm. Don't know what your requirements are.
> Best Regards, Alon Bar-Lev.
cheers,
andreas happe
--
"With the proper course of action made so explicit, we had merely to choose
between wisdom and folly. Precisely how we chose folly in this instance is
not entirely clear." someone on penny-arcade.com
Rafael J. Wysocki wrote:
> First, you need to generate the RSA key pair using suspend-keygen and save
> the output file as /etc/suspend.key (or something else pointed to by
> the "RSA key file =" configuration parameter of suspend). This file
> contains the public modulus (n), public exponent (e) and
> Blowfish-encrypted private exponent (d) of the RSA key pair.
>
> Then, the suspend utility will load the contents of this file, generate a
> random session key (k) and initialization vector (i) for the image
> encryption and use (n, e) to encrypt these values with RSA. The encrypted
> k, i as well as the contents of the RSA key file will be saved in the
> image header.
>
> The resume utility will read n, e and (encrypted) d as well as (encrypted)
> k, i from the image header. Then it will ask the user for a passphrase
> and will try to decrypt d using it. Next, it will use (n, e, d) to
> decrypt k, i needed for decrypting the image.
what interface will those tools use? can I replace them with my own
code, e.g. that uses smart cards instead of an encrypted public key
on a disk?
Andreas
On ?t 21-03-06 10:45:40, Andreas Jellinghaus wrote:
> Rafael J. Wysocki wrote:
> > First, you need to generate the RSA key pair using suspend-keygen and save
> > the output file as /etc/suspend.key (or something else pointed to by
> > the "RSA key file =" configuration parameter of suspend). ?This file
> > contains the public modulus (n), public exponent (e) and
> > Blowfish-encrypted private exponent (d) of the RSA key pair.
> >
> > Then, the suspend utility will load the contents of this file, ?generate a
> > random session key (k) and initialization vector (i) for the image
> > encryption and use (n, e) to encrypt these values with RSA. ?The encrypted
> > k, i as well as the contents of the RSA key file will be saved in the
> > image header.
> >
> > The resume utility will read n, e and (encrypted) d as well as (encrypted)
> > k, i from the image header. ?Then it will ask the user for a passphrase
> > and will try to decrypt d using it. ?Next, it will use (n, e, d) to
> > decrypt k, i needed for decrypting the image.
>
> what interface will those tools use? can I replace them with my own
> code, e.g. that uses smart cards instead of an encrypted public key
> on a disk?
It is userspace, so yes, you can use smart cards if you hack code at
suspend.sf.net a bit.
Pavel
--
Picture of sleeping (Linux) penguin wanted...