PUFZIN: Device Authentication with PUFs and Zero-Knowledge Proofs

February 02, 2026 · Device Security

PUF Zero-Knowledge Proofs IoT Security Blockchain

The 20-Second Summary

IoT devices that participate in blockchain-style audit trails often authenticate using secrets stored in firmware or flash. If those secrets are extracted, an attacker can clone or impersonate a device indefinitely. This line of work was introduced in our IEEE LCN 2024 conference paper and extended in the PUFZIN journal article in the Journal of Information Security and Applications. PUFZIN combines a hardware-rooted identity signal (PUFs) with zero-knowledge proofs (Groth16) so a device can authenticate without sending a replayable secret.

The Threat Model

In a blockchain-IoT system, assume an attacker can observe network traffic, replay messages, and in some cases obtain physical access long enough to extract keys from flash or firmware. Under those conditions, authentication schemes that depend on stored private keys are vulnerable to cloning and long-term impersonation.

Traditional PKI-based authentication fails because private keys stored in flash memory can be extracted. Even secure elements have been defeated by side-channel attacks.

Why Existing Approaches Fail

Approach	Problem
Password/Token	Easily captured and replayed
PKI/Certificates	Private keys extractable from memory
Hardware Secure Modules	Expensive, still vulnerable to physical attacks
Blockchain-only identity	Relies on key storage, no hardware binding

The core issue: digital secrets can always be copied. We need something that’s physically unclonable.

My Approach: PUFZIN

PUFZIN (PUF + Zero-Knowledge + Identity) combines two powerful primitives:

Physical Unclonable Functions (PUFs)

PUFs exploit manufacturing variations in silicon to create unique, device-specific “fingerprints.” Like human fingerprints, they produce device-unique challenge/response behavior that is difficult to replicate with copied firmware alone. In practice, PUFs can be noisy, so real deployments typically require a tolerance mechanism (e.g., helper data / error correction) to accept responses that are “close enough.”

Zero-Knowledge Proofs (ZKPs)

ZKPs let the device prove it knows its PUF response without revealing the response itself. The network never sees the raw response, and an eavesdropper can’t trivially replay a captured value to impersonate a device. The verifier learns only whether the proof is valid.

The Protocol

The verifier issues a fresh challenge C.
The device queries its PUF on C to obtain a (noisy) response R.
The device generates a Groth16 proof that it knows an R consistent with enrollment (under an explicit tolerance rule).
The verifier checks the proof without learning R.

What We Measured

The paper evaluates feasibility using an Ethereum development environment (local chain + smart contracts) and Groth16 zk-SNARKs, quantifying proof generation/verification and robustness under a simulated PUF noise model.

We focused on end-to-end feasibility metrics: prover latency, verifier latency, proof size, and whether authentication succeeds under a simulated PUF noise model.

Results

In the reported evaluation, proof generation on standard hardware averages ~65.3 ms (stable across 0–10% simulated PUF noise), while verification in the evaluation environment averages ~1.13 s. On Raspberry Pi-class ARM hardware, proof generation averages ~3.87 s, with proof size ~723 bytes in the resource-constrained experiments. Using an explicit error-tolerant acceptance rule, authentication success is reported as 100% under the simulated 0–10% noise model.

Limitations & What I’d Do Next

Current Limitations:

This requires PUF-equipped hardware (not universal in IoT), and proof generation is heavier than simple signatures. The evaluation uses a simulated PUF noise model, so real PUF reliability plus helper-data/ECC effects need validation, and the reported numbers come from a controlled dev environment rather than a scaled deployment.

Future Work:

Next steps are benchmarking in a deployed blockchain-IoT setup under realistic load (permissioned or consortium), evaluating more constrained devices than Raspberry Pi-class hardware (e.g., microcontrollers), and exploring ZKP design alternatives/optimizations to reduce prover latency on the edge.