How It Works
End-to-end architecture of Hawcx authentication — what happens on-device, what hits the network, and how every step is secured.
System Architecture
Hawcx splits responsibility across four layers. Cryptographic secrets never leave the device, your backend never sees them, and Hawcx Cloud only receives zero-knowledge proofs.
| Layer | What lives here | What it never sees |
|---|---|---|
| Device | Private keys, biometric binding | — |
| SDK | State machine, UI steps, PKCE challenge | Private keys (handled by device APIs) |
| Your Backend | OAuth client, session logic | Private keys, raw proofs |
| Hawcx Cloud | Proof verification, challenge issuance | Private keys, session tokens |
Authentication Flow
When a user authenticates, the SDK drives a state machine through a series of steps. Here is the full sequence for a returning user:
Key points:
- Steps 3–6 happen on-device. The private key is accessed through platform secure storage (Keychain, StrongBox, TPM) and never serialized or transmitted.
- The proof is zero-knowledge. Hawcx Cloud learns that the user controls the device — nothing more.
- PKCE prevents interception. The
codeVerifieris generated client-side and never sent to Hawcx. Only your backend can exchange the auth code.
Device-Bound Proof Generation
Unlike passkeys, Hawcx keys are non-exportable and non-syncable. Each device holds its own key material, bound to the hardware secure element.
Why this matters:
| Property | Passkeys | Hawcx |
|---|---|---|
| Key storage | Cloud-synced across devices | Device-only, hardware-bound |
| Transferability | Can be shared, exported | Non-exportable by design |
| Key lifetime | Long-lived public key on server | Ephemeral per-session keys |
| Quantum exposure | Harvest-now-decrypt-later risk | No long-lived keys to harvest |
Three-Tiered Verification Chain
What makes the Hawcx protocol structurally different from FIDO2 or any other authentication system is its three-tiered sequential verification. Each tier uses a fundamentally different class of cryptographic primitive. An attacker must defeat all three — independently — to bypass authentication.
| Tier | Primitive | What it proves | What blocks it |
|---|---|---|---|
| 1. Hash commitment | SHA-256 | Client state is consistent (correct user, device, domain) | A single bit wrong → completely different hash → instant rejection |
| 2. Symmetric verification | AES-GCM-256 (AEAD) | Client holds the correct vault-derived key + server data is untampered | Wrong key → decryption fails. Tampered data → authentication tag fails |
| 3. Asymmetric proof | Ed25519 signature | Client possesses the actual private key | Forging a signature without the key is computationally infeasible |
Why the ordering matters: The tiers are arranged from cheapest to most expensive, and from broadest to most specific. Tier 1 (hash check) rejects invalid requests instantly without any decryption. Tier 2 (symmetric) rejects without signature verification. Only legitimate requests reach the expensive Tier 3 signature check. This creates natural rate-limiting and makes denial-of-service attacks against the verification chain impractical.
Why this exceeds FIDO2: FIDO2 uses a single-tier model — challenge → signature → verify. One cryptographic barrier. Hawcx interposes two additional verification tiers (hash commitment and symmetric AEAD mutual authentication) before reaching the same asymmetric signing step. Three mathematically independent barriers built on different hardness assumptions.
Mutual Authentication
Most authentication is one-directional: the server verifies the client. But how does the client know the server is legitimate?
Hawcx provides dual-AEAD mutual authentication. During Tier 2, the symmetric verification works in both directions:
- Client → Server: The server verifies the client's key is correct via AEAD decryption of stored data
- Server → Client: The server returns encrypted data that only the legitimate server could produce. The client's AEAD decryption verifies the server holds the original registration data, untampered
This means a rogue server cannot impersonate Hawcx Cloud. The client cryptographically verifies server authenticity before proceeding to the signature step — a property FIDO2 does not provide at the protocol level.
Security Properties
Each layer of the architecture prevents a specific class of attack:
| Attack | How Hawcx prevents it | Where |
|---|---|---|
| Phishing | Credentials are device-bound — nothing to type, nothing to steal | Device layer |
| Credential stuffing | No passwords or shared secrets exist | Device layer |
| Server breach | Server stores only double-hashed indexes and encrypted keysets — no plaintext credentials | Hawcx Cloud |
| Man-in-the-middle | Dual-AEAD mutual authentication + domain-bound challenge signing | SDK ↔ Cloud |
| Token interception | PKCE ensures only the originating client can exchange the auth code | SDK ↔ Backend |
| Replay attacks | Ephemeral keys, unique challenges, and nonces make each proof single-use | Device + Cloud |
| Harvest-now-decrypt-later | No long-lived public keys stored on server. Three independent layers of quantum resistance at rest | Device layer |
| Session hijacking | Your backend controls session policy (cookies, TTL, rotation) | Your Backend |
| Rogue server | Client verifies server authenticity via AEAD before signing | SDK ↔ Cloud |
What happens next
Now that you understand the architecture, you can:
- Integrate in 5 minutes — ship a working auth flow
- Explore device-bound authentication — deep dive into the cryptographic model
- Understand zero-knowledge proofs — how proofs are constructed and verified