On Tue, Mar 19, 2013 at 11:00:31PM +0000, James Bottomley wrote: > On Tue, 2013-03-19 at 18:50 +0000, Matthew Garrett wrote: > > Well, that somewhat complicates implementation - we'd be encrypting the > > entire contents of memory except for the key that we're using to encrypt > > memory. Keeping the public key away from userspace avoids having to care > > about that. > > I don't quite understand what you're getting at: the principle of public > key cryptography is that you can make the public key, well public. You > only need to guard the private key. Ok, so let's just rephrase it as asymmetric cryptography. The aim is to ensure that there's never a situation where userspace can decrypt a hibernation file, modify it and reencrypt it. So, shim (or whatever) generates a keypair. The encryption key is passed to the kernel being booted. The decryption key is stashed in a variable in order to be passed to the resume kernel. If the decryption key is available to userspace then the kernel needs to discard the encryption key during image write-out - otherwise the encryption key will be in the encrypted image. If the decryption key isn't available to userspace then this isn't a concern. If the decryption key *is* available to userspace (as it would be in your case), there's a requirement to discard the encryption key during the hibernation process. This isn't impossible, but it does add a little to the complexity. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
