[ksk-change] Helping the panel name the reasons for the KSK rollover

[Michael StJohns]

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 the same class of HSM device), 
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).