Try the Demo

Security

Threat Model

Althea's threat model is built around four attacker classes. For each, we describe what they want, what they have, and what stops them.

Curious dApp

Wants: learn who its users are.

Has: the wallet address and any data it asks the user for.

Stopped by: the SDK never returns personal data to the dApp. The only Althea-derived datum the dApp ever sees is the attestation boolean and timestamp. The dApp can correlate attestation timing across users it knows, but it cannot link a wallet to a NIN, name, or DOB — that link doesn't exist anywhere in Althea's system.

Compromised Althea Backend

Wants: forge credentials, mint fake attestations, or retroactively dox users.

Has: full server access including the EdDSA private key.

Stopped by: the attacker can sign arbitrary credentials, but cannot reverse history. The backend keeps no logs and no DB rows, so there is nothing to retroactively read. Forged credentials can only verify wallets the attacker controls; Althea's nullifier rule prevents them from claiming the attestation of an existing real user. Detection of forgery is via on-chain anomaly monitoring; recovery is via key rotation and a new program-stored public key.

Mitigation roadmap

Future versions will multi-sig the EdDSA signing key across N independent operators so a single backend compromise does not yield a usable signing key.

Malicious User

Wants: verify multiple wallets with the same identity, or verify with a fake NIN.

Has: a real NIN, plus the ability to manipulate their own client.

Stopped by:

  • Fake NIN: rejected at Dojah lookup. The backend will not sign a credential for a NIN that doesn't resolve.
  • Multiple wallets with same NIN: rejected on-chain. The NullifierRecord PDA is init-only, so a second submission for the same nullifier fails with DuplicateNullifier.
  • Modified SDK that bypasses the circuit: can't help — the Anchor program runs its own proof verification and rejects anything that doesn't verify against the embedded Ax/Ay.

Network Adversary

Wants: intercept user credentials in transit.

Has: position to MITM the user's connection.

Stopped by: HTTPS to the Althea backend. Certificate pinning is recommended for high-risk deployments. The only personal data ever transmitted is during the single POST to /api/verify — once that round trip ends, the credential is no longer in transit anywhere.

Known limitations

  • Althea trusts Dojah to faithfully represent NIMC/CBN data. A compromised Dojah could attest false identities; we accept this dependency because alternatives require direct NIMC access which is not available to most stakeholders.
  • Althea does not prevent a user from voluntarily selling their verified wallet on a secondary market. The protocol enforces one-identity-one-wallet at registration time; the user's subsequent custody is their own responsibility.
  • Althea does not currently handle revocation triggered by NIMC (e.g. a NIN reported as fraudulent after verification). A future version will accept signed revocation messages from Althea operators.