Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 20 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.
A live attack is a security compromise in KERI that targets cryptographic keys currently in active use—either the current signing keys used for non-establishment events or the current pre-rotated keys needed to sign subsequent establishment events—representing an active threat to identifier control authority.
A live attack represents a critical security threat in key management systems where an adversary compromises cryptographic key material that retains current control authority over an identifier. In the context of KERI (Key Event Receipt Infrastructure), a live attack specifically targets keys that are either actively being used for signing operations or are designated for immediate future use in key rotation events.
The term "live" distinguishes this attack category from attacks on keys that have been rotated away or are otherwise no longer in active use. A live attack poses an immediate security risk because the compromised keys can be used to sign fraudulent events that appear legitimate to validators who have not yet detected the compromise.
Active Control Authority: Live attacks target keys that currently possess control authority over an AID (Autonomic Identifier). This means the compromised keys can sign valid events that will be accepted by validators following the normal KERI protocol.
Two Attack Surfaces: KERI's architecture creates two distinct targets for live attacks:
Temporal Sensitivity: The "liveness" of an attack is time-dependent. Keys that are compromised become part of a dead attack once the key state has been rotated to new keys, making the temporal window of vulnerability a critical security consideration.
Implementing live attack detection requires careful coordination between multiple KERI components:
Witness Receipt Validation: Validators must collect and compare receipts from multiple witnesses to detect duplicity. Implementation should include timeout mechanisms to handle network delays and witness unavailability.
Duplicity Evidence Storage: Systems should maintain records of detected duplicity as evidence of live attacks. This evidence is critical for forensic analysis and dispute resolution.
Key Rotation Triggers: Automated systems should trigger key rotation when duplicity is detected, though human oversight is recommended for high-security applications to prevent automated exploitation.
Watcher Query Strategies: Validators should query multiple independent watchers, not just controller-designated witnesses, to detect live attacks that may have compromised the witness pool.
Pre-Rotated Key Storage: The security of pre-rotated keys is critical. These keys should be stored in separate secure environments from current signing keys to prevent simultaneous compromise.
Witness Selection: Controllers should select witnesses that are operationally and administratively independent to prevent coordinated compromise during live attacks.
Rotation Authority Separation: For high-security applications, consider using custodial rotation to separate signing authority from rotation authority, limiting live attack impact.
Threshold Configuration: The TOAD parameter should be set based on threat model—higher values provide better live attack detection but require more witnesses and increase latency.
Regular Key Rotation: Establish rotation schedules appropriate to the threat model. More frequent rotation reduces the temporal window for live attacks.
Duplicity Monitoring: Implement continuous monitoring for duplicity evidence across witness and watcher networks.
Incident Response: Develop procedures for responding to detected live attacks, including key rotation, stakeholder notification, and forensic analysis.
Key Compromise Indicators: Establish monitoring for indicators of key compromise (unusual signing patterns, unexpected event promulgation, etc.) to enable early live attack detection.
A live attack is bounded by the current key state of an identifier. Once a rotation event successfully changes the authoritative keypairs, any compromise of the previous keys transitions from a live attack to a dead attack. This temporal boundary is enforced through KERI's key event log (KEL) structure, where each establishment event cryptographically commits to the next set of keys through pre-rotation.
The scope of a live attack is limited to operations that the compromised keys are authorized to perform. Current signing keys can only sign interaction events, while pre-rotated keys can only be used for the next rotation event. This separation of concerns is a fundamental security property of KERI's architecture.
The concept of live key compromise has been a persistent challenge in public key infrastructure (PKI) systems since their inception. Traditional PKI systems using Certificate Authorities (CAs) face the problem that once a private key is compromised, the attacker can impersonate the legitimate key holder until the compromise is detected and the certificate is revoked.
Early self-certifying identifier systems, which cryptographically bind identifiers to public keys, faced a fundamental limitation: if the private key was compromised, the identifier itself became permanently compromised because there was no mechanism for key rotation. This made live attacks catastrophic—once an attacker gained control of the private key, they permanently controlled the identifier.
Blockchain-based identity systems attempted to address this through on-chain key rotation mechanisms, but these introduced new vulnerabilities. The rotation authority typically resided in the currently exposed keys, meaning a live attack could compromise not just current operations but also the ability to rotate to new keys, effectively locking out the legitimate controller.
Certificate Transparency (CT) systems introduced the concept of public logs that could detect fraudulent certificate issuance, but these systems operate at the certificate level rather than the key level. They can detect when a CA issues a duplicate certificate, but they cannot prevent an attacker who has compromised a private key from using that key to sign fraudulent data.
KERI's architecture provides sophisticated defenses against live attacks through multiple complementary mechanisms that work together to detect, prevent, and recover from key compromise.
Pre-rotation is KERI's foundational defense against live attacks. In each establishment event, the controller commits to the next set of keys by including cryptographic digests of those keys in the current event. Critically, these next keys are not exposed until they are actually used in a subsequent rotation event.
This creates a powerful security property: even if an attacker compromises the current signing keys and the current pre-rotated keys (a complete live attack), they cannot prevent the legitimate controller from rotating to a new set of keys if the controller has additional pre-rotated keys held in reserve through partial rotation.
The pre-rotation mechanism provides post-quantum security against live attacks because the unexposed pre-rotated keys are protected by one-way hash functions. An attacker who compromises current keys cannot work backward to discover the pre-images of the committed key digests, even with a quantum computer.
KERI's witness infrastructure provides real-time detection of live attacks through duplicity detection. When an attacker uses compromised keys to sign fraudulent events, they must choose between two strategies:
Attempt to hide the attack: Create fraudulent events but not promulgate them to the legitimate controller's witnesses. This limits the attack's effectiveness because validators will not see the fraudulent events.
Promulgate fraudulent events: Send the fraudulent events to witnesses, but this creates detectable duplicity when the legitimate controller also sends events to the same witnesses.
The KAACE (KERI's Agreement Algorithm for Control Establishment) consensus mechanism ensures that witnesses maintain consistent views of the KEL. When duplicity is detected—meaning two different versions of the same event exist—this provides immediate evidence of a live attack.
The threshold of accountable duplicity (TOAD) parameter allows controllers to specify how many witnesses must confirm an event before it is considered established. This creates a security threshold where an attacker must compromise not just the controller's keys but also a sufficient number of witnesses to successfully execute a live attack without detection.
Watchers operate in "promiscuous mode," maintaining copies of KELs without being designated by controllers. This creates an ambient duplicity detection network where any validator can query multiple independent watchers to verify KEL consistency.
For live attacks, watcher networks provide a critical defense: even if an attacker compromises a controller's keys and successfully promulgates fraudulent events to the controller's designated witnesses, independent watchers may detect the duplicity by comparing their copies of the KEL with the fraudulent version.
The first-seen policy implemented by honest watchers creates an immutable record of the first version of each event they observe. This makes it impossible for an attacker to retroactively change the historical record—once a watcher has seen the legitimate version of an event, any subsequent fraudulent version will be detected as duplicity.
KERI supports multi-signature configurations where multiple keypairs must sign each event. This exponentially increases the difficulty of live attacks because an attacker must compromise multiple independent keys simultaneously.
The signing threshold and rotation threshold can be configured independently, allowing controllers to require different numbers of signatures for different types of events. For example, a controller might require 2-of-3 signatures for interaction events but 3-of-3 signatures for rotation events, making live attacks on rotation authority more difficult.
KERI's delegation mechanism enables hierarchical key management where a root identifier delegates authority to subsidiary identifiers. This creates a bivalent key management infrastructure where compromise of a delegated identifier's keys (a live attack at the delegated level) does not compromise the delegating identifier.
The delegating identifier can revoke the delegation through a rotation event, effectively recovering from the live attack on the delegated identifier. This provides organizational resilience where different operational contexts can use different identifiers with different security profiles, and compromise of lower-security identifiers does not cascade to higher-security root identifiers.
In practice, live attacks in KERI systems are detected through duplicity evidence. When a validator queries witnesses or watchers and receives conflicting versions of events, this indicates either a live attack or a network partition. The validator must then:
The legitimate controller, upon detecting that their keys have been compromised (evidenced by duplicity detection), must immediately rotate to new keys using their pre-rotated keypairs. This rotation event, when properly witnessed and confirmed, establishes a new key state that the attacker cannot forge because they do not possess the pre-rotated keys.
Live attack protection involves several practical trade-offs:
Witness Configuration: More witnesses provide better duplicity detection but increase operational complexity and latency. Controllers must balance security requirements against operational efficiency.
Key Storage Security: Pre-rotated keys must be stored securely but remain accessible for rotation. This often involves using hardware security modules (HSMs) or trusted execution environments (TEEs) for high-security applications.
Rotation Frequency: More frequent rotations reduce the window of vulnerability for live attacks but increase operational overhead. Controllers must determine appropriate rotation schedules based on their threat model.
Multi-Signature Complexity: While multi-signature configurations provide stronger protection against live attacks, they increase the complexity of key management and the risk of losing access if multiple keys are lost.
Different applications have different live attack threat models:
High-Value Identifiers: Root organizational identifiers or identifiers controlling significant assets should use maximum protection: multi-signature configurations, large witness pools, frequent rotation, and HSM-based key storage.
Operational Identifiers: Identifiers used for day-to-day operations might use delegated identifiers with moderate security, accepting higher live attack risk in exchange for operational flexibility.
Ephemeral Identifiers: Short-lived identifiers for specific transactions might use minimal protection, as the temporal window for live attacks is inherently limited.
Custodial Arrangements: Custodial rotation enables splitting signing authority (held by a custodian) from rotation authority (held by the owner), limiting the impact of live attacks on custodial keys while preserving owner control.
When a live attack is detected, KERI's recovery procedure leverages pre-rotation:
This recovery mechanism is post-quantum secure because the attacker cannot forge the rotation event without the pre-rotated keys, which are protected by one-way hash functions committed in previous events.