Initializing a SmartCard-HSM

A SmartCard-HSM fresh from production is protected with an electronic seal, so that you can verify that is wasn't used or manipulated before. Before you can use it, you must perform an initialization procedure to claim ownership.

A new SmartCard-HSM should appear empty and with the Not initialized message.

In the normal life-cycle of a SmartCard-HSM, it can only get back into this state with a firmware update. That also removes all traces of a previous use and creates a new identity.

Talking about identities: Every SmartCard-HSM has a cryptographically provable identity, given to it during initial production or firmware update. It is based on an EC key generated and certified during production. You can see the Device Certificate and the certificate of the device issuer in the Key Manager.

Both are Card Verifiable Certificates (CVC) and play an important role in authenticating the SmartCard-HSM, secure channel establishment and Public Key Attestation.

The output also contains the Default Key Domain, which is a part of the Device Authentication Public Key. It can be seen as a worldwide unique identifier of this specific identity.

The human readable device identification can be found in the CHR field of the device certificate (here DECC1209355). It is also shown in the outline on the left side. The name is assigned by the Device Issuer (here DEDICC12 in the CAR field), which itself is certified by the Scheme Root-CA (SRCA) identified by DESRCACC1 (the CAR field of the DICA). The trailing 00001 in the name is a serial number.

Sometime you see a path as unique identifier. This is actually a concatenation of the SRCA name, the DICA name and the device name (here /DESRCACC1/DEDICC12/DECC1209355). By policy of the SRCA, the path is always unique.

Breaking the Seal

The electronic seal on a SmartCard-HSM can be broken by doing the first initialization. In this first initialization you set the Initialization Code (aka SO-PIN in PKCS#11 terminology). In a subsequent initialization you need to provide the same Initialization Code, so it is important to remember the SO-PIN you set at the first time.

We recommend to start with the proposed test value (3537363231383830) as long as you are testing. Later you can switch to a more secure SO-PIN or even better use a Managed SO-PIN. The test value SO-PIN is also called the Default SO-PIN.

Select Initialize Device from the context menu of the SmartCard-HSM node in the outline.

The Key Manager then proposes an Initialization Code (SO-PIN) to use. Stick to the test value for testing, so you don't accidentially brick the device.

Next you can choose an optional label. A label may help you identify the token. If a label is set, it is later shown in the outline. You can change the label whenever you repeat the initialization.

By the way, you can always cancel the procedure and nothing will be changed.

In the next step you can define an optional provisioning URL. Such a URL is useful, if you plan to use the SmartCard-HSM as TrustCenter token in the PKI-as-a-Service Portal. If you have no plans to use the PKI-as-a-Service Portal you can leave that field empty.

You can choose a mechanism for user authentication. This is different from the SO-PIN, which is used to reinitialize the device or unblock a User-PIN. The authentication mechanism selected here is for day-to-day use. Typically you would select a User-PIN for tokens given to individuals and Public Key Authentication for TrustCenter token.

User PIN is a 6 to 16 character PIN or password.

Transport PIN is a 6 to 16 character PIN that must be changed to a user selected value before the token can be used.

Public Key Authentication allows to register an authentication key on a another SmartCard-HSM (i.e. a personal token) for authentication in a n-of-m threshold scheme.

Public Key Authentication or User PIN is the combination of PKA or User PIN.

Public Key Authentication and User PIN is the combination of PKA and User PIN.

The Biometic Matching options are only available on devices that support biometric matching, like the GoID fingerprint card or the KeyXentic KX901.

We start with a User PIN, which has three further options to choose from.

Resetting and unblocking PIN with SO-PIN not allowed means that you can not unblock or reset the User PIN if the retry counter expired after three wrong attempts to enter the PIN value.

Unblocking PIN with SO-PIN allowed means that you can use the SO-PIN to unblock the retry counter, allowing further PIN verification attempts.

Resetting PIN with SO-PIN allowed means that you can set a new PIN value and unblock the retry counter using the SO-PIN.

Now you can define the User PIN. The Key Manager proposes the User PIN test value that we use through the documentation. Please choose your own secret value or let the Key Manager generate a random PIN by erasing the input field.

The KEK Scheme in the next dialog allows you to define, if you want to support key backup or key migration to other tokens.

No DKEK means to use no Key Domains at all.

Randomly generated DKEK means to create one Key Domain with a randomly generated KEK. With this you can only export and import keys into the same device.

DKEK Shares means to create one Key Domain with DKEK Shares to import.

Key Domains this is the option to choose for newer SmartCard-HSMs (>= 3.x) as it allows you to create Key Domain Slots on the device that you can later configure for DKEK or XKEK Key Domains. This options gives more flexibility, while the former options provide more compatibility with the sc-hsm-tool from OpenSC.

We go for Key Domains and choose to create 4 Key Domain slots.

This is the final dialog and subsequently the initialization with the selected parameter is performed. The outline is updated to reflect the new status.

You can repeat the initialization procedure as often as you want, but remember that re-initialization will remove all cryptographic keys on the device.

Using a Random SO-PIN and User PINs

Before you initialize a SmartCard-HSM for the first time, you can create a fresh set of random SO-PIN, User PIN and Transport PIN. The function uses the build-in random number of the inserted SmartCard-HSM.

The generated values are printed in the shell windows and you can choose to use these values for this token.

You can save the generated values in plain to a profile on the workspace. If you don't save the values, you should note them otherwise.

The generated SO-PIN, User PIN and Transport PIN values are printed on the left, with the profile name to which the values where saved.

If you open the profile, you can see the values in plain. Please make sure, the profiles are secured accordingly (File encryption etc.).

{
    "soPIN": "CC5642F8BD1D1380",
    "userPIN": "246884",
    "transportPIN": "601807"
}

Whenever you insert the SmartCard-HSM, the Key Manager will try to locate the profile and preset the internal values in PIN related dialogs with the saved values.

If you later change the SO-PIN or User PIN, you are prompted to update the profile.