[Cryptography] Is storing a hash of a private key a security risk?

Jerry Leichter leichter at lrw.com
Tue Apr 12 17:43:27 EDT 2016


> For private keys stored in a secure enclave in an embedded environment,
> there's some concern that over long periods of time the key components may be
> subject to bit rot/corruption.  One possible solution is to store a truncated
> hash of the private key components outside the enclave and use that to verify
> that nothing has changed, by asking the enclave whether the stored key
> corresponds to the given hash value.  Without going into a huge amount of
> detail on the specific application, it has to be a hash, it can't be a MAC or
> something similar, and the hash can't be stored inside the enclave because it
> only stores key components (it's a hardware constraint).
It's not clear to me what the assumptions are here.

Is the private key known outside the secure enclave?  If not, detecting the bit rot is all well and good but how do you recover?

How much cryptography does the secure enclave do?  If it implements a deterministic cryptographic algorithm - input is (key id, plaintext), output is cipher text (or the other way around) ... why do you need a separate hash function?  Compute and remember the encryption of a couple of set values; to test for bit rot, compute the same thing again and make sure you get the same values out.  This uses the secure enclave exactly as it was meant to be used, so can't possibly open any new vulnerabilities.

If the enclave is non-deterministic, it's a bit more complex - you would have to do a full round trip through a paired enclave containing the same key.

                                                        -- Jerry



More information about the cryptography mailing list