[ksk-change] FIPS-140 levels

Bolivar, Al abolivar at verisign.com
Mon Oct 6 19:09:02 UTC 2014


Paul brought up a really good point. I don't think the current HSMs we use support ECC, the newer model, the Keyper plus does support ECCDSA/ECCDH. This model is FIPS 140-3 level 4.



> On Oct 6, 2014, at 10:39, Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>> On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo at gmail.com> wrote:
>> What I'm trying to say is the security controls in the key management
>> environment are redundant by design. It's not about choosing the
>> better one but actually having both controls in place for additional
>> security.
> Understood. If IANA wants to make to make the choice between "redundant security controls" and "significantly better cryptography with more vendor choices" towards the first, that's fine. I personally disagree with it, but having that discussion here seems to be in the spirit of why this list was started.
>> I'm sorry for repeating myself but this is to accomplish defense in
>> depth (layered security).
> Fully agree. However, there are other ways to have defense in depth other than relying on the systems inside the HSM that IANA did not design, and which IANA does not control. Joe Abley said the other day: "The root zone KSK security design depends upon physical security of the facility". That seems like a good, auditable design.
>> Below is what the HSM that is currently used by ICANN reacts to and
>> renders the cryptographic key useless by destroying the keys that
>> protect the KSK (IMK, ISMK, SMK).
>> - External (mains) voltage outside of specified fatal range
>> - External (mains) voltage outside of specified operational range
>> - Storage temperature outside of normal operating range
>> - Physical breach of tamper casing (mesh)
>> - Operational temperature outside of normal operating range
>> - External tamper switch triggered
>> - Power fluctuation
>> - Total power failure (both internal battery and mains power)
>> Below is some example if attacks it mitigates.
>> - Probe attacks (physical tampering will blow up the key)
>> - Side channel attacks (module attenuates readable signals)
>> - Electrical attacks (applying unusual voltage to cause error will
>> blow up the key)
>> - Fault attacks (whatever unusual input will blow the key)
> Yes, and none of those are of concern *in IANA's operating environment*, correct? If anyone has unauthorized physical access to the HSM, IANA will invalidate the key and use a new one, right? This is the crux of my point: if IANA has processes that are more stringent than those provided by Levels 2 through 4, then all you get from insisting on higher-than-Level-1 is restrictions on cryptography and restriction of choice of models.
> (As a side note: listing "side channel attacks" is particularly humorous in this setting, given the number of side channel attacks that have been listed for RSA signing in the past five years.)
>> This might sound weird but I'm not actually advocating for FIPS140
>> level 4 HSMs and I do like EC too.
> Those two do not make sense together in the current environment where we expect the CFRG to decide on new elliptic curve specifications in the coming months. No one would expect such cryptography to be available in a Level 4 HSM for many, many years. Look how little choice you have even for current ECDSA HSMs at Level 4.
>> I just think we shouldn't go down
>> to FIPS140 level 1 if we still decide to use HSMs to store and manage
>> the KSK. In addition, if we are to change the security level, we need
>> to come up with compensating controls or a good justification.
> Fully agree with that last bit. I was going along with what with Joe said the other day, which does not require redundant security in the HSM, only the standard crypto security that is tested in FIPS-140 Level 1. But if IANA wants to stick with a Level 4 requirement for redunancy, the tradeoffs are clear.
> --Paul Hoffman
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover

More information about the ksk-rollover mailing list