Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Comment: 24.R1: Updated intro text and other information.

Remember to update the release version number before publishing externally.

David Banz can you review the updated version of this article? (smile) Thanks!

DONE

Info

This article includes updates for Smart ID IdentityManager 24.R1.

...

As the default, built-in attestation keys can be found in any Smart ID Mobile App and Smart ID Desktop App installation. Any , any device can install the app and try to request certificates. Configuring custom keypairs limits the devices that can request certificates to devices whose mobile or desktop app has the custom private key installed. The corresponding public keys can be configured into Identity Manager. This process consists of two steps:

  1. Generate the PKCS#12 keystores.
    To make the public keys available to Identity Manager, keystores that contain a certificate with the public key must be created. Nexus provide a tool that, given the modulus and public exponent of the public key in BASE64 Base64 format (or an RSA JWK public key), creates the keystore.

  2. Configure the sign and encrypt engine.
    The sign and encrypt engine must have access to the keystores.

...

If the file could not be created, for example, due to missing write permissions, the tool will print its contents on the screen as a long BASE 64 Base64 string. You can copy and paste this string in a file, Base64-decode it and store it. This will create the same file that could not be created in the first step. Alternatively, fix the problem and rerun the tool.

...

  1. Copy the created keystore to a location where Identity Manager can access it.

  2. Edit the sign and encrypt engine's configuration and create a new key entry referencing the keystore.

  3. Create a new descriptor entry referencing this key entry. The name of the descriptor must be exactly the same as it is named in the Smart ID mobile app and Smart ID Desktop App, prepended with the string "att_".
    The key name is denoted "kid" in the key material. In the example above, it is "att_attestation_key_id"attestation_2023-11-02T08:29:08GMT”, so the descriptor name would be “att_attestation_2023-11-02T08:29:08GMT“.

To use new keys for an existing descriptor, create a new descriptor or key entry with an incremented version. Signatures will be validated against all versions of the key, until a valid one is found. This is useful in case some clients still have the old keys.

...

Code Block
languagexml
<?xml version="1.0" encoding="UTF-8"?>
<engineSignEncrypt>
    <descriptors>
         <descriptor name="att_attestation_key_idattestationKeyId" version="1">
            <type algorithm="SHA256withRSA" size="" result="" key="attestationKey_old" />
        </descriptor>
          <descriptor name="att_attestation_key_idattestationKeyId" version="2">
            <type algorithm="SHA256withRSA" size="" result="" key="attestationKey_current" />
        </descriptor>
        <!-- others descriptors -->
    </descriptors>
    <keys>
        <key name="attestationKey_old">
            <type name="pkcs12" locationValue="classpath:attKeyOld.p12" pin="1234"/>
        </key>
         <key name="attestationKey_current">
            <type name="pkcs12" locationValue="classpath:attKeyCurrent.p12" pin="1234"/>
        </key>
        <!-- others keys -->
     </keys>
</engineSignEncrypt>