Hi! > >> Please explain your security goals. > > > > My security goals: > > > > - Encrypt and authicate hibernate snapshot image in kernel space. Userspace > > can only touch an encrypted and signed snapshot image. > > Signed? > > I’m not entirely convinced that the keyring mechanism is what you > want. ISTM that there are two goals here: > > a) Encryption: it should be as hard as can reasonably be arranged to > extract secrets from a hibernation image. > > b) Authentication part 1: it should not be possible for someone in > possession of a turned-off machine to tamper with the hibernation > image such that the image, when booted, will leak its secrets. This > should protect against attackers who don’t know the encryption key. > > c) Authentication part 2: it should be to verify, to the extent > practical, that the image came from the same machine and was really > created using hibernation. Or maybe by the same user.
So... this looks like "security goals" I was asking in the first
place. Thanks!
Could we get something like that (with your real goals?) in the next
version of the patch?
> As far as I can tell, there is only one reason that any of this needs
> to be in the kernel: if it’s all in user code, then we lose “lockdown”
> protection against compromised user code on a secure boot system. Is
> that, in fact, true?
And this is what I'd really like answer to. Because... I'd really like
this to be in userspace if it does not provide additional security
guarantees.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
