[ksk-rollover] Thales Luna Credentials questions

[Micha Bailey]

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 at 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 at 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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ksk-rollover/attachments/20240303/98458e5a/attachment-0001.html>