Skip to content
FaceOff Technologies

PharmaQR

Post-quantum anti-counterfeiting for pharmaceutical packaging. Every strip carries a Dilithium2-signed QR issued under a five-layer key hierarchy, and a consumer scan has to clear four independent locks before a verdict is shown — with operational batch data and signing secrets kept off central infrastructure

Product Walkthrough
0:000:00

What it is

Four locks between a patient and a counterfeit strip

A fake strip reaches a patient with nothing in the supply chain able to tell it apart from the real one. Plain printed serials and unsigned QR codes can be reproduced, and a database lookup cannot distinguish an original pack from a duplicate reprint.

PharmaQR signs every strip with Dilithium2 (ML-DSA-44, FIPS 204) under a five-layer key hierarchy — Root CA, manufacturer, quarterly sub-key, batch, strip — and a consumer scan has to clear four independent locks before any verdict is rendered: the post-quantum signature, the brand-to-key binding, app attestation with TLS certificate pinning, and a signed, encrypted verdict channel.

The server stays thin. The central identity registry holds cryptographic identities and public records; operational batch data remains on manufacturer infrastructure, and strip HMAC tokens and signatures are never written to a database at all — they are recomputed from batch key references on demand.

Cryptography proves the data on a strip is authentic; it does not stop a printed QR being physically cloned onto fake packaging. Lock 5 — a Copy Detection Pattern printed at press limits, paired with an inner-pack confirmation code — is designed and currently unbuilt.

ML-DSA-44 under FIPS 204, verified against the standard — no classical fallback

Dilithium2

ML-DSA-44 under FIPS 204, verified against the standard — no classical fallback

p95 verification latency, against a p95 target under 500 ms

56.5 ms

p95 verification latency, against a p95 target under 500 ms

QR generation throughput, about 4.3 ms per strip

13,894 / min

QR generation throughput, about 4.3 ms per strip

Internal code audit: 51 pass, 2 partial, 0 fail — both partials procurement-bound

51 of 53

Internal code audit: 51 pass, 2 partial, 0 fail — both partials procurement-bound

How it works

From a scan at the counter to a verdict that was proven first

  1. 01

    Scan the strip

    No account, no registration, no consumer PII requested

  2. 02

    Lock 1 · Signature

    Dilithium2 verified to standard; no classical fallback

  3. 03

    Lock 2 · Brand binding

    SHA-256 fingerprint over batch key, composition, pack size, manufacturer

  4. 04

    Lock 3 · Channel

    SPKI SHA-256 pinning with Play Integrity or App Attest

  5. 05

    Lock 4 · Verdict

    HMAC recomputed, signed with root Ed25519, then encrypted

  6. 06

    Result on screen

    Signature checked by the client before anything is rendered

What sets it apart

Ordered by impact, most decisive first

  1. Post-quantum signing, with no classical fallback

    Strips are signed with Dilithium2 (ML-DSA-44, FIPS 204) through a validated post-quantum cryptographic library. An unknown algorithm raises a hard error rather than degrading to a classical signature, and the backend runs strict cryptographic self-tests at startup. A strip signed today keeps its proof for the whole of its shelf-life.

    Flagship capability · ML-DSA-44 under FIPS 204

  2. Four-lock consumer verification

    A scan has to clear signature validation, brand-to-key binding, app attestation with TLS certificate pinning, and a signed and encrypted verdict channel. Locks 1 and 2 fail to COUNTERFEIT, Lock 3 fails to HTTP 403, and Lock 4 fails as a tampered response — the client verifies the root Ed25519 signature before it renders anything.

    Four independent checks · all must pass

  3. Five-layer key hierarchy

    Root CA, manufacturer, quarterly sub-key, batch, strip. Quarterly keys are API-enforced to a maximum of 1095 days with daily rotation alerts, so a compromised batch can be revoked without touching adjacent production lines.

    Quarterly sub-keys capped at 1095 days

  4. Zero secret storage

    Strip HMAC tokens and signatures are never stored in a database. They are recomputed from batch key references on demand, so there is no table of live secrets for an attacker or a subpoena to reach.

    Recomputed on demand, never persisted

  5. HSM-backed key protection

    Keys are held in a certified hardware security module over PKCS#11. Master wrapping keys never leave the module, and plaintexts are zeroed in memory immediately after use.

    Certified HSM · PKCS#11

  6. Offline verification

    On-device verification runs against cached identity-registry snapshots with a 24-hour TTL, with a single OCSP-style certificate check per scan. Where certificate status cannot be reached, the result is shown as a yellow partial banner rather than a false GENUINE.

    24h cached snapshot · partial banner, not a guess

  7. Append-only audit

    Insert-only audit rules are verified when the backend starts. Modification and deletion are explicitly restricted, so the history a regulator pulls is the history that was written.

    INSERT-only rules verified at startup

  8. Quota enforcement and four-way reconciliation

    Per-batch signing limits are enforced with row-level locks, and reconciliation compares four tallies against each other — authorised, issued, invoiced and scanned — so an over-run shows up as a mismatch rather than as extra stock.

    Authorised · issued · invoiced · scanned

  9. Per-admin isolation

    Multi-tenant queries are scoped per administrator, and a record that is not yours returns HTTP 404 rather than 403 — so the API does not leak the existence of another manufacturer's batches.

    404 rather than 403 on non-owned records

How it compares

Measured against what the industry ships today

Against printed serials, holograms, QR signed with classical cryptography, and cloud track-and-trace serialisation.

  • Verification without a network

    Plain QR or serial
    NoNeeds a lookup
    Hologram
    YesVisual check
    Classically signed QR
    PartlyDepends on the client
    Cloud track & trace
    NoCloud lookup
    PharmaQR
    YesCached registry snapshot
  • Post-quantum signature

    Plain QR or serial
    NoUnsigned
    Hologram
    NoNo cryptography
    Classically signed QR
    NoClassical only
    Cloud track & trace
    NoClassical only
    PharmaQR
    YesDilithium2 · FIPS 204
  • Operational batch data stays local

    Plain QR or serial
    NoCentral database
    Hologram
    NoNo data layer
    Classically signed QR
    NoCentral database
    Cloud track & trace
    NoVendor cloud
    PharmaQR
    YesThin server
  • Signed and encrypted verdict channel

    Plain QR or serial
    NoPlain response
    Hologram
    NoNo verdict
    Classically signed QR
    NoPlain response
    Cloud track & trace
    NoPlain response
    PharmaQR
    YesRoot Ed25519, then encrypted
  • Signing secrets held in hardware

    Plain QR or serial
    NoNo keys
    Hologram
    NoNo keys
    Classically signed QR
    PartlyVaries
    Cloud track & trace
    PartlyVaries
    PharmaQR
    YesCertified HSM over PKCS#11
  • Resistance to a photocopied code

    Plain QR or serial
    NoTrivially reprinted
    Hologram
    YesPhysical feature
    Classically signed QR
    NoTrivially reprinted
    Cloud track & trace
    NoTrivially reprinted
    PharmaQR
    NoLock 5 designed, unbuilt

The architecture

Signed under five layers — verified behind four locks

One boundary, and the operational batch data never crosses it

  • Root CA · Dilithium2
  • Manufacturer key
  • Quarterly sub-key · 1095d

At issuance

Batch keypair

Bound to the brand, capped by a signing quota

Serialised

On the pack

Strip QR

HMAC token recomputed on demand, never stored

Thin server

The registry holds cryptographic identities and public records only. Operational batch data stays on manufacturer infrastructure, and operational secret keys are never stored centrally.

  • Lock 1PQ signature
  • Lock 2Brand binding
  • Lock 3TLS + attestation
  • Lock 4Signed verdict

All four have to pass. Any failure returns COUNTERFEIT or is refused at the channel — never a rendered result.

At the point of scan

Signed verdict

Root Ed25519 signature checked before anything renders

Logged
Append-only audit · INSERT only

Evidence and trust

Measured on the bench, then audited line by line

Measured on development infrastructure with a hardware-security-module simulator, and re-tested on 6 June 2026.

QR generation throughput, about 4.3 ms per strip, against a target of 300 per minute

13,894 / min

QR generation throughput, about 4.3 ms per strip, against a target of 300 per minute

Verification latency at p50 and p95, against a p95 target under 500 ms

41.9 / 56.5 ms

Verification latency at p50 and p95, against a p95 target under 500 ms

Tampered strips rejected as COUNTERFEIT — corrupt signature, wrong serial, wrong batch, revoked

4 of 4

Tampered strips rejected as COUNTERFEIT — corrupt signature, wrong serial, wrong batch, revoked

False negatives on genuine strips, against a target of zero

0 of 50

False negatives on genuine strips, against a target of zero

Key ceremony validation checks passed

19 of 19

Key ceremony validation checks passed

A 53-item internal code audit returned 51 pass, 2 partial and 0 fail; both partial findings relate to hardware procurement and production build hardening rather than to the cryptography. A one-off cold start of about 2.1 s occurs on the first HSM key unwrap and cryptographic-library initialisation, before latency settles to the figures above.

Use cases by sector

Who scans, and what it settles for them

Manufacturers

Serialise production runs, set enforceable batch quotas, and revoke a compromised batch without affecting adjacent production lines.

Contract manufacturing

Own-account, loan-licence and toll manufacturing tracked explicitly, with quota alignment under Form 25/28 and Rules 69-A and 74-A.

Brand owners

A BATCH_REGISTERED webhook the moment a batch is created under a registered brand, backed by immutable audit logs.

Distributors and wholesalers

Verify inbound shipments statelessly at any point in the chain, with no query limits and no change to handling.

How the sector deploys it

Pharmacists and consumers

Point-of-dispense verification with no account to create, showing the full product passport and the verified manufacturer identity.

How the sector deploys it

Inspectors and regulators

Export append-only audit histories and four-way reconciliation reports comparing authorised, issued, invoiced and scanned tallies.

How the sector deploys it

Deployment strategy

From the root ceremony to a serialised production run

Six steps, in order. Nothing is signed until the manufacturer, the brand and the quota above it exist.

  1. Root ceremony

    The Root CA is initialised inside the HSM vault — Dilithium2 for the QR chain and Ed25519 for verdict signing — against a 19-check validation protocol.

  2. Manufacturer onboarding

    The manufacturer is registered under a membership agreement with a validated CIN, PAN, GSTIN and drug licence.

  3. Brand binding

    Brand composition, strength and pack size are registered, which is what locks the parameters a later batch can be issued against.

  4. Sub-key issuance

    A manufacturer key and a quarterly sub-key are created, the sub-key API-enforced to a maximum of 1095 days with daily rotation alerts.

  5. Batch keypair

    A batch is initialised against its brand and sub-key with a mandatory signing quota, enforced with row-level locks.

  6. Strip generation

    Strip QRs are generated individually or in bulk within a single lock session, at about 4.3 ms per strip.

Four things pharmaceutical serialisation has to get right

How long the signature lasts, where the operational data sits, how the keys are held, and what an inspector can pull out of it.

Signature lifetime
Dilithium2 (ML-DSA-44, FIPS 204) through a validated post-quantum library, with a hard error rather than a classical fallback on an unknown algorithm. NIST advises migration off RSA and ECC by 2030; a strip signed today can still be on a shelf after it.
Data sovereignty
A thin server. Cryptographic identities and public records stay central, operational batch data stays on self-hosted manufacturer infrastructure, and strip tokens and signatures are recomputed from batch key references rather than stored.
Key protection
A certified hardware security module over PKCS#11, with master wrapping keys that never leave it and plaintexts zeroed in memory. Quarterly sub-keys are API-capped at 1095 days with daily rotation alerts.
What a regulator can pull
Append-only audit rules verified at startup, four-way reconciliation across authorised, issued, invoiced and scanned, and per-admin isolation that returns 404 rather than 403 on records that are not yours.

Frequently Asked Questions

Lock 1 verifies the Dilithium2 (ML-DSA-44) signature against the standard, with no classical fallback. Lock 2 matches a SHA-256 fingerprint over the batch key, composition, pack size and manufacturer, so a valid signature on the wrong product still fails. Lock 3 is SPKI SHA-256 certificate pinning with Play Integrity or App Attest, so an unverified app cannot obtain a verdict. Lock 4 has the server recompute the strip HMAC, sign the verdict with the root Ed25519 key and encrypt it with an ephemeral X25519 key and AES-256-GCM. Locks 1 and 2 fail to COUNTERFEIT, Lock 3 fails to HTTP 403, and Lock 4 fails as a tampered response. The mobile client verifies the root signature before it renders any result.

Book a technical walkthrough

45 minutes with a solutions engineer. No slide deck unless you ask for one.

We use this to schedule the call. It does not enter a marketing sequence.

The rest of the line

More in Zero-Trust Identity

Sign a batch before the shelf-life outlives the cryptography

Pilots cover onboarding, key ceremony execution, single-batch issuance, QA sample scans and performance verification.