Thales Luna Credentials questions
Hi, I have a few questions about the key cards.
From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct?
I can not seem to find an alternative to the OP cards, is there a reason for this. Additionally I can not seem to find a replacement for SMK cards. I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3. Also a backup HSM is mentioned in the document. Is this in place of an APP card? What credentials will be required to transfer a KSK to a new HSM? What credentials will be required to apply existing cards to a new HSM? What credentials will be required to decrypt the KSK backup? Kind Regards Will
I was also curious about the different operation, and spent some time reading the manuals on thalesdocs.com. There were a couple points that were unclear, or that weren’t stated explicitly, but my understanding from reading the Thales documentation suggests as follows (and I may be wrong on any of these points): • First, to clarify, it seems that these HSMs don’t use smart cards at all — the external credentials consist of USB devices called iKeys, reminiscent of a small flash drive, and can all be split M-of-N as you’d expect. Keys can optionally have a PIN as a second factor, but I’d assume that’s not going to be set up for the KSK use case, based on the current procedure of leaving card PINS set to 11223344. From pictures there does seem to be a slot at the bottom that looks like it should accept a card, but it’s unclear whether that’s actually the case or what it’s used for, there’s no mention in the documentation. • It seems there isn’t a way to have multiple credentials at once for a specific entity/role, but at the point of creating a credential it’s possible to create multiple discrete split sets, which can in turn have different M-of-N parameters. Once a credential is initialized, that’s it — but any given iKey can later be cloned, 1:1, PIN and all, seemingly on any Luna HSM/PED. • APP cards don’t have a direct equivalent, these HSMs can only transfer keys from HSM to HSM (over a secure channel via the PC they’re both attached to, or in some scenarios [that I assume won’t come into play here] over a network), no external media involved • The portable USB-attached HSMs have a single partition (a kind of sub-HSM, with its own completely separate credentials from other partitions, as well as the ones that manage the HSM itself), as opposed to other models (e.g. the network-attached ones) which can support many partitions. • There’s also a separate SKU, the “Backup HSM”, which shares a similar (identical?) form factor to the USB HSM, but can hold many partitions, while being limited to backup storage and unable to perform any cryptographic operations. • Each partition, at initialization time, is given a “domain” credential, either by generating a new key or importing an existing one. • In order to transfer/clone/backup/restore keys between HSMs, they must all be initialized with the same domain credential. This is therefore the closest equivalent to the Keyper’s SMK, as far as I can tell, with the biggest difference being that that credential isn’t able to be re-exported (unlike on the Keyper, where the process for initializing a new HSM involves, IIRC, exporting the SMK from an existing one onto temporary cards that are then destroyed. • The AAK doesn’t have a direct equivalent (one credential that other credentials are based on, whereby importing it makes the others all work). When each role (SO, CO, audit, etc.) is initialized, and later if the credentials are replaced (some credentials absolutely require the old one in order to change, others can be optionally configured to be resettable by higher tiers of access), the operator can either generate a new credential, or present an existing credential to import it for use. This seems to apply separately to each individual credential, and for that matter each individual HSM, with no forced connection between them (besides the domain key, as mentioned previously). • It appears that the optional CU role is the rough equivalent of the OP, but they’re a subset of the CO permissions, such that if they’re issued to the same people and kept together there’s no real benefit to using them. • Not positive about this, but it seems that the process for transferring a key from one HSM to another/backing up/restoring/etc. is to connect the two devices to the same machine, and then each device must be presented with both the domain credential with which the partition was initialized (and which must be the same on all devices), and with that particular partition’s CO credential (which, IIUC, can be different on each device, or can be the same if they were so configured). I haven’t yet gotten around to rereading the analysis with the new understanding of the system, but I do remember a couple things I saw there didn’t quite make sense to me. I’ll briefly address each point inline. On Sun, Mar 3, 2024 at 9:18 PM Will Tubby via ksk-rollover < ksk-rollover@icann.org> wrote:
Hi,
I have a few questions about the key cards.
From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct?
The security model seems to work differently, AAK and APP don’t have direct equivalents
I can not seem to find an alternative to the OP cards, is there a reason for this.
As mentioned - the CU essentially fills that role but is also not necessarily useful here, as it’s a strict subset of CO
Additionally I can not seem to find a replacement for SMK cards.
Domain credential is the closest, but it’s not exportable and must be presented in order to backup/transfer keys
I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3.
I believe in the current setup RKSHs hold a 5-of-7 split indeed, and for new HSM initialization the SMK is temporarily exported onto new cards which are then wiped and destroyed after use, a process which isn’t applicable with the Luna family
Also a backup HSM is mentioned in the document. Is this in place of an APP card?
Yes, essentially — although it’s not clear to me that it’s necessary to use the backup-specific SKU here, unless being incapable of cryptographic operations is considered a desirable trait
What credentials will be required to transfer a KSK to a new HSM?
1. The domain key, which must be shared across all signing and backup HSMs across both KMFs, being generated at the initialization of the first HSM in the system and presented at the initialization of each new HSM after that. 2. The CO key for the source HSM. 3. The CO key for the new HSM, which may be the same key as the source HSM if the new HSM was so initialized, or in principal could be different as well. What credentials will be required to apply existing cards to a new HSM?
What credentials will be required to decrypt the KSK backup?
In the default mode, keys never exist outside the HSMs, so those scenarios are not applicable.
Kind Regards
Will
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Sorry, I just realized that
What credentials will be required to apply existing cards to a new HSM? was referring to role cards. The answer seems to be “the role credential itself”.
On Sun, Mar 3, 2024 at 10:09 PM Micha Bailey <michabailey@gmail.com> wrote:
I was also curious about the different operation, and spent some time reading the manuals on thalesdocs.com. There were a couple points that were unclear, or that weren’t stated explicitly, but my understanding from reading the Thales documentation suggests as follows (and I may be wrong on any of these points): • First, to clarify, it seems that these HSMs don’t use smart cards at all — the external credentials consist of USB devices called iKeys, reminiscent of a small flash drive, and can all be split M-of-N as you’d expect. Keys can optionally have a PIN as a second factor, but I’d assume that’s not going to be set up for the KSK use case, based on the current procedure of leaving card PINS set to 11223344. From pictures there does seem to be a slot at the bottom that looks like it should accept a card, but it’s unclear whether that’s actually the case or what it’s used for, there’s no mention in the documentation. • It seems there isn’t a way to have multiple credentials at once for a specific entity/role, but at the point of creating a credential it’s possible to create multiple discrete split sets, which can in turn have different M-of-N parameters. Once a credential is initialized, that’s it — but any given iKey can later be cloned, 1:1, PIN and all, seemingly on any Luna HSM/PED. • APP cards don’t have a direct equivalent, these HSMs can only transfer keys from HSM to HSM (over a secure channel via the PC they’re both attached to, or in some scenarios [that I assume won’t come into play here] over a network), no external media involved • The portable USB-attached HSMs have a single partition (a kind of sub-HSM, with its own completely separate credentials from other partitions, as well as the ones that manage the HSM itself), as opposed to other models (e.g. the network-attached ones) which can support many partitions. • There’s also a separate SKU, the “Backup HSM”, which shares a similar (identical?) form factor to the USB HSM, but can hold many partitions, while being limited to backup storage and unable to perform any cryptographic operations. • Each partition, at initialization time, is given a “domain” credential, either by generating a new key or importing an existing one. • In order to transfer/clone/backup/restore keys between HSMs, they must all be initialized with the same domain credential. This is therefore the closest equivalent to the Keyper’s SMK, as far as I can tell, with the biggest difference being that that credential isn’t able to be re-exported (unlike on the Keyper, where the process for initializing a new HSM involves, IIRC, exporting the SMK from an existing one onto temporary cards that are then destroyed. • The AAK doesn’t have a direct equivalent (one credential that other credentials are based on, whereby importing it makes the others all work). When each role (SO, CO, audit, etc.) is initialized, and later if the credentials are replaced (some credentials absolutely require the old one in order to change, others can be optionally configured to be resettable by higher tiers of access), the operator can either generate a new credential, or present an existing credential to import it for use. This seems to apply separately to each individual credential, and for that matter each individual HSM, with no forced connection between them (besides the domain key, as mentioned previously). • It appears that the optional CU role is the rough equivalent of the OP, but they’re a subset of the CO permissions, such that if they’re issued to the same people and kept together there’s no real benefit to using them. • Not positive about this, but it seems that the process for transferring a key from one HSM to another/backing up/restoring/etc. is to connect the two devices to the same machine, and then each device must be presented with both the domain credential with which the partition was initialized (and which must be the same on all devices), and with that particular partition’s CO credential (which, IIUC, can be different on each device, or can be the same if they were so configured).
I haven’t yet gotten around to rereading the analysis with the new understanding of the system, but I do remember a couple things I saw there didn’t quite make sense to me.
I’ll briefly address each point inline.
On Sun, Mar 3, 2024 at 9:18 PM Will Tubby via ksk-rollover < ksk-rollover@icann.org> wrote:
Hi,
I have a few questions about the key cards.
From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct?
The security model seems to work differently, AAK and APP don’t have direct equivalents
I can not seem to find an alternative to the OP cards, is there a reason for this.
As mentioned - the CU essentially fills that role but is also not necessarily useful here, as it’s a strict subset of CO
Additionally I can not seem to find a replacement for SMK cards.
Domain credential is the closest, but it’s not exportable and must be presented in order to backup/transfer keys
I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3.
I believe in the current setup RKSHs hold a 5-of-7 split indeed, and for new HSM initialization the SMK is temporarily exported onto new cards which are then wiped and destroyed after use, a process which isn’t applicable with the Luna family
Also a backup HSM is mentioned in the document. Is this in place of an APP card?
Yes, essentially — although it’s not clear to me that it’s necessary to use the backup-specific SKU here, unless being incapable of cryptographic operations is considered a desirable trait
What credentials will be required to transfer a KSK to a new HSM?
1. The domain key, which must be shared across all signing and backup HSMs across both KMFs, being generated at the initialization of the first HSM in the system and presented at the initialization of each new HSM after that. 2. The CO key for the source HSM. 3. The CO key for the new HSM, which may be the same key as the source HSM if the new HSM was so initialized, or in principal could be different as well.
What credentials will be required to apply existing cards to a new HSM?
What credentials will be required to decrypt the KSK backup?
In the default mode, keys never exist outside the HSMs, so those scenarios are not applicable.
Kind Regards
Will
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Micha, Please see my comments inline below. On Sun, Mar 03, 2024 at 10:12:17PM +0200, Micha Bailey via ksk-rollover wrote:
Sorry, I just realized that
What credentials will be required to apply existing cards to a new HSM? was referring to role cards. The answer seems to be “the role credential itself”.
On Sun, Mar 3, 2024 at 10:09 PM Micha Bailey <michabailey@gmail.com <mailto:michabailey@gmail.com> <mailto:michabailey@gmail.com <mailto:michabailey@gmail.com>> <mailto:michabailey@gmail.com <mailto:michabailey@gmail.com> <mailto:michabailey@gmail.com <mailto:michabailey@gmail.com>>>> wrote:
I was also curious about the different operation, and spent some time reading the manuals on thalesdocs.com. There were a couple points that were unclear, or that weren’t stated explicitly, but my understanding from reading the Thales documentation suggests as follows (and I may be wrong on any of these points): • First, to clarify, it seems that these HSMs don’t use smart cards at all — the external credentials consist of USB devices called iKeys, reminiscent of a small flash drive, and can all be split M-of-N as you’d expect. Keys can optionally have a PIN as a second factor, but I’d assume that’s not going to be set up for the KSK use case, based on the current procedure of leaving card PINS set to 11223344. From pictures there does seem to be a slot at the bottom that looks like it should accept a card, but it’s unclear whether that’s actually the case or what it’s used for, there’s no mention in the documentation.
We will use iKeys without a PIN. Also, the Luna and backup HSMs have a card reader at the bottom, but the card reader is disabled and cannot be used. The response I got was that it was considered, but then they disabled it. Additionally, it is not part of the security policy and firmware; therefore, it was not included in the FIPS certification.
• It seems there isn’t a way to have multiple credentials at once for a specific entity/role, but at the point of creating a credential it’s possible to create multiple discrete split sets, which can in turn have different M-of-N parameters. Once a credential is initialized, that’s it — but any given iKey can later be cloned, 1:1, PIN and all, seemingly on any Luna HSM/PED.
On ceremony 53 day 2, we will create all the credentials for all Crypto Officers in both KMFs and RKSHs.
• APP cards don’t have a direct equivalent, these HSMs can only transfer keys from HSM to HSM (over a secure channel via the PC they’re both attached to, or in some scenarios [that I assume won’t come into play here] over a network), no external media involved
Backups will be via HSM cloning and backup HSMs.
• The portable USB-attached HSMs have a single partition (a kind of sub-HSM, with its own completely separate credentials from other partitions, as well as the ones that manage the HSM itself), as opposed to other models (e.g. the network-attached ones) which can support many partitions.
We will use the same credentials for the HSM and the partition.
• There’s also a separate SKU, the “Backup HSM”, which shares a similar (identical?) form factor to the USB HSM, but can hold many partitions, while being limited to backup storage and unable to perform any cryptographic operations.
We will use backup HSMs with the same credentials as the HSM.
• Each partition, at initialization time, is given a “domain” credential, either by generating a new key or importing an existing one. • In order to transfer/clone/backup/restore keys between HSMs, they must all be initialized with the same domain credential. This is therefore the closest equivalent to the Keyper’s SMK, as far as I can tell, with the biggest difference being that that credential isn’t able to be re-exported (unlike on the Keyper, where the process for initializing a new HSM involves, IIRC, exporting the SMK from an existing one onto temporary cards that are then destroyed. • The AAK doesn’t have a direct equivalent (one credential that other credentials are based on, whereby importing it makes the others all work). When each role (SO, CO, audit, etc.) is initialized, and later if the credentials are replaced (some credentials absolutely require the old one in order to change, others can be optionally configured to be resettable by higher tiers of access), the operator can either generate a new credential, or present an existing credential to import it for use. This seems to apply separately to each individual credential, and for that matter each individual HSM, with no forced connection between them (besides the domain key, as mentioned previously). • It appears that the optional CU role is the rough equivalent of the OP, but they’re a subset of the CO permissions, such that if they’re issued to the same people and kept together there’s no real benefit to using them. • Not positive about this, but it seems that the process for transferring a key from one HSM to another/backing up/restoring/etc. is to connect the two devices to the same machine, and then each device must be presented with both the domain credential with which the partition was initialized (and which must be the same on all devices), and with that particular partition’s CO credential (which, IIUC, can be different on each device, or can be the same if they were so configured).
For cloning and backup, both HSMs will be connected to the ceremony laptop at the same time.
I haven’t yet gotten around to rereading the analysis with the new understanding of the system, but I do remember a couple things I saw there didn’t quite make sense to me.
I’ll briefly address each point inline.
On Sun, Mar 3, 2024 at 9:18 PM Will Tubby via ksk-rollover < ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>>>> wrote:
Hi,
I have a few questions about the key cards.
From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct?
The security model seems to work differently, AAK and APP don’t have direct equivalents
I can not seem to find an alternative to the OP cards, is there a reason for this.
As mentioned - the CU essentially fills that role but is also not necessarily useful here, as it’s a strict subset of CO
Additionally I can not seem to find a replacement for SMK cards.
Domain credential is the closest, but it’s not exportable and must be presented in order to backup/transfer keys
I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3.
I believe in the current setup RKSHs hold a 5-of-7 split indeed, and for new HSM initialization the SMK is temporarily exported onto new cards which are then wiped and destroyed after use, a process which isn’t applicable with the Luna family
Also a backup HSM is mentioned in the document. Is this in place of an APP card?
Yes, essentially — although it’s not clear to me that it’s necessary to use the backup-specific SKU here, unless being incapable of cryptographic operations is considered a desirable trait
What credentials will be required to transfer a KSK to a new HSM?
1. The domain key, which must be shared across all signing and backup HSMs across both KMFs, being generated at the initialization of the first HSM in the system and presented at the initialization of each new HSM after that. 2. The CO key for the source HSM. 3. The CO key for the new HSM, which may be the same key as the source HSM if the new HSM was so initialized, or in principal could be different as well.
What credentials will be required to apply existing cards to a new HSM?
What credentials will be required to decrypt the KSK backup?
In the default mode, keys never exist outside the HSMs, so those scenarios are not applicable.
Kind Regards
Will
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>>> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>>>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>>>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>>>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>>> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>>>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>>>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>>>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Best regards, -- Andres Pavez Cryptographic Key Manager
Hi Andres, Thank you for your reply. I have also looked over the replies to Micha. Can you please confirm I understand correctly COs will be given a full set of iKeys. RKSHs will only be given Domain and CO cards Domain cards will be 5 out of 7 All other cards will be 3 out of 7 The backup will now be on a different HSM I have a few additional questions In my first email I asked the question: What credentials will be required to apply existing cards to a new HSM? by this I was referring to transferring the new credentials (Domain, Audit, CO, SO) between all of the different Thales Luna HSMs In your reply to Micha you state that new HSMs are to be added every two to three years. However looking at the previous scripts quite a few of the recent ones involve new HSMs. Is this just to do with the lifecycle of the originals? Finally I notice that KSK Ceremony 53 is split into two parts. Will the second part (Introducing the new HSMs) be live streamed the same way as the normal ceremony? I apologise for all the questions but it doesn't help that I only started learning about DNSSEC and the KSK about 3 months ago. Kind Regards, Will
Hi Will, Andres and I perform the same role, and I can answer your questions as well. Please see responses in line:
COs will be given a full set of iKeys. RKSHs will only be given Domain and CO cards Domain cards will be 5 out of 7 All other cards will be 3 out of 7 The backup will now be on a different HSM
This is correct. The backups are on a dedicated backup HSM. They appear identical to the standard HSMs, but have a different firmware to be clear.
In my first email I asked the question: What credentials will be required to apply existing cards to a new HSM? by this I was referring to transferring the new credentials (Domain, Audit, CO, SO) between all of the different Thales Luna HSMs
During the initial setup of an HSM one is prompted to create a new set of credentials or import an existing set of credentials. If one opts to import an existing set of credentials, the HSM requires the M in the M of N (either 3 or 5 depending on the credential in question here) to be inserted into the HSM, and with that, the import is complete. On Day 2 we plan to configure the first HSM and generate all of the credential sets that are required, clone the individual credentials until we have what is required for distribution to all TCRs, and then import these credentials to the remaining HSMs to be configured that day. We have 2 Luna G7 signing HSMs and 2 Luna G7 backup HSMs for testing in our possession and have performed test scenarios on the hardware to ensure our logic is sound. This coupled with the Thales documentation allows us to ensure accuracy with the ceremony scripts.
In your reply to Micha you state that new HSMs are to be added every two to three years. However looking at the previous scripts quite a few of the recent ones involve new HSMs. Is this just to do with the lifecycle of the originals?
In recent ceremonies we introduced new Keyper HSMs to replace aging units (HSMs 5 and 6 for both KMFs) to ensure their lifecycles would exceed the remaining lifecycle of the current KSK-2017. This will allow us a lengthy pre-publication period of the KSK-2024 slated for generation this April on the new equipment before the rollover date scheduled in 2026. You may read more about the key rollover phases here: https://www.icann.org/en/system/files/files/proposal-future-rz-ksk-rollovers... The plan with Luna HSMs Is to align the lifecycle of the signing HSMs with the lifecycle of the KSKs they contain. Additionally, we plan to introduce additional backup HSMs approximately midway through a key’s lifecycle so we’ll have backup HSMs manufactured at different times going forward. This plan provides the 2-3 year cadence Andres previously mentioned.
Finally I notice that KSK Ceremony 53 is split into two parts. Will the second part (Introducing the new HSMs) be live streamed the same way as the normal ceremony?
Yes. We have separate ceremony pages set up for the two ceremony days, and each will have its own embedded YouTube livestream link. Each day will have its own annotated script and ceremony artefacts posted afterward as is customary.
I apologise for all the questions but it doesn't help that I only started learning about DNSSEC and the KSK about 3 months ago.
It sounds like you’re off to a great start. We don’t mind the questions. Our goal is to promote awareness and trust in the process, so we are here to serve that purpose. -Aaron
Hi Will, Please see my comments inline below. On Sun, Mar 03, 2024 at 07:18:26PM +0000, Will Tubby via ksk-rollover wrote:
Hi,
I have a few questions about the key cards.
From looking at the document linked in response to mike I believe that the CO and SO cards act the same as they did on the Keyper. It also appears that the AAK and APP cards are combined to form the domain cards. Is this correct?
No. They have similarities but work with different concepts. For example, Luna products have partitions, and for each partition, you can have different SO. We have decided to use the same SO credentials to manage the HSM and manage one partition that will have the KSK. The AAK for the Keyper allows you to use the same credentials (OP, SO, and CO) in another Keyper that has the same AAK. The APP key is protected by the SMK. In the Luna, the keys are protected by the Domain and CO Keys.
I can not seem to find an alternative to the OP cards, is there a reason for this.
The keyper OP cars are only used to put the HSM online. Using the Luna, we will use the SO credential to take the HSM out of Secure Transport Mode (STM), then the CO cards tot the Luna HSM "online" too.
Additionally I can not seem to find a replacement for SMK cards.
I can say that the Domain and CO credentials combined can act similarly to the SMK.
I attempted to investigate myself and found that when the SMK cards were used to set up a new HSM only 3 cards were used and they were already in the KMF. I thought that SMK cards are held by RKSHs and that 5 are required, not 3.
Yes, we split the SMK for the COs in a 3 of 7 schema to allow us to introduce new HSMs. This was a plan created in 2019 and implemented in 2022 and 2023 when we reissued all the credentials for the COs in both KMFs.
Also a backup HSM is mentioned in the document. Is this in place of an APP card?
No. The backups HSMs will contain the KSK, and access to these backup HSMs will require both Domain and CO credentials. A backup HSM can only store keys and cannot perform cryptographic operations.
What credentials will be required to transfer a KSK to a new HSM?
To transfer the KSK from the Luna HSM to another Luna HSM or backup HSM at least the Domain and the CO credentials are required. For operations, we will use all the same credentials (CO, SO, Domain and Audit).
What credentials will be required to apply existing cards to a new HSM?
The new Luna HSM uses a different type of credential. They are not compatible with the Keyper.
What credentials will be required to decrypt the KSK backup?
For Keyper HSMs, one needs the SMK to import an APP key backup. For Luna HSMs, one needs to use the Domain and CO credentials to access a Luna Backup HSM.
Kind Regards
Will _______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org> <mailto:ksk-rollover@icann.org <mailto:ksk-rollover@icann.org>>> https://mm.icann.org/mailman/listinfo/ksk-rollover <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>> <https://mm.icann.org/mailman/listinfo/ksk-rollover>>>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>> <https://www.icann.org/privacy/policy>>>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>> <https://www.icann.org/privacy/tos>>>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Best regards, -- Andres Pavez Cryptographic Key Manager
participants (4)
-
Aaron Foley -
Andres Pavez -
Micha Bailey -
Will Tubby