Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 81 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Key compromise refers to the unauthorized access to or exposure of private cryptographic keys, or more broadly in KERI, the compromise of any of the three critical key management infrastructures: key pair creation and storage, event signing, or event signature verification.
Key compromise represents a fundamental security failure in cryptographic identity systems where an adversary gains unauthorized access to private key material or the infrastructure that manages it. In traditional PKI systems, key compromise typically refers narrowly to the exposure of private keys themselves. However, KERI adopts a more comprehensive definition that recognizes three distinct infrastructures that must be protected:
When discussing "key compromise" in KERI, the term encompasses potential compromise of any of these three infrastructures, not just the keys themselves. This broader definition reflects KERI's comprehensive approach to security, recognizing that protecting cryptographic keys requires securing the entire lifecycle from generation through verification.
The core properties of key compromise include:
Implementations must protect three distinct infrastructures:
Key Pair Creation and Storage:
Event Signing:
Event Signature Verification:
Key Generation:
Commitment Creation:
Rotation Execution:
Witness Configuration:
Key compromise has been a persistent challenge throughout the history of cryptographic systems. Traditional PKI systems face several fundamental vulnerabilities:
Certificate Authority Compromise: The DNS/CA model relies on trusted third parties whose compromise can affect millions of users. Historical incidents include the DigiNotar breach (2011) where attackers obtained fraudulent certificates for major domains, and the Comodo breach (2011) where attackers obtained certificates for high-value targets.
Key Rotation Vulnerability: Traditional PKI systems face a critical problem during key rotation - the rotation operation itself must be signed by potentially compromised keys. If an attacker compromises a private key, they can rotate to their own keys and permanently capture control of the identifier. This creates a fundamental security gap where the very mechanism designed to recover from compromise becomes the attack vector.
Blockchain Approaches: Distributed ledger systems attempted to address PKI vulnerabilities through algorithmic consensus, but introduced new challenges. Once keys controlling blockchain-based identifiers are compromised, recovery is often impossible without hard forks or governance interventions. The immutability that provides security also prevents recovery.
Detection Challenges: Traditional systems often lack mechanisms for detecting key compromise in real-time. Certificate Transparency logs provide post-facto detection, but cannot prevent the issuance of fraudulent certificates. By the time compromise is detected, significant damage may have occurred.
KERI introduces revolutionary mechanisms specifically designed to address key compromise through multiple complementary strategies:
KERI's most significant innovation for key compromise protection is pre-rotation, which fundamentally changes the security model for key rotation:
Cryptographic Commitment: During each establishment event (inception or rotation), the controller makes a cryptographic commitment to the next set of rotation keys via a digest (hash). This commitment is included in the current event and signed by current keys.
One-Time Use: Pre-rotated keys are used exactly once - only for the next rotation event. After use, they are immediately replaced with a new pre-rotated commitment. This minimizes the exposure window.
Forward Security: Because the pre-rotated keys are committed via one-way hash functions, an attacker who compromises current signing keys cannot determine what the pre-rotated keys are. The cryptographic hiding property of hash functions provides post-quantum security - even a quantum computer cannot reverse the hash to discover the pre-rotated keys.
Recovery Mechanism: If current signing keys are compromised, the legitimate controller can still perform a valid rotation using the pre-rotated keys that only they possess. The attacker, despite controlling the current signing keys, cannot perform a valid rotation because they don't have the pre-rotated keys.
KERI implements sophisticated duplicity detection mechanisms that provide near real-time evidence of key compromise:
First-Seen Policy: Witnesses and watchers implement a "first seen, always seen, never unseen" policy. The first valid event they receive for a given sequence number becomes permanently recorded. If a controller (or attacker with compromised keys) attempts to create conflicting events, this creates observable duplicity.
Witness Consensus: The controller designates a pool of witnesses who must reach consensus on events through KERI's Agreement Algorithm for Control Establishment (KAACE). An attacker who compromises signing keys but not pre-rotated keys cannot create events that will achieve witness consensus if the legitimate controller is also attempting operations.
Watcher Networks: Independent watchers monitor witness pools and detect inconsistencies across different witnesses. This creates an "ambient duplicity detection" capability where any-body, any-where, any-time can detect if a controller has created conflicting versions of their key event log.
Judge and Jury Mechanisms: When duplicity is detected, particularly after a key rotation event, KERI's judge and jury components can evaluate the conflicting event logs and determine which represents the legitimate controller's actions versus attacker actions.
KERI enables threshold signature schemes that dramatically increase the difficulty of successful key compromise:
Multi-Signature AIDs: Controllers can use M-of-N threshold signatures where multiple keys must be compromised simultaneously for an attacker to gain control. For example, a 2-of-3 threshold requires an attacker to compromise at least 2 of the 3 keys.
Witness Thresholds: The Threshold of Accountable Duplicity (TOAD) requires a minimum number of witness confirmations before events are considered valid. This prevents attackers from using compromised keys to create events that bypass witness validation.
Bivalent Key Management: KERI supports hierarchical delegation where different keys have different security levels. High-value root keys can be stored in highly secure environments (HSMs, air-gapped systems) while delegated keys used for routine operations can be more accessible. Compromise of delegated keys doesn't compromise the root.
KERI architecturally separates two types of authority:
Signing Authority: Current keys used for signing non-establishment events (interactions) and authenticating operations. These keys are more exposed through regular use.
Rotation Authority: Pre-rotated keys used exclusively for establishment events (rotations). These keys can be stored in highly secure environments and never exposed until needed.
This separation means that compromise of signing keys (the more likely scenario due to their regular use) does not automatically grant rotation authority. The attacker must compromise both the current signing keys AND the pre-rotated keys to fully capture control.
When key compromise is detected, KERI provides structured recovery mechanisms:
Superseding Rules: The KERI specification defines clear rules for how to handle conflicting events and determine which version of the key event log represents the legitimate controller's actions.
Reconciliation Process: Controllers can decide whether to accept a fork of their KEL, potentially recovering their identifier rather than abandoning it entirely. This process has limited visibility - only a small number of parties observe the recovery actions.
Witness Rotation: If witnesses themselves are compromised or collude with attackers, the controller can rotate to a new witness pool through a valid rotation event signed with pre-rotated keys.
The comprehensive approach to key compromise protection has significant practical implications:
High-Value Identity Systems: Organizations managing legal entity identifiers (like GLEIF's vLEI system) require robust key compromise protection because identifier compromise could enable fraud, unauthorized transactions, or regulatory violations. KERI's pre-rotation and duplicity detection provide the necessary security guarantees.
Long-Lived Identifiers: Identifiers that must remain valid for years or decades face increasing probability of key compromise over time. KERI's recovery mechanisms enable persistent identifiers that can survive compromise events without requiring identifier abandonment.
Multi-Party Control: Organizations with distributed authority (boards of directors, multi-signature treasuries) benefit from threshold structures that prevent single points of compromise while maintaining operational efficiency.
Regulatory Compliance: Systems subject to regulations requiring non-repudiation and audit trails benefit from KERI's duplicity detection, which provides cryptographic evidence of compromise attempts.
Proactive Protection: Pre-rotation provides protection before compromise occurs, rather than relying solely on detection and response.
Post-Quantum Security: The cryptographic hiding of pre-rotated keys provides protection against future quantum computing attacks, addressing a threat that will eventually compromise current public key cryptography.
Decentralized Recovery: Unlike blockchain systems requiring governance interventions or traditional PKI requiring certificate authority actions, KERI enables controllers to recover from compromise autonomously.
Ambient Verifiability: Any party can independently verify the integrity of a key event log and detect duplicity without requiring access to centralized infrastructure or trusted third parties.
Graduated Security: The separation of signing and rotation authority, combined with threshold structures and delegation, enables organizations to implement security appropriate to their risk profile without sacrificing usability.
Complexity: KERI's comprehensive approach to key compromise protection introduces complexity in key management. Controllers must securely manage both current signing keys and pre-rotated keys, with different security requirements for each.
Operational Overhead: Witness pools, watcher networks, and threshold signatures require additional infrastructure and coordination compared to simple single-signature systems.
Recovery Visibility: While KERI enables recovery from key compromise, the recovery process may be observable by witnesses and watchers, potentially revealing that a compromise occurred (though with limited visibility compared to public blockchain recovery).
Key Storage Requirements: Pre-rotation requires secure storage of keys that won't be used until future rotation events, potentially years in the future. This long-term storage requirement demands robust key management practices.
Coordination Challenges: Multi-signature and witness threshold systems require coordination among multiple parties, which can introduce latency and operational complexity, particularly for time-sensitive operations.
Despite these trade-offs, KERI's approach represents a fundamental advancement in addressing the key compromise problem that has plagued cryptographic identity systems since their inception. By combining pre-rotation, duplicity detection, threshold structures, and clear recovery procedures, KERI provides a comprehensive framework for building identity systems that can survive key compromise events while maintaining cryptographic verifiability and decentralized control.
Watcher Deployment:
First-Seen Policy:
Compromise Detection:
Recovery Execution:
Post-Recovery: