PUF Keys vs. Public Keypairs: Understanding Their Roles in Hardware Security

By /

Why a PUF key isn’t a keypair — and how it enables secure cryptographic identities

In modern hardware security, physically unclonable functions (PUFs) are becoming a preferred way to derive device-unique secrets without storing them in non-volatile memory. But a common point of confusion is whether a PUF key itself is a public–private keypair.

The short answer is: ❌ No, a PUF key is not a public keypair.
Instead, it serves as a unique, secret seed from which keypairs can be derived deterministically and securely inside hardware.

This post explains the distinction clearly and shows how PUF keys are used to generate cryptographic identities in silicon.

🧠 1. What Is a PUF Key?

A PUF key is a device-unique secret generated from the inherent physical variations present in silicon.

  • 📏 Typically 128–512 bits (often 256 bits)
  • 🔐 Never stored in flash, fuses, or external memory
  • 🧱 Reconstructed at boot using a fuzzy extractor or error correction mechanism
  • 🧬 Unique per chip, thanks to uncontrollable manufacturing variations

Key property:

The PUF key exists only inside the silicon boundary, and cannot be cloned or guessed externally.

PUFs act like a hardware “fingerprint”, giving each device a stable but unclonable root secret.

🔐 2. Why a PUF Key Is Not a Keypair

A public–private keypair (e.g., ECC or RSA) has the following properties:

  • Mathematically related private and public components
  • Can be used for signing, encryption, attestation, or key agreement
  • The public key can be shared externally; the private key remains secret

A PUF key, in contrast:

  • Is a single secret value, not a pair
  • Has no mathematical “public counterpart”
  • Cannot be used directly in standard cryptographic protocols

👉 Think of the PUF key as a master seed, not as a cryptographic identity by itself.

🧭 3. Deriving Keypairs from PUF Keys

While the PUF key isn’t itself a keypair, it can be used to deterministically generate one inside secure hardware. A typical flow looks like this:

          ┌───────────────────┐
          │  PUF Circuit      │
          │ (e.g., SRAM PUF)  │
          └─────────┬─────────┘
                    │
                    ▼
          ┌───────────────────┐
          │  Error Correction │ → stable 256-bit PUF key
          └─────────┬─────────┘
                    │
                    ▼
          ┌───────────────────┐
          │   KDF (HKDF)      │ → 48 bytes for ECC-384
          └─────────┬─────────┘
                    │
                    ▼
          ┌──────────────────────────┐
          │   ECC KeyGen Engine      │
          │  - derive private scalar │
          │  - compute public key    │
          └──────────────────────────┘

Key steps:

  1. PUF Key Generation: The device reconstructs a stable 256-bit secret at boot.
  2. Key Derivation: Use a KDF (e.g., HKDF) to expand that secret into the required key length for ECC or other algorithms.
  3. ECC Keypair Generation: Hardware interprets the derived bits as a private scalar and computes the corresponding public key.
  4. Public Key Export / Certification: The public key can be enrolled with a CA, embedded in a certificate, or used in attestation protocols.

The private key is never stored — it’s regenerated each time the device powers up.

🧰 4. Why This Matters

PropertyPUF KeyECC/RSA Keypair
StructureSingle secretMathematically related pair
StorageNot storedUsually stored or derived
ShareabilityNever sharedPublic key can be distributed
Use CasesRoot seed for derivationSigning, encryption, TLS, attestation
ClonabilityTied to physical siliconBased on math, not physical

Using PUF keys as roots for key derivation enables:

  • 🛡️ Storage-free private keys — no flash or fuse provisioning
  • 🔐 Hardware-tied identities — resistant to cloning or tampering
  • 🌍 Standards compliance — works with X.509, TLS, and attestation frameworks
  • 🔄 Deterministic regeneration — no key injection needed at manufacturing

🌐 5. Real-World Applications

  • Device Identity Certificates: Derive ECC-384 keypairs from PUF keys to enroll devices with a CA.
  • Secure Boot & Attestation: Use derived keys to sign boot measurements or manifests.
  • IoT Onboarding: Authenticate devices to cloud services without storing keys in NVM.
  • Supply Chain Trust: Tie cryptographic identity directly to silicon, preventing cloning attacks.

🚀 Conclusion

A PUF key is not a public keypair, but it plays a critical role as the hardware root secret from which cryptographic identities are deterministically derived.

This separation allows devices to combine physical uniqueness (PUF) with standard cryptographic protocols (ECC/RSA) — without the risks of key storage.

In short:

🧠 PUF = unique root secret
🔑 Keypair = derived cryptographic identity

This architecture is increasingly used in secure elements, IoT devices, automotive ECUs, and SoCs to achieve low-cost, unclonable, and standards-compliant security.

📚 Further Reading

  • NIST SP 800-56C – Key Derivation
  • TCG DICE Architecture
  • Intrinsic ID SRAM PUF Whitepapers
  • IEEE 802.1AR – Secure Device Identity
Scroll to Top