Manufacturers
Serialise production runs, set enforceable batch quotas, and revoke a compromised batch without affecting adjacent production lines.
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
What it is
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.
Dilithium2
ML-DSA-44 under FIPS 204, verified against the standard — no classical fallback
56.5 ms
p95 verification latency, against a p95 target under 500 ms
13,894 / min
QR generation throughput, about 4.3 ms per strip
51 of 53
Internal code audit: 51 pass, 2 partial, 0 fail — both partials procurement-bound
How it works
01
No account, no registration, no consumer PII requested
02
Dilithium2 verified to standard; no classical fallback
03
SHA-256 fingerprint over batch key, composition, pack size, manufacturer
04
SPKI SHA-256 pinning with Play Integrity or App Attest
05
HMAC recomputed, signed with root Ed25519, then encrypted
06
Signature checked by the client before anything is rendered
What sets it apart
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
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
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
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
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
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
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
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
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
Against printed serials, holograms, QR signed with classical cryptography, and cloud track-and-trace serialisation.
Verification without a network
Post-quantum signature
Operational batch data stays local
Signed and encrypted verdict channel
Signing secrets held in hardware
Resistance to a photocopied code
The architecture
One boundary, and the operational batch data never crosses it
At issuance
Bound to the brand, capped by a signing quota
On the pack
HMAC token recomputed on demand, never stored
The registry holds cryptographic identities and public records only. Operational batch data stays on manufacturer infrastructure, and operational secret keys are never stored centrally.
All four have to pass. Any failure returns COUNTERFEIT or is refused at the channel — never a rendered result.
At the point of scan
Root Ed25519 signature checked before anything renders
Evidence and trust
Measured on development infrastructure with a hardware-security-module simulator, and re-tested on 6 June 2026.
13,894 / min
QR generation throughput, about 4.3 ms per strip, against a target of 300 per minute
41.9 / 56.5 ms
Verification latency at p50 and p95, against a p95 target under 500 ms
4 of 4
Tampered strips rejected as COUNTERFEIT — corrupt signature, wrong serial, wrong batch, revoked
0 of 50
False negatives on genuine strips, against a target of zero
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
Serialise production runs, set enforceable batch quotas, and revoke a compromised batch without affecting adjacent production lines.
Own-account, loan-licence and toll manufacturing tracked explicitly, with quota alignment under Form 25/28 and Rules 69-A and 74-A.
A BATCH_REGISTERED webhook the moment a batch is created under a registered brand, backed by immutable audit logs.
Verify inbound shipments statelessly at any point in the chain, with no query limits and no change to handling.
How the sector deploys itPoint-of-dispense verification with no account to create, showing the full product passport and the verified manufacturer identity.
How the sector deploys itExport append-only audit histories and four-way reconciliation reports comparing authorised, issued, invoiced and scanned tallies.
How the sector deploys itDeployment strategy
Six steps, in order. Nothing is signed until the manufacturer, the brand and the quota above it exist.
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.
The manufacturer is registered under a membership agreement with a validated CIN, PAN, GSTIN and drug licence.
Brand composition, strength and pack size are registered, which is what locks the parameters a later batch can be issued against.
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.
A batch is initialised against its brand and sub-key with a mandatory signing quota, enforced with row-level locks.
Strip QRs are generated individually or in bulk within a single lock session, at about 4.3 ms per strip.
How long the signature lasts, where the operational data sits, how the keys are held, and what an inspector can pull out of it.
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.
Because the signature has to outlive the pack. NIST finalised ML-DSA under FIPS 204 in August 2024 and advises migration off RSA and ECC by 2030, and a strip signed today can still be on a shelf past that date — which makes a classical signature on long-dated stock a present risk rather than a future one. "Harvest now, decrypt later" applies directly to printed physical packaging, because the code cannot be re-issued once it is printed. A market scan found no publicly documented post-quantum pharmaceutical serialisation offering.
The system runs a thin server model. The central identity registry holds cryptographic identities and public records; operational batch data stays on self-hosted manufacturer infrastructure. Strip HMAC tokens and signatures are not stored anywhere — they are recomputed from batch key references on demand — and master wrapping keys never leave the hardware security module, with plaintexts zeroed in memory immediately after use.
No account and no registration. The public verification endpoints require zero authentication, no consumer PII is requested, and the zero-PII architecture is what the DPDP Act 2023 alignment rests on. A result reads GENUINE or COUNTERFEIT, or shows a yellow partial banner where certificate status could not be checked offline. Every verdict carries the six label fields Rule 96 of the Drugs Rules 1945 makes mandatory.
Yes. 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 app shows a yellow partial banner rather than reporting a strip as genuine on incomplete evidence.
A REST API over HTTPS with a published OpenAPI specification. Public verification endpoints need no authentication; admin operations are protected with JWT access tokens. Per-brand BATCH_REGISTERED webhooks fire on batch creation, and there are reconciliation CSV exports, invoice submission APIs, and signed registry snapshot and OCSP-style certificate endpoints. Backends run a Python API service with a relational database, manufacturer servers are self-hosted to keep the data boundary, and the HSM integration is standard PKCS#11 in software, simulated or hardware form — with AWS CloudHSM and Thales Luna on the procurement roadmap. The consumer app ships as an Android APK through EAS Build, with iOS App Attest support.
It does not stop physical cloning. Cryptography proves the data on a strip is authentic; it cannot prevent a printed QR being reproduced onto fake packaging. Lock 5 — a high-resolution Copy Detection Pattern printed at press limits, paired with an inner-pack confirmation code — is designed and currently unbuilt, and is the roadmap item that targets that attack. It also does not replace CDSCO, SUGAM, iVEDA or State FDA regulatory portals; the ISO 27001, 27701 and 42001 certifications are roadmap rather than held.
The rest of the line
Pilots cover onboarding, key ceremony execution, single-batch issuance, QA sample scans and performance verification.