[ksk-change] FIPS-140 levels

[Bolivar, Al]

+1.

Al

> On Oct 6, 2014, at 15:23, Tomofumi Okubo <tomofumi.okubo at gmail.com> wrote:
> 
> Hi Rick, that would be great.
> I can also talk to other vendors too if necessary.
> Cheers,
> Tomofumi
> 
> 
>> On Mon, Oct 6, 2014 at 12:17 PM, Richard Lamb <richard.lamb at icann.org> wrote:
>> FWIW: With enough warning I believe we can get AEP to work with us.
>> 
>> 
>> -----Original Message-----
>> From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org]
>> On Behalf Of Tomofumi Okubo
>> Sent: Monday, October 06, 2014 12:15 PM
>> To: Bolivar, Al
>> Cc: ksk-rollover at icann.org; Paul Hoffman
>> Subject: Re: [ksk-change] FIPS-140 levels
>> 
>> Hello Al,
>> 
>> Yes, I know that Keyper Pro does not support EC and Keyper Plus does
>> however, unfortunately, even if Keyper Plus does support EC, it might
>> not actually support the curves we want to use.
>> 
>> Cheers,
>> Tomofumi
>> 
>>> On Mon, Oct 6, 2014 at 12:09 PM, Bolivar, Al <abolivar at verisign.com> wrote:
>>> Tomofumi,
>>> 
>>> 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.
>>> 
>>> Thanks,
>>> 
>>> Al
>>> 
>>> 
>>>>> 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
>> _______________________________________________
>> ksk-rollover mailing list
>> ksk-rollover at icann.org
>> https://mm.icann.org/mailman/listinfo/ksk-rollover