Keys and key storage

The service generates and holds the keys it computes with. The caller gets a key ID and, for key pairs, the public key. This page describes how long a key lives, how it's protected, and what that means for operations.

• Key ID (key_id): an unsigned 32-bit number a request uses to refer to a key inside the service. The value 0 is never a valid key ID.
• Key store: the in-memory table that maps key IDs to keys.
• Nonce: the 12-byte number-used-once of AES-GCM. Using the same nonce twice with the same key reveals the authentication key and the XOR of both plaintexts.

1. Generate. Key generation draws the key material from OpenSSL's random number generator and puts it in the key store. For which key types each form can generate, see Deployment forms compared.
2. Assign an ID. The service picks the ID at random, not sequentially, so nobody who lacks an ID can find one by counting.
3. Use. Signing, decapsulation, and AES operations name the ID. The private key never leaves the service.
4. Read the public key. For ML-DSA and ML-KEM keys, the service returns the public key. The same request fails for an AES key.
5. End. The service has no way to delete an individual key. All keys end with the process. When the service releases key material, it overwrites it with zeros.

Because nothing is persisted, every key ID is invalid after a restart. If signatures must stay verifiable across restarts, your application has to keep the public key itself and have new keys generated after the restart.

For each AES key, the service remembers the last 1024 nonces it encrypted with and rejects encryption with any of them. That catches programming errors, such as a nonce hard-coded in source. It isn't complete protection:

• The service no longer recognizes a nonce older than the last 1024.
• In the L4Re form, the caller supplies the nonce and is responsible for its uniqueness; a counter or 12 bytes from a vetted random number generator are the usual approaches.
• The Windows form generates every nonce itself from 12 random bytes. Per NIST SP 800-38D, a key used with random nonces should encrypt no more than 2³² messages.

• Short-lived keys are a good fit. Session keys, keys for a single exchange, and demonstration keys are what this key store is for.
• Long-lived signing keys aren't. The key of a certificate authority, or any key whose signatures must remain valid for years, belongs in a hardware security module. For certificate authorities, ETSI EN 319 411-1 requires an evaluated secure cryptographic device; a software process doesn't qualify.
• The process is the security boundary. Whoever can read the service's memory can read the keys. On L4Re, the microkernel isolates the tasks; on Windows, only the user account the service runs under protects them.

• The individual requests for generating keys and reading public keys; see L4Re binary protocol and Windows JSON protocol.

• NIST SP 800-38D: Galois/Counter Mode (GCM) and GMAC
• ETSI EN 319 411-1: Policy and security requirements for Trust Service Providers issuing certificates