Every API call carries a ZK-STARK proof that the device is enrolled, the network is authorized, and the endpoint is bound. No fingerprints. No IPs. No metadata exposed. 16ms on ARM. Sub-microsecond verification. 192 bytes.
Not device management. Not certificate pinning. Cryptographic proof of endpoint integrity that fails at the arithmetic level — not at the policy level.
Authorization proves who you are. DeviceProof proves where you are, what you're running on, and which endpoint you're calling — with math, not metadata.
A stolen token works from any device on any network. FHE encrypts correctly regardless of who's calling. The requestor's hardware is unverified. An exfiltrated JWT replayed from a foreign server is indistinguishable from the legitimate user.
Certificate pinning prevents man-in-the-middle attacks but says nothing about whether the device is compromised, jailbroken, or enrolled. A valid cert on a stolen laptop is indistinguishable from one on the authorized workstation.
HIPAA requires US processing. GDPR requires EU residency. IP geolocation is not cryptographically verifiable. Proxies, VPNs, and tunnels defeat it trivially. Your compliance team is trusting a number that anyone can change.
From enrollment to revocation, the raw hardware fingerprint never leaves the device. The proof is all that travels.
Each proof circuit targets a specific attestation domain. All three are recursively aggregated into a single 192-byte bundle that rides alongside your Bearer token.
Proves the calling device has an enrolled TPM or Secure Enclave without revealing the hardware fingerprint. The verifier learns "this is an enrolled device" and nothing else.
Proves the device is in an authorized IP range or jurisdiction without revealing the actual IP address. HIPAA US-only and GDPR EU-only become cryptographically enforceable, not policy-based.
Proof is valid only for the target API route. A proof generated for /api/patients is mathematically rejected by /api/billing. No routing tricks. The arithmetic rejects mismatched endpoints.
These numbers represent the same instruction set architecture used in Apple A-series and M-series chips. On an actual iPhone, we project 25–35ms total — 6x to 12x under our 200ms engineering budget.
| Operation | Median | P95 |
|---|---|---|
| Poseidon commitment | 43 us | 43 us |
| Device integrity proof | 5.17 ms | 5.66 ms |
| Network jurisdiction proof | 2.98 ms | 3.44 ms |
| Endpoint binding proof | 3.10 ms | 3.23 ms |
| Full aggregated attestation | 16.15 ms | 17.10 ms |
| Verification | <1 us | <1 us |
| Proof size | 192 bytes | — |
Rust core with bindings for every language that matters. Native hardware attestation on every platform that supports it.
Native Secure Enclave attestation via the Apple CryptoKit bridge. Hardware-backed Poseidon commitments on every Mac with a T2 chip or Apple Silicon.
Direct TPM 2.0 integration via the system TPM stack. Works with discrete and firmware TPMs on all major distributions and Windows 10/11.
Native hardware attestation on both mobile platforms. Secure Enclave on iPhones. StrongBox Keymaster on Android devices with dedicated security hardware.
Host attestation bridge via Unix socket. Container workloads inherit the host node's TPM attestation through a privileged DaemonSet. No sidecar required.
Software fallback for local development and CI pipelines. Generates valid proof structures with a dev-only signing key. Automatically rejected in production.
Rust core with native bindings for Node.js, Python, Java, and Go. FFI layer handles all memory and type marshaling. Same proof format across every runtime.
DeviceProof proves jurisdiction, device state, and endpoint authorization without H33 ever seeing the underlying data.
Prove US-only processing without logging IP addresses. Network jurisdiction proofs are cryptographically verifiable evidence of data residency that satisfies Security Rule requirements without creating new PHI exposure vectors.
Prove EU-only access without storing location data. Article 44 transfer restrictions become mathematically enforceable. Auditors verify jurisdiction proofs without accessing network logs.
Prove authorized endpoints only. Every verification event is logged with a Dilithium-signed timestamp. Endpoint binding proofs create an unforgeable audit trail of which devices accessed which financial endpoints.
No fingerprints, no IPs, no routing data in H33 logs. The proof is self-contained. H33 verifies the math without learning what the math is about. Your compliance posture improves without creating new data liabilities.
DeviceProof ships with every H33 product. It is not a separate line item.
Device attestation is a security primitive, not an upsell. Every API call that touches H33 can carry a DeviceProof attestation at no additional cost.
ZK-STARK device attestation is a cryptographic protocol where a device generates a zero-knowledge proof that its hardware integrity checks pass — without revealing the actual hardware fingerprint, TPM endorsement key, or Secure Enclave identifier to the verifier. The device commits to its state using a Poseidon hash, then constructs a STARK proof that the committed state satisfies the enrollment policy. The verifier learns only one bit: this device is valid. No serial numbers, no platform identifiers, no side-channel leakage. The proof is 192 bytes, generates in 16ms on ARM, and verifies in sub-microsecond time at the API gateway.
DeviceProof constructs a Poseidon commitment of the device's IP address, then generates a STARK proof that the committed IP falls within an authorized CIDR range — without revealing the IP itself. The verifier specifies jurisdiction constraints (e.g., "US-only for HIPAA" or "EU-only for GDPR"), and the proof confirms range membership. The Poseidon commitment takes approximately 43 microseconds. The resulting proof is mathematically bound to both the jurisdiction policy and the specific API endpoint, meaning a proof generated for one compliance boundary cannot be replayed against a different jurisdiction requirement. IP addresses never leave the device in plaintext.
Endpoint-specific proof binding means each DeviceProof attestation is mathematically tied to the exact API route it was generated for. The proof includes a cryptographic commitment to the target endpoint URL, HTTP method, and request parameters. If an attacker intercepts a valid proof and attempts to replay it against a different endpoint — even on the same server — the STARK verification fails. This is not policy enforcement; it is mathematical rejection. The verifier's equation literally does not balance for any endpoint other than the intended one. This eliminates an entire class of proof relay and session hijacking attacks.
DeviceProof generates a full attestation proof in 16 milliseconds on ARM processors (iPhone, Android, Apple Silicon Macs, AWS Graviton). Verification at the API gateway takes sub-microsecond time — fast enough that it adds zero perceptible latency to any API call. The final proof is 192 bytes, smaller than a typical HTTP cookie. On x86 desktop processors, generation is even faster. The SDK handles all proof construction internally; from the developer's perspective, it is a single function call that returns an opaque 192-byte blob to attach as a request header. No round-trips, no challenge-response, no pre-authentication handshake required.
When a device is revoked, its enrollment commitment is removed from the global Merkle tree. This change propagates to all verifiers within 60 seconds. Once propagated, the revoked device cannot generate a valid STARK proof because its commitment no longer exists in the tree — the Merkle inclusion proof fails. This is not a blocklist lookup; it is a cryptographic impossibility. The revoked device's SDK will return an error on proof generation, and any cached proofs from before revocation will fail verification due to the 30-second temporal validity window. Revocation is immediate, irreversible without re-enrollment, and requires no coordination with the device itself.
Yes. Kubernetes containers do not have direct access to host TPM or Secure Enclave hardware, so DeviceProof uses a host attestation bridge. A lightweight agent runs on the Kubernetes node and exposes a Unix socket inside each pod. When a container needs a DeviceProof attestation, the SDK connects to the Unix socket, the host agent generates the proof using the node's hardware security module, and returns the 192-byte proof to the container. The container never touches the TPM directly. This architecture supports DaemonSet deployment, node-level caching, and is compatible with EKS, GKE, AKS, and bare-metal Kubernetes clusters.
Certificate pinning and SafetyNet (now Play Integrity) prove credential possession — the device holds a valid certificate or passes Google's attestation check. DeviceProof proves device state using zero-knowledge proofs. The difference is fundamental: a compromised device with a valid certificate still passes pinning checks. A rooted device with a patched Play Integrity module can pass SafetyNet. DeviceProof proves that the device's actual hardware integrity measurements, secure boot chain, and enclave state satisfy the enrollment policy — without trusting a third-party attestation service. The proof is self-verifiable, requires no callback to Google or Apple, and works offline.
Yes. Every DeviceProof attestation is fully post-quantum secure. The STARK proofs use Poseidon hashing, which is based on arithmetic operations over prime fields and is not vulnerable to Shor's algorithm or Grover's algorithm. All proof signatures use Dilithium (ML-DSA, NIST FIPS 204), a lattice-based signature scheme that provides NIST security level 2 or higher. The Merkle tree uses SHA3-256, which provides 128-bit post-quantum security against Grover's algorithm. No component of the DeviceProof pipeline relies on RSA, ECDSA, or any other algorithm that a quantum computer could break.
The DeviceProof SDK supports six platform targets: macOS with Secure Enclave (Apple Silicon and T2 Macs), Linux with TPM 2.0 (servers, desktops, and embedded devices), Windows with TPM 2.0, iOS with Secure Enclave (iPhone 5s and later), Android with StrongBox Keymaster or hardware-backed Keystore, and a development fallback mode that uses software-emulated attestation for local testing. The core SDK is written in Rust with official bindings for Node.js, Python, Java, and Go. Kubernetes containers are supported via the host attestation bridge. Each platform binding provides identical API surface and proof format.
Every DeviceProof attestation includes a timestamp committed inside the STARK proof. When a verifier checks the proof, it compares the proof timestamp against the current server time. If the absolute difference exceeds 15 seconds (|proof_ts - current_ts| > 15s), the proof is rejected. This is not a policy expiration — the proof is mathematically stale. The 30-second total window (plus or minus 15 seconds) accounts for network latency and minor clock drift while preventing proof replay attacks. A captured proof becomes useless within seconds. Combined with endpoint binding, this means an attacker has an extremely narrow window and the proof only works against one specific route.
Our Blind Mode Demo shows DeviceProof attestation alongside FHE encryption and ZK-STARK verification in real time. Not a video. Live cryptography.