Configure custom attestation keys

Custom attestation keys should be configured in IDM whenever possible. The Mobile and/or Desktop App must have access to the private keys. The corresponding public keys can be configured into IDM. This process consists of two steps:

Generate PKCS#12 keystores. On order to make the public keys available to IDM, keystores must be created that contain a certificate with the public key. We provide a tool that, given the modulus and public exponent of the public key in BASE64 format (or an RSA JWK public key), creates the keystore.
Configure the sign and encrypt engine. The sign and encrypt engine needs access to the keystores.

Prerequisites

This is a summary of what must be in place before you proceed with the configuration in IDM.

You have a Mobile and/or Desptop App with custom keys.
You have the public key material of these custom keys. That's a string that looks similar to this, containing the public key in single-line JWK-based format ({"alg":"RS256", ...etc... ,"use":"sig"}):

CODE

PublicKey: {"alg":"RS256","e":"AQAB","keystate":"active","kid":"attestation_2023-11-02T08:29:08GMT","kty":"RSA","n":"trfHQvFlcFcOEaB9v9tF6R1NggU3o9ddhmDb3GnGuEA3bP8XaKOgIrvh-KFvinE0xATcZk_XQC9n5ORhm-c5KvfryAdCGM62SKoBonc7Av7Iu6YHdcJHjoSCvjNSsw6B3mPoWP6IRvzwZRKgLHIDeNCjA7r0oKCXQIr05IxMVjOSHD8FIxKsgDq8CaF6j-0UFYS92pV5Ok-20nXqLsGv_IHojqazIE3xnNi1kEmNJF4q2LmVFu6VFkegjCj_O78wIGTI9JUZJK1LNMU1BqSDUKek8iTGPgojurNLe31l4Uvpe4j1Gi52mVzEiCufKhJP4xJzK7EGeT9rtcuUf4tB5SmCT_t9WYz6MvJ7cwFJ9sF7bb8vwYU22qgKuyvGtQGIojoYXOyWzCj3E3ZJM_PQxOyJwRF8oCGYD1UjHGdDqzFVQa3NHKwTlz4vdnfRzAdcbG3tn0tB5OCA8vMrGZvP30QJx0MmBrxduLm4bN59FSPV1WLmFkYOVVdf0RIG-bNq65rrlMOOQcV5jasgBEy6alb5uh21ewWx0Ld2DOMosWCEDa6G02QRLZfWIAqMvRvZtfyrv5FRIVoAPUQTnFMH7AGNAQ0rEywYPRa0XE7viTspeLULRrltjzh5rg9YXVhNspyca4SqooZniVEDz2cqOSn7r37VXD_qz2DBKPtSXo8","n#len":"4096","storage":"APP","use":"sig"}

You have Nexus' keystore creator tool
You have a JRE installed

Step-by-step instructions

Generate PKCS#12 keystores

Keep the public key material at hand. For our example, we will use the following:

CODE

PublicKey: {"alg":"RS256","e":"AQAB","keystate":"active","kid":"attestation_2023-11-02T08:29:08GMT","kty":"RSA","n":"trfHQvFlcFcOEaB9v9tF6R1NggU3o9ddhmDb3GnGuEA3bP8XaKOgIrvh-KFvinE0xATcZk_XQC9n5ORhm-c5KvfryAdCGM62SKoBonc7Av7Iu6YHdcJHjoSCvjNSsw6B3mPoWP6IRvzwZRKgLHIDeNCjA7r0oKCXQIr05IxMVjOSHD8FIxKsgDq8CaF6j-0UFYS92pV5Ok-20nXqLsGv_IHojqazIE3xnNi1kEmNJF4q2LmVFu6VFkegjCj_O78wIGTI9JUZJK1LNMU1BqSDUKek8iTGPgojurNLe31l4Uvpe4j1Gi52mVzEiCufKhJP4xJzK7EGeT9rtcuUf4tB5SmCT_t9WYz6MvJ7cwFJ9sF7bb8vwYU22qgKuyvGtQGIojoYXOyWzCj3E3ZJM_PQxOyJwRF8oCGYD1UjHGdDqzFVQa3NHKwTlz4vdnfRzAdcbG3tn0tB5OCA8vMrGZvP30QJx0MmBrxduLm4bN59FSPV1WLmFkYOVVdf0RIG-bNq65rrlMOOQcV5jasgBEy6alb5uh21ewWx0Ld2DOMosWCEDa6G02QRLZfWIAqMvRvZtfyrv5FRIVoAPUQTnFMH7AGNAQ0rEywYPRa0XE7viTspeLULRrltjzh5rg9YXVhNspyca4SqooZniVEDz2cqOSn7r37VXD_qz2DBKPtSXo8","n#len":"4096","storage":"APP","use":"sig"}

Nexus' keystore creator tool supports only RSA algorithum based keys.
In case you are on a windows machine and the environment variable JAVA_HOME is not set, edit createP12.bat and createP12fromJWK.bat and set JAVA_HOME to point to your java installation.

Start the keystore creator.
You can either start it in a mode that expects a complete public key in JWK format (createP12fromJWK.bat / createP12fromJWK.sh), or in a mode that expects individual key components (createP12.bat / createP12.sh):
1. Start the keystore creator by executing createP12fromJWK.bat (on Windows) or createP12fromJWK.sh (on Linux). Then follow the instructions on the screen:
  1. Enter the public key in single-line JWK format.
  2. Enter the filename of the keystore to create, for example "attestationKey.p12".
  3. Enter the keystore's password. You need to enter this twice for verification. Write this password down or remember it, as you will need to also set in the sign and encrypt engine's configuration.
  4. The tool will now create a dummy certificate with the given public key. The certificate itself is not relevant, it just serves as a container for the public key. The path to the created file will be printed on the screen.
  5. If the file could not be created, e.g. because of missing write permissions, the tool will print its contents on the screen, as a long BASE 64 string. You can copy + paste this string in a file, Base64-decode it and store it. This will create exactly the same file that could not be created in the previous step. Alternatively, fix the problem and rerun the tool.
2. Start the keystore creator by executing createP12.bat (on Windows) or createP12.sh (on Linux). Then follow the instructions on the screen:
  1. Enter the public key exponent. This is denoted "e" in the key material. In our example, that would be "AQAB". As a matter of fact, it is highly likely that your key also has a public key exponent of "AQAB".
  2. Enter the modulus. This is denoted "n". In our example, this would be the long string "trfHQ....tSXo8"
  3. Enter the filename of the keystore to create, for example "attestationKey.p12".
  4. Enter the keystore's password. You need to enter this twice for verification. Write this password down or remember it, as you will need to also set in the sign and encrypt engine's configuration.
  5. The tool will now create a dummy certificate with the given public key. The certificate itself is not relevant, it just serves as a container for the public key. The path to the created file will be printed on the screen.
  6. If the file could not be created, e.g. because of missing write permissions, the tool will print its contents on the screen, as a long BASE 64 string. You can copy + paste this string in a file, Base64-decode it and store it. This will create exactly the same file that could not be created in the previous step. Alternatively, fix the problem and rerun the tool.

Configure the sign and encrypt engine

You must make the keystore available to both IDM Administrator (for configuring processes with the created attestation keys) and IDM Operator.

Copy the created keystore to a location where IDM can access it.
Edit the sign and encrypt engine's configuration and create a new key entry referencing the keystore.
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 Mobile or Personal App, prepended with the string "att_". The key name is denoted "kid" in the key material, so in the example above you need to set it to "att_attestation_key_id"

In order to use new keys for an existing descriptor, please create a new descriptor/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.

During bootstrap, if you have custom keys, it is advised to remove the default attestation keys from the engine's configuration. Thus only clients with the custom attestation keys will be able to generate keypairs. If instead you keep the default keys and add new keys under a newer version of the same descriptor, requests signed with the default keys will still be accepted.

A sample descriptor configuration looks like this:

Example: attestation key

CODE

<?xml version="1.0" encoding="UTF-8"?>
<engineSignEncrypt>
    <descriptors>
         <descriptor name="att_attestation_key_id" version="1">
            <type algorithm="SHA256withRSA" size="" result="" key="attestationKey_old" />
        </descriptor>
          <descriptor name="att_attestation_key_id" version="2">
            <type algorithm="SHA256withRSA" size="" result="" key="attestationKey_current" />
        </descriptor>
    </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>
     </keys>
</engineSignEncrypt>