Re: mlock(1)

[Andy Lutomirski]

Valdis.Kletnieks@xxxxxx wrote:
> On Sat, 25 Sep 2004 04:58:48 +0200, Andrea Arcangeli said:
>
>
> > I don't even think "save their key securely" (I mean saving anything
> > related to the swapsuspend encryption key on disk) is needed. A mixture
> > of a on-disk key + passphrase would not be more secure than a simple
> > "passphrase" alone, because the on-disk key would be in cleartext and
> > readable from the attacker. the only usable key is the one in the user memory,
> > it cannot be saved in the computer anywhere. Peraphs for additional
> > security (and to avoid having to type and remember it) one could use an
> > usb pen to store and fetch the key... but then I leave the fun to the
> > usb folks since to do that usb should kick off before resume overwrites
> > the kernel image ;)
>
>
> Well, obviously saving the actual key on the disk is a losing idea, but saving
> "key hashed by passphrase" would work (similar to how PGP or SSH don't save the
> actual key, but rather the key hashed by something).
>
> I suspect that having the *entire* key be the passphrase remembered by the user
> is also a non-starter security-wise (unless we do something like Jari Ruusu's
> loop-AES stuff does and forces a minimim 20-char passphrase) - there's going to
> be all too many blocks in the swsusp area that are "known plaintext" and easily
> brute-forceable for most passphrases that users are likely to actually use.
>
> So in order to make it at all secure, we really need to save on the disk
> a key with O(128 bits) of entropy, perturbed by enough bits that are *not*
> to be found anywhere on the machine so that it isn't a slam-dunk for an attacker.
>
> Do any of the crypto experts lurking have ideas/opinions on just how many
> bits we need to store externally (be it in a USB dongle, a thumbprint, a
> passphrase, whatever)?

Not really a crypto expert, but...  use a random session key, at least 
128 bits.  Encrypt _that_ with the passphrase or whatever, eliminating 
any known plaintext.  Since this decryption is only done once at bootup, 
we don't care how slow it may be, so use an iterated scheme (like 
Blowfish crypt).  That way the user could dial it to take 500ms or so on 
the local machine to try a passphrase, making weak passphrases a lot 
harder to bruteforce.  Or the kernel should iteratively encrypt it at 
suspend for some fixed time, then store the iteration count.

So long as suspend/resume is supported, there's a risk that someone 
captures a suspended system and steals a disk image.  Later they force 
the owner to reveal the passphrase.  Now they can see not only the 
useful contents of memory but any old stuff that's been sitting in swap 
since the last reboot (like PGP keys).  This could be avoided by making 
the system somewhat forward-secret: generate a random key per vma and 
zero it out of RAM when the vma goes away (assuming the vma is the right 
unit for it).  If the IVs are chosen based on position in the swap 
device then there should be very little overhead.

--Andy
-
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/