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.