[ksk-change] Helping the panel name the reasons for the KSK rollover
Michael StJohns
msj at nthpermutation.com
Mon Feb 23 16:33:57 UTC 2015
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).
More information about the ksk-rollover
mailing list