Page Comparison

TODO: Write some high level description of the engine here

This article describes the sign and encrypt engine in Smart ID Identity Manager. There are a number of use cases in Identity Manager that are based on encryption or signing, for example:

...

The sign and encrypt engine provides a consistent configuration of keys and certificates for both signing and encryption. You can define algorithms and parameters and reference keys from an HSM (for most use-cases) or from PKCS#12 files (always supported).

Bootstrapping Requirements

...

Important: Most descriptors need to have their certificates and keys bootstrapped before starting the application(s) for the first time.

IDM 24.R1 makes a number of significant changes:

• PKCS#12 files containing demo keys are no longer included to avoid them ending up in productive environments.

• Various checks are introduced - see Sign and Encrypt engine bootstrap verification:

  • The old demo keys are explicitly blacklisted and IDM will print an error log message, if any of those is encountered on startup of IDM Operator and IDM Admin.

  • IDM Admin and IDM Operator will no longer start without bootstrapping, as most descriptors have missing keys/certs by default.

  • IDM Admin and IDM Operator check on startup whether the configured key for encrypted fields matches the database and will abort if that is not the case.

  • IDM Operator checks on startup if the currently configured key for history signing matches the database and will abort if that is not the case.

• Bootstrap CA/certificate/key generation tooling has been refined, it now works properly on Docker and is limited to dev-/test-use (see Bootstrapping Development And Test Systems).
  For productive environments manual bootstrapping via Certificate Authorities is required - see Descriptors of the sign and encrypt engine for details.

• Pin scrambling of signencrypt.xml now works in Docker deployments via dedicated tooling. See Scramble sensitive data in Identity Manager files.

• Each descriptor now references its own key by default, instead of e.g. ZIP signing and history signing sharing the same key.

Whenever object history entries or secrets were created with the demo keys, a simple bootstrapping is no longer possible without resigning the object history (using the batch_re-sign_history tool) and re-encrypting the secrets (using the batch_secretfieldstore_change_encryption_key tool, see Change Encryption key of secret field store).

Bootstrapping Productive Systems

Bootstrapping of productive systems involves use of various certificate authorities to generate keys and issue certificates used by IDM.

Most descriptors, such as EncryptedFields and ObjectHistorySigner, always require proper bootstrapping for secure operation. However, depending on the subset of IDM features to be used, certain descriptors may be configured with placeholder keys and certificates (e.g. SignEmailDescriptor, if E-Mail signing in IDM is not enabled).

See Descriptors of the sign and encrypt engine detailing the specific requirements for each descriptor.

Bootstrapping Dev/Test Systems

For development- and test-environments, test keys and certificates for all default descriptors can be generated using features of the IDM bootstrap.zip package and bootstrap Docker container, see Bootstrapping Development And Test Systems .

...

Additional Information

...