3 ms·

I'm not an encryption guy so maybe this is a stupid question, but doesn't this mean you can't update the firmware without losing all your encrypted data?

by Pxtl 3y ago

loup-vaillant 3y ago
Yes, and no. If you lose the firmware entirely you would indeed lose the derived decryption keys. But if you keep the firmware somewhere safe (or even fetch it again from wherever you got it first), then loading it again would derive the same keys, and you can decrypt your stuff again. This makes reproducible builds very important by the way: if you rely on a source control system to hold on to old versions of the firmware (just in case someone needs it to decrypt old files), you really really want a way to re-generate the same binary blob from the same source code.
bluegate010 3y ago
Not a stupid question. CDIs are groovy for minting secrets that are bound to the exact firmware that's running, but are a bit less ergonomic out of the box when it comes to keeping long-lived secrets around across a firmware update. Firmware changes --> CDI changes --> anything derived from or sealed to the CDI is gone, by design. A more ergonomic approach for sealing long-lived data is to use something like a hash chain [0], where the chain starts with the equivalent of a DICE UDS, and the chain's length is (MAX_VERSION - fw.version). The end of that chain is given to firmware, and the firmware can lengthen the chain to derive older firmware's secrets, but cannot shorten it to derive newer firmware's secrets. This presumes that the firmware is signed of course, since otherwise there'd be no way to securely associate the firmware with a version number. If the public key is not baked into the HSM, then the hash of the public key should be used to permute the root of the hash chain. [0] https://en.wikipedia.org/wiki/Hash_chain https://en.wikipedia.org/wiki/Hash_chain
Hello71 3y ago
most systems for encrypting large amounts of data (e.g. a whole hard drive) don't use the user-derived key directly for encryption; the data is encrypted with a content encryption key (Microsoft) or master key (LUKS), which is then encrypted with the user-derived key and stored in the encryption header. this allows the user passphrase to be changed by reencrypting the CEK/MK rather than the whole drive.

I'm not an encryption guy so maybe this is a stupid question, but doesn't this mean you can't update the firmware without losing all your encrypted data?

by Pxtl 3y ago

I'm not an encryption guy so maybe this is a stupid question, but doesn't this mean you can't update the firmware without losing all your encrypted data?

loup-vaillant 3y ago

Yes, and no. If you lose the firmware entirely you would indeed lose the derived decryption keys. But if you keep the firmware somewhere safe (or even fetch it again from wherever you got it first), then loading it again would derive the same keys, and you can decrypt your stuff again. This makes reproducible builds very important by the way: if you rely on a source control system to hold on to old versions of the firmware (just in case someone needs it to decrypt old files), you really really want a way to re-generate the same binary blob from the same source code.

bluegate010 3y ago

Not a stupid question. CDIs are groovy for minting secrets that are bound to the exact firmware that's running, but are a bit less ergonomic out of the box when it comes to keeping long-lived secrets around across a firmware update. Firmware changes --> CDI changes --> anything derived from or sealed to the CDI is gone, by design. A more ergonomic approach for sealing long-lived data is to use something like a hash chain [0], where the chain starts with the equivalent of a DICE UDS, and the chain's length is (MAX_VERSION - fw.version). The end of that chain is given to firmware, and the firmware can lengthen the chain to derive older firmware's secrets, but cannot shorten it to derive newer firmware's secrets. This presumes that the firmware is signed of course, since otherwise there'd be no way to securely associate the firmware with a version number. If the public key is not baked into the HSM, then the hash of the public key should be used to permute the root of the hash chain. [0] https://en.wikipedia.org/wiki/Hash_chain https://en.wikipedia.org/wiki/Hash_chain

Hello71 3y ago

most systems for encrypting large amounts of data (e.g. a whole hard drive) don't use the user-derived key directly for encryption; the data is encrypted with a content encryption key (Microsoft) or master key (LUKS), which is then encrypted with the user-derived key and stored in the encryption header. this allows the user passphrase to be changed by reencrypting the CEK/MK rather than the whole drive.