XKEK Key Domains

A XKEK Key Domain is a group of SmartCard-HSMs where membership in the group is controlled by a Group Signer and key migration in the group is based on a Key Encryption Key pairwise established using an authenticated Diffie-Hellman scheme (ECDH).

It is a specific characteristic of a XKEK Key Domain that key material can never leave that key domain. Only authentic SmartCard-HSM, entitled by the Group Signer to participate in the key domain, can exchange keys. There is no mechanism to insert or extract keys from a XKEK key domain. XKEK Key Domains allow a very strict regime on how keys are be distributed.

When two SmartCard-HSMs perform ECDH to establish a XKEK, they need to trust the public key of the peer. This in ensured by public key attestation, a mechanism in the SmartCard-HSM that signs every newly generated public key of a key pair with the Device Authentication Key. The peer can verify the signature applied to the public key and validate the certificate chain up to the root certificate as trust anchor. The root certificate (SRCA) is placed in a SmartCard-HSM during production, at the same time the Device Authentication Key is generated and certified.

Both, public key attestation and public key verification are a mechanism implemented internally in the SmartCard-HSM, so both devices can rely on this mechanism to trust each other.

While SmartCard-HSMs generally trust each other, if their Device Certificate traces back to the same root CA, forming groups requires a second cryptographic control. This second mechanism further limits the spreading of keys in a sub-group of authentic SmartCard-HSMs. This group is controlled by a single ECDSA key, called the Group Signer Key. Purpose of the Group Signer Key is to sign Key Domain Memberships. Key Domain Memberships are issued to grant SmartCard-HSMs, identified by their Device Authentication Key, access to a group. Each group is uniquely identified by the Group Signer Public Key, so that forging KDMs without access to the Group Signer Public Key is impossible.

A SmartCard-HSM validates the signature applied to a KDM, by building a certificate chain from the attested Group Signer Public Key along the Device Certificate, Device Issuer Certificate up to the root certificate. As a consequence, a Group Signer must always be generated on a SmartCard-HSM that is issued under the same root CA.

Once a SmartCard-HSM has validated the KDM, it considers itself part of the XKEK Key Domain and indicates this in public key attestation for keys that are generated in that key domain. With this additional information, the peer SmartCard-HSM can verify, that both device are in the same key domain, when deriving the XKEK.

The following diagram shows the complete picture.

Remember, that the SmartCard-HSM is a trusted computing device, so that the trust established by public key attestation can be extend to include the key domain membership indicator. There is no need to have some additional KDM distribution or verification in other peers.

Create the Group Signer

To create a XKEK Key Domain you need to generate the Group Signer Key Pair by selecting Generate ECC Key from the context menu of the SmartCard-HSM node in the outline.

Select brainpoolP256r1 as curve parameter, as the SmartCard-HSM System PKI uses this for EC keys.

In the next step choose a key name that allows you to identify the key as Group Signer for a certain group.

The key reference is included in public key attestation and can later be used to help identifying the key domain. You can stick with the proposed name in the meantime.

The Group Signer needs to perform ECDSA operations with SHA-256, so either enter "ECDSA,ECDSA_SHA2" in the algorithm field or leave the field empty for default.

The key pair is now generated and the public key embedded in an Authenticated Card Verifiable Certificate Request as per BSI TR-03110 (AT-CVREQ).

The AT-CVREQ is signed by the Device Authentication Key. The mouse points to the Group Signer Public Key. Remember the '9E42BD..' as this will later uniquely identify the key domain.

Issue Key Domain Membership

Now that we have a Group Signer, we need to sign Key Domain Memberships for all SmartCard-HSM that should be part of the group. As KDMs sign the Device Authentication Key, we first need to obtain the Device Certificate of the Device we want to issue a KDM for. Lets insert the SmartCard-HSM with Id UTCC0100013 and save the Device Certificate and the full chain to a file.

Use the proposed file name.

Now switch back to the SmartCard-HSM containing the Group Signer, login and open the context menu attached to the certificate (AT-CVREQ). Select Group Signer Operations.

Select Static key domain membership.

Next select the file with the Device-ID that you created some steps before.

The Key Manager prompts you to confirm, that you want to issue a Key Domain Membership by signing the Device Authentication Key.

Now the KDM is created and saved to file. You can see the file name in the shell on the right side.

The next step is to use the KDM to create the XKEK Key Domain on the other SmartCard-HSM. Switch back to the other SmartCard-HSM, login and select Create XKEK Key Domain in the context menu of an unused key domain slot.

Select the previously created KDM file.

If the KDM is valid and matches the inserted SmartCard-HSM, then the XKEK Key Domain is created.

Create a Key in the Key Domain

To show how a key can be migrated from one SmartCard-HSM to another, we create an AES Test-Key in the just created XKEK Key Domain. Select Generate AES Key from the context menu of the XKEK Key Domain.

Make sure the WRAP attribute is set for the key. Without the WRAP attribute the key can not be exported.

The newly generated key can now be seen in the outline located in the key domain.

Now repeat the procedure for all SmartCard-HSM that shall be part of the key domain.

Transfer Key

To move a key within the key domain to another SmartCard-HSM we need to do the following:

1. Create an ECDH key pair on the receiving SmartCard-HSM.
2. Save the ECDH public key to file.
3. Create an ECDH key pair on the sending SmartCard-HSM.
4. Save the ECDH public key to file.
5. Derive the XKEK using the ECDH public key of the receiver and the private key of the sender.
6. Wrap the test keys with the XKEK and save the cryptogram.
7. At the receiver derive the XKEK using the ECDH public key of the sender and the private key of the receiver.
8. Import and unwrap the test keys with the XKEK.

In the key domain on the receiving SmartCard-HSM create the ECDH key pair, again with brainpoolP256r1 and a suitable name. It is important, that the key has the attribute ECDH_XKEK (and only that attribute).

Then save the public key using Export Public Key from the context menu for the certificate.

Use the proposed file name.

Now switch to the sending SmartCard-HSM and login. Repeat creating the ECDH key pair and saving the public key.

Next derive the XKEK by performing an EC Diffie-Hellman with the private key and the other public key. Select Derive XKEK from the context menu for the certificate of the ECDH key.

Select the file containing the public key of the ECDH key pair generated at the receiving SmartCard-HSM.

After performing the ECDH operation, the Key Encryption Key is derived and the Key Check Value is presented at the XKEK node in the outline. Remember this KCV, as we later see the same value on the receiving SmartCard-HSM.

Now that the XKEK is derived, we can wrap the test key using Wrap Key (and Certificate) from the context menu of the test key (As the key is an AES, there is no certificate).

Select a suitable file name to save the key cryptogram, meta-data and optional certificate.

At this point you could delete the test key and re-import from the .wky file. The relevant information saved with the wrapped key is the KCV. As long as the KCV is present or can be recreated (by deriving the XKEK another time).

Now switch to the receiving SmartCard-HSM, login and derive the XKEK as it was done on the sending SmartCard-HSM. Instead of the receiving SmartCard-HSM's public key you now select the sending SmartCard-HSM's public key.

Due to the nature of the Diffie-Hellman algorithm, the resulting XKEK is identical, as can derived from the KCV.

Finally you can import and unwrap the key from the .wky file using Unwrap Key (and Certificate) from the context menu of the SmartCard-HSM top level node. You don't need to select the key domain into which you would like to import the key, as this is automatically determined from the KCV value saved with the key cryptogram.

Select the file containing the wrapped key.

Now the AES test key is available at the receiving SmartCard-HSM.

To complete the transmission you might want to delete the ECDH private key and XKEK. This prevents, that the process can be repeated and ensures freshness of the derive XKEK (The XKEK is the result of the ECDH operation. so it is repeatable on both sides, the sender and the receiver).

To delete the XKEK select Delete Key Encryption Key from the context menu of the XKEK entry in the outline.

Obviously transferring keys requires a lot of steps, with the creation of ECDH keys, the XKEK derivation, wrap and unwrap.

Fortunately there is Copy Keys from Management Token function in the Key Manager, explain here.

XKEK Key Domains are also the technological basis for Key Escrow in the PKI-as-a-Service Portal.