This was the first VIP meeting class, so we did introductions with the other members in the team and the instructors. From the intro slides, I learnt about the different teams in this project, such as Simulation and Analysis, ROS, and Device Security. I was particularly interested in device security, especially when related to side channel attacks and FPGAs. I completed the Welcome Quiz, and stated that my preference was to be on the Device Security team.

Note: I am a 1 credit hour student, and will be completing one entry per week.

In our second group meeting, I was assigned to be on the Device Security team as requested. I researched more about the different possible tracks, and after consulting with one of our instructors (Hayden), I chose FPGA RO PUFs as my area of concentration for this project. I read some papers on the topic to better understand RO PUFs and their advantages compared to other security methods:

• Kareem, H., & Dunaev, D. (2023). A robust architecture of ring oscillator PUF: Enhancing cryptographic security with configurability. Microelectronics Journal, 143, 106022. https://doi.org/10.1016/j.mejo.2023.106022
• 142 RO-based Physically Unclonable Function (PUF) - tiny tapeout. (2026, September 7). Quicker, Easier and Cheaper to Make Your Own Chip! https://tinytapeout.com/chips/tt07/tt_um_litneet64_ro_puf

RO PUFs are newly emerging in cybersecurity since they use the chip's microscopic physical distinctions to generate the output encryption key, making it extremely challenging to produce counterfeits of the device. Also, RO PUFs are being further developed to increase the number of bits in the output, which provides an impressive combination of output uniqueness, reliability and randomization ability.

I also explored the Linux tutorial, and learned about commands such as pwd, cd, ls, echo, file and grep.

prishab@Prishas-MacBook-Air-2 ~ % echo $SHELL
/bin/zsh

prishab@Prishas-MacBook-Air-2 ~ % pwd
/Users/prishab

prishab@Prishas-MacBook-Air-2 ~ % ls 
a.out				Music
Applications			path
Claude				Pictures
Desktop				Public
Documents			PythonWebScraperProject
Downloads			test.c		
Lab2ProjectileMotion.trk	verilog_project
Library				WebScraperProject
Movies

prishab@Prishas-MacBook-Air-2 ~ % file Desktop/ROPUFInfo.pdf
Desktop/ROPUFInfo.pdf: PDF document, version 1.7

This week, we did not have a full group meeting as our instructors were out for a conference. However, the device security subteam did meet up to discuss roles and split the tasks for the slides. I worked with Estelle on researching and completing the Kickoff slides for PUFs, as this is the project we will be working on together for the rest of the semester.

Estelle has been working on this VIP in the previous semester, so they guided me to some great resources to catch up on the progress so far. In my slides, I included a short introduction to PUFs, key advantages and potential challenges that we might face, as listed below. Estelle prepared the long and short term goals, as well as subteam tasks.

Introduction: A PUF is a physical object that provides a unique identifier, equivalent to a digital fingerprint, as the output of a challenge-response mechanism. It uses microscopic variations in a chip that occur during manufacturing (which are fully random and uncontrollable) to produce a response. Used in device security to prevent cloning, and provide extremely high accuracy for chip authentication.

Advantages:

• Compared to cryptographic keys which are vulnerable to extraction, PUFs are not stored in memory, so cannot be stolen or extracted.
• Unclonable to even the manufacturer so no issues with data leaks, copies and reprogramming as the PUF response is totally random.
• Fully tamper resistant as probing or delayering a chip will alter its microstructure, and effectively change the PUF response.

Potential Challenges:

• Noise – PUF responses can be affected by environmental factors (temperature, aging, etc) so the same challenge can only guarantee a response which is 95% identical (unusable as a key). Needs error-correction.
• Limited control – fully ‘random’ PUF responses may be subject to systemic bias or little variation, which can produce correlated responses across chips.

This week we had our Kickoff presentations, and I met Estelle who I will be working with on the PUFs. The presentation went very well overall, and I feel that we covered all the necessary content in an organized and efficient manner. To improve, one of the pieces of feedback we received was to make our slides less dense in terms of information. For the rest of the week, I plan to research more about RO-PUFs (since those are the type we will be using) and also read up on what the team has accomplished so far.

Our long-term goals are:

• Implement PUF-Based Device Authentication. Use SRAM PUF responses to uniquely identify grid devices and provide a hardware-rooted trust anchor.
• Develop Secure PUF Key Generation Mechanisms. Generate cryptographic keys from PUF outputs using helper data and error correction, without storing keys externally.
• Evaluate PUF Reliability and Security Against Physical Attacks. Test stability under environmental variation and assess vulnerability to side-channel and fault-injection attacks.

And our current short-term goals are:

• Build working knowledge of SRAM PUFs. — the reliability metrics, the fuzzy extractor construction, and BCH parameters as a design tool.
• Reproduce the existing analysis pipeline — recover their stability, error-rate and BCH results from the archived data and scripts.
• Independently validate the findings — rederive the metrics from scratch, check parser correctness and statistical assumptions

The Kickoff slides for the Device Security subteam are attached here:

Copy of Device Security Kickoff Presentation.pptx.pdf

This week, I focused on short-term goal 1: building a working knowledge of SRAM PUFs, and also connecting with Estelle to find a suitable time for us to experiment with the physical devices. For my research, I focused on understanding the foundational concepts of PUFs and fuzzy extractors first and then tried to explore RO-PUFs. Mainly, I was looking into why we switched to RO-PUFs, and what the potential benefits of that could be. Following is the document I made containing my research.

SRAM_PUFs_Reliability_Fuzzy_Extractors_BCH.pdf

This week, I read through one of the research papers sent by our instructor (Hayden) and looked further into PUFs in general, specifically RO PUFs. Following are the notes I made based on my readings:

Problem

• Chips need secret keys, which are usually stored in fuses or EEPROM.
• A stored key is always sitting there, so an attacker can physically read it.
• Protecting it needs expensive tamper-sensing hardware.

Idea

• PUF (Physical Unclonable Function): get the key from random manufacturing differences in the chip instead of storing it.
• Every chip is slightly different, so its PUF output is unique, unpredictable and uncloneable.
• The key only exists while the chip is on. There’s nothing stored to steal.

Ring Oscillator (RO) PUF

• Build many identical ring oscillators. Each one runs at a slightly different speed due to manufacturing.
• To make a bit, compare two oscillators: A faster than B gives 1, otherwise 0.
• It’s easy to build on an FPGA, with no careful layout needed.
• Use each oscillator once to keep bits independent (256 oscillators → 128 bits).

Reliability fix: masking

• Heat or voltage changes can make close-speed pairs swap order, which flips the bit.
• Fix: out of every 8 pairs, keep only the one with the biggest speed gap.
• Save which pairs you picked (public info).

Key generation Problem: PUF output is slightly noisy, but a crypto key must match exactly every time.

Setup (once): read the PUF and save an error-correcting syndrome (a hint for fixing flipped bits). It’s public, so it can be stored anywhere. Every use: read the PUF, fix the flipped bits with the syndrome, then hash the result into a key. For AES, use the hash directly as the key. For RSA, use it as the seed for key generation.

Leakage: the syndrome leaks some bits, so generate extra.

BCH(127,64,21): 127 bits read, 64 bits stay secret. It corrects up to 10 errors.

Results (15 FPGAs)

• Different chips: 46% of bits differ (ideal is 50%).
• Same chip at worst-case temperature and voltage: 0.48% of bits differ.
• Key regeneration fails less than 5×10⁻¹¹ of the time.

BOTTOM LINE: Random chip flaws give a fingerprint. Error correction makes it stable, and hashing turns it into a key that’s never stored.

My next planned step is to try and build a simple RO PUF in Verilog on an FPGA:

1. Make 2 ring oscillators, then add counters and a comparator to get 1 bit.
2. Use (* keep *) / DONT_TOUCH so the tools don’t optimize the oscillator loops away.
3. Scale to about 16 pairs and read the bits over UART or LEDs.
4. Measure how stable the bits are on one board, and how different they are across two boards.
5. Stretch goal: add masking, simple error correction and a hash to get a stable key.

This week, Estelle and I will be meeting up after our VIP meeting to test out RO PUF implementation. The main idea is to build a ring-oscillator PUF on FPGA (Artix-7, Vivado) producing a unique, repeatable per-board response. Following is our implementation plan.

Architecture: N ROs → 2 muxes (challenge selects pair) → 2 counters → comparator → 1 response bit. Repeat over non-overlapping pairs → multi-bit response → UART to PC.

Steps:

1. Single RO: 1 NAND + 4 inverters; keep loop from being optimized out.
2. Counter: count RO edges over fixed window (e.g. 10k sys-clk cycles @100 MHz).
3. Array: instantiate 32 ROs via generate.
4. Select + compare: muxes pick RO i/j; resp = (cntA > cntB).
5. Placement: identical layout per RO via LOC/Pblock constraints.
6. Readout: UART to PC; log responses.
7. Evaluation: reliability (same board, 100+ runs), uniqueness (~50% inter-board HD), uniformity (~50% ones).

Code:

module ro(input en, output out);
  (* DONT_TOUCH="true" *) wire [4:0] w;
  assign w[0] = en & w[4];
  assign w[1] = ~w[0];
  assign w[2] = ~w[1];
  assign w[3] = ~w[2];
  assign w[4] = ~w[3];
  assign out  = w[4];
endmodule

module ro_counter(input ro_clk, input rst, input en, output reg [31:0] cnt);
  always @(posedge ro_clk or posedge rst)
    if (rst) cnt <= 0;
    else if (en) cnt <= cnt + 1;
endmodule

# constraints (.xdc)
set_property ALLOW_COMBINATORIAL_LOOPS TRUE [get_nets -hier *w*]

Milestones

• M1: read count from a single RO
• M2: 32-RO array + challenge/response working
• M3: placement constrained, UART logging
• M4: reliability/uniqueness/uniformity results

Risks:

• Synthesis removes loop → DONT_TOUCH + ALLOW_COMBINATORIAL_LOOPS
• Unstable bits (near-equal ROs) → majority vote / discard close pairs
• Temperature drift → test later
• Placement bias → constrain RO placement