Cryptographic Bill of Materials

How this document is maintained

This page is a hand-maintained reference, reviewed each time PICMS application code adds or changes a cryptographic primitive. The live algorithm configuration is also exposed at /cbom.json — that endpoint reads directly from the running wrapper and reflects the algorithms in use right now. The two should always agree; if they don't, the JSON wins.

Symmetric primitives — application code

All symmetric cryptography in PICMS application code routes through a single audited wrapper module (infrastructure/security/crypto-provider.js). Symmetric-cryptography algorithm migration is concentrated in this single wrapper module rather than scattered across the codebase. The wrapper does not eliminate the engineering work of adopting NIST FIPS 203/204 algorithms — those depend on availability in our Node.js runtime — but it concentrates the integration work to one file.

Primitive	Algorithm in use	Where it's used	Purpose	Quantum-vulnerable
Hash	`SHA-256`	Wrapper `hash()`	Document deduplication, RAG chunk fingerprinting, S3 object integrity	No
Keyed integrity	`HMAC-SHA-256`	Wrapper `hmac()` / `hmacVerify()`	Service-token validation, signed S3 export bundles	No
Authenticated encryption	`AES-256-GCM`	Wrapper `encryptSecret()` / `decryptSecret()`	API token storage, internal AI request audit log	No*
Random tokens	`CSPRNG` (Node `crypto.randomBytes`)	Wrapper `randomToken()`	Invitation tokens, consultant API keys, webhook secrets, link tokens	No
Random identifiers	`UUID v4`	Wrapper `randomId()`	Database primary keys, session identifiers	No
Detached signature	`Ed25519`	Wrapper `sign()` / `verify()`	Customer-verifiable signatures on weekly S3 export bundles. Public key at `/.well-known/picms-export-pubkey.pem`. Verifier script at `/scripts/verify-picms-export.mjs`.	Yes**

* AES-256 is considered quantum-resistant in the practical sense: Grover's algorithm reduces effective key strength to ~128 bits, which remains computationally secure against all known quantum hardware projections through and beyond NCSC's 2035 deadline. Symmetric primitives are not the priority concern in post-quantum migration; asymmetric ones are.
** Ed25519 is classically secure but quantum-vulnerable to Shor's algorithm. We use it as the interim customer-verifiable signature scheme so customers can independently verify export integrity today; we will migrate to ML-DSA (NIST FIPS 204) when Node core ships it. The migration is local to the wrapper module — the verifier script + sidecar format are designed to be backwards-compatible.

Asymmetric primitives — application code

None. PICMS application code performs no asymmetric cryptographic operations — no RSA, no ECDSA, no ECDH, no in-process key exchange or digital signature creation. Every asymmetric operation in the platform is inherited from a vendor boundary (see below). This is the most consequential single fact in this CBOM: the bulk of post-quantum cryptographic risk lives at vendor edges, not in code we own. Our migration plan therefore depends primarily on the vendor migration roadmaps, monitored continuously.

Independent verification: an auditor inspecting the running container can run grep -rn "createSign\|createVerify\|generateKeyPair\|crypto.subtle.sign" --include="*.js" across the application source tree to confirm zero matches. The wrapper deliberately does not expose those primitives.

Inherited cryptography

Cryptographic operations PICMS depends on but does not own. Each row identifies the vendor responsible for migrating that boundary to a post-quantum primitive. The full sub-processor list (with locations, purposes, and DPA terms) lives at /trust#subprocessors and /privacy-policy §5.

Boundary	Algorithm in use	Provider	Migration responsibility	Quantum-vulnerable
TLS termination	`ECDHE-RSA` / `ECDHE-ECDSA` with `TLS 1.2 / 1.3`	AWS (Application Load Balancer)	AWS	Yes
Authentication tokens	`RS256` JWT signature verification	Auth0	Auth0	Yes
Stripe webhook verification	`HMAC-SHA-256`	Stripe	Stripe (jointly)	No
AWS SDK request signing	`SigV4 (HMAC-SHA-256)`	AWS SDK	AWS	No
AI provider transport	`TLS 1.2/1.3`	Anthropic, OpenAI	Provider	Yes (handshake)

Third-party packages with cryptographic roles

Packages from package.json that perform or wrap cryptographic operations. The full machine-readable inventory is at /cbom.json.

Package	Role	Algorithms	Quantum-vulnerable
`node:crypto`	Standard library — wrapped by `crypto-provider.js`. Application code does not import it directly.	SHA-256, HMAC-SHA-256, AES-256-GCM, CSPRNG	No
`@aws-sdk/*`	AWS API client — TLS + SigV4 request signing	TLS 1.2, SigV4 HMAC-SHA-256	No
`@anthropic-ai/sdk` / `openai`	Network clients for AI providers — TLS only	TLS 1.2	No
`stripe`	Payment client — webhook signature verification (HMAC) + TLS	HMAC-SHA-256, TLS 1.2	No
`express-jwt`	JWT verification middleware (Auth0 RS256 tokens)	RS256	Yes (Auth0-owned)
`jwks-rsa`	JWKS fetching for the JWT verifier	TLS 1.2	No
`helmet`	Security HTTP headers (CSP, HSTS, X-Frame-Options) — no crypto operations	—	N/A
`puppeteer`	PDF rendering via headless Chromium — Chromium uses BoringSSL/OpenSSL transitively	Various (via Chromium)	No
`nodemailer`	SMTP email transport (fallback)	TLS 1.2	No
`@supabase/supabase-js`	Vector database client	TLS 1.2	No

bcrypt and jsonwebtoken are listed in package.json for historical reasons but are not directly invoked by PICMS application code. Authentication is handled entirely by Auth0; password hashing is not performed in-process.

Migration roadmap

PICMS started PQC preparation in 2026, two years ahead of the UK NCSC's 2028 inventory deadline and well in advance of the 2035 full-migration target. The roadmap, narrative, and current posture are documented at /quantum. Current state in summary:

Cryptographic inventory complete — this document and the /cbom.json endpoint.
Symmetric-cryptography wrapper live in production — every callsite routes through one audited module.
HMAC integrity protection live on weekly S3 export bundles (PICMS-internal verification).
Customer-verifiable Ed25519 signatures live on weekly S3 export bundles. Verify any bundle yourself with the zero-dep script + the public key — no PICMS contact required.
Automated data retention live for indefinite-retention surfaces — reduces "harvest now, decrypt later" exposure.
NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) trial planned once the algorithms are available in our Node.js runtime. Ed25519 signature scheme will migrate to ML-DSA in a single wrapper-module change.

Verifying this CBOM

Four independent ways for an auditor or compliance manager to confirm what this page claims.

Live algorithm configuration

The running wrapper's algorithm choices are exposed verbatim at /cbom.json. Refresh the JSON whenever this HTML page is updated; the two should agree.

Open /cbom.json

Verify an export bundle yourself

Each weekly S3 export carries an Ed25519 signature in its sidecar .sig file. Download the public key and the zero-dependency verifier script, run it locally — no PICMS server contact required.

Public key Verifier script

Wrapper inspection on request

The full source of crypto-provider.js can be made available to your auditor under NDA. Request via the security disclosure channel below.

Request inspection

Signed copy for ISMS files

Customers building an ISMS can request a PDF copy of this CBOM with a SHA-256 hash for evidence binding. We're happy to issue one tagged to your audit cycle.

Request signed copy

Verification recipe. Save the bundle .jsonl.gz, its sidecar .sig, and picms-export-pubkey.pem in the same directory, then:
node verify-picms-export.mjs bundle.jsonl.gz bundle.jsonl.gz.sig picms-export-pubkey.pem
Exit code 0 = verified. Exit 1 = tampered or wrong key. The script has no third-party dependencies — Node 18+ is the only requirement.

Every cryptographic primitive in PICMS application code.