Bootstrap the sign and encrypt engine in Identity Manager

This article includes updates for Smart ID 23.04.2.

Overview

The sign/encrypt engine is a component of Identity Manager which manages keys and certificates used for several purposes, and most of them have to be configured for each deployment, so that the private keys are kept secret.

The keys themselves may be stored in files or externally on a HSM (Hardware Security Module) for increased security, which is a separate topic not further discussed here - see, for example, Configure HSM in Identity Manager, which does not yet cover Docker deployment.

This article focuses on bootstrapping with PKCS#12 files.

Important: Some keys and certificates need to be bootstrapped before starting the application(s) the first time, especially for the two first use-cases below.
Whenever secrets or history entries were created with the demo keys, a simple bootstrapping is no longer possible without using additional tooling in order to re-sign history entries or re-encrypt secrets.

Use-cases in detail

Encrypt and decrypt secret fields

bootstrap requirement
- mandatory
risk
- Secrets in the database can be accessed by a well-known private key. As we don't support key versioning here. The key can only be changed with the tool batch_secretfieldstore_change_encryption_key once the first secret is in the database.
configured in these applications
- Identity Manager Admin / (earlier know as PRIME Designer)
- Identity Manager Operator / (earlier known as PRIME Explorer)
configured in these special-case tools
- batch_secretfieldstore_change_encryption_key
  (repair tool for secret fields)
- batch_migration_smartact_to_prime
  (for migration of data from Identity Manager's/PRIME's predecessor SmartAct, it has additional requirements for decrypting secret fields and config entries from the source system)
certificate requirements
- key usage at least key encipherment and data encipherment

Sign and verify object history

bootstrap requirement
- mandatory
risk
- Re-signing the object history (or parts of it) is possible based on a well-known private key.
configured in these applications
- Identity Manager Admin
  (technically not used here, but required for startup due to bean requirements - subject to change in future releases)
- Identity Manager Tenant / (earlier known as PRIME Tenant)
  (technically not used here, but required for startup due to bean requirements - subject to change in future releases)
- Identity Manager Operator
configured in these special-case tools
- batch_re-sign_history
  (repair tool for history signature)
- batch_migration_smartact_to_prime
  (for migration of data from Identity Manager's/PRIME's predecessor SmartAct)
certificate requirements
- if key usage extension is critical, then digitalSignature must be set

Sign config ZIPs

ZIP verification is done via Identity Manager trust-store instead (see certificate requirements below)

bootstrap requirement
- optional
risk
- Config ZIP will be signed with a certificate, that shouldn't provide trust.
configured in these applications
- Identity Manager Admin
- Identity Manager Operator
certificate requirements
- if key usage extension is critical, then digitalSignature must be set
- issuing certificate has to be installed in the Identity Manager trust-store
- certificate must not be self-signed

Send signed S/MIME e-mails

bootstrap requirement
- optional
  (can be skipped if you do not send signed e-mails or any e-mails at all from IDM)
risk
- E-mails will be signed with a certificate, no one trusts. Which means it doesn't work at all - mail clients will complain about invalid signatures.
configured in this application
- Identity Manager Operator
obsolete in this application
- Identity Manager Admin
  (referenced but not used - can be removed, if present)
certificate requirements
- a general S/MIME certificate which the required e-mail clients actually trust

Sign JWT for Web Service Authentication (i.e. Self-Service)

bootstrap requirement
- mandatory
  (even if you do not use Self-Service, this does present an attack vector if not configured properly, see below)
risk
- the web service interface can be used with any active user, based on a well known private key
configured in this application
- Identity Manager Operator
certificate requirements
- recommended key usage at least digital signature

Dummy CA used for Messaging (Desktop App / Mobile)

bootstrap requirement
- optional
  (you may keep the example file, as it has no security relevance)
risk
- n/a
  (this CA generates certificates for transient key-pairs generated on a target device - the certificates themselves serve no security purpose and are merely used to bind a key usage to the key-pair, so it can be used for decryption)
configured in these applications
- Identity Manager Operator
- obsolete in these applications and tools
  - Identity Manager Admin (referenced but not used - can be removed, if present)
  - Identity Manager Tenant (referenced but not used - can be removed, if present)
  - batch_migration_smartact_to_prime (referenced but not used - can be removed, if present)
certificate requirements
- recommended key usage at least certificate signing, either no basic constraints or subject type CA on basic constraints
  (a certificate without extensions will suffice here)

Attestation keys (Desktop App / Mobile)

bootstrap requirement
- optional
risk
- As the default, built-in keys can be found in any Mobile or Desktop App installation, any device, even personal ones, can install the App and try to request certificates. Configuring custom keys limits the devices that can request certificates to devices whose Mobile/Desktop App has the custom private key installed.
configured in these applications
- Identity Manager Operator
- Identity Manager Admin
- obsolete in these applications and tools
  - Identity Manager Tenant (referenced but not used - can be removed, if present)
  - batch_migration_smartact_to_prime (referenced but not used - can be removed, if present)
certificate requirements
- n/a