IM Engineer Study Notes
← Back to list
Security & Privacy
#PUF#하드웨어보안#신뢰뿌리#IoT보안#퍼지추출기
Last updated · 2026-10-06

Physically Unclonable Function (PUF)

1. Overview

A. Definition

A hardware security primitive that extracts the unavoidable microscopic physical variations introduced during semiconductor manufacturing (wire delay, transistor threshold voltage, oxide thickness, etc.) as a "fingerprint," producing an output (Response) that is unique to each chip yet reproducible for a given input (Challenge). Rather than storing a key in memory, it regenerates (derives) the key on the fly from the chip's physical characteristics whenever needed, and is thus summarized as a "key that is never stored."

The core idea of a PUF is that "instead of guarding a key inside a vault, the key itself is etched into the chip's physical body, while never actually existing anywhere during normal operation." Traditional security has evolved toward storing a secret key in non-volatile memory (eFuse, Flash) and protecting that memory cryptographically and physically. A stored key, however, remains in place even when powered off, making it a target for physical analysis with lasers and electron microscopes after decapsulation, or for memory remanence attacks. A PUF inverts the premise, treating a key as a "phenomenon" rather than "matter." A Response manifests only at the instant power is applied and a Challenge is asserted; when power is removed, the key physically vanishes. If an attacker disassembles the chip, the very microscopic-variation structure is disturbed and the PUF value itself changes, naturally endowing it with a tamper-evidence property.

B. Background and Necessity

As IoT and edge devices grow to tens of billions, "how to plant a Root of Trust into low-cost, mass-produced devices" has become an industrial challenge. HSMs and dedicated security chips (Secure Elements) are powerful but hard to embed in every sensor and actuator in terms of unit cost, area, and power. A PUF, by contrast, can generate a per-device unique key using only the SRAM already inside the chip or a small number of logic gates, without a separate secure memory or expensive process, making it highly efficient in cost and area. For example, programming and managing a unique key at the factory for each of hundreds of millions of IoT sensors creates a key-leakage channel across the whole supply chain, whereas a PUF eliminates the "key injection" step itself.

Another driver is supply-chain security and anti-tampering. Semiconductor counterfeiting, recycling, and overproduction (surplus production diverted to gray markets) constitute a problem on the scale of tens of billions of dollars annually, creating a need for a hardware-level identifier that proves a chip is genuine. Because a PUF is an unclonable physical fingerprint, it is directly used for chip authenticity verification (anti-counterfeiting). Finally, as quantum computing and advanced side-channel attacks strengthen the premise that "a stored secret can eventually be extracted," PUF-based key management, in which the key does not exist during normal operation, draws ever more attention. In short, the necessity of PUFs arises from three axes: (1) a root of trust for low-cost mass devices, (2) supply-chain anti-tampering, and (3) overcoming the structural vulnerability of stored secrets.

C. Key Characteristics

The properties that distinguish a PUF from other security measures are summarized below, all deriving from the single principle of "using physical randomness as a key."

  • Unclonability: Not even the manufacturer can intentionally reproduce an identical PUF, because process variation is an uncontrollable random phenomenon.
  • Uniqueness: Even chips stamped out with the same design and process must yield different Responses; ideally, the Hamming distance (HD) of Responses between two chips converges to 50%.
  • Reliability (Reproducibility): The same chip must produce nearly the same Response for the same Challenge even as temperature, voltage, and aging vary (intra-chip HD converging to 0%).
  • Unpredictability: Knowing some Challenge-Response Pairs (CRPs) must not allow predicting other CRPs.
  • Non-storage (Tamper-evidence): The key is not persistently stored and the characteristics are destroyed upon physical disassembly.

2. Operating Principle and Architecture

A PUF is not a single component but a system in which "physical-variation extraction → error correction → key regeneration → application linkage" is bound into one flow. The overall diagram below shows how a noisy Raw Response, once a Challenge is asserted, is refined into a stable cryptographic key for use by higher security functions.

flowchart LR
  CH["Challenge input<br/>(input bitstring)"] --> PUF["PUF cell array<br/>(process-variation extraction)"]
  PUF --> RAW["Raw Response<br/>(contains noise)"]
  RAW --> ECC["Fuzzy extractor<br/>(error correction·helper data)"]
  ECC --> KEY["Stabilized key<br/>(reproducible Response)"]
  KEY --> APP["Application layer<br/>(authentication·key gen·signing)"]
  HD["Helper-data store<br/>(not secret, publishable)"] --> ECC
  ECC --> HD

A. Physical-variation extraction (Entropy Source) — A PUF starts from uncontrollable physical randomness. Typically, an SRAM PUF uses the "power-up state" in which each SRAM cell tips to 0 or 1 due to the slight asymmetry of its two inverters as a fingerprint. An Arbiter PUF produces a bit by having an arbiter judge the propagation-delay difference between two identically designed signal paths. Such nanoscale variation that "cannot be made identical no matter how hard one tries" is the source of entropy, and this randomness is not in the schematic but exists only in that chip's body.

B. The noise problem and the fuzzy extractor — Being a physical phenomenon, the Raw Response fluctuates by a few percent of bits each time with temperature, voltage, noise, and device aging (e.g., the bit error rate of an SRAM PUF under environmental variation is commonly reported in the range of a few % to 15%). Because a cryptographic key becomes an entirely different value if even one bit differs, a fuzzy extractor that corrects this fluctuation with an error-correcting code (ECC) and helper data is essential. At enrollment, helper data to recover the difference from a stable reference value is created; at reconstruction, the fluctuated Raw Response is corrected with the helper data to always recover the identical key. The key point is that the helper data is designed to be non-secret and safe to store or disclose externally, with the key still existing only in the chip.

C. Key regeneration and application linkage — The refined stabilized key is not exported itself but is used internally as a seed for symmetric and asymmetric keys for authentication, encryption, and digital signing. A structure in which the PUF key serves as a root from which a device identifier, TLS client key, firmware decryption key, etc., are derived is common. The point to note here is that a PUF is "a source that establishes a root of trust," not "a device that makes a single key." If use-specific subkeys are derived from a single PUF root key with a KDF (Key Derivation Function), a single physical fingerprint can bind identification, communication, and storage encryption together, anchoring the device's entire security system on one PUF. Conversely, this means that if the PUF is broken, the upper system collapses with it, so the physical protection of the root and the separation of the derivation hierarchy must be designed together.

D. The two phases of enrollment and reconstruction — The PUF lifecycle divides broadly into two phases. Enrollment is a one-time stage of creating reference Responses and helper data in a trusted, secure environment (typically the factory or a secure provisioning server), and reconstruction is the stage of correcting the fluctuating Raw Response in the field each time with helper data to recover the identical key. Because enrollment occurs "once, at the most trusted point in time," the environmental and procedural security at this moment is the premise of the entire trust. If enrollment is contaminated (e.g., an enrollment-server breach), all subsequent reconstruction becomes meaningless, so the enrollment stage is treated as a core control point of supply-chain security.

D. CRP-Based Authentication Flow

The most intuitive use of a PUF is challenge-response authentication. A trusted server safely collects many CRPs at the enrollment stage, then on each later authentication throws a new Challenge and checks whether the Response matches. Below is a detailed diagram of that process.

sequenceDiagram
  participant S as "Verification server"
  participant D as "PUF device"
  Note over S,D: Enrollment phase (secure environment)
  S->>D: Send many Challenges
  D->>S: Return Raw Responses
  S->>S: "Securely store CRP DB"
  Note over S,D: Authentication phase (field)
  S->>D: Select·send a random Challenge
  D->>D: "Generate Response on the fly via PUF"
  D->>S: Return Response
  S->>S: "Compare with stored CRP·decide"

The strength of this scheme is that it does not send the key over the network. The advantages compared with the traditional pre-shared symmetric-key approach are as follows.

  • No key transmission: The secret is not exposed on the line or in memory, removing eavesdropping and dump targets.
  • Device binding: The Response is regenerated only on that chip, so key duplication or porting is impossible.
  • Lightweight: It grants identity to mass devices without complex key-storage and protection hardware.

That said, a "Weak PUF" that stores a finite number of CRPs is hard to reuse once the CRPs are exhausted or stolen, so a "Strong PUF" with an exponentially large CRP space is preferred for authentication.

3. Types and Comparison

PUFs are classified by their implementation device and by the size of the CRP space. Type selection is a trade-off problem among security strength, area, reliability, and process compatibility.

Axis Type Principle Characteristics
Delay-based Arbiter PUF Judge delay diff of two paths Strong PUF, vulnerable to modeling
Delay-based Ring Oscillator PUF Compare ring-oscillator frequencies Easy to implement, power·area burden
Memory-based SRAM PUF Cell initial value at power-up Many commercial uses, reuses IP
Memory-based Butterfly/Latch PUF Latch metastable state FPGA-friendly
Optical·other Optical PUF Optical scattering pattern External, needs a sensor

A. The difference and implications of weak vs. strong PUFs — The most important distinction is the size of the CRP space. A weak PUF has few Challenges (as few as one) and is mainly used for key-storage replacement (key generation and keeping). The SRAM PUF is representative, optimal for safely regenerating a single chip-unique key set. A strong PUF, by contrast, has an exponentially large CRP space usable for many one-time authentications, making it suitable for device authentication. However, strong PUFs such as the Arbiter PUF have been proven by many studies to be vulnerable to modeling attacks that collect many CRPs and replicate the internal model via machine learning, and defenses that raise nonlinearity with XOR Arbiter, feed-forward structures, etc., have been researched. This difference translates directly into the design decision of "whether to use the PUF as a key vault or as an authentication token."

B. Relationship with TPM, HSM, and Secure Element — A PUF is complementary to these rather than competing. TPM/HSM/SE are strong at "storing and using keys inside a secure boundary," but the problem of how to safely create and regenerate the top-level root key inside that boundary still remains. It is precisely here that a PUF provides a "root key that is not stored," strengthening the trust root of security chips. In fact, the number of cases in which the latest security MCUs, smart cards, and TPM chips embed an SRAM PUF to protect their internal keys is increasing.

Item PUF TPM/SE HSM
Key existence form Normally absent (regenerated) Stored inside chip Stored in dedicated boundary
Primary use Root-key gen·lightweight auth Platform integrity·key store Central mass key mgmt
Cost·area Very low Low High
Target IoT·edge·chip PC·terminal Data center

4. Application Cases and Security Analysis

Looking at actual application cases makes the value of PUFs clear. In (1) IoT device onboarding, instead of injecting and managing keys at the manufacturing stage, each device's SRAM PUF generates a unique key on the fly and registers it with the cloud (e.g., device-identity-based mutual TLS authentication). This eliminates the key-leakage channel in the factory programming process. In (2) semiconductor anti-tampering, a PUF fingerprint that differs per chip is linked with an authenticity certificate to identify recycled or counterfeit chips. In (3) secure boot and firmware protection, a PUF key seals the firmware decryption and integrity-verification keys so that firmware operates only on a specific chip. All three cases leverage the essence of a PUF: "establishing a unique trust per chip while storing the key nowhere."

From a security-analysis standpoint, PUF quality is evaluated with quantitative metrics. The main metrics are as follows, each with a physical basis for "why that value is ideal."

  • Uniqueness: Measured by the Hamming distance of Responses between different chips; the ideal value is 50%, because two chips' responses must be as independent as coin flips so that neither can be guessed from the other.
  • Reliability: Measured by the variation (intra-chip Hamming distance) of Responses repeatedly measured on the same chip; the ideal value is 0%, as reproducibility governs the key-recovery success rate.
  • Uniformity: Checks whether the ratio of 0s and 1s within one chip's Response is close to 50:50; a skew reduces entropy and weakens against guessing attacks.
  • Bit-aliasing: The degree to which a given bit position tips to the same value across many chips; the more it tips, the more uniqueness is harmed.

For example, if uniqueness moves away from 50%, different chips yield similar keys, raising collision and guessing risk; if reliability worsens, the error-correction burden and helper-data size grow, increasing area and power cost. In other words, these metrics are mutually in trade-off, and PUF design is the engineering of finding this balance point. ISO/IEC 20897 standardizes exactly the measurement and evaluation methods of these metrics, letting a third party objectively verify the PUF quality a vendor claims.

To understand with concrete figures: when regenerating a 128-bit symmetric key with a PUF, if the Raw Response's bit error rate from environmental variation is 10%, on average dozens of bits may flip at each regeneration. Restoring this to nearly 0 requires correspondingly strong ECC (e.g., a BCH·Reed-Muller code combination) and enough Raw bits. For example, designs that consume hundreds to a thousand bits of Raw Response to obtain a 128-bit stable key are common, directly showing the cost structure that "the higher the reliability, the more PUF cells, helper data, and power are needed." The designer must size the ECC parameters while jointly considering the target key length, the allowable regeneration failure rate, and the available area and power.

The main threats and defenses must also be examined together.

  • Modeling Attack: On a strong PUF, collect many CRPs and learn the internal delay model via ML (logistic regression, evolutionary computation, deep learning) to predict even the Response of an unseen Challenge. Defenses include limiting CRP exposure, strengthening nonlinearity with output hashing·XOR, and designing protocols (e.g., mutual authentication·obfuscation) that do not expose CRPs directly.
  • Side-channel and helper-data leakage: Bit information may leak from the power·electromagnetic emissions of the error-correction process or from helper data, so a design that quantitatively analyzes leakage entropy and leaves a margin (entropy margin) is needed.
  • Reliability degradation·aging: If bit errors increase from device aging such as NBTI or extreme temperature·voltage, key recovery fails, so from an availability standpoint an ECC margin, majority voting, and re-enrollment procedures must be in place.
  • Cloning·emulation attempts: Physical cloning is impossible, but replay and relay after stealing the CRP DB are possible, so they are defended with one-time Challenge consumption and timestamp·session binding.

5. Deep Dive — Latest Trends and Standardization

Recent flows in the PUF domain are summarized as standardization, response to the quantum·AI era, and a commercial IP ecosystem.

First, international standardization has progressed. ISO/IEC 20897 (security requirements and test methods for physically unclonable functions) has been established, providing common criteria for PUF security properties and evaluation methods, which becomes a basis for objectively requiring PUF quality in procurement and certification. Also, with NIST's Lightweight Cryptography standardization selecting Ascon, designs that combine PUF-based keys with lightweight cryptography in extremely resource-constrained IoT are becoming realistic. As a matter of fact, detailed figures and revision timing may vary by vendor and edition, so assertions are avoided.

Second is combination with PQC and Zero Trust. As quantum computing raises the threat to long-term stored secrets, a PUF in which "the secret does not exist during normal operation" is being re-evaluated as a means of generating and protecting device root keys. Coupled with the trend of requiring strong identity for every device in a Zero Trust architecture, PUF-based device identity emerges as an economical implementation of a hardware-anchored identity.

Third is the two-sided relationship between AI and PUFs. On one hand, machine learning is the "spear" that threatens strong PUFs with modeling attacks, but on the other, ML is also used as the "shield" that compensates for the environment of and improves the reliability of PUF responses. This spear-and-shield co-evolution pressures PUF design to continuously raise nonlinearity and entropy.

Fourth is the maturation of the commercial IP ecosystem. As cases of providing SRAM PUFs as licensed IP (e.g., the technology of Intrinsic ID, acquired by Synopsys) increase, fabless designers can integrate a PUF by reusing existing SRAM without a separate process change. This shows that PUFs have entered a stage of actually being mounted in volume SoCs and security MCUs, beyond a laboratory technology.

6. Considerations and Implications

Adopting a PUF is not merely a component choice but a matter of device trust-root design and key governance, and from a professional engineer's standpoint the following must be considered in balance.

A. Reliability·availability and error-correction design — Because a PUF inherently carries noise, the ECC strength, helper-data size, and re-enrollment strategy must be quantified at the design stage so that the key is stably recovered even under extreme temperature·voltage and aging. Excessive ECC inflates area·power·latency cost, so an appropriate margin proportional to the measured bit error rate of the target environment is key. A key-recovery failure is itself a loss of device availability, so availability and security must be designed as a trade-off together.

B. PUF-type selection matched to the threat model — If the goal is "key-vault replacement," choose a weak PUF (SRAM) with good reproducibility; if the goal is "mass one-time authentication," choose a strong PUF but always accompany it with modeling-attack defenses (XOR·hashing·limiting CRP exposure). Using a strong PUF without modeling defense can be a serious design flaw.

C. Enrollment·helper-data·key governance — A PUF, too, presupposes trust at the initial enrollment moment, and the process of collecting, storing, and distributing CRPs·helper data becomes a new attack surface. Helper data is non-secret but its leakage entropy must be quantitatively managed, and policies for protecting, aging, and handling exhaustion of the CRP DB itself must be established together. Re-enrollment, revocation, and rotation procedures (the key lifecycle) must also be applied to the PUF.

D. Standard·certification compliance and consistency with the overall architecture — Depending on the application domain, ISO/IEC 20897, the Common Criteria (CC), and relevant crypto-module requirements must be confirmed in advance, and it is effective only when how the PUF links with upper key infrastructure such as TPM·SE·HSM·KMS is designed. A PUF is only the "root" of trust; it is completed only when it meshes organically with the PKI, provisioning, and update systems above it.

E. Cost·process compatibility and supply-chain strategy — A scheme that reuses existing devices like an SRAM PUF is cost-efficient because it can be integrated without an additional process, whereas a particular PUF has process·device constraints. Mass-producibility, yield, and process portability must be evaluated together, and the balance between the adoption goal of supply-chain anti-tampering and the actual integration cost must be struck.

In summary, a PUF is a technology that plants an unclonable trust root into low-cost mass devices with the idea of a "key that is not stored," and its strategic importance is growing in the era of IoT·edge·supply-chain security and PQC·Zero Trust. The professional engineer must view a PUF not as a single-device technology but from the perspective of key governance and trust-root design across the device's entire life, balancing the multi-axis trade-offs of reliability, threat model, enrollment system, standards, and cost.

References

In one line: A PUF extracts a semiconductor's microscopic process variation as a "fingerprint" to regenerate a chip-unique Response per Challenge, a low-cost trust root that blocks cloning·theft by deriving the key from physical characteristics when needed rather than storing it, becoming the hardware-security foundation of the IoT·supply-chain·PQC era around the fuzzy extractor·CRP authentication·modeling-attack defense and ISO/IEC 20897.