MY robot stores an unpublished research file in its SoC. Before choosing a PUF, the teacher asks what an attacker could obtain if the device were stolen. The data needs encryption, but its key also needs protection. This lesson follows that key-protection question back to the chip’s physical source.
This is a fictional classroom scenario. Bit tables, circuits and formation curves are teaching illustrations, not silicon measurements performed for this course, a security certification or a formal proof. Each of the thirteen sections has a complete written explanation; read it with the comics or switch to text-only mode.
1. The data is encrypted. Who protects the key?
Draw two objects on the board: a research file and the data key used to encrypt it. Encryption turns the file into ciphertext. When the legitimate user opens it later, the corresponding key is still needed. The file has protection, but the design now has another object to protect.
Our deliberately flawed design stores both the ciphertext and the plaintext key in a region the attacker can copy. With both objects, the attacker can run the public decryption algorithm. Nothing in the cipher has to be broken. The relevant assumption is access to the key, not physical proximity: two objects being inside the same SoC does not mean that every storage region has the same access permissions.
A student suggests moving the key into a different file. Can the same attacker read that file too? If so, moving it has not changed the attacker’s ability to obtain the secret. Another proposal is to protect the data key with a second key. This has a practical use, called key wrapping, but it leads to another question: who protects the wrapping key? Wrapping must address both confidentiality and integrity of the protected key.[6]
Following that question to the root explains why students want a chip-native secret and may even ask for it to be ‘absolutely safe.’ A PUF offers one route from physical variation to secret material. PUFsecurity’s public application description includes protection of injected secrets. The physical source, the way a usable secret is obtained, and the permissions for using it remain separate questions.[1]
We will examine two uses. One protects a key that already exists, such as an independently generated data key. The other supports a hardware unique key, or HUK, from which purpose-specific keys can be derived. They can overlap: a key derived from a HUK can wrap the data key. These are useful architectural perspectives, not mutually exclusive product classes or a mandatory hierarchy for every SoC.
Classroom question: does splitting a plaintext key across two files solve the problem if the attacker can read both? No. Evaluate the information and operations the attacker can ultimately obtain, rather than counting how many pieces you created. We will first look inside the chip to understand the physical source.
2. Same design, different silicon?
MY places two samples of the same SoC on the bench. A common design means they are intended to perform the same functions. It does not require every microscopic device parameter to match exactly. Ordinary digital logic tolerates variation while producing the required results; a PUF selects physical effects through which some of that variation contributes to an observation.
SRAM startup behavior, for example, can be influenced by device mismatch. Two nominally symmetric sides have slightly different actual characteristics. The magnified pictures in this lesson are conceptual illustrations, not microscope measurements. They do not imply that all PUFs use the particular geometric difference drawn here. The relevant source depends on the mechanism and fabrication process.[2]
PUF is commonly expanded as Physically Unclonable Function. A ‘chip fingerprint’ is an analogy for instance-specific features. It does not mean that fingerprint ridges are etched into silicon, or that a published response can still be treated as a secret. The physical feature stays in the chip; a readout circuit turns its behavior into digital material for further processing.
Keep three stages distinct. The source tells us what is being observed. The measurement method tells us how the signal is obtained. Digital processing determines how the observation supports a particular task. A string of zeros and ones, by itself, does not establish that its origin, repeatability or exposure to an attacker makes it suitable for protecting research data.
Now change the temperature or supply conditions. These can alter an observation from the same readout path, but that does not make them a fixed device identity. In this lesson, manufacturing variation provides the source and environmental conditions affect measurement. Mixing them up would treat ‘the chip is warmer today’ as evidence that it is a different chip.
Classroom question: if eight selected bits happen to match on two chips, does that prove their physical structures are identical? No. A finite digital observation retains only some information. Different physical states may map to the same short string. Distinguishability and security require adequate samples and a stated method of evaluation.
3. Different, repeatable, unpredictable: three separate tests
Calling a response ‘very random’ can hide three separate questions. Can we distinguish different chips? Can the original chip reproduce the required material? After observing some information, can an attacker predict the secret? All three matter for data protection, but one cannot stand in for the others.
Try a hand-worked example. Chip A first gives 10100110 and, after another power-up, A′ gives 10100100. Chip B gives 11001100. Align A with A′: only position 7 differs, so the Hamming distance HD(A,A′) is 1. Align A with B: positions 2, 3, 5 and 7 differ, so HD(A,B) is 4. Hamming distance counts unequal positions. It is not subtraction of the binary numbers.
Repeated observations of one chip examine repeatability. Comparisons across chips help examine distinguishability. These eight-bit values were chosen for teaching; they are not silicon measurements. They do not establish a product error rate of one eighth, and four differing positions do not mean four bits of security. A real evaluation must state sample counts, repeated trials, operating conditions and statistical distributions.
Consider the public constant 01010101. It contains four zeros and four ones, yet someone who knows the rule can predict the entire next occurrence. This counterexample shows why the balance of one string cannot establish an attacker’s uncertainty. Correlations, bias, helper data and exposed interfaces also matter when the material is supposed to remain secret.
For the same reason, the word ‘unclonable’ cannot replace analysis. If an architecture exposes many input-output observations, an attacker may try to build a model that predicts its behavior. Original research demonstrates modeling attacks on particular PUF families under stated observation conditions. That is not a finding that every protected PUF key architecture is broken in the same way. Conversely, difficulty reproducing the physical structure does not excuse predictable behavior.[9]
Classroom question: is a perfectly repeatable string suitable as a secret key when everyone knows it? No. It may be stable while offering none of the needed secrecy. Keep these three questions separate as we compare the physical mechanisms.
4. What do SRAM, RO and NeoPUF measure?
MY puts three candidate designs on the bench for the same research-data problem. These are alternatives to evaluate, not a requirement to install all three in one SoC. Ask what each measures before comparing its supporting circuits, test requirements and lifecycle costs.
An SRAM PUF observes the startup preferences of memory cells. It uses physical mismatch, rather than reading a secret from a file that was written earlier. Reusing existing SRAM is conditional: the startup data must be available before initialization overwrites it, and the memory’s power control, readout timing and isolation must support the intended use.[2]
RO stands for ring oscillator. Conceptually, two oscillators can be counted independently over the same measurement interval, and their counts compared so that delay variation contributes to an output. Each oscillator feeds its own counter; oscillator A should not be drawn as driving oscillator B. The interval, oscillator selection, supply coupling and readout conditions matter. This page is a functional illustration, not a tape-out-ready circuit.[10]
Our NeoPUF example uses paired NeoFuse elements. Microscopic oxide variation participates in controlled formation, followed by later readout of the resulting state. The pair forms one decision unit. NeoFuse and NeoPUF are not names for two different devices in that pair, and the two sides should not be drawn as independently generating two PUF bits.[1][3]
Suppose the SoC has plentiful SRAM, but its startup firmware immediately clears the entire array. A source that initially looked inexpensive now needs a different acquisition sequence. Conversely, a source with convenient repeatability may require additional process support, formation or testing. A useful comparison includes source acquisition, protected use, operating conditions and cost; the family name cannot make that decision.
Classroom question: if an RO comparison repeats three times, can we declare it more secure than SRAM? No. Three observations do not cover prediction attacks, the operating range or the key-use interface. Fix the product objective and threat assumptions before comparing candidates.
Engineer extension
Engineer extension: weak/strong PUF terminology commonly concerns the available challenge-response space and related properties. It is not a weak/strong security score. A physical challenge might select paths or cells. A fresh authentication nonce identifies a protocol interaction. These are different layers; a timestamp cannot simply be connected to every PUF block.[9][10]
5. How does SRAM settle when power rises?
Start with two cross-coupled inverters. An inverter turns a high input into a low output, and a low input into a high output. Connecting each output to the other input creates feedback. Call the two nodes Q and QB. A stable state can have Q=1 and QB=0, or the complementary values.
The plate uses functional symbols for the storage core, not a complete transistor schematic. In a common 6T SRAM cell, four transistors form the two inverters. Two additional access transistors, controlled by the wordline, connect Q and QB to the bitline pair. Omitting those branches helps us focus on feedback, but the omission must be stated; otherwise a four-transistor core can be mistaken for the complete six-transistor cell.
As power rises, the circuit enters its operating range. In an ideally symmetric picture, neither side has an inevitable advantage. Real mismatch and noise influence startup. Suppose Q becomes slightly higher first. Through the opposite inverter, that pushes QB lower. A lower QB, in turn, supports a higher Q. Positive feedback amplifies the initial imbalance until the circuit settles into a state it can hold.[2]
‘Preference’ matters here. It describes an outcome that is more likely under specified conditions, not a promise that every startup is identical. An array of cells supplies chip-related observations, some of which may vary more than others. Also, the two complementary nodes of one cell are not two independent sources of entropy: knowing Q constrains QB in a stable state.
If MY writes Q to 1 during normal operation and repeatedly reads 1 afterward, the cell is retaining written data. It has not repeated the startup competition. Studying SRAM-PUF behavior requires suitable power removal, discharge, power-up and prompt acquisition. Firmware must not overwrite the selected locations before the observations are collected.
Classroom question: are a thousand reads after one power-up the same test as a thousand power-ups? No. The former mainly examines an already-held state and its read path; the latter repeatedly tests startup behavior. A test plan that misses this distinction can produce an impressive read log without answering whether a key can be reconstructed.
6. Why can a reboot change a few bits?
MY powers the same chip up three times. In our teaching table, position 7 gives 1, then 0, then 1; the other illustrated positions stay unchanged. That observation does not, by itself, mean the chip is defective. The useful question is whether the variation falls within what the design can handle.
A cell with a pronounced mismatch may be less easily redirected by small disturbances. A nearly balanced cell may be more sensitive to noise. The balance-scale drawing is an analogy for preference and disturbance; SRAM does not contain mechanical weights. Its startup behavior involves device characteristics, the power ramp and internal node dynamics.[2]
Temperature, supply and aging tests bring the evaluation closer to how the stored data will actually be used. Research results may need to be decrypted years after manufacture. If the root material is recoverable only under the original room-temperature test, the design lacks evidence that its data-access path will work across the product’s intended conditions.
Selecting stable bits is one available measure, but it has costs. Discarded positions reduce usable capacity, and testing more conditions takes production time. Selection records may need storage and belong in the information-leakage analysis. ‘We selected the more stable bits’ does not justify ‘these bits can never fail,’ nor does it justify an unsupported stable-bit percentage for every process.
For key protection, the problem is more consequential than a red square in a table. If a changed observation produces a different KEK, the originally wrapped DEK may not unwrap correctly. Availability therefore belongs beside confidentiality: keeping a secret from an attacker while permanently locking out the legitimate researcher would still fail the product’s objective.
Classroom question: if every position observed to flip is excluded, can error handling be omitted? No. Past observations are finite, and later operation may encounter untested conditions or other faults. The next page separates obtaining a raw observation from reconstructing a usable secret.
7. How can noisy readings recover the same secret?
Decryption needs the corresponding key. If raw SRAM observations can vary, sending each new observation straight into a cipher does not make it become the same key. MY needs a reconstruction design with stated conditions: tolerate the expected observation differences while retaining sufficient secrecy.
During enrollment, the system obtains reference observations according to its design and produces secret material plus helper data for later reconstruction. An implementation may take repeated measurements, select locations or use a particular code. Not every PUF follows ‘one read, then the same ECC block.’ On a later occasion, the new observation and the corresponding helper data enter reconstruction, with recovery promised only under the design’s conditions.[4]
There are three jobs. Error correction or reconciliation addresses observation differences. Entropy extraction produces suitable secret material under a stated source model. A KDF derives keys for specified purposes and contexts. An implementation can combine stages while retaining these separate responsibilities. Hashing does not identify and repair changed SRAM positions or guarantee the same digest for nearby inputs.
The experiment later on this page computes code-offset reconstruction with an eight-bit response and a four-bit classroom key. SECDED corrects one error and detects two; three flips can cause miscorrection. This exposes a tolerance boundary, without a secrecy guarantee: anyone can enumerate the tiny key space. Residual entropy and helper-data tampering still require separate analysis.
Public helper data is a property of some constructions under a stated security model, not a claim that it carries no information. Evaluate the uncertainty left after it is observed, and the consequences of replacing or modifying it. Basic fuzzy-extractor work and robust fuzzy extractors addressing active interference consider different adversarial conditions. Do not extend a passive-data guarantee to arbitrary tampering.[4][5]
When errors exceed the design’s capability, the system may not automatically know. A decoder can fail or return a different candidate. Appropriate checks and failure handling are additional requirements. The plate’s check-and-allow/stop branch expresses that design obligation; it does not promise perfect detection of every error. A wrong candidate may surface later as a wrapping or data-authentication failure, so diagnosis must follow the path rather than blame only the final block.
Classroom question: does applying SHA-256 to the new reading produce an error-corrected, stable key? No. Hashing does not establish the required tolerance relation or create secrecy absent from the source. State the reconstruction assumptions, source quality and checks before deciding how purpose keys are obtained.
Engineer extension
Let W denote the reference observation. A fuzzy extractor's generation procedure can be written Gen(W)→(R,P), with secret output R and helper data P. Rep(W′,P) recovers R under the specified distance and source conditions. This notation does not remove the distance bound, statistical-closeness requirement or residual-entropy assumptions. Observing P, modifying P and forcing repeated enrollment are different analysis settings.[4][5]
8. Where does NeoPUF obtain its physical variation?
After SRAM, we examine another candidate. This transition does not declare SRAM a failure or select NeoPUF for every product. The point is to ask how formation, readout and testing change when secret material comes from a different physical source.
The lesson follows the paired-NeoFuse example described publicly by eMemory and PUFsecurity. The elements have the same nominal design, but their microscopic oxide states differ. Oxide traps influence carrier transport. The published mechanism connects those differences to controlled formation that establishes a state for later readout.[1][3]
The illustration separates gate, oxide and substrate so the reader can locate the relevant physical region. Dots, paths and colors are conceptual. Counting the dots does not estimate actual trap density, and the width of a drawn path does not determine current. Precise claims about a process require the corresponding structure, bias conditions and measurements.
Two confusions would derail the explanation. NeoPUF names the technology or architecture under discussion; one bit-cell in this example uses two NeoFuse elements, not a NeoFuse paired with a different device called a NeoPUF. Nor is this an OTP patch that supplies replacement values for unstable SRAM bits. That picture would merge two different sources and distort the meaning of enrollment.
Why give the mechanism three pages? The source answers where variation comes from. Formation explains how controlled conditions establish a physical state. Readout explains how that state later becomes a digital observation. A single arrow from ‘physical variation’ to ‘secure key’ would conceal the intermediate steps that require evidence.
Classroom question: does the same nominal structure guarantee identical formation behavior on both sides? No; microscopic differences are part of the mechanism. Conversely, observing differences does not prove an ideally balanced output distribution. Bias still needs measurement and analysis.
9. Enrollment: which side forms first?
Enrollment in this NeoPUF example includes physical formation. In the public description, paired elements undergo different current evolution under higher-field conditions, with sensing and feedback controlling formation. The stop arrow expresses an important design function: the process does not simply apply unlimited stress.[3]
Think of nominally symmetric elements with different microscopic states. Formation develops that difference into a result suitable for subsequent sensing, with the left or right side forming. The two branches in the plate are alternative outcomes for one bit-cell. They are not a sequence in which the same cell forms on the left today and is arbitrarily rewritten on the right tomorrow.
The current plot is qualitative teaching material, not an instrument trace. Its unnumbered threshold cannot specify a real voltage, pulse width or stopping rule. A product has its own circuit, process and screening requirements. The lesson explains causal relationships in the public mechanism rather than exposing or inventing internal implementation parameters.
‘An operator does not directly choose the secret bit’ also does not mean that operating conditions are irrelevant. If a systematic bias favors one side, the output distribution requires examination. Equal-sized left and right branches are a layout choice, not experimental evidence for equal probabilities. Control conditions, sample statistics and the security judgment belong in separate records.
Compare this with SRAM enrollment. There we obtained reference observations and established selection or reconstruction data according to the design. Here enrollment includes creating a physical state. The same English term can cover different tasks in different architectures. Defining it universally as ‘store the reference value’ would hide that distinction.
Classroom question: can the two outcomes be joined into a repeatable 0-to-1 write operation? No. That would change the lifecycle into a different memory operation. After formation, the next question is how to read the established state.
10. Extraction: reading the state already formed
The research file must be opened today, so the system needs its secret material again. Our NeoPUF example senses the already-formed paired state under lower read conditions. Obtaining another reading does not require repeating the original higher-field formation each time.[3]
Separate physical state from bit encoding. The sensing circuit observes an electrical difference between the paired elements, and digital logic encodes the result. Our convention maps left-side formation to 1 and right-side formation to 0. Another consistent encoding is possible. The mapping is a representation choice, not a law that the left side is physically a logical 1.
SRAM and this example use different lifecycles. SRAM observations come from startup preference and require the design to handle relevant repeatability issues. This example first establishes a physical state and later reads it. Both must provide trustworthy digital material, but power timing, enrollment and readout circuitry can differ.
A conveniently readable state still requires evaluation of read margin, intended voltage and temperature ranges, aging and faults. Product claims about correction overhead or observed errors must stay within their test and use conditions. We do not turn a vendor’s ideal characteristics or a bounded result into a promise that every device is permanently error-free or immune to aging.
Here, Extraction means physical readout. Cryptographic entropy extraction in section 7 concerns a different processing layer and its assumptions about uncertainty. Similar names do not imply that a low-voltage sensing circuit automatically meets every fuzzy-extractor requirement. The processing after readout remains an architectural decision.
Classroom question: does reversing every left/right bit assignment increase secret entropy? No. A known, consistent reversal changes the representation. We now have a source and acquisition path to discuss; the next step is to reconnect them to the original research file.
11. Use one: protect an existing data key
Return to the bench. The blue Data Encryption Key, DEK, protects the research data. The amber Key Encryption Key, KEK, protects the DEK. Their names identify jobs; they do not require different cipher algorithms. Recoloring the same raw key would not create the separation being illustrated.
We choose a concrete teaching architecture. A DEK already exists, generated through an appropriate secure-random mechanism, and a protected cryptographic service encrypts the data with it. The PUF path supplies root material from which a KEK is derived. That KEK wraps the existing DEK. Readable storage receives the data ciphertext and wrapped DEK; saving the file does not export the plaintext DEK or KEK into ordinary readable memory.
Wrapping is not an invitation to pick an arbitrary encryption mode for a key. NIST SP 800-38F describes confidentiality and integrity for key wrapping and defines methods including AES-KW and AES-KWP. These help explain why the protected key must also be checked, but a mode name is not a complete storage protocol. Object names, purpose, versions and permission to unwrap require trusted policy or appropriate cryptographic binding.[6]
On the next read, the corresponding KEK is obtained inside the protected boundary. The service unwraps and checks the DEK before using it to authenticate and decrypt the data. If a check fails, it must not release unverified candidate plaintext or substitute a blank key and continue. Diagnosis should trace reconstruction, the wrapped object, algorithm parameters and stored content instead of blaming the final decryption block alone.
The data can use a suitable authenticated-encryption construction, such as AES-GCM operated under its specification. AEAD addresses confidentiality and integrity but still has nonce-management requirements and usage limits. For GCM, a nonce must not repeat under the same key. Resetting a counter at reboot or rolling stored state back can violate that requirement. A record’s nonce, tag and public metadata may be saved; they are not additional secret keys.[7]
If the attacker only copies ciphertext, the wrapped DEK and public parameters, without the KEK or permission to decrypt, the copied objects do not directly reveal the file under our assumptions. That answers one version of the opening problem. Stored-data protection does not cover every subsequent use of plaintext: the service must still decide who receives the result.
Classroom question: because the KEK protects the DEK, can we use the KEK directly to decrypt the research file? That does not follow. The file was encrypted with the DEK, which must first be correctly recovered. Follow each key’s role through the arrows rather than treating the two keys as interchangeable after unwrap.
Engineer extension
Engineer extension: write B=Wrap(KEK,DEK) and (C,T)=AEAD_Encrypt(DEK,N,M,A). B is the wrapped key, C the data ciphertext, T the tag, N the nonce and A the authenticated but unencrypted associated data. Reading requires successful Unwrap followed by AEAD verification using the corresponding parameters. This notation omits a full format, persistent nonce management, rollback policy and key-version migration; KW/KWP and AEAD interfaces cannot be freely interchanged. Integrity does not imply freshness: replaying an entire formerly valid record needs a separate anti-rollback defense.[6][7]
12. Use two: a PUF-backed HUK and purpose keys
HUK means Hardware Unique Key. It is a device-related root-secret role in an architecture. A PUF is one physical route to the secret material supporting that role; other secure hardware mechanisms are possible. Separating role from source avoids assuming that every platform mentioning a HUK contains a particular PUF.
If this SoC chooses a PUF path, raw observations still require processing appropriate to source quality, repeatability and the cryptographic design before supporting the root-key role. The plate’s source-to-processing-to-HUK chain describes logical layers. It does not require permanent storage of every intermediate value or make every value visible to software.
Why derive more keys from the root? If the storage and wrapping services directly reuse the same root key, exposure or misuse at either interface can immediately affect the other job. Purpose separation lets the architecture assign keys, algorithms and policies to particular services while avoiding use of the root at every entry point.
A KDF combines secret input with purpose and context parameters. HKDF’s info can bind derived material to an application context, using consistent, unambiguous encodings. Those labels generally need not be secret. They identify the job; secrecy still relies on the root material and algorithm assumptions. A KDF cannot manufacture entropy missing from its source.[8]
Trusted Firmware-M’s Protected Storage design is one example: the storage service asks a cryptographic service to derive a storage key from a HUK and requests operations through handles rather than obtaining all the key bytes. This illustrates protected use and context separation. It does not establish that every TF-M platform uses a PUF or requires its storage key to wrap an independent DEK.[11]
The two uses can now connect. In our chosen architecture, one HUK-derived purpose key is the KEK from section 11, protecting an existing DEK; another service can have another branch. Whether to use this hierarchy depends on updates, sharing, rotation, object counts and product requirements. Root compromise may still affect multiple branches. A KDF is not a firewall that removes root-level risk.
Classroom question: if ordinary software knows the public label ‘wrapping,’ should it be allowed to request arbitrary root-key derivations? No. A label separates contexts; it is not an authorization credential. The secure service must check the caller, allowed purpose and output policy. Otherwise an attacker may use the service to perform forbidden operations without ever reading the root secret.
13. A protected root is not the whole system
MY began by wanting to protect research data stored in an SoC. We can now state a conditional answer: protect the data with a DEK, and wrap that DEK with a KEK obtained and used inside an enforced boundary. A PUF can support the root source and the HUK role behind this path. Copying ordinary readable storage still leaves the attacker without the secrets and permissions that our initial model excludes.
Change just one condition. Instead of removing storage, the attacker exploits software on the original SoC. If that software is authorized to request decryption, the attacker may obtain plaintext through an otherwise legitimate service path. The PUF structure has not been cloned, and the root key may never have been read directly. The research data can nevertheless leak. Unique device keys do not answer an access-control or software-compromise problem.
Secure Boot checks startup software against a trust policy. Access control decides which callers may operate on which data. Hardware isolation limits where secrets appear. These functions can work with a PUF but are not automatically provided by it. Signed software may still contain vulnerabilities, and passing boot verification does not prove that later execution cannot be compromised.
Product evaluation must also consider physical and interface attacks. Are debug paths disabled or controlled? Do operations reveal useful timing or power information? Can faults skip checks? Can reconstruction data be substituted? Does an exposed PUF interface provide enough observations for modeling? These questions require specific designs and tests. Different families, interfaces and attacker capabilities cannot be collapsed into one universal secure/insecure label.[5][9]
Now consider repair. If only the original chip’s root can unlock the data, replacing it with the same SoC model may not reproduce the required key. With a failed original and no prearranged authorized recovery path, the data may be permanently lost. Backup, escrow or migration schemes can change that outcome, while adding secrets, permissions or external dependencies to protect. A design cannot promise both exclusive access through the original chip and unconditional recovery after that chip is destroyed.
Transfer question: two legitimate devices need the same encrypted research file. Can the first device’s wrapped DEK simply be copied to the second? With different device KEKs, it generally will not unwrap directly. The system needs an authorized distribution or rewrapping path. That does not require publishing the HUK or giving both devices the same root. Sharing requirements and device-binding policy should be decided together.
Returning to ‘who protects the key at the bottom,’ an adequate answer names more than a component. It explains the source, reliable acquisition, purpose separation, enforced isolation, permissions and lifecycle. A PUF can supply part of that root. Each function attached to it still has assumptions to explain and verify.
Engineer extension
Engineer extension: authentication is another potential application. A device can use a protected identity key to answer an appropriate fresh challenge, with trusted enrollment binding verification material to the intended device. Identity binding, replay defenses and protocol context still need design; publishing a raw PUF secret is not that protocol. Successful authentication does not automatically establish trustworthy current software, correct measurements or absence of relaying. Authentication remains an extension here; the main storage problem has already been resolved under its assumptions.
Five points to keep
- A PUF supplies a physical source of secret material; its name is not a guarantee against every attack.
- Evaluate same-chip repeatability, cross-chip variation and attacker unpredictability separately.
- SRAM reconstruction and NeoPUF formation/readout are different workflows. Hashing alone does not correct noise.
- A DEK protects data and a KEK wraps the DEK. HUK names a root role whose purpose keys can include the KEK.
- Design protected boundaries, service permissions, failure handling and cross-device recovery alongside the PUF.
Continue with Hardware Root of Trust to connect root keys, boot trust and access boundaries, or revisit Secure Boot and ask what happens when malicious software can call an otherwise protected key service.
Glossary
| Term | Meaning in this lesson |
|---|---|
| PUF | A circuit using physical variation to produce measurable responses; security depends on the implementation, processing and threat model. |
| DEK | Data Encryption Key: the key that encrypts the data. |
| KEK | Key Encryption Key: used here to wrap and unwrap a DEK. |
| HUK | Hardware Unique Key: a device-specific root-key role. A PUF is one possible source. |
| Helper data | Auxiliary reconstruction data. Public storage does not remove integrity or leakage-analysis requirements. |
| Enrollment | An initial setup stage; SRAM observation/coding and NeoPUF controlled formation must be distinguished. |
| Extraction | In the public NeoPUF mechanism, readout of a formed state; distinct from cryptographic entropy extraction. |
| KDF / HKDF | Derives keys from input material and purpose context; neither error correction nor a source of new entropy. |
| Key wrapping | Protection of another key’s confidentiality and integrity using a KEK; AES key wrapping is the example here. |
References
- PUFsecurity — NeoPUF: A Reliable and Non-traceable Quantum Tunneling PUF — Public mechanism and use cases; vendor performance claims require validation under their stated conditions.
- Holcomb, Burleson & Fu — Power-Up SRAM State as an Identifying Fingerprint and Source of True Random Numbers — SRAM startup state, device preference and noise.
- Charles Hsu / eMemory — The Quantum Tunneling Mechanism of NeoPUF — Oxide variation, paired elements, formation control and readout; not measurements performed for this lesson.
- Dodis et al. — Fuzzy Extractors: How to Generate Strong Keys from Biometrics and Other Noisy Data — Formal conditions for reconstruction, entropy and public helper data.
- Kanukurthi & Reyzin — An Improved Robust Fuzzy Extractor — Active helper-data tampering and robust fuzzy extractors.
- NIST SP 800-38F — Methods for Key Wrapping — Confidentiality and integrity of wrapped keys; this lesson uses AES key wrapping as its example.
- NIST SP 800-38D — Galois/Counter Mode (GCM) and GMAC — Authenticated encryption and nonce/IV requirements.
- RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF) — Extraction, expansion and purpose context; a KDF does not manufacture source entropy.
- Rührmair et al. — Modeling Attacks on Physical Unclonable Functions — Modeling attacks against particular PUF designs and query interfaces; not a universal result for every implementation.
- Suh & Devadas — Physical Unclonable Functions for Device Authentication and Secret Key Generation — Ring-oscillator PUFs, frequency comparison and key applications.
- Trusted Firmware-M — Protected Storage Key Management — A concrete HUK/storage-key hierarchy, not a requirement that every HUK be PUF-derived.
#PUF #SRAM #NeoPUF #DEK #KEK #HUK #HardwareSecurity #ComicClassroom
Flip one bit, then two: can reconstruction continue?
Keep enrollment response 165 and classroom key 9. Try noise mask 1, then 3: these flip one and two bits. Inspect helper XOR and the SECDED syndrome. Try 7 to see a miscorrection outside the guaranteed distance.
An 8-bit code-offset reconstruction toy: W=R XOR C(k), with SECDED(8,4) correcting one error and detecting two. Three or more errors have no guarantee. The four-bit key is trivial to enumerate. This is neither a PUF measurement nor a secure fuzzy extractor; it proves no helper-data privacy, entropy or environmental stability. Production designs require separate assessment.
The final key comparison uses the classroom’s known enrollment answer to expose miscorrection. It does not mean a real device automatically retains or knows that key. Production systems need their own candidate validation and failure handling.
Learning guide
How Trust Is Built Inside a Chip
Open the course outline → · Progress counts published lessons only
Prerequisites
- Basic digital logic and encryption
What I learned
- Trace data protection through DEK, KEK and a possible HUK
- Distinguish physical sources, reconstruction and formation/readout
- Assess permissions, failure and recovery boundaries