PhysIDDocs

PhysID threat model

v1 sandbox surface. This page is the document enterprise security reviewers should read end-to-end before any pilot conversation.

Trust boundaries

  • Hardware anchor. Post-quantum signed NFC tag or embedded secure element. Private keys never leave the secure element.
  • Identity layer. Concordium agent registry. Operator identity is IDP-verified at account creation and split across independent Privacy Guardians.
  • Local channel. NFC tap (deliberate, mm range) and BLE broadcast (ambient, opt-in metadata only, no identity).
  • PhysID services. API + MCP + shared vault. Vault holds anything needing signing; the API requests operations and never sees raw private keys.

Threats and mitigations

T1 — Tag cloning

Each tag carries a unique key in a tamper-resistant secure element. Cloning requires extracting the key, which the element resists at silicon level. Reissuance through the registry revokes any prior tag bound to the unit.

T2 — Replay of NFC handshake

Every encounter generates a fresh nonce; the tag's response is bound to that nonce and the verifier's public input. A captured payload cannot be replayed against a different verifier or in a different session.

T3 — Ambient broadcast deanonymisation

BLE broadcast (Tier 1) carries class, operator category, jurisdiction, and a rotating session ID. No identity is broadcast. Session IDs rotate on a short interval to defeat long-term tracking.

T4 — Unauthorised disclosure of operator identity

Tier 3 disclosure (full operator identity) requires Concordium Privacy Guardian cooperation under documented procedure. PhysID is not a Privacy Guardian and cannot disclose unilaterally — including under legal compulsion to PhysID alone.

T5 — Compromise of the PhysID service

PhysID does not hold operator private keys; those live in the shared vault, which enforces per-operator authorisation on every signing operation. A full PhysID API compromise yields the ability to enqueue invalid registry calls — which the on-chain registry rejects — but cannot issue valid Concordium transactions on behalf of an operator.

T6 — Compromise of the shared vault

Vault uses standard OpenBao threat-model assumptions: sealed at rest, audit-logged at use, sealed again on restart. Operator keys are encrypted-at-rest with per-operator KEKs that themselves require auth to unwrap.

T7 — Stolen unit / ownership transfer

Ownership transfer requires both old and new operator to co-sign a transfer transaction on Concordium. A stolen unit cannot be transferred without the original operator's signature; revoke via POST /v1/registry/{unit_id}/revoke is the response path.

T8 — Offline verification accepting revoked tags

Offline verifiers accept cached credentials with a stated freshness bound. Verifiers connecting later check on-chain status and surface revocations retroactively. Tier 2 NFC responses include the cache freshness in milliseconds so callers can decide whether offline acceptance is adequate for the use case.

T9 — Compromise of the Concordium API path

PhysID calls the internal Concordium API where keys are registered, not a public node directly. This means a downstream node compromise cannot trick PhysID into accepting a forged registry response — the response is signed by the internal API and verified by PhysID before the response is returned to the caller.

T10 — Supply-chain compromise of tag production

Tags are personalised by Provenance Tags in a controlled facility. Each tag's key material is generated on-device and never exported. Production lots are signed and the registry records the lot signature at first registration so a later production-chain compromise can be bounded to specific lots.

Privacy posture

  • Sandbox traffic terminates in EU regions (Fly.io ams).
  • PhysID does not log NFC payloads, decode-request bodies, or operator identifiers in plain text beyond what is needed for the immediate response.
  • Per-unit credentials are stored in the on-chain registry, not in a PhysID-private database.
  • Waitlist + sandbox-access submissions are stored in a Fly Postgres cluster in the EU and used only to issue keys + contact.

Disclosure

Security reports → security@physid.ai. We follow coordinated disclosure; responses within 72 hours; we publish a security disclosure document at /.well-known/security.txt.

Open items for v1 → v2

  • Full MCP tool handlers wired to the real API path
  • Production API key issuance flow with per-operator rate limiting
  • Customer dashboard at app.physid.ai for self-serve key + unit management
  • Per-customer audit log surfaced through the dashboard
  • Public encounter receipt explorer (v3)