Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:06:21PM +0200, Pavel Machek wrote: For the symmetric key solution, I will try HMAC (Hash Message Authentication Code). It's already used in networking, hope the performance is not too bad to a big image. Kernel already supports crc32 of the hibernation image, you may want to take a look how that is done. Maybe you want to replace crc32 with cryptographics hash (sha1?) and then use only hash for more crypto? That way speed of whatever crypto you do should not be an issue. Well, yes, one could skip the CRC when the signing is enabled to gain a little speedup. Actually... Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. First, there is no encryption going on. Only doing a HMAC (digest (hash) using a key) of the image. Second, since NVRAM is accessible through efivarsfs, storing the hash in NVRAM wouldn't prevent an attacker from modifying the hash to match a modified image. There is a reason why the key for the HMAC is stored in the NVRAM in a BootServices variable that isn't accessible from the OS and is write-protected on hardware level from the OS. And that may even be useful for non-secure-boot people, as it ensures you boot right image after resume, boot it just once, etc... The HMAC approach isn't much more complicated, and it gives you all these benefits even with secure boot disabled. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 02:21:23PM +0200, Michal Marek wrote: Is not it as simple as storing hash of hibernation image into NVRAM and then verifying the hash matches the value in NVRAM on next startup? No encryption needed. I think that part of the exercise is to minimize the number of writes to the NVRAM. The hash changes with every hibernation, obviously. The key should, too. -- Vojtech Pavlik Director SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Thu, Sep 26, 2013 at 04:48:00PM +0200, Jiri Kosina wrote:
The only two problems I see are
1. The key isn't generational (any compromise obtains it). This
can be fixed by using a set of keys generated on each boot and
passing in both K_{N-1} and K_N
I think this could be easily made optional, leaving the user with choice
of faster or safer boot.
Ideally, the key should be regenerated on each true reboot and kept the
same if it is just a resume. Unfortunately, I don't see a way to
distinguish those before we call ExitBootServices().
The reasoning behind that is that in the case of a kernel compromise, a
suspended-and-resumed kernel will still be compromised, so there is no
value in passing it a new key. A freshly booted kernel, though, should
get a new key, exactly because the attacker could have obtained a key
from the previous, compromised one.
This speeds up the ususal suspend-and-resume cycle, but provides full
security once the user performs a full reboot.
The question that remains is how to tell in advance.
2. No external agency other than the next kernel can do the
validation since the validating key has to be secret
This is true, but as you said, the relevance of this seems to be rather
questionable.
Indeed, it's hard to imagine a scenario that is also valid within the
secure boot threat model.
--
Vojtech Pavlik
Director SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
