Security Overview
How the Registry protects codes, the Reserve Ledger and personal data, in terms a counterparty's compliance or information-security team can assess.
1. Design principles
- Server-side only. Code generation, check characters, ledger resolution and verification run only on the Registry's servers. The browser holds no Registry logic, keys or data beyond the page being shown.
- Nothing to steal in the code. An EBRICS code carries no recoverable data. It is a keyed seal, and it means something only to the Reserve Ledger.
- Consent-gated disclosure. A verified profile is shown only with a valid ATV issued by the holder and delivered by the Registry.
- Uniform failure. Every failed verification returns the same response, padded to the same response time.
2. Cryptography
| Control | Implementation |
|---|---|
| Code seals | HMAC-SHA256 over the canonical verified inputs, 256-bit random entropy, a microsecond timestamp, the entity identifier and the preceding seals |
| Check characters | Keyed (secret-dependent), so they cannot be derived from real codes |
| Key hierarchy | Versioned master keys; a separate HKDF-SHA256 sub-key for every purpose |
| Data at rest | AES-256-GCM for sealed profiles, codes, entropy, holder requests and staff authentication secrets |
| Look-ups | Codes, ATV references, tokens and API keys stored only as keyed hashes (blind indexes) |
| Ledger integrity | Hash-chained entries, re-derivation of every code on each verification, a nightly full audit |
| Transport | HTTPS only, with HSTS |
| Staff credentials | Argon2id password hashing and TOTP two-factor authentication with replay protection |
3. Application security
- Strict Content Security Policy: no inline script, style or event handlers, and no third-party scripts
- Clickjacking protection, no-sniff and no-referrer headers
- Anti-CSRF tokens on every form; session cookies set as
Secure,HttpOnlyandSameSite=Strict - Server-side validation against controlled vocabularies for every input
- Rate limiting on the decoder, holder services, seal checks, console sign-in and API keys
- Single-use, time-limited confirmation links that act only on an explicit POST
- Uploaded documents hashed in memory and discarded, never stored
4. Access control
Staff access is role-based (registrar, compliance officer, auditor, superadmin) with separation of duties. Console sessions end after 20 minutes of inactivity. Five failed sign-ins lock an account for 15 minutes. Every staff action is written to the audit log.
5. Key management
Master keys are held outside the web root and the database. Offline escrow copies are held under dual control. Keys can be rotated without invalidating codes already issued, and the rotation procedure is tested. Compromise of the database alone does not allow codes to be generated or profiles decrypted.
6. Monitoring and incident response
- The integrity of the full chain is audited nightly, and any failure raises an immediate security alert.
- Verification outcomes are monitored for enumeration patterns.
- Personal data breaches are assessed without delay and, where required, reported to the ICO within 72 hours and to other supervisory authorities, and to affected individuals, within the periods their laws require.
- If a holder's code or mailbox is suspected to be compromised, the code is suspended and re-issued. All ATVs issued under the old code are withdrawn automatically.
7. Business continuity
Encrypted database backups run daily and restoration is tested. The Registry Charter commits to key escrow, tested restoration and succession arrangements so that the Ledger survives the loss of any single system, supplier or operator.
8. Reporting a vulnerability
See the Responsible Disclosure policy or the machine-readable security.txt.