Duplicity Detection

Duplicity is the main threat that KERI is designed to expose. This article explains what duplicity is, how KERI makes it detectable, what a verifier should do when it is detected, and what Foundry shows today.

What is Duplicity?

A key event log (KEL) should be a single, linear chain of events. Duplicity occurs when two or more conflicting versions of an identifier’s KEL exist: two different events, each signed with the identifier’s keys, at the same position in the log.

Version seen by verifier A:  Inception → Event 1 → Event 2 → Event 3
Version seen by verifier B:  Inception → Event 1 → Event 2 → Event 3'
                                                             ↑
                                                        Fork point

Duplicity can arise in several ways:

• A dishonest controller signs two versions of an event and shows each version to a different party.
• An attacker who has the current signing keys signs events of their own alongside the controller’s events.
• An attacker who has both the current and the pre-rotated next keys rotates the identifier to keys of their own.

Both versions carry valid signatures from the identifier’s keys. Anyone who holds both versions can therefore prove that the identifier’s keys signed conflicting events.

How KERI Makes Duplicity Detectable

Pre-Rotation Limits What Stolen Keys Can Do

Each establishment event (inception or rotation) commits to the next keys by publishing a digest of them. An attacker who has only the current signing keys can sign events with them, but cannot rotate the identifier, because a valid rotation must reveal keys that match the earlier commitment.

The legitimate controller recovers by rotating to the pre-committed next keys. Under KERI’s recovery rules, this rotation can supersede interaction events that were signed with the compromised keys after the last rotation, and the compromised keys can no longer sign for the identifier.

Witnesses Receipt the First Version They See

The controller designates witnesses and a receipt threshold in the KEL. Each witness keeps the first version of an event it sees at a given position and signs a receipt only for that version. A verifier accepts an event when it carries receipts from at least the threshold number of the controller’s witnesses.

Witnesses do not vote and do not decide which version is legitimate; they only issue receipts. With a threshold above one, a single faulty or compromised witness cannot make an event appear fully receipted on its own, and it is hard to get two conflicting versions of the same event fully receipted.

Watchers Compare What They See

Watchers work on behalf of verifiers. A watcher keeps its own copy of the KELs it watches and collects events and receipts from witnesses and other sources. It follows the KERI rule “first seen, always seen, never unseen”: it keeps the first version of each event it receives. If it later receives an event that conflicts with the version it holds, it has detected duplicity and can report it to the verifiers that rely on it.

Because watchers are independent of the controller, a controller cannot easily show one version of its log to some verifiers and a different version to others without the conflict becoming visible.

When Duplicity Is Detected

KERI makes duplicity provable. Deciding what to do about it is up to each verifier. A careful verifier should:

1. Stop relying on the identifier after the fork point. Do not accept new signatures, key changes or credentials from it until the situation is resolved.
2. Keep the evidence. Retain both conflicting versions, with their signatures and receipts.
3. Contact the controller through a separate channel to find out whether its keys were compromised.
4. Wait for recovery, or treat the identifier as compromised. If only the current signing keys were compromised, the controller can recover by rotating to the pre-committed next keys. Check the identifier’s key state again before relying on it.
5. Review dependent credentials. Do not trust credentials issued or signed by the identifier after the fork point until its key state is clear.

When Recovery Is Not Possible

If an attacker obtains both the current keys and the pre-rotated next keys, the attacker can rotate the identifier to keys of their own. A non-delegated identifier cannot be recovered in that case. The controller must stop using it, create a new identifier and tell relying parties which identifier replaces it, and verifiers should stop trusting the old one.

A delegated identifier has an additional safeguard: each of its rotations takes effect only when its delegator anchors the rotation in the delegator’s own KEL.

What Foundry Shows Today

Administrators can see the state of the witness and watcher network on the Network page in the sidebar (page title Network Status):

• Witness Network: each witness that serves the Platform, whether it is online, and whether enough witnesses are online to meet the receipt threshold
• Monitored AIDs: your tenant’s identifiers that the watcher checks, with the status of each, the time it was last checked and a digest of its KEL

The Platform also shows witness and watcher status in other places:

• An enterprise’s page shows witness and watcher status for its Enterprise AID, and its Officers tab shows watcher status for each officer’s AID.
• When a Trustable is verified, the report includes a Witness Receipts check and a Watcher Monitoring check for the issuer’s identifier.

Security Properties

These properties come from the KERI protocol:

• Provable duplicity: conflicting events carry signatures from the same keys, so anyone who holds both can prove that duplicity occurred.
• Recoverable key compromise: pre-rotation lets a controller recover when only its current signing keys are compromised.
• No single trusted witness: with a receipt threshold above one, no single witness can make an event appear fully receipted.
• Availability: multiple witnesses keep a KEL available when some of them are offline.

See KERI Fundamentals for the underlying concepts.