BIOMETRIC HARDWARE DNA
The gate. Identity, before any data, any message, any file.
Most enterprise authentication stacks were built for convenience. Vendors hold the keys. Vendors host the data. Vendors decide who is in and who is out. AURA was built for the opposite premise: face images are never stored, the facial template is encrypted and never leaves your organization's node, the device key never leaves your hardware, and no third party stands between the user and the system.
| THREAT VECTOR | MITIGATION | ENFORCEMENT |
|---|---|---|
| Credential phishing | FIDO2 platform attachment · userVerification required | Hardware-bound when FIDO2 is used |
| Replay attack | HMAC-SHA256 step token · 15min TTL · userId+timestamp bound | Per-request |
| Session hijack | Session JWT · IP + UA bound · HKDF-SHA256 derived | Per-session |
| Spoofing (photo/video) | Multi-signal liveness | |
| Biometric exfiltration | Template encrypted (AES-256-GCM) on your node · no face images stored | Cryptographic |
| Audit tampering | SHA-256 hash chain · Ed25519 signed · append-only | Cryptographic |
| Vendor lock-in | Single-tenant deployment · no external API in the data path | Architectural |
AURA operates as Zone 1 in the SYNARIS sovereign architecture. The authentication perimeter sits between the external request origin and the private SYNARIS node. Biometric capture happens on the user's device and no images leave it. Only a numeric facial template crosses the wire over TLS, and it is stored encrypted on your node. The device key (FIDO2 / WebAuthn) never leaves the hardware. AURA verifies, mints a session token, and writes the event to the AuditChain.
ZONE 0 ZONE 1 ZONE 2 ZONE 3
EXTERNAL AUTH PERIMETER SYNARIS NODE RESULT
───────── ────────────── ──────────── ──────
USER DEVICE ────────► AURA ENGINE ─────────► HUB · MY POST · NEXO ────► SESSION
JWT + IP BIND VAULT · IRIS · MIA ESTABLISHED
HKDF-SHA256
NONCE 60s TTL
Ed25519 SIGN
│
▼
AUDITCHAIN
SHA-256 chain
Ed25519 sealed
append-only
| LAYER | COMPONENT | FUNCTION |
|---|---|---|
| Capture | Device camera (in-browser) | No images stored · template encrypted on your node |
| Attestation | FIDO2 / WebAuthn | Platform authenticator · userVerification: required |
| Liveness | Multi-signal engine | Descriptor + landmark + temporal coherence + time span |
| Token | HMAC-SHA256 step token | 15min TTL · userId+timestamp bound |
| Session | JWT · HKDF-SHA256 | AES-256-GCM payload · IP + UA bound |
| Audit | AuditChain | SHA-256 hash chain · Ed25519 sealed · append-only |
| FUNCTION | PRIMITIVE |
|---|---|
| Biometric matching | Euclidean 128D Float32 descriptor · enforced threshold |
| Liveness | Multi-frame temporal validation · descriptor + landmark + coherence |
| Step token | HMAC-SHA256 · TTL 5min · userId+timestamp bound |
| Session JWT | HKDF-SHA256 · AES-256-GCM payload · IP+UA bound |
| Message signing | Ed25519 (RFC 8032) · per-user keypair · WebCrypto |
| Audit chain | Append-only · SHA-256 hash chain · Ed25519 signed |
| At-rest encryption | AES-256-GCM · random IV · auth tag |
| WebAuthn | FIDO2 · platform attachment · userVerification required |
AURA is designed under explicit assumption of adversarial conditions. The attack surface is enumerated and bounded. The following table maps the principal vectors and the architectural property that makes the bypass non-trivial.
| VECTOR | BYPASS COMPLEXITY | ARCHITECTURAL DEFENCE |
|---|---|---|
| Stolen password | MEDIUM | Face match + multi-frame liveness · FIDO2 when enrolled |
| Photo / printed face | MEDIUM | Multi-frame temporal validation · descriptor variance |
| Recorded video | MEDIUM | Temporal coherence + time-span validation |
| Deep-fake feed injection | HIGH | Multi-frame liveness |
| Token replay | VERY HIGH | HMAC step token · 15min TTL · single-use |
| Session hijack | VERY HIGH | JWT IP + UA binding · HKDF-derived per-session key |
| Audit log tamper | EXTREME | Hash chain breakage detected · Ed25519 verifiable |
| Server-side biometric leak | HIGH | Templates encrypted at rest (AES-256-GCM) · no images stored |
| FRAMEWORK | ARTICLE | IMPLEMENTATION |
|---|---|---|
| GDPR | Art. 9 | Biometric explicit consent · BIOMETRIC_CONSENT_GRANTED audit event |
| GDPR | Art. 13 | First-login privacy modal · /privacy/accept |
| GDPR | Art. 15 | DSR export endpoint · /privacy/export |
| GDPR | Art. 17 | VAULT delete preserves audit chain integrity |
| GDPR | Art. 32 | AES-256-GCM at rest · TLS 1.3 in transit · audit trail |
| GDPR | Art. 35 | DPIA documented · docs/compliance/DPIA_biometric_v1.0 |
| NIS2 | — | SHA-256 audit chain · append-only · permanent record |
| eIDAS | — | Ed25519 electronic signatures |
| LAYER | SPECIFICATION |
|---|---|
| Architecture | Sovereign single-tenant deployment |
| Operating system | Hardened Linux LTS |
| Cryptography | Industry-standard primitives (RFC 8032 · AES-256-GCM · SHA-256) |
| Network | TLS 1.3 · HSTS · strict CSP · intrusion prevention |
| TLS | Automated certificate renewal |
| Sovereignty | No external API in the data path · dedicated EU-hosted node |
| High availability | Multi-node failover · available on the multi-node plan |
Every authentication event is committed to the AuditChain. Comprehensive event taxonomy continuously expanded. The chain is append-only, hash-linked, and Ed25519-sealed at each entry.
{
"event_type": "AUTH_SUCCESS",
"user_id": "string",
"timestamp": 1714230000000,
"tenant": "string",
"prev_hash": "sha256...",
"current_hash": "sha256...",
"signature": "ed25519..."
}
Full architecture, threat model, primitives and compliance specification. Ed25519-signed PDF · gated access.