This document describes the security boundary of iam-core 1.1, wire version 2, and the optional iam-anchor1 profile. It states assumptions and limits, not a certification or a claim that every attack has been examined. SECURITY.md collects the principal weaknesses.
The assets are control of an identity’s signing key, authentic graph operations, reproducible evaluation of a selected history, and an application’s correct use of that result. Identity is the full public key. A name, nick, or four-word seal does not establish a unique person or authenticate an unknown key by itself.
Verification assumes the specified cryptographic primitives remain secure, implementations follow the complete validation rules, and verifiers receive an authentic initial tree identifier and any required anchoring configuration. Signing additionally assumes trustworthy input, execution, randomness where required, secret storage, and coordination of every writer using that key. Application permissions and the binding between a person and a key require their own policy. Valid ACCEPT signatures establish the actor’s action, not the target’s consent or real-world identity.
These labels describe possible capabilities. They are not security levels: a bot operator can control infrastructure, and a corporation or state can also compromise an endpoint.
| Adversary | Capabilities considered | Protection and remaining exposure |
|---|---|---|
| Hostile network or relay | Modify, replay, duplicate, delay, reorder, suppress, or partition traffic; supply malformed records. | Content hashes, signatures, closed schemas, and chain checks reject unauthenticated changes. Suppression can leave a verifier on an old anchor or without usable data. Core validation does not supply delivery or freshness. |
| Bots or bulk attackers | Create arbitrary keypairs, guess many phrases, submit conflicting or expensive inputs, and flood queues. | Verification and bounded resource policies limit what is accepted and retained. IAM has no proof of personhood, Sybil resistance, network rate limiting, or universal denial-of-service guarantee. |
| Corporation or infrastructure operator | Observe accessible graphs, correlate repeated keys and external metadata, control distribution, and fund offline guessing. | Signatures do not provide confidentiality or anonymity. Separate identities can limit direct key reuse, but IAM does not prevent other correlation or a distributor’s censorship. |
| Targeted state or similarly resourced attacker | Concentrate guessing on one person, compromise devices or software delivery, coerce signers, or compromise trusted publishers and members. | IAM does not claim resistance to endpoint compromise or coercion. A stolen root key can produce valid signatures. Resource-rich attackers receive no special cryptographic exclusion. |
The current derivation uses Argon2id with 64 MiB total memory, three iterations, and one lane, followed by HKDF. An attacker who knows or guesses the name can test incantations offline against the public key. The KDF raises each guess’s cost; it does not create missing phrase entropy. Equal names share a salt. Neither a minimum phrase length nor an attacker label supplies a security budget.
P0, P1, and P2 are not adopted derivation profiles in this specification and do not presently promise protection against any row above. Their parameters, identification, reproducibility, and recovery requirements belong in the derivation-profile proposal, with measured costs and explicit assumptions before adoption. Changing derivation changes the resulting identity. Root-key rotation preserving that identity is not provided; recovering with a new key requires new trust relationships.
A signature authenticates a key’s operation; an authorized key can still act maliciously. Fork handling detects conflicting signed children in the selected history, but cannot force a signer to cooperate. Revocation reaches a verifier only through admission, anchoring, and evaluation. Another active path can preserve membership after one parent’s REVOKE.
A compromised axiomatic community member retains its bootstrap authority unless an applicable LEAVE removes it. Other members cannot revoke that axiom; removing it without such a LEAVE requires a new bootstrap. Multiple roots are not a quorum. This member key is distinct from the ephemeral genesis signer: genesis is reserved, is not made a member, and cannot issue applicable ordinary operations in its community. Its prescribed erasure cannot be remotely proved.
prev establishes ordering within one actor’s chain. The deterministic ready
order (m, id) is not proof of causality between actors, and signer-supplied
timestamps do not prove when events occurred. Applications must accommodate
dependent operations that fail because of that ordering.
Core evaluation agrees only for the same complete inputs. It does not select an authoritative history. The optional anchoring profile trusts a pinned publisher to select snapshots; that authority cannot forge member signatures. A publisher can omit records or explicitly replace history. Observed publisher equivocation freezes selection, while withheld evidence can leave peers with different views. Offline authentication proves neither latest state nor the absence of newer revocations. Availability and freshness need runtime policy.
IAM does not encrypt graphs, conceal network metadata, or erase replicated records. LEAVE changes evaluated membership; it does not remove past evidence. Deployment-specific disclosure, retention, authentication, and permission decisions remain outside the core.