[ksk-change] FIPS-140 levels

[Richard Lamb]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141006/2ba5480f/smime.p7s>