Device-Bound Authentication
How Hawcx ties credentials to specific devices for enhanced security
When passkeys sync through iCloud or Google Password Manager, a compromise of that cloud account gives an attacker every passkey you own. When passwords are stored on a server, a breach exposes every user at once. The problem isn't weak algorithms. It's that credentials exist somewhere they can be stolen.
Hawcx solves this by making credentials physically inseparable from the device.
Why this matters
For developers: No password database to protect. No sync infrastructure to trust. No "forgot password" flow to build. The device IS the credential.
For security teams: If an attacker compromises your server, they get nothing usable. If they compromise a user's cloud account, they get nothing usable. The only way to authenticate is to physically possess the registered device.
How it works
Each device generates cryptographic material inside its secure hardware: Secure Enclave on iOS, TEE on Android, WebCrypto in browsers. This material is:
- Non-exportable because the operating system physically prevents extraction
- Non-syncable and never uploaded to iCloud, Google, or any cloud service
- Non-transferable and cannot be copied to another device, even by the user
When a user authenticates, the device generates a fresh proof using this material. The proof is valid for that single session and cannot be replayed. The secret itself never leaves the hardware boundary.
Platform-specific protection
Hawcx doesn't apply a one-size-fits-all approach. The protocol uses the strongest available protection mechanism on each platform, adapting to the security capabilities of the environment.
Mobile (iOS & Android)
On mobile, the root-of-trust key (UAK) is stored in hardware-isolated secure storage, specifically the Secure Enclave on iOS and the StrongBox/TEE on Android. This key never leaves the hardware boundary.
The signing key is protected by a two-layer mechanism:
- Information-theoretic splitting: the key is split into two components held by different parties (device and server). Neither component alone reveals any information about the key. This provides the same mathematical property as a one-time pad, proven by Claude Shannon to be unconditionally secure.
- AEAD verification: before recombination, the server's component is verified through AES-GCM authenticated encryption, ensuring it came from the legitimate server and hasn't been tampered with.
The recombined key exists only transiently in the app's process memory, protected by the operating system's hardware-enforced process isolation (MMU-level memory protection on iOS, SELinux + kernel isolation on Android).
Web (Browsers)
Browsers don't provide the same process-level memory isolation as mobile operating systems. Hawcx adapts by using a different protection model:
The private signing key is wrapped (encrypted) inside the Web Crypto vault using a symmetric key derived from the hardware-bound root key. The raw private key bytes never exist in JavaScript-accessible memory at any point. The entire key lifecycle (generation, wrapping, unwrapping, and signing) is performed within the browser's cryptographic engine (BoringSSL in Chromium, NSS in Firefox), below the JavaScript layer.
An XSS attacker who reads browser storage obtains only AES-GCM ciphertext. Decrypting it requires the vault-held root key, which the Web Crypto API marks as non-extractable.
| Dimension | Mobile (iOS / Android) | Web Browser |
|---|---|---|
| Root key protection | Secure Enclave / TEE (hardware) | Web Crypto vault (software, non-extractable) |
| Signing key protection | Information-theoretic splitting | AES-GCM vault wrapping |
| Memory isolation | OS kernel process isolation (MMU) | Same-origin JS execution context |
| Quantum resistance | Unconditional (information-theoretic) | Computational (AES-256 hardness) |
| XSS vulnerability | N/A (no browser context) | Private key never in JS memory; storage is ciphertext only |
What this eliminates
| Attack vector | With passwords/passkeys | With Hawcx |
|---|---|---|
| Phishing site | User types credential into fake site | Nothing to type, and the credential can't leave the device |
| Server breach | Attacker dumps credential database | No credentials stored on server |
| Cloud account compromise | Attacker gets synced passkeys via iCloud/Google | Nothing synced, so nothing to get |
| Device theft (locked) | Credential may be extractable | Secured by hardware enclave + biometric |
| Malware on device | May intercept passwords in memory | Keys in secure hardware, inaccessible to apps |
Multi-device support
Device-bound doesn't mean single-device. Users register each device independently. If a user has a phone and a laptop, each device has its own cryptographic material. Losing one device doesn't affect the other, and revoking one device doesn't require re-enrollment everywhere.
This is fundamentally different from passkey sync, where all devices share the same key material through a cloud account. With Hawcx, compromising one device's registration is an isolated event, not a cascading failure across every device.