On 2/23/2015 10:40 AM, Edward Lewis wrote:
HSM aging -- The hardware signing modules (HSMs) used for the root key
have a guaranteed life of five years, and that time has already passed. I think this is a misstatement. I don’t want to confuse the story further so I won’t offer corrective text but encourage someone more familiar with the lifetime of components (particularly the batteries).
This one is probably the most critical and the least understood of the reasons for doing a trust anchor update. The assumption you have to make is there is no way to move the private key from one HSM technology to another, and that there is no guarantee that the current HSM vendor will be in place to support their HSM for any given time. The reality may end up being different (e.g. there may actually be a way of extracting the private key from within the HSM policy boundary - which has its own issues, or the HSM vendor lives on for 20-30 years and is willing to support t), but we have to deal with the worst case scenarios. There are basically two sub issues for HSM aging: a) HSM support. This is basically what Paul wrote. Hardware has a finite lifetime. The HSM vendor guaranteed the current devices for 5 years and we're past that. Over the next 5 years we can expect failures in power supplies, chassis components and maybe even the core security processor. Failure of the former will require existence of replacement parts and service knowledge. Failure of the latter *MAY* result in the private key becoming unavailable. Redundancy is your friend here and having two of these is useful, but at some point we're going to have to migrate from the current generation of HSM to the next - either the same vendor or someone else - as support for the current devices becomes problematic. That migration is made simpler if we do not need to transfer the existing private key to the new technology. b) HSM vulnerability. The other problem with HSM aging is that security technology is always going to be an arms race. Breaking into a circa 2005 HSM design to extract the key is generally going to be easier in 2015. Moving to a new HSM designed to defeat new threats (e.g. various sensor and scanning technologies, fault injection, tamper detection defeats to prevent zeroization, etc) seems prudent every so often. Again, migration to new technology is simplified if we do not need to transfer the existing private key. So a new reason for trust anchor update: HSM key migration considered harmful. If you have to extradite a private key from one technology for injection in another - at some point the private key (encrypted or not) is vulnerable in the wild. There are ways to mitigate the vulnerabilities, but not to completely eliminate them. There are ways to generate a key pair and clone them safely (cryptographically safe, not just hardware safe) at the time of generation to multiple HSMs, but doing this after the fact requires updating the policy wrapping the signing key in a manner that could be attacked (e.g. you shouldn't be able to update the HSM code without wiping the keys).