# ISO/IEC 11770 Key Management Series **Source**: https://quantumsequrity.com/blog/iso-iec-11770-key-management **Category**: Standards & Documents --- [← Back to Blog](../../blog.html) Standards & Documents # ISO/IEC 11770 Key Management Series 12 min read The hardest part of cryptography is not the math. It is the keys. Generating them, distributing them, storing them, rotating them, retiring them, recovering from compromise. A well-designed system can fail spectacularly because someone left a private key in a public Git repository, or because a 20-year-old root CA expired without a replacement plan. To bring discipline to key management, ISO/IEC 11770 was created. It is a multi-part standard maintained by ISO/IEC JTC 1 / SC 27. Part 1 lays out the framework. Part 2 covers symmetric key establishment (two parties agreeing on a shared secret using symmetric techniques). Part 3 covers asymmetric key establishment (using public-key methods, including the upcoming PQC additions). Part 4 covers weak secrets (password-derived keys). Part 5 covers group key management. Part 6 covers key derivation. This post walks through each part, explains how the framework applies to PQC migration, and shows where QNSQY's design fits the ISO/IEC 11770 model. For organizations operating under international compliance frameworks, ISO/IEC 11770 is the reference for key lifecycle requirements. ## What Key Management Covers Key management is the full lifecycle of a cryptographic key: - **Generation**: producing keys with sufficient entropy from a trusted source - **Distribution / Establishment**: getting keys to the parties who need them - **Storage**: protecting keys at rest from unauthorized access - **Use**: ensuring keys are used only for their intended purpose - **Backup**: enabling recovery from hardware failure - **Rotation**: replacing keys before they exceed their cryptoperiod - **Revocation**: marking compromised keys as no-longer-valid - **Destruction**: securely erasing keys at end of life Each phase has standards and best practices. ISO/IEC 11770 codifies the framework. NIST SP 800-57 (a three-part document) covers the same ground from a US perspective and aligns closely. ## Part 1: Framework ISO/IEC 11770-1:2010 (with revision in progress) is the umbrella document. It defines the model: - **Key types**: data encryption keys (DEKs), key encryption keys (KEKs), authentication keys, signing keys, key agreement keys - **Key states**: pre-active, active, suspended, deactivated, compromised, destroyed - **Trust models**: centralized (single key authority), distributed, hierarchical - **Cryptoperiods**: how long a key is valid before mandatory rotation The 2010 version is being revised to incorporate post-quantum considerations. Expected publication: 2026 to 2027. ## Part 2: Symmetric Key Establishment ISO/IEC 11770-2:2018 covers symmetric techniques for establishing shared keys. This includes: - **Pre-shared keys (PSK)**: two parties manually exchange a key via secure channel - **Key derivation from a master key**: HKDF-style derivation for session keys - **Symmetric key transport**: one party generates the key, encrypts it under another shared key, sends it - **Key wrap**: AES-KW (RFC 3394) for protecting keys with keys Symmetric key establishment is fundamental but limited: it requires a prior secure channel for the initial key. That is why most modern systems use asymmetric methods for initial establishment, then derive symmetric session keys. QNSQY uses symmetric key derivation extensively: the file encryption key (FEK) is derived from the KEM shared secret using HKDF-SHA-256, and the MAC key is derived alongside. Both follow Part 2 patterns. ## Part 3: Asymmetric Key Establishment ISO/IEC 11770-3:2021 is the most actively used part. It covers asymmetric methods including: - **Diffie-Hellman**: classical DH and ECDH - **RSA-based key transport**: encrypt a key with the recipient's RSA public key - **MQV** (Menezes-Qu-Vanstone): authenticated DH variant - **El-Gamal-based key transport**: less common - **PQC KEMs**: ML-KEM, HQC, in upcoming amendments The PQC amendments are the big change for Part 3. Draft amendment will add ML-KEM-512, ML-KEM-768, ML-KEM-1024 with hybrid mode guidance. HQC will follow once ISO/IEC 18033-2 standardizes it. See [ISO/IEC 18033](../iso-iec-18033-encryption.html). For QNSQY users, key establishment uses ML-KEM (post-quantum) plus X25519 (classical ECDH) in hybrid mode. The shared secrets from each are combined with HKDF. This satisfies both classical and upcoming PQC requirements in Part 3. See [hybrid encryption](../hybrid-encryption.html). ## Part 4: Weak Secrets ISO/IEC 11770-4:2017 covers key establishment from weak secrets, primarily passwords. It standardizes: - **Password-Authenticated Key Exchange (PAKE)**: protocols where both parties have the password and end up with a strong shared key, but eavesdroppers cannot brute-force - **Augmented PAKE**: where the server stores a verifier, not the password itself - **SRP, SPAKE2, OPAQUE**: specific PAKE protocols (some are in revision) PAKE is increasingly important. Traditional password authentication transmits a hash of the password to the server, which is vulnerable to phishing and server compromise. PAKE protocols never transmit anything that helps an attacker offline. QNSQY uses Argon2id (RFC 9106) for password-based key derivation when a user encrypts with a password. Argon2id is memory-hard, defeating GPU and ASIC brute-force attacks. The derived key is then used as the symmetric key for AES-256-GCM or ChaCha20-Poly1305 encryption. This is a Part 4 pattern: deriving a strong key from a weak secret. ## Part 5: Group Key Management ISO/IEC 11770-5:2020 covers group key management. Use cases: - Conference calling encryption (multiple participants share a key) - Multicast / broadcast encryption (one sender, many receivers) - Group messaging (Signal groups, MLS) Group keys are harder than two-party keys because: - Joining: a new member needs the current group key - Leaving: when a member leaves, the group key must change so the departed member cannot decrypt future messages - Forward secrecy: even compromise of the current key should not reveal past keys IETF MLS (RFC 9420) is the modern protocol for group messaging E2EE. ISO/IEC 11770-5 covers the underlying patterns. See [IETF RFC 9420 MLS](../ietf-rfc-9420-mls.html). QNSQY supports multi-recipient encryption: one encrypted file readable by N recipients, each with their own KEM keypair. This uses Part 5 patterns combined with Part 3 KEM techniques. See the QSPG v2 multi-recipient design. ## Part 6: Key Derivation ISO/IEC 11770-6:2016 covers key derivation. Algorithms include: - **HKDF** (RFC 5869): the dominant derivation function in modern protocols - **NIST SP 800-108 KDFs**: counter, feedback, pipeline modes - **PBKDF2**: password-based, older - **scrypt, Argon2**: memory-hard password-based KDFs HKDF is everywhere. TLS 1.3, Signal protocol, Noise framework, QNSQY, all use HKDF for deriving session keys, traffic keys, and authentication keys from initial shared secrets. Its design is simple (extract-then-expand) and well-analyzed. For PQC, HKDF works without changes. The shared secret produced by ML-KEM is fed into HKDF the same way as a Diffie-Hellman shared secret. This makes the PQC transition cleaner: only the establishment changes, not the derivation. ## Cryptoperiods and Rotation NIST SP 800-57 Part 1 specifies cryptoperiod recommendations that ISO/IEC 11770-1 mirrors: - **Encryption keys (data at rest)**: 1 to 2 years - **Encryption keys (data in transit)**: per-session, derived from key agreement - **Signing keys**: 1 to 3 years for moderate use, longer for low-volume - **Master keys / KEKs**: 5 to 10 years - **Root CA keys**: 10 to 20 years (with strict storage) For PQC, these timelines are similar. The longest cryptoperiods (root CAs, code signing) are the most urgent to migrate to PQC because they need to remain valid for decades. See [harvest now decrypt later](../harvest-now-decrypt-later.html). ## Key Storage and HSMs Where keys live matters as much as how they are generated. ISO/IEC 11770-1 references different protection levels: - **Software-only**: keys in memory, protected by OS access control. Lowest assurance. - **OS-protected**: keys in OS keystores (Keychain, DPAPI, etc.). Better. - **TPM-protected**: keys in a Trusted Platform Module, never extractable in clear. Strong. - **HSM-protected**: keys in a dedicated Hardware Security Module, FIPS 140-3 validated. Highest assurance for software systems. QNSQY today uses software-protected keys with strict zeroization (`Zeroizing<>` wrapper, no Display impl). HSM integration is on the roadmap for Business and Enterprise tiers, with PKCS#11 support planned for 2026. ## Key Backup and Recovery A key that cannot be recovered after disk failure is a liability. But a key that is too easy to recover is a security hole. ISO/IEC 11770-1 calls for balanced backup: - **Encrypted backups**: store keys encrypted under a backup key - **Secret sharing**: split keys using Shamir Secret Sharing (k of n recovery) for high-value keys - **Trusted custodians**: human procedures for accessing the backup - **Audit logs**: every backup access logged QNSQY supports Shamir Secret Sharing for backing up master keys: split into shares, distribute among trusted parties, reassemble when k of n shares are available. This is the standard pattern for high-value key backup. ## Key Compromise Response If a key is compromised, the response sequence: 1. **Detect**: notice the compromise (alert, audit log, intelligence) 2. **Revoke**: mark the key as compromised in revocation lists, OCSP, etc. 3. **Notify**: tell affected parties so they can stop using the key 4. **Rotate**: generate a fresh key for replacement 5. **Re-issue**: update certificates, ACLs, configurations 6. **Investigate**: determine the cause to prevent recurrence CRLs (certificate revocation lists) and OCSP (online certificate status protocol) handle the technical revocation in PKI deployments. ISO/IEC 11770-1 references these mechanisms. QNSQY's billing system has its own revocation: subscription keys can be invalidated server-side, and clients fail closed if they cannot validate. This is Part 1 lifecycle management applied to subscription tokens. ## Key Ceremony Procedures A key ceremony is the formal process for generating, splitting, and provisioning a high-value cryptographic key. ISO/IEC 11770-1 references key ceremonies and ANSSI, NIST, and major commercial CAs publish detailed procedures. For PQC migration, key ceremonies for new master keys are appearing in 2025 and 2026. A typical ceremony for a new ML-DSA-65 master signing key includes: 1. **Ceremony location**: a Faraday-shielded room with no network access, video recording, witnesses representing different roles. 2. **Hardware preparation**: an HSM, in cleared and reset state, verified as the correct firmware version. 3. **Entropy gathering**: hardware RNG output, possibly mixed with dice rolls for additional entropy. 4. **Key generation**: HSM generates the master keypair internally; the private key never leaves the module. 5. **Public key extraction and signing**: the public key is exported and signed by an existing trust anchor (or self-signed for a new root). 6. **Backup share generation**: HSM exports a Shamir-split backup of the private key under a separate KEK. 7. **Share distribution**: each share goes into a tamper-evident envelope, into a separate safe, with separate custodians. 8. **Ceremony documentation**: video, witness statements, and HSM audit logs are sealed and archived. The whole process can take several hours and involves four to seven people. For organisations migrating to PQC, the first ML-DSA or hybrid ML-DSA root key ceremony is typically a major operational event. QNSQY's signing key infrastructure is designed for this kind of ceremony, with HSM-friendly key generation paths and Shamir backup support already in place. The 2026-04-29 signing key rotation followed exactly this pattern. ## Key Management Maturity Model A useful frame for assessing key management posture is the maturity model implicit in ISO/IEC 11770 and NIST SP 800-57. **Level 0 (ad hoc)**: keys live wherever the developer put them. Some are in environment variables, some in config files, some in the source tree. No inventory. **Level 1 (centralised storage)**: a central secrets manager (Vault, KMS) holds keys. Access is gated by ACL. No formal cryptoperiods or rotation schedules. **Level 2 (lifecycle management)**: cryptoperiods are documented. Automated rotation runs on schedule. Audit logs cover every access. Key compromise procedures are written down. **Level 3 (HSM-backed)**: high-value keys live in HSMs. Key ceremonies are formal, witnessed events. Backup keys are split using Shamir Secret Sharing. Compliance evidence is automated. **Level 4 (PQ-ready)**: master keys use hybrid PQ algorithms. Cryptoperiods explicitly account for the harvest-now-decrypt-later threat. Migration plans tie to NIST IR 8547 timelines. Key compromise procedures include PQ regeneration. Most organisations starting PQC migration are at Level 1 or 2. Level 3 typically takes a year or more of investment. Level 4 is the goal state for organisations under CNSA 2.0 mandates. ## FAQ ### Do I need to read all six parts of ISO/IEC 11770? For most engineers, no. Part 1 (framework) and Part 3 (asymmetric establishment) cover the bulk of practical key management. Part 6 (derivation) is useful if you implement KDFs. Parts 4 (PAKE) and 5 (group keys) are specialized. ### Where does PBKDF2 fit? PBKDF2 is in ISO/IEC 11770-4 and NIST SP 800-132. It derives a strong key from a password by iterating a hash function many times. Modern alternatives (Argon2, scrypt) are preferred for new systems, but PBKDF2 is still common for legacy compatibility. ### Does QNSQY follow ISO/IEC 11770? QNSQY's design aligns with the framework: HKDF for all key derivation (Part 6), ML-KEM hybrid for asymmetric establishment (Part 3), Argon2id for password-based keys (Part 4), and multi-recipient encryption using group key patterns (Part 5). The implementation is documented in the QSPG v2 file format. ### How long should I keep an encryption key? Per NIST SP 800-57: 1 to 2 years for data-at-rest encryption keys before rotation. Longer for archival use cases with key wrapping. Session keys live only for the session. The recommended cryptoperiod depends on the threat model: high-value data and long retention need shorter cryptoperiods. ### What is the difference between key transport and key agreement? Key transport: one party generates the key and securely sends it to the other (RSA-based, hybrid public key encryption). Key agreement: both parties contribute to deriving the shared key (Diffie-Hellman, ECDH, ML-KEM is technically encapsulation but functions like agreement). Modern protocols favor key agreement for forward secrecy. ### How does ISO/IEC 11770 handle key escrow? Key escrow is the deliberate copying of a private key to a third party for recovery purposes. ISO/IEC 11770-1 covers escrow scenarios but stops short of recommending escrow for general use because the third party becomes a single point of compromise. For environments that legally or operationally require escrow (some regulated industries, some government contexts), the standard documents the controls needed: split-key escrow with multiple custodians, audit-logged access, formal release procedures. ### Are PAKE protocols quantum-safe? Most current PAKE protocols (SRP, SPAKE2, OPAQUE) are based on Diffie-Hellman or elliptic curve operations and are not quantum-safe. Research on PQ PAKE has been active since 2020 and several candidate protocols (CHIP-CRISP, OPAQUE-PQ, lattice-based PAKE) have been published. None has yet been standardised. For organisations that need PAKE today and are concerned about future quantum threats, the conservative approach is to layer a PQ KEM on top of a classical PAKE, similar to the hybrid pattern in TLS. ## Sources 1. ISO/IEC 11770-1:2010, "Information technology, Security techniques, Key management, Part 1: Framework." https://www.iso.org/standard/53456.html 2. ISO/IEC 11770-3:2021, "IT Security techniques, Key management, Part 3: Mechanisms using asymmetric techniques." https://www.iso.org/standard/82709.html 3. ISO/IEC 11770-4:2017, "IT Security techniques, Key management, Part 4: Mechanisms based on weak secrets." https://www.iso.org/standard/67933.html 4. NIST SP 800-57 Part 1 Rev 5, "Recommendation for Key Management: Part 1, General." https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final 5. IETF RFC 5869, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." https://datatracker.ietf.org/doc/html/rfc5869 6. NIST SP 800-132, "Recommendation for Password-Based Key Derivation." https://csrc.nist.gov/publications/detail/sp/800-132/final 7. IETF RFC 9106, "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications." https://datatracker.ietf.org/doc/rfc9106/ 8. ANSSI, "Recommandations pour la gestion des clés cryptographiques." https://www.ssi.gouv.fr/ ## Related Articles - [ISO/IEC PQC standards](../iso-iec-pqc-standards.html) - [ISO/IEC 19790 modules](../iso-iec-19790-modules.html) - [Hybrid encryption](../hybrid-encryption.html) - [Harvest now decrypt later](../harvest-now-decrypt-later.html) - [NIST FIPS guide](../nist-fips-guide.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)