<div dir="auto">Sorry, I just realized that</div><div dir="auto"><div dir="auto"><span style="font-family:arial,sans-serif;font-size:14.666667px;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important;background-color:rgba(0,0,0,0);border-color:rgb(0,0,0);color:rgb(0,0,0)">> What credentials will be required to apply existing cards to a new HSM?</span></div></div><div dir="auto">was referring to role cards. The answer seems to be “the role credential itself”.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 3, 2024 at 10:09 PM Micha Bailey <<a href="mailto:michabailey@gmail.com">michabailey@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">I was also curious about the different operation, and spent some time reading the manuals on <a href="http://thalesdocs.com" target="_blank">thalesdocs.com</a>. 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):</div><div dir="auto">• 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.</div><div dir="auto">• 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.</div><div dir="auto">• 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</div><div dir="auto">• 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.</div><div dir="auto">• 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.</div><div dir="auto">• Each partition, at initialization time, is given a “domain” credential, either by generating a new key or importing an existing one.</div><div dir="auto">• 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.</div><div dir="auto">• 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).</div><div dir="auto">• 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.</div><div dir="auto">• 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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">I’ll briefly address each point inline.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 3, 2024 at 9:18 PM Will Tubby via ksk-rollover <<a href="mailto:ksk-rollover@icann.org" target="_blank">ksk-rollover@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">Hi,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">I have a few questions about the key cards.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">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?</span></p></span></div></blockquote><div dir="auto">The security model seems to work differently, AAK and APP don’t have direct equivalents</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">I can not seem to find an alternative to the OP cards, is there a reason for this.</span></p></span></div></blockquote><div dir="auto">As mentioned - the CU essentially fills that role but is also not necessarily useful here, as it’s a strict subset of CO</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">Additionally I can not seem to find a replacement for SMK cards.</span></p></span></div></blockquote><div dir="auto">Domain credential is the closest, but it’s not exportable and must be presented in order to backup/transfer keys</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">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. </span></p></span></div></blockquote><div dir="auto">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</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">Also a backup HSM is mentioned in the document. Is this in place of an APP card?</span></p></span></div></blockquote><div dir="auto">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</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">What credentials will be required to transfer a KSK to a new HSM?</span></p></span></div></blockquote><div dir="auto">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.</div><div dir="auto">2. The CO key for the source HSM.</div><div dir="auto">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. </div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p></span></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">What credentials will be required to apply existing cards to a new HSM?</span></p></span></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">What credentials will be required to decrypt the KSK backup?</span></p></span></div></blockquote><div dir="auto">In the default mode, keys never exist outside the HSMs, so those scenarios are not applicable.</div></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr"><span id="m_-5619557371472091678m_-9136005743924560150gmail-docs-internal-guid-c3ac82ae-7fff-3909-2d67-737f552f2d95"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)"></span></p><br><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">Kind Regards</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial,sans-serif;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;background-color:transparent;color:rgb(0,0,0)">Will</span></p></span><br></div>
_______________________________________________<br>
ksk-rollover mailing list<br>
<a href="mailto:ksk-rollover@icann.org" target="_blank">ksk-rollover@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ksk-rollover" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ksk-rollover</a><br>
<br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). 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.</blockquote></div></div>
</blockquote></div></div>