[ksk-change] Keeping two KSK keys long term
Greetings again. It is my impression that having two (or more) KSK keys long term makes 5011 rollovers a bit less problematic, but I could be misunderstanding some of the subtleties of 5011 when mixed with draft-ietf-dnsop-dnssec-key-timing. If it is better, I would propose that the timing of the KSK change be "add second and third key, wait a bit, remove current (first) key" over "add a second key, wait a bit, remove the current (first) key, wait a bit, add a new key (so we have two)". Thoughts? --Paul Hoffman
On 1 okt 2014, at 21:45, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
It is my impression that having two (or more) KSK keys long term makes 5011 rollovers a bit less problematic, but I could be misunderstanding some of the subtleties of 5011 when mixed with draft-ietf-dnsop-dnssec-key-timing.
Have two keys, and replacing one with another will keep the response sizes about the same over time (given that the key algorithm and size are the same), but other than that I haven't heard this. Perhaps Mike can clarify? jakob
On 10/1/2014 4:20 PM, Jakob Schlyter wrote:
On 1 okt 2014, at 21:45, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
It is my impression that having two (or more) KSK keys long term makes 5011 rollovers a bit less problematic, but I could be misunderstanding some of the subtleties of 5011 when mixed with draft-ietf-dnsop-dnssec-key-timing. Have two keys, and replacing one with another will keep the response sizes about the same over time (given that the key algorithm and size are the same), but other than that I haven't heard this.
Perhaps Mike can clarify?
The contents of the root DNSKEY RRSet do not have to include all the trust anchors. One of the things that struck me during the recent discussion is "why didn't they generate multiple trust anchor key pairs and provide that data during the initial bootstrap process (e.g. on the ICANN website) even if they only used one to sign"? A new trust anchor can be added simply by being present in the root DNSKEY RRSet (RDR!) signed by any existing trust anchor key for at least the Add Holddown time. Once present in the trust anchor key set, it need not be present in the RDR unless its actually being used to sign stuff. Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot. It's not that the presence of multiple keys makes rollover less problematic exactly, but that it makes recovery from emergency revocations due to compromise possible as well as automated scheduled routine key changes. Of course, this all depends on assumptions and operating procedures. For example, If its possible compromise both keys by breaking into the same box once, you obviously don't gain the protection. Mike
jakob
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 1 okt 2014, at 23:00, Michael StJohns <msj@nthpermutation.com> wrote:
Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot.
That only makes sense if you maintain and protect the keys separately, something that comes with a considerable cost. We did considering this when the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis did not justify such a scheme. jakob
On Oct 1, 2014, at 2:15 PM, Jakob Schlyter <jakob@kirei.se> wrote:
On 1 okt 2014, at 23:00, Michael StJohns <msj@nthpermutation.com> wrote:
Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot.
That only makes sense if you maintain and protect the keys separately, something that comes with a considerable cost. We did considering this when the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis did not justify such a scheme.
With all due respect, I'd like to see those numbers. The cost is approximately "have an extra HSM stored somewhere where the other HSMs are not". I'm not sure how expensive that can be relative to "fly a bunch of folks around twice a year for the ceremonies", much less relative to "if we needed it, we could show people we had planned for it". --Paul Hoffman
Hello, On Wed, Oct 1, 2014 at 3:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 2:15 PM, Jakob Schlyter <jakob@kirei.se> wrote:
With all due respect, I'd like to see those numbers. The cost is approximately "have an extra HSM stored somewhere where the other HSMs are not". I'm not sure how expensive that can be relative to "fly a bunch of folks around twice a year for the ceremonies", much less relative to "if we needed it, we could show people we had planned for it".
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities. Even if we don't store the HSMs for the backup keys at a different location, I think introducing a different brand of HSM for the backup key would have it's own benefits. We can prevent vendor lock-in and a single HSM brand failing (critical flaw in hardware etc...) and needing to do a full trust reboot. Not to mention, this will cost a lot of money (around 150k) too. Cheers, Tomofumi
On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
I propose that this additional key need a new key ceremony room; in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there. Rent a party bus for the participants so that they can watch the HSM the whole time. You can even have the HSM sign something at the new location to prove that it is the same key that was created at the first place. Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree? --Paul Hoffman
Paul, On Oct 1, 2014, at 4:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities. I propose that this additional key need a new key ceremony room;
I presume you meant to write “didn’t propose”
in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there.
It might be useful to describe the requirements for the “other location”. Gaining unauthorized access to that HSM would be “bad”, so we’re probably not talking about storing the HSM under somebody’s bed. It might not need the full controls used in the KSF, but presumably there would need to be non-trivial controls (as well as controls related to transfer).
Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree?
Having more than one key would be good. Having more than one vendor of HSM would be good. If we’re looking at using the initial key roll as a way of making changes to the way the root key(s) is(are) managed, it might be useful to enumerate the good things and bad things. Regards, -drc
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining unauthorized access to that HSM would be “bad”,
This is one of those misperceptions that's important to correct quickly. Gaining access to an HSM, _*along with its ignition keys*_ would be bad. Gaining access to the HSM by itself shouldn't be. The whole purpose of an HSM is to make generic access to the HSM non-bad. E.g. the key's locked inside and without the use credential you ain't going to get it to do anything. Attempts to extract a key will fail and ideally cause the HSM to zeroize.
so we’re probably not talking about storing the HSM under somebody’s bed. Actually, why not? If its a good HSM, then its a piece of iron without the credentials to enable it. The critical piece is to figure out how to prevent combination of the HSM with the unlocking credentials until policy says you should, and that's a different problem that keeping the HSM in a vault or under a bed.
E.g. steal my smart card (another HSM, albeit in a smaller form factor) and its of no use to you without the PIN. Later, Mike
Mike, On Oct 1, 2014, at 4:39 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining unauthorized access to that HSM would be “bad”, This is one of those misperceptions that's important to correct quickly.
Fair enough. Poor wording. Apologies.
Gaining access to an HSM, along with its ignition keys would be bad.
Yes. I’d assumed this was understood.
so we’re probably not talking about storing the HSM under somebody’s bed. Actually, why not?
Because it increases the risk of being able to gain full access since you only need to get the other half (the “unlocking credentials”). Regards, -drc
On 10/1/2014 7:44 PM, David Conrad wrote:
Mike,
On Oct 1, 2014, at 4:39 PM, Michael StJohns <msj@nthpermutation.com <mailto:msj@nthpermutation.com>> wrote:
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining unauthorized access to that HSM would be “bad”, This is one of those misperceptions that's important to correct quickly.
Fair enough. Poor wording. Apologies.
Gaining access to an HSM, _*along with its ignition keys*_ would be bad.
Yes. I’d assumed this was understood.
so we’re probably not talking about storing the HSM under somebody’s bed. Actually, why not?
Because it increases the risk of being able to gain full access since you only need to get the other half (the “unlocking credentials”).
AIRC the unlocking credentials for the HSM require something more than just a single smart card? You'd need to grab the HSM, plus enough of the unlocking credentials to enable the device. It's mostly just a numbers game. I'm going to follow up on Richard's note with a more comprehensive discussion.
Regards, -drc
Hello Mike, On Wed, Oct 1, 2014 at 4:39 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining access to an HSM, along with its ignition keys would be bad. Gaining access to the HSM by itself shouldn't be. The whole purpose of an HSM is to make generic access to the HSM non-bad. E.g. the key's locked inside and without the use credential you ain't going to get it to do anything. Attempts to extract a key will fail and ideally cause the HSM to zeroize.
I do agree that in general, gaining access to the HSM is not equivalent to gaining access to the key materials on the HSM if its without the credentials although, if the adversary's objective is to sabotage the operation, they can simply destroy the HSM (and key that resides on it) so I still believe that unauthorized access to the HSM is pretty bad (from a key management standpoint). Cheers, Tomofumi
Tomofumi, In the scenario you are talking about the adversary would gain access to both HSMs at one of the facilities right? Then you could still use the other two HSMs you have at the other facility, provided they didn¹t get access to the smart cards (credentials) as well. You could then import the KSK into new HSMs via the APP cards. Thanks, Al On 10/1/14, 9:22 PM, "Tomofumi Okubo" <tomofumi.okubo@gmail.com> wrote:
Hello Mike,
On Wed, Oct 1, 2014 at 4:39 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining access to an HSM, along with its ignition keys would be bad. Gaining access to the HSM by itself shouldn't be. The whole purpose of an HSM is to make generic access to the HSM non-bad. E.g. the key's locked inside and without the use credential you ain't going to get it to do anything. Attempts to extract a key will fail and ideally cause the HSM to zeroize.
I do agree that in general, gaining access to the HSM is not equivalent to gaining access to the key materials on the HSM if its without the credentials although, if the adversary's objective is to sabotage the operation, they can simply destroy the HSM (and key that resides on it) so I still believe that unauthorized access to the HSM is pretty bad (from a key management standpoint).
Cheers, Tomofumi _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 2 Oct 2014, at 13:13, Bolivar, Al <abolivar@verisign.com> wrote:
In the scenario you are talking about the adversary would gain access to both HSMs at one of the facilities right? Then you could still use the other two HSMs you have at the other facility, provided they didn¹t get access to the smart cards (credentials) as well. You could then import the KSK into new HSMs via the APP cards.
It's of course possible that someone could gain unauthorised access to the HSMs in one facility without getting access to the corresponding credentials. However, given that the details of where things are stored is surely well-known (it's documented and shown clearly in video that is made publicly available) it seems likely that any motivated attacker would not open the equipment safe and ignore the credentials safe which is sitting right next to it in the same cage. The root zone KSK security design depends upon physical security of the facility, not significant separation between the HSMs and the credentials needed to use them. (The PINs associated with each smart card are also not secret; they all use the same PIN which is disclosed in ceremony scripts and in public video). I'm not suggesting there's a flaw in the design here -- the decision to focus on physical security and associated controls and not to use secret PINs or credentials stored elsewhere was a measured, intentional one. Joe
On Oct 2, 2014, at 10:29 AM, Joe Abley <jabley@hopcount.ca> wrote:
The root zone KSK security design depends upon physical security of the facility, not significant separation between the HSMs and the credentials needed to use them. (The PINs associated with each smart card are also not secret; they all use the same PIN which is disclosed in ceremony scripts and in public video).
I'm not suggesting there's a flaw in the design here -- the decision to focus on physical security and associated controls and not to use secret PINs or credentials stored elsewhere was a measured, intentional one.
Thank you, this helps actually move this conversation forward. I was assuming that the root key protection design was based on the security properties of the HSM, not of the facility. Unless we want to change the basis of the original design, the question of whether we should have two KSK keys long terms then comes down to either of: 1) Is there an advantage to having two long-term KSKs in the same facilities that we have now? 2) Is there sufficient funding to having an additional facility (or two) for the additional KSK? --Paul Hoffman
Hello Paul,
On Thu, Oct 2, 2014 at 12:11 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
1) Is there an advantage to having two long-term KSKs in the same facilities that we have now?
Yes. I mentioned this before but the backup key could reside on different HSMs. This will prevent vendor lock-in and reduce the risk of all HSMs going bad at once for some reason (critical flaw etc...).
2) Is there sufficient funding to having an additional facility (or two) for the additional KSK?
I'm not sure about this one... Just FYI, to build a facility from scratch, it will take at least 6 - 8 months. To update the policies and procedures in a manner that it won't affect the third party audit, it will take at least another 6 months including the inspection by the auditors. Cheers! Tomofumi
Hello Al, If someone is able to sabotage your key management operation, you will have bigger issues before performing any cryptographic operations. It's a huge damage to the reputation/trust. I believe this is why you have very good protection and monitoring around your KMF. Also, I personally love HSMs but unfortunately, I cannot fully trust them when it comes to key management. If someone gets hold of the HSM we don't know if there is a flaw or backdoor that allows the adversary to extract the key. This is why we implement compensating controls to prevent it from happening. I'm paranoid to a point that I need to know where the key material resides and when they are used. But this is more from an information security practitioner's standpoint rather than an engineer. Cheers, Tomofumi
On Oct 2, 2014, at 10:13, "Bolivar, Al" <abolivar@verisign.com> wrote:
Tomofumi,
In the scenario you are talking about the adversary would gain access to both HSMs at one of the facilities right? Then you could still use the other two HSMs you have at the other facility, provided they didn¹t get access to the smart cards (credentials) as well. You could then import the KSK into new HSMs via the APP cards.
Thanks,
Al
On 10/1/14, 9:22 PM, "Tomofumi Okubo" <tomofumi.okubo@gmail.com> wrote:
Hello Mike,
On Wed, Oct 1, 2014 at 4:39 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/1/2014 7:26 PM, David Conrad wrote:
Gaining access to an HSM, along with its ignition keys would be bad. Gaining access to the HSM by itself shouldn't be. The whole purpose of an HSM is to make generic access to the HSM non-bad. E.g. the key's locked inside and without the use credential you ain't going to get it to do anything. Attempts to extract a key will fail and ideally cause the HSM to zeroize.
I do agree that in general, gaining access to the HSM is not equivalent to gaining access to the key materials on the HSM if its without the credentials although, if the adversary's objective is to sabotage the operation, they can simply destroy the HSM (and key that resides on it) so I still believe that unauthorized access to the HSM is pretty bad (from a key management standpoint).
Cheers, Tomofumi _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Security level/controls for all key material must be equal or better. That's why we don't have a second backup key since the storage of the additional key would incur the high costs of ensuring it to was equally secured in a separate facility (5-6 tiers etc...). But of course I am just parroting what I learned from the experts on the cc line. If the community says they don't care, well..... -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of David Conrad Sent: Wednesday, October 01, 2014 4:26 PM To: Paul Hoffman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term Paul, On Oct 1, 2014, at 4:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities. I propose that this additional key need a new key ceremony room;
I presume you meant to write "didn't propose"
in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there.
It might be useful to describe the requirements for the "other location". Gaining unauthorized access to that HSM would be "bad", so we're probably not talking about storing the HSM under somebody's bed. It might not need the full controls used in the KSF, but presumably there would need to be non-trivial controls (as well as controls related to transfer).
Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree?
Having more than one key would be good. Having more than one vendor of HSM would be good. If we're looking at using the initial key roll as a way of making changes to the way the root key(s) is(are) managed, it might be useful to enumerate the good things and bad things. Regards, -drc
On 10/1/2014 11:49 PM, Richard Lamb wrote:
Security level/controls for all key material must be equal or better. That's why we don't have a second backup key since the storage of the additional key would incur the high costs of ensuring it to was equally secured in a separate facility (5-6 tiers etc...). But of course I am just parroting what I learned from the experts on the cc line. If the community says they don't care, well.....
-Rick
Hi Rick - This one is going to be long winded and slightly pedantic - details are important. It's a general follow up to your email and to the others on this thread. "Security level/controls for all key material must be equal or better." As stated, this has a number of issues. I'm going to restate this in a slightly different way: "Cryptographic material (keys, hardware security modules, crypto ignition keys, backup material) must be protected in a manner to provide at least the minimum desired level of assurance for the system. This does not mean that all cryptographic material must be protected equally, but that, taken as a whole, the protections applied to each component enable at least that minimum level of assurance for the system as a whole." There are two items of assurance that you have to address, and each has its own set of concerns: 1) Sufficient cryptographic material has to be available to complete a desired cryptographic operation when necessary; (e.g. assurance against loss); 2) Sufficient protections need to be in place to prevent the completion of the cryptographic operation unless the policy requirements are met (assurance against compromise - includes both using the HSM out of policy, and extracting key material from within any policy wrapper). (1) is generally addressed through redundancy and backups. You provide sufficient copies of the material to reduce the chance of a complete loss of the material is less than your assurance threshold. That can be done through split key (threshold) paper systems, smart cards, backup HSMs etc. The hard part with (1) is preventing (1) from causing issues with (2). But that's not actually hard if you look at the math rather than the hardware. There used to be a device called a STU III - secure telephone unit. It was certified to encrypt voice up to the US Top Secret level. The interesting thing about the device was that it was unclassified when separated from its crypto ignition key. The STU III and the CIK each had part of the key material necessary to enable secure communications and policy required nothing more than the operator carry the CIK with him when the STU III wasn't in use to make both pieces unclassified. (This by the way drove the crypto custodians bonkers as this was *something new*). The point is that if its impossible to get enough of the parts of the private key together without someone finding out about it, then the protections on each share of the key do not need to be at the same level as the key when its assembled. Using more of the math based approaches (in addition to hardware based approaches) for key protection should be considered the next go round. (2) Is slightly more interesting. One of the discussion points on an earlier thread was the issue of getting N people to show up every so often to do a key ceremony. Looking at this, I understand this is good theater, but maybe not a sustainable operational model. How about instead: 1. Each partial signer has a smart card (miniHSM?) with a specific key pair where the public key is known to the HSM. 2. ICANN publishes (a week before the due date) a draft "object to be signed" - basically the new DNSKEY RRSet with all the right times and keys. 3. Each partial signer "signs" the object to be signed using its own key pair and publishes the result to a publicly available webpage. 4. ICANN, on the date of the signing ceremony: * Verifies each signature from (3) external to the HSM and * randomly selects K (where K is the minimum necessary signers) step (3) signed objects * Feeds the step (3) signed objects into the HSM where each is independently verified * When the HSM verifies K signed objects, it produces its own signature over the "object to be signed" and emits it. 5. ICANN publishes the new signed DNSKEY RRSet. This requires a change to the policy engine of the HSM obviously (e.g. PKCS11 isn't sufficient), but means that you can securely sign the root with remote actions in a publicly verifiable manner. It also means that you can increase the number of possible partial signers (with the resultant broader community participation) with minimal cost. Note that you still need some sort of ceremony to generate new keys. An even more comprehensive change would be something like "Practical Threshold Signatures, Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99" where there is no central HSM, but where the partial signatures are done remotely and then assembled into a full signature by anyone who wanted to do so. I built DNSSEC signing code for this that works quite nicely That paper applies to RSA, but there are similar (not equivalent) schemes for EC. There are a number of ways to enhance this using cryptographic techniques combined with hardware policy enforcement to minimize the chance of even one of the remote private keys being compromised (e.g. 2of2 or 2of3 secret sharing of the partial signer's private key with reassembly only for signing). I said earlier that it's a numbers game and if - mathematically - you need N pieces to do the crypto operation, preventing an attacker from getting N-1 is a win. If there are K total elements, then you also need to ensure that no more than K-N elements are irrevocably lost. Going back to the original comment that not all cryptographic material requires the same level of protection. Consider a two key trust anchor set for the root. One key is used fairly regularly, the second is the back up. 3 parts of the backup key pair resides in a PCIe HSM card locked in a safe deposit box near the ICANN facility, three parts on a second PCIe HSM at the back up facility, part of the key pair is on a smart card in Paris, part on a smart card in London and part on a smart card in ??. Also, none of those smart cards actually give you credentials to enable the HSM - those are held by other people. The backup system requires a 4 of 6 key recovery (an HSM plus one smart card). The cost for the PCIe HSMs is ~$5k, but even if they're stolen they're useless without one of the 3 smart cards, and without the operational credentials for the HSM. The smart cards on the other hand are mathematically useless without the data in the HSM. The cost for doing the separation of operational key from backup key becomes the cost of two safe deposit boxes, 2 PCIe HSMs and 3 smart cards being carried around in wallets. (Or maybe 6 - the 4 of 6 for HSM A may not be the same split of 4 of 6 keys for HSM B). Mike
Mike- Thank you very much for this. As clearly one of those experts, I appreciate the time (and patience) you have taken in an attempt to educate me. I will need read through this a few times more to get the full effect but I think I get the overall logic and agree. For some things the devil IS in the details and cannot be explained in a one-liner. I particularly like the scheme described in (2). As we all know no system is perfect and it was with this in mind that we made sure that the system we use now for root ksk management was not cast in stone. We have thought about many improvements and implemented some minor ones suggested by the TCRs but an in depth view like yours is, well, refreshing. Thank you, -Rick From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Michael StJohns Sent: Thursday, October 02, 2014 9:49 AM To: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term On 10/1/2014 11:49 PM, Richard Lamb wrote: Security level/controls for all key material must be equal or better. That's why we don't have a second backup key since the storage of the additional key would incur the high costs of ensuring it to was equally secured in a separate facility (5-6 tiers etc...). But of course I am just parroting what I learned from the experts on the cc line. If the community says they don't care, well..... -Rick Hi Rick - This one is going to be long winded and slightly pedantic - details are important. It's a general follow up to your email and to the others on this thread. "Security level/controls for all key material must be equal or better." As stated, this has a number of issues. I'm going to restate this in a slightly different way: "Cryptographic material (keys, hardware security modules, crypto ignition keys, backup material) must be protected in a manner to provide at least the minimum desired level of assurance for the system. This does not mean that all cryptographic material must be protected equally, but that, taken as a whole, the protections applied to each component enable at least that minimum level of assurance for the system as a whole." There are two items of assurance that you have to address, and each has its own set of concerns: 1) Sufficient cryptographic material has to be available to complete a desired cryptographic operation when necessary; (e.g. assurance against loss); 2) Sufficient protections need to be in place to prevent the completion of the cryptographic operation unless the policy requirements are met (assurance against compromise - includes both using the HSM out of policy, and extracting key material from within any policy wrapper). (1) is generally addressed through redundancy and backups. You provide sufficient copies of the material to reduce the chance of a complete loss of the material is less than your assurance threshold. That can be done through split key (threshold) paper systems, smart cards, backup HSMs etc. The hard part with (1) is preventing (1) from causing issues with (2). But that's not actually hard if you look at the math rather than the hardware. There used to be a device called a STU III - secure telephone unit. It was certified to encrypt voice up to the US Top Secret level. The interesting thing about the device was that it was unclassified when separated from its crypto ignition key. The STU III and the CIK each had part of the key material necessary to enable secure communications and policy required nothing more than the operator carry the CIK with him when the STU III wasn't in use to make both pieces unclassified. (This by the way drove the crypto custodians bonkers as this was *something new*). The point is that if its impossible to get enough of the parts of the private key together without someone finding out about it, then the protections on each share of the key do not need to be at the same level as the key when its assembled. Using more of the math based approaches (in addition to hardware based approaches) for key protection should be considered the next go round. (2) Is slightly more interesting. One of the discussion points on an earlier thread was the issue of getting N people to show up every so often to do a key ceremony. Looking at this, I understand this is good theater, but maybe not a sustainable operational model. How about instead: 1. Each partial signer has a smart card (miniHSM?) with a specific key pair where the public key is known to the HSM. 2. ICANN publishes (a week before the due date) a draft "object to be signed" - basically the new DNSKEY RRSet with all the right times and keys. 3. Each partial signer "signs" the object to be signed using its own key pair and publishes the result to a publicly available webpage. 4. ICANN, on the date of the signing ceremony: * Verifies each signature from (3) external to the HSM and * randomly selects K (where K is the minimum necessary signers) step (3) signed objects * Feeds the step (3) signed objects into the HSM where each is independently verified * When the HSM verifies K signed objects, it produces its own signature over the "object to be signed" and emits it. 5. ICANN publishes the new signed DNSKEY RRSet. This requires a change to the policy engine of the HSM obviously (e.g. PKCS11 isn't sufficient), but means that you can securely sign the root with remote actions in a publicly verifiable manner. It also means that you can increase the number of possible partial signers (with the resultant broader community participation) with minimal cost. Note that you still need some sort of ceremony to generate new keys. An even more comprehensive change would be something like "Practical Threshold Signatures, Victor Shoup (sho@zurich.ibm.com), IBM Research Paper RZ3121, 4/30/99" where there is no central HSM, but where the partial signatures are done remotely and then assembled into a full signature by anyone who wanted to do so. I built DNSSEC signing code for this that works quite nicely That paper applies to RSA, but there are similar (not equivalent) schemes for EC. There are a number of ways to enhance this using cryptographic techniques combined with hardware policy enforcement to minimize the chance of even one of the remote private keys being compromised (e.g. 2of2 or 2of3 secret sharing of the partial signer's private key with reassembly only for signing). I said earlier that it's a numbers game and if - mathematically - you need N pieces to do the crypto operation, preventing an attacker from getting N-1 is a win. If there are K total elements, then you also need to ensure that no more than K-N elements are irrevocably lost. Going back to the original comment that not all cryptographic material requires the same level of protection. Consider a two key trust anchor set for the root. One key is used fairly regularly, the second is the back up. 3 parts of the backup key pair resides in a PCIe HSM card locked in a safe deposit box near the ICANN facility, three parts on a second PCIe HSM at the back up facility, part of the key pair is on a smart card in Paris, part on a smart card in London and part on a smart card in ??. Also, none of those smart cards actually give you credentials to enable the HSM - those are held by other people. The backup system requires a 4 of 6 key recovery (an HSM plus one smart card). The cost for the PCIe HSMs is ~$5k, but even if they're stolen they're useless without one of the 3 smart cards, and without the operational credentials for the HSM. The smart cards on the other hand are mathematically useless without the data in the HSM. The cost for doing the separation of operational key from backup key becomes the cost of two safe deposit boxes, 2 PCIe HSMs and 3 smart cards being carried around in wallets. (Or maybe 6 - the 4 of 6 for HSM A may not be the same split of 4 of 6 keys for HSM B). Mike
Hi Paul, I do like the idea of having a backup key but I'm still not convinced that the backup key requires a separate key ceremony room. The entire site getting physically compromised is not the only scenario and I don't think it has the highest probability. Instead, most likely, the issue would be a flaw in the HSM or a flaw in the algorithm or an insufficient key strength. An alternate site is not required to mitigate these risks. You just need a backup key with different specs on different HSMs. I believe these are more important before adding an alternate site. Cheers, Tomofumi On Wed, Oct 1, 2014 at 4:03 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
I propose that this additional key need a new key ceremony room; in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there. Rent a party bus for the participants so that they can watch the HSM the whole time. You can even have the HSM sign something at the new location to prove that it is the same key that was created at the first place.
Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree?
--Paul Hoffman
I agree based on the principles behind the original ksk management design (equal security for all). But happy to entertain other approaches if the community is willing to sign off on the risks. -R -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Wednesday, October 01, 2014 4:04 PM To: Tomofumi Okubo Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
I propose that this additional key need a new key ceremony room; in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there. Rent a party bus for the participants so that they can watch the HSM the whole time. You can even have the HSM sign something at the new location to prove that it is the same key that was created at the first place. Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree? --Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
+1 Cheers! Tomofumi
On Oct 1, 2014, at 8:53 PM, Richard Lamb <richard.lamb@icann.org> wrote:
I agree based on the principles behind the original ksk management design (equal security for all). But happy to entertain other approaches if the community is willing to sign off on the risks. -R
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Wednesday, October 01, 2014 4:04 PM To: Tomofumi Okubo Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term
On Oct 1, 2014, at 3:48 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
I propose that this additional key need a new key ceremony room; in fact, that idea hadn't even occurred to me. Create the key in one of the current rooms, then drive the HSM to some other location and plant it there. Rent a party bus for the participants so that they can watch the HSM the whole time. You can even have the HSM sign something at the new location to prove that it is the same key that was created at the first place.
Again, I'm only proposing this because my reading of 5011 makes it seem like having a second active KSK would be better if one of the KSKs is accidentally or purposely made unusable. Mike seems to agree with this; do others disagree?
--Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
If the chain of custody of this emergency spare HSM was broken - e.g., the HSM was stolen or compromised in a different way - ICANN would be very bad position. As security engineers, we believe/know/hope that the HSM is supposed to be unusable without activation keys and we have 3rd parties (like NIST) that certifies this. However, this is not enough in the eyes of the community, and this why we have the key management facilities. If everyone actually trusted the HSMs fully, we would not need all that and HSM could sit on a shelf at the IANA offices. jakob
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive. Thanks, Al On 10/1/14, 6:48 PM, "Tomofumi Okubo" <tomofumi.okubo@gmail.com> wrote:
Hello,
On Wed, Oct 1, 2014 at 3:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 2:15 PM, Jakob Schlyter <jakob@kirei.se> wrote:
With all due respect, I'd like to see those numbers. The cost is approximately "have an extra HSM stored somewhere where the other HSMs are not". I'm not sure how expensive that can be relative to "fly a bunch of folks around twice a year for the ceremonies", much less relative to "if we needed it, we could show people we had planned for it".
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
Even if we don't store the HSMs for the backup keys at a different location, I think introducing a different brand of HSM for the backup key would have it's own benefits. We can prevent vendor lock-in and a single HSM brand failing (critical flaw in hardware etc...) and needing to do a full trust reboot. Not to mention, this will cost a lot of money (around 150k) too.
Cheers, Tomofumi _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 10/2/2014 1:42 PM, Bolivar, Al wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
Thanks,
Al
One of my pet peeves with the HSM vendors is that none of them provide more than rudimentary policy controls on the use of keys. I keep waiting for someone to make an HSM that implements either the Javacard Connected standards or something similar so I can define a programmatic policy wrapper more comprehensive than "I need a PIN to use it" "I need two PINs to use it" "I need a smart card to use it" etc. I can do this on a smart card, why is it so hard to do it on a big iron HSM? Mike
Hi Mike, I fully agree. It would be very nice to have that flexibility. There was an HSM (I believe IBM?) that has a programable portion that is outside the cryptographic boundary but we wanted one that has the authentication function within the cryptographic boundary of the HSM. It would be nice to have an HSM that gives us more options and still have the authentication function within the cryptographic boundary of the HSM. Cheers! Tomofumi On Thu, Oct 2, 2014 at 11:06 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 10/2/2014 1:42 PM, Bolivar, Al wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
Thanks,
Al
One of my pet peeves with the HSM vendors is that none of them provide more than rudimentary policy controls on the use of keys. I keep waiting for someone to make an HSM that implements either the Javacard Connected standards or something similar so I can define a programmatic policy wrapper more comprehensive than "I need a PIN to use it" "I need two PINs to use it" "I need a smart card to use it" etc. I can do this on a smart card, why is it so hard to do it on a big iron HSM?
Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Mike, SafeNet is working with IBM to come up with a FIPS 140 level 4 HSM. I don't know what the current state of development is but do you think it's worth asking them if they could incorporate a trusted path authentication that has a bit more flexibility? The worst thing that could happen is they say no. Thanks, Al On 10/2/14, 2:06 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
On 10/2/2014 1:42 PM, Bolivar, Al wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
Thanks,
Al
One of my pet peeves with the HSM vendors is that none of them provide more than rudimentary policy controls on the use of keys. I keep waiting for someone to make an HSM that implements either the Javacard Connected standards or something similar so I can define a programmatic policy wrapper more comprehensive than "I need a PIN to use it" "I need two PINs to use it" "I need a smart card to use it" etc. I can do this on a smart card, why is it so hard to do it on a big iron HSM?
Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 10/2/2014 4:01 PM, Bolivar, Al wrote:
Mike,
SafeNet is working with IBM to come up with a FIPS 140 level 4 HSM. I don't know what the current state of development is but do you think it's worth asking them if they could incorporate a trusted path authentication that has a bit more flexibility? (Just for clarification are you talking FIP 140-2 level 4 or something in the "maybe soon to be published FIPS 140-4" standard?)
The idea of a more flexible authentication system is a good start. But what I'm really thinking needs to happen is a system that supports expressing policy more like: * A CA key that will only sign properly formatted X.509 certificates and ensures that the signed certificate has a unique serial number and has appropriate validity info, and infrastructure extensions (e.g. SKI extension, AKI extension, appropriate policy bits) - things that are normally enforced outside the HSM boundary these days. * A wrapping key that can wrap and unwrap AES Key Wrap mode material where the material has its own set of attached policy bits (e.g. a secret key which can only be used for KDFs) and protect that unwrapped key appropriately. * A signing key that will only sign a properly formatted DNSKEY RRSet and only if it sees that N other known keys have signed it. * A system that ensures the data that the remote signers agreed could be signed is actually the data signed. * A more comprehensive set of threshold key systems (e.g. Shamir's plus others) both for partial signatures and for information retrieval/escrow (think of taking Shoup's scheme that I mentioned and publish the public key - data could be encrypted using that key, but N of K private key holders would need to come together to retrieve that encrypted data -think further about that with respect to backup key generation) I mentioned Javacard Connected as there's a lot of experience with similar things in smart cards. I can't quite figure out why I can't buy an HSM that does what a smart card can be programmed to do. Mike
The worst thing that could happen is they say no.
Thanks,
Al
On 10/2/14, 2:06 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
On 10/2/2014 1:42 PM, Bolivar, Al wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
Thanks,
Al One of my pet peeves with the HSM vendors is that none of them provide more than rudimentary policy controls on the use of keys. I keep waiting for someone to make an HSM that implements either the Javacard Connected standards or something similar so I can define a programmatic policy wrapper more comprehensive than "I need a PIN to use it" "I need two PINs to use it" "I need a smart card to use it" etc. I can do this on a smart card, why is it so hard to do it on a big iron HSM?
Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Mike, I don't have an answer to your question, but I can certainly find out from the vendor. I will share that when I get the answer. Have a good weekend. Al On Oct 3, 2014, at 12:11, Michael StJohns <msj@nthpermutation.com<mailto:msj@nthpermutation.com>> wrote: On 10/2/2014 4:01 PM, Bolivar, Al wrote: Mike, SafeNet is working with IBM to come up with a FIPS 140 level 4 HSM. I don't know what the current state of development is but do you think it's worth asking them if they could incorporate a trusted path authentication that has a bit more flexibility? (Just for clarification are you talking FIP 140-2 level 4 or something in the "maybe soon to be published FIPS 140-4" standard?) The idea of a more flexible authentication system is a good start. But what I'm really thinking needs to happen is a system that supports expressing policy more like: * A CA key that will only sign properly formatted X.509 certificates and ensures that the signed certificate has a unique serial number and has appropriate validity info, and infrastructure extensions (e.g. SKI extension, AKI extension, appropriate policy bits) - things that are normally enforced outside the HSM boundary these days. * A wrapping key that can wrap and unwrap AES Key Wrap mode material where the material has its own set of attached policy bits (e.g. a secret key which can only be used for KDFs) and protect that unwrapped key appropriately. * A signing key that will only sign a properly formatted DNSKEY RRSet and only if it sees that N other known keys have signed it. * A system that ensures the data that the remote signers agreed could be signed is actually the data signed. * A more comprehensive set of threshold key systems (e.g. Shamir's plus others) both for partial signatures and for information retrieval/escrow (think of taking Shoup's scheme that I mentioned and publish the public key - data could be encrypted using that key, but N of K private key holders would need to come together to retrieve that encrypted data -think further about that with respect to backup key generation) I mentioned Javacard Connected as there's a lot of experience with similar things in smart cards. I can't quite figure out why I can't buy an HSM that does what a smart card can be programmed to do. Mike The worst thing that could happen is they say no. Thanks, Al On 10/2/14, 2:06 PM, "Michael StJohns" <msj@nthpermutation.com><mailto:msj@nthpermutation.com> wrote: On 10/2/2014 1:42 PM, Bolivar, Al wrote: I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive. Thanks, Al One of my pet peeves with the HSM vendors is that none of them provide more than rudimentary policy controls on the use of keys. I keep waiting for someone to make an HSM that implements either the Javacard Connected standards or something similar so I can define a programmatic policy wrapper more comprehensive than "I need a PIN to use it" "I need two PINs to use it" "I need a smart card to use it" etc. I can do this on a smart card, why is it so hard to do it on a big iron HSM? Mike _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org<mailto:ksk-rollover@icann.org> https://mm.icann.org/mailman/listinfo/ksk-rollover
FWIW: +1. We did look high and low for additional level 4 vendors (I did various evals in 2008) but at the time there was nothing other than AEP and IBM and safenet main engineer said unlikely. IBM PCI card tampered too easily and stand alone was of interest. So would love to see some HSM diversity here. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Bolivar, Al Sent: Thursday, October 02, 2014 10:43 AM To: Tomofumi Okubo; Paul Hoffman Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive. Thanks, Al On 10/1/14, 6:48 PM, "Tomofumi Okubo" <tomofumi.okubo@gmail.com> wrote:
Hello,
On Wed, Oct 1, 2014 at 3:09 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 1, 2014, at 2:15 PM, Jakob Schlyter <jakob@kirei.se> wrote:
With all due respect, I'd like to see those numbers. The cost is approximately "have an extra HSM stored somewhere where the other HSMs are not". I'm not sure how expensive that can be relative to "fly a bunch of folks around twice a year for the ceremonies", much less relative to "if we needed it, we could show people we had planned for it".
It will roughly cost around 500k to set up one key ceremony room but it's more about the overhead to manage the facilities.
Even if we don't store the HSMs for the backup keys at a different location, I think introducing a different brand of HSM for the backup key would have it's own benefits. We can prevent vendor lock-in and a single HSM brand failing (critical flaw in hardware etc...) and needing to do a full trust reboot. Not to mention, this will cost a lot of money (around 150k) too.
Cheers, Tomofumi _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Oct 2, 2014, at 10:42 AM, Bolivar, Al <abolivar@verisign.com> wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
As I understand it, the requirement for the FIPS 140-2 level 4 certification for HSMs in the current setup came from the US government. Under the assumption that the US government will not be putting requirements on future changes to the DNSSEC root keying, this is a good time to look at what the community wants. The current setup has the HSM wrapped in a tamper-evident bag, in a safe, between uses, and that the uses are all viewed by lots of people and recorded on cameras. Given that, I see no advantages to FIPS-140 levels above 1. By using these processes, the DNS root key community has our own tamper evidence, our own tamper resistance, and our own access control mechanisms. There are serious disadvantages to requiring level 4 (or even level 2 or 3) for HSMs: there are fewer vendors, and fewer models from vendors. This is going to bite us hard if we decide to start using signature algorithms other than RSA, such as elliptic curves (which are tremendously safer to use than RSA for the levels of assurance we want for the DNS root). Even if there are vendors who have FIPS-140 level 4 HSMs for ECDSA using P256, the IETF is probably going to standardize different curve forms with different parameters in the next six months. These will come out of the TLS WG first, but the signature algorithms will probably be everywhere within a year. There will be lots of publicity for the advantages of these curves over RSA and over P256. If the DNSSEC root stays with less-safe RSA, or switches to EC P256 which has already been shown to have operational problems, because of the requirement to wait for FIPS-140 level 4 HSMs, we could lose a fair amount of the credibility that we have garnered so far. If folks here can show that FIPS-140 level 2, 3, or 4 are valuable *in our already-existing usage environment* (our own tamper evidence, our own tamper resistance, our own administration controls), I'm all ears. If no one can, we should start talking about FIPS-140 level 1 or better for future HSMs as a way to give us more choices of vendors, models, and particularly signing algorithms. --Paul Hoffman
Paul- Thank you for lending your experience and voice of reason. I agree that from the perspective of our little community (which includes me) that fips 140 level 4 is a bit overkill. However, in architecting this system the target was a much broader audience with the idea that things like DANE and other key-in-dns technologies may someday bootstrap themselves from the DNS. Specifically I was thinking of the financial community and how to get their buy in. This is what brings in the AICPA/CICA and the SysTrust audit we pass every year. Again not because there is anything special about this process (although I do believe it does help keep ICANN at attention), but instead as a necessity to get the buy in from the "suits" of the world as without their trust*, I think we only have an expensive experiment. But I am open to discussion and have heard many different suggestions, some very clever, on how to better manage the root KSK to both simplify and build trust from certain communities - but do not necessarily fit what auditors might consider best common practice. Happy to make happen whatever everyone decides and even have someone change my mind that we need to make the accountants and lawyers of the world happy to make DNSSEC successful. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Paul Hoffman Sent: Friday, October 03, 2014 5:44 PM To: ksk-rollover@icann.org Subject: [ksk-change] FIPS-140 levels On Oct 2, 2014, at 10:42 AM, Bolivar, Al <abolivar@verisign.com> wrote:
I would like to add that I support the addition of another vendor. Tomofumi and I spoke to another vendor about introducing a competing FIPS 140-2 level 4 HSM. In my opinion having other choices will be positive.
As I understand it, the requirement for the FIPS 140-2 level 4 certification for HSMs in the current setup came from the US government. Under the assumption that the US government will not be putting requirements on future changes to the DNSSEC root keying, this is a good time to look at what the community wants. The current setup has the HSM wrapped in a tamper-evident bag, in a safe, between uses, and that the uses are all viewed by lots of people and recorded on cameras. Given that, I see no advantages to FIPS-140 levels above 1. By using these processes, the DNS root key community has our own tamper evidence, our own tamper resistance, and our own access control mechanisms. There are serious disadvantages to requiring level 4 (or even level 2 or 3) for HSMs: there are fewer vendors, and fewer models from vendors. This is going to bite us hard if we decide to start using signature algorithms other than RSA, such as elliptic curves (which are tremendously safer to use than RSA for the levels of assurance we want for the DNS root). Even if there are vendors who have FIPS-140 level 4 HSMs for ECDSA using P256, the IETF is probably going to standardize different curve forms with different parameters in the next six months. These will come out of the TLS WG first, but the signature algorithms will probably be everywhere within a year. There will be lots of publicity for the advantages of these curves over RSA and over P256. If the DNSSEC root stays with less-safe RSA, or switches to EC P256 which has already been shown to have operational problems, because of the requirement to wait for FIPS-140 level 4 HSMs, we could lose a fair amount of the credibility that we have garnered so far. If folks here can show that FIPS-140 level 2, 3, or 4 are valuable *in our already-existing usage environment* (our own tamper evidence, our own tamper resistance, our own administration controls), I'm all ears. If no one can, we should start talking about FIPS-140 level 1 or better for future HSMs as a way to give us more choices of vendors, models, and particularly signing algorithms. --Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Oct 5, 2014, at 11:28 AM, Richard Lamb <richard.lamb@icann.org> wrote:
Thank you for lending your experience and voice of reason. I agree that from the perspective of our little community (which includes me) that fips 140 level 4 is a bit overkill.
Note that I didn't say "a bit". FIPS-140 levels are progressively more restrictive, and I asked for examples of anything that we even need in level 2 that we do not provide ourselves.
However, in architecting this system the target was a much broader audience with the idea that things like DANE and other key-in-dns technologies may someday bootstrap themselves from the DNS. Specifically I was thinking of the financial community and how to get their buy in. This is what brings in the AICPA/CICA and the SysTrust audit we pass every year. Again not because there is anything special about this process (although I do believe it does help keep ICANN at attention), but instead as a necessity to get the buy in from the "suits" of the world as without their trust*, I think we only have an expensive experiment.
The banking community is one which understands physical security better than most. The kinds of things that IANA does for tamper evidence, tamper prevention, and operational role separation are way more effective and constantly provable than a FIPS-140 validation. This is particularly true because you cannot easily verify that a device is operating in "FIPS-140 mode". Banks appreciate proof, and the recording of the ceremonies and of the physical protections do that.
But I am open to discussion and have heard many different suggestions, some very clever, on how to better manage the root KSK to both simplify and build trust from certain communities - but do not necessarily fit what auditors might consider best common practice.
Can you be more specific about the latter? That is, is there an auditor who is saying that IANA needs to conform to "common practice", not the better practice that you have instituted?
Happy to make happen whatever everyone decides and even have someone change my mind that we need to make the accountants and lawyers of the world happy to make DNSSEC successful.
It could certainly help to document IANA's current (and expected future) practices in the same terms as what NIST uses for FIPS-140 higher-than-level-1 certification. The folks closest to the process already take some of those things for granted, but the communities you care about will want to hear about them. --Paul Hoffman
Ooo...Was just trying to be diplomatic .."a bit". You know that is not my usual mode :-) As long as we can "sell" DNSSEC to the wider audience and the community accepts the risks, I am fine. The engineering was never really so much of a problem. Our auditors have not said anything negative. Its just if you look at standard CPSs and have conversations with various auditors - we spent $$ on advice from many - , there is definitely a common framework that all of the Webtrust/Systrust audited entities seem to follow, FIPS 140-2 >= level 3 being one. I am not arguing for any of this at an engineering level. I know you are much more expert than I in these things and am happy following my true instincts and creating something based on engineering logic rather than following the herd*... but my business side says it must sell. And selling isn't always based on sense - otherwise I would be rich. Just want to make sure by tossing out FIPS 140-2 level 3+4 we are not throwing something useful in promoting DNSSEC to business away. Its your call. Thanks for the offer to help doc and new practices when we take them on. You are obviously already a sought after member of the community. We do have a couple new guys who's difficult task it is to maintain the 16+ policy+procedures docs around the root KSK operations that our auditors see. They are sharp and I am hoping they get up to speed soon. Tomofumi, Dalini, and I are tired. -Rick *FWIW, personally, I built my own hsm, alarm systems, wrote my own (slow) RSA+miller rabin, off-line custom s/w signer for my stuff just so I know who to blame ;-) .. Id like to use djb curve25519 - is it any good? -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Sunday, October 05, 2014 11:41 AM To: Richard Lamb Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] FIPS-140 levels On Oct 5, 2014, at 11:28 AM, Richard Lamb <richard.lamb@icann.org> wrote:
Thank you for lending your experience and voice of reason. I agree that from the perspective of our little community (which includes me) that fips 140 level 4 is a bit overkill.
Note that I didn't say "a bit". FIPS-140 levels are progressively more restrictive, and I asked for examples of anything that we even need in level 2 that we do not provide ourselves.
However, in architecting this system the target was a much broader audience with the idea that things like DANE and other key-in-dns technologies may someday bootstrap themselves from the DNS. Specifically I was thinking of the financial community and how to get their buy in. This is what brings in the AICPA/CICA and the SysTrust audit we pass every year. Again not because there is anything special about this process (although I do believe it does help keep ICANN at attention), but instead as a necessity to get the buy in from the "suits" of the world as without their trust*, I think we only have an expensive experiment.
The banking community is one which understands physical security better than most. The kinds of things that IANA does for tamper evidence, tamper prevention, and operational role separation are way more effective and constantly provable than a FIPS-140 validation. This is particularly true because you cannot easily verify that a device is operating in "FIPS-140 mode". Banks appreciate proof, and the recording of the ceremonies and of the physical protections do that.
But I am open to discussion and have heard many different suggestions, some very clever, on how to better manage the root KSK to both simplify and build trust from certain communities - but do not necessarily fit what auditors might consider best common practice.
Can you be more specific about the latter? That is, is there an auditor who is saying that IANA needs to conform to "common practice", not the better practice that you have instituted?
Happy to make happen whatever everyone decides and even have someone change my mind that we need to make the accountants and lawyers of the world happy to make DNSSEC successful.
It could certainly help to document IANA's current (and expected future) practices in the same terms as what NIST uses for FIPS-140 higher-than-level-1 certification. The folks closest to the process already take some of those things for granted, but the communities you care about will want to hear about them. --Paul Hoffman
Hi Paul, When security engineers design a service, one of the things they consider is "defence in depth". The idea is establishing layers of security controls so that failure of one will not be as critical as it would be. (a.k.a. don't put all your eggs in one basket) What you suggested is simply lowering the security level for convenience as you did not suggest compensating controls. Instead you just suggested removing controls as it is overlapping with existing ones. Changing the design not as easy as one might think. I'm all for an idea that improves the design but not the other way around. IMHO, it is better to have tamper evidence (level2) and tamper resistance (level3) at the HSM level. I personally think the environmental controls (level4) might be too much but it is true that it has controls that protects the cryptographic key from different type of attacks. Cheers, Tomofumi On Sun, Oct 5, 2014 at 12:30 PM, Richard Lamb <richard.lamb@icann.org> wrote:
Ooo...Was just trying to be diplomatic .."a bit". You know that is not my usual mode :-)
As long as we can "sell" DNSSEC to the wider audience and the community accepts the risks, I am fine. The engineering was never really so much of a problem.
Our auditors have not said anything negative. Its just if you look at standard CPSs and have conversations with various auditors - we spent $$ on advice from many - , there is definitely a common framework that all of the Webtrust/Systrust audited entities seem to follow, FIPS 140-2 >= level 3 being one. I am not arguing for any of this at an engineering level.
I know you are much more expert than I in these things and am happy following my true instincts and creating something based on engineering logic rather than following the herd*... but my business side says it must sell. And selling isn't always based on sense - otherwise I would be rich. Just want to make sure by tossing out FIPS 140-2 level 3+4 we are not throwing something useful in promoting DNSSEC to business away. Its your call.
Thanks for the offer to help doc and new practices when we take them on. You are obviously already a sought after member of the community.
We do have a couple new guys who's difficult task it is to maintain the 16+ policy+procedures docs around the root KSK operations that our auditors see. They are sharp and I am hoping they get up to speed soon. Tomofumi, Dalini, and I are tired.
-Rick
*FWIW, personally, I built my own hsm, alarm systems, wrote my own (slow) RSA+miller rabin, off-line custom s/w signer for my stuff just so I know who to blame ;-) .. Id like to use djb curve25519 - is it any good?
-----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Sunday, October 05, 2014 11:41 AM To: Richard Lamb Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] FIPS-140 levels
On Oct 5, 2014, at 11:28 AM, Richard Lamb <richard.lamb@icann.org> wrote:
Thank you for lending your experience and voice of reason. I agree that from the perspective of our little community (which includes me) that fips 140 level 4 is a bit overkill.
Note that I didn't say "a bit". FIPS-140 levels are progressively more restrictive, and I asked for examples of anything that we even need in level 2 that we do not provide ourselves.
However, in architecting this system the target was a much broader audience with the idea that things like DANE and other key-in-dns technologies may someday bootstrap themselves from the DNS. Specifically I was thinking of the financial community and how to get their buy in. This is what brings in the AICPA/CICA and the SysTrust audit we pass every year. Again not because there is anything special about this process (although I do believe it does help keep ICANN at attention), but instead as a necessity to get the buy in from the "suits" of the world as without their trust*, I think we only have an expensive experiment.
The banking community is one which understands physical security better than most. The kinds of things that IANA does for tamper evidence, tamper prevention, and operational role separation are way more effective and constantly provable than a FIPS-140 validation. This is particularly true because you cannot easily verify that a device is operating in "FIPS-140 mode". Banks appreciate proof, and the recording of the ceremonies and of the physical protections do that.
But I am open to discussion and have heard many different suggestions, some very clever, on how to better manage the root KSK to both simplify and build trust from certain communities - but do not necessarily fit what auditors might consider best common practice.
Can you be more specific about the latter? That is, is there an auditor who is saying that IANA needs to conform to "common practice", not the better practice that you have instituted?
Happy to make happen whatever everyone decides and even have someone change my mind that we need to make the accountants and lawyers of the world happy to make DNSSEC successful.
It could certainly help to document IANA's current (and expected future) practices in the same terms as what NIST uses for FIPS-140 higher-than-level-1 certification. The folks closest to the process already take some of those things for granted, but the communities you care about will want to hear about them.
--Paul Hoffman
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Oct 5, 2014, at 2:50 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
What you suggested is simply lowering the security level for convenience as you did not suggest compensating controls.
It wasn't "for convenience", it was to enable us to have a wider choice of HSMs that meet our needs. For example, one of our possible needs is "have HSMs from a variety of manufacturers", which is something you proposed just the other day. Another possible need is "have an HSM that uses the signing algorithm we want", given that there are some people who want to move towards modern elliptic curve signatures in the future.
Instead you just suggested removing controls as it is overlapping with existing ones.
I did not propose "removing controls": I proposed meeting specific requirements ourselves if IANA can do it better. If the tamper evidence provided by the additions in the Level 2 part of an HSM's FIPS-140 certification is as good as, or not even as good as, what is provided by IANA's design (the tamper-evident bags), then it is not an actual control. The same is true for Level 3 and Level 4, I believe. I'm not sure, so I'm asking for others who know the specifics of how the levels are met *in HSMs* to comment.
IMHO, it is better to have tamper evidence (level2) and tamper resistance (level3) at the HSM level.
Why? This is a serious question. Why rely on the tamper evidence and tamper resistance of a system when you can add better functionality for both, which is what IANA is already doing?
I personally think the environmental controls (level4) might be too much but it is true that it has controls that protects the cryptographic key from different type of attacks.
In the case of the HSMs that IANA uses, what specific attacks are those? I would be somewhat surprised if the same controls weren't required for Level 1, but you are more familiar with how HSMs meet the FIPS-140 requirements. --Paul Hoffman
Hello Paul, On Sun, Oct 5, 2014 at 3:16 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 5, 2014, at 2:50 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
It wasn't "for convenience", it was to enable us to have a wider choice of HSMs that meet our needs. For example, one of our possible needs is "have HSMs from a variety of manufacturers", which is something you proposed just the other day. Another possible need is "have an HSM that uses the signing algorithm we want", given that there are some people who want to move towards modern elliptic curve signatures in the future.
Yes, I do agree that we need more variety (right now there is only one) but I'm just against opening the door for inferior options or reducing the security around the KSK. FIPS140 level 1 does not require any physical controls. This is why softwares like OpenSSL can be FIPS140-2 level 1 certified. BTW, I personally like EC (especially curve 25519). EC will solve the size issue but I think it is a great idea but I think we should tread carefully before trying to make radical changes to the HSM requirement.
I did not propose "removing controls": I proposed meeting specific requirements ourselves if IANA can do it better. If the tamper evidence provided by the additions in the Level 2 part of an HSM's FIPS-140 certification is as good as, or not even as good as, what is provided by IANA's design (the tamper-evident bags), then it is not an actual control. The same is true for Level 3 and Level 4, I believe. I'm not sure, so I'm asking for others who know the specifics of how the levels are met *in HSMs* to comment.
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.
IMHO, it is better to have tamper evidence (level2) and tamper resistance (level3) at the HSM level.
Why? This is a serious question. Why rely on the tamper evidence and tamper resistance of a system when you can add better functionality for both, which is what IANA is already doing?
I'm sorry for repeating myself but this is to accomplish defense in depth (layered security). We can't solely rely on the tamper evident bag for tamper evidence. Putting all eggs in one basket is not the best practice when it comes to security. It is about adding redundancy (e.g. 2 door is better then 1). The safety mechanism on the HSM is the last resort if any other process-based security control gets compromised.
In the case of the HSMs that IANA uses, what specific attacks are those? I would be somewhat surprised if the same controls weren't required for Level 1, but you are more familiar with how HSMs meet the FIPS-140 requirements.
Environmental controls adopted by level 4 crypto modules are not required for level 1 crypto modules neither are tamper evidence (level2) or tamper resistance (level3). The controls each level is quite different. Requirements for FIPS140 level 1 is pretty loose compared to others. 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) This might sound weird but I'm not actually advocating for FIPS140 level 4 HSMs and I do like EC too. 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. Cheers! Tomofumi
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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
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@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
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@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@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
FWIW: With enough warning I believe we can get AEP to work with us. -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Tomofumi Okubo Sent: Monday, October 06, 2014 12:15 PM To: Bolivar, Al Cc: ksk-rollover@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@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@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
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@icann.org> wrote:
FWIW: With enough warning I believe we can get AEP to work with us.
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Tomofumi Okubo Sent: Monday, October 06, 2014 12:15 PM To: Bolivar, Al Cc: ksk-rollover@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@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@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
+1. Al
On Oct 6, 2014, at 15:23, Tomofumi Okubo <tomofumi.okubo@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@icann.org> wrote: FWIW: With enough warning I believe we can get AEP to work with us.
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Tomofumi Okubo Sent: Monday, October 06, 2014 12:15 PM To: Bolivar, Al Cc: ksk-rollover@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@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@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Oct 6, 2014, at 12:17 PM, Richard Lamb <richard.lamb@icann.org> wrote:
FWIW: With enough warning I believe we can get AEP to work with us.
With enough warning, I hope that IANA can get *all* the relevant HSM manufacturers to implement whatever curves are chosen by the IETF for TLS, and then possibly by this community for DNSSEC. --Paul Hoffman
On 10/6/2014 3:23 PM, Paul Hoffman wrote:
On Oct 6, 2014, at 12:17 PM, Richard Lamb <richard.lamb@icann.org> wrote:
FWIW: With enough warning I believe we can get AEP to work with us. With enough warning, I hope that IANA can get *all* the relevant HSM manufacturers to implement whatever curves are chosen by the IETF for TLS, and then possibly by this community for DNSSEC.
FWIW - it's trivial for most HSM manufacturer's to support the X9.63 style curves and public keys and signatures. Generally, it's just giving them the new curve data. Supporting any of the non-X9.63 curves (including Curve25519 and probably the NUMS Twisted Edwards, but not the NUMS Weiserstrass) will require some selling to the HSM vendors (new math, new math engines, new formats etc) and something more than just the ICANN asking for them. I don't think actually that being chosen for TLS is the right benchmark for DNSSEC - different needs. Mike
--Paul Hoffman
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Hello Paul, Thanks for your reply. On Mon, Oct 6, 2014 at 7:38 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Oct 5, 2014, at 10:37 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
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?
Yes, that's right but that is if the other security controls successfully detects the compromise. The mechanism on the HSM will be the last line of defense if the other security controls fail for some reason. This is why in the ICANN definition, HSM is labelled as Tier 7.
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.
I still think level 1 HSMs are not suitable for mission critical operations like Root DNSSEC. I've never heard of a commercial CA or banks that uses FIPS140 level 1 HSMs for their CA cert operation (not EE).
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 agree that we currently don't have much options and that is definitely an issue. I'm hoping that if the algorithms you mentioned are really going to be the mainstream, it won't take multiple years for the HSM vendors to incorporate them. As I mentioned on the list, we can always talk to the HSM vendors if we come up with what we actually want. Cheers! Tomofumi
On 10/5/2014 6:16 PM, Paul Hoffman wrote:
On Oct 5, 2014, at 2:50 PM, Tomofumi Okubo <tomofumi.okubo@gmail.com> wrote:
What you suggested is simply lowering the security level for convenience as you did not suggest compensating controls. It wasn't "for convenience", it was to enable us to have a wider choice of HSMs that meet our needs. For example, one of our possible needs is "have HSMs from a variety of manufacturers", which is something you proposed just the other day. Another possible need is "have an HSM that uses the signing algorithm we want", given that there are some people who want to move towards modern elliptic curve signatures in the future.
Instead you just suggested removing controls as it is overlapping with existing ones. I did not propose "removing controls": I proposed meeting specific requirements ourselves if IANA can do it better. If the tamper evidence provided by the additions in the Level 2 part of an HSM's FIPS-140 certification is as good as, or not even as good as, what is provided by IANA's design (the tamper-evident bags), then it is not an actual control. The same is true for Level 3 and Level 4, I believe. I'm not sure, so I'm asking for others who know the specifics of how the levels are met *in HSMs* to comment.
The following table is taken directly from the FIPS 140-2 doucment. The most important piece you get with Level 4 of this is that when tamper is detected, zeroization is performed. L4 devices are designed to the Roach Motel standard - keys check in but they never check out. I'm responding behind a number of other responses. WRT to your original comment, the only thing you get if you remove HSM protections and keep the tamper stuff is a knowledge that you're *really* screwed when the tamper seal is broken. If the tamper seals are defeated (e.g. the key material is removed from the tamper bag and copied and returned), you don't even know that... Then there are all the possible slight of hand scams that can take place - cf http://en.wikipedia.org/wiki/Pigeon_drop for one example.
IMHO, it is better to have tamper evidence (level2) and tamper resistance (level3) at the HSM level. Why? This is a serious question. Why rely on the tamper evidence and tamper resistance of a system when you can add better functionality for both, which is what IANA is already doing?
The answer to this is that a tamper event causes destruction of the key material. Tamper evidence or tamper resistance does not by itself give you any assurance with respect to the underlying key material.
I personally think the environmental controls (level4) might be too much but it is true that it has controls that protects the cryptographic key from different type of attacks. In the case of the HSMs that IANA uses, what specific attacks are those? I would be somewhat surprised if the same controls weren't required for Level 1, but you are more familiar with how HSMs meet the FIPS-140 requirements.
See the above table. A software module can be certified as L1 (and I believe one of the mozilla pseudo-PKCS11 software modules is so certified). It really provides no protection against cloning or extraction of the key material. Mike
--Paul Hoffman _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On 1 Oct 2014, at 17:15, Jakob Schlyter <jakob@kirei.se> wrote:
On 1 okt 2014, at 23:00, Michael StJohns <msj@nthpermutation.com> wrote:
Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot.
That only makes sense if you maintain and protect the keys separately, something that comes with a considerable cost. We did considering this when the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis did not justify such a scheme.
I think it's still worth considering, though. It seems possible that we discounted the possibility of secure storage of multiple sets of keys with different threat models too early because we assumed it would require double the facility cost. For example, a standby key could be stored in key shares across the existing two facilities such that the threat model is usefully different to the production key (e.g. such that you'd need to attack both facilities to recover the standby key, whereas you only need to attack a single facility to compromise the production key). Joe
Yep. That's what Tomofumi and I had been considering doing with the current setup as well. -Rick -----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Joe Abley Sent: Thursday, October 02, 2014 8:42 AM To: Jakob Schlyter Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term On 1 Oct 2014, at 17:15, Jakob Schlyter <jakob@kirei.se> wrote:
On 1 okt 2014, at 23:00, Michael StJohns <msj@nthpermutation.com> wrote:
Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot.
That only makes sense if you maintain and protect the keys separately, something that comes with a considerable cost. We did considering this when the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis did not justify such a scheme.
I think it's still worth considering, though. It seems possible that we discounted the possibility of secure storage of multiple sets of keys with different threat models too early because we assumed it would require double the facility cost. For example, a standby key could be stored in key shares across the existing two facilities such that the threat model is usefully different to the production key (e.g. such that you'd need to attack both facilities to recover the standby key, whereas you only need to attack a single facility to compromise the production key). Joe _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
Yes, I agree that building another KMF is not the only way of introducing the standby key. Cheers! Tomofumi
On Oct 2, 2014, at 9:02, Richard Lamb <richard.lamb@icann.org> wrote:
Yep. That's what Tomofumi and I had been considering doing with the current setup as well. -Rick
-----Original Message----- From: ksk-rollover-bounces@icann.org [mailto:ksk-rollover-bounces@icann.org] On Behalf Of Joe Abley Sent: Thursday, October 02, 2014 8:42 AM To: Jakob Schlyter Cc: ksk-rollover@icann.org Subject: Re: [ksk-change] Keeping two KSK keys long term
On 1 Oct 2014, at 17:15, Jakob Schlyter <jakob@kirei.se> wrote:
On 1 okt 2014, at 23:00, Michael StJohns <msj@nthpermutation.com> wrote:
Having two keys - in the trust anchor set - should be the minimum steady state. It means that you can compromise one of them and still recover without needing to do a full trust reboot.
That only makes sense if you maintain and protect the keys separately, something that comes with a considerable cost. We did considering this when the current Root DNSSEC was engineered, and IIRC the cost/benefit analysis did not justify such a scheme.
I think it's still worth considering, though. It seems possible that we discounted the possibility of secure storage of multiple sets of keys with different threat models too early because we assumed it would require double the facility cost.
For example, a standby key could be stored in key shares across the existing two facilities such that the threat model is usefully different to the production key (e.g. such that you'd need to attack both facilities to recover the standby key, whereas you only need to attack a single facility to compromise the production key).
Joe _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
participants (9)
-
Bolivar, Al -
David Conrad -
Jakob Schlyter -
Joe Abley -
Michael StJohns -
Paul Hoffman -
Richard Lamb -
Tomofumi O -
Tomofumi Okubo