It was my first day of CPS - VIp. We covered the foundational structure of the Cyber Physical Systems VIP class. We learned the CPS problem domain and explained how cyber (software, firmware, networking) and physical (power systems, sensors, actuators) components integrate to form critical grid infrastructure.We went over the course agenda, project scope, expectations for GitHub-based notebooks, and how grading is based on.

I'm interested in Device Security Team.

I want to join Device Security Team, so I focused on the security-related parts of the Week 1 lecture:

• Device security in CPS involves protecting embedded devices such as Raspberry Pis used in substations.
• What we will explore this semester: ** reverse engineering of binaries ** cryptographic algorithms ** side-channel attacks ** hardware trojans ** fault injection ** PUF-based device authentication
• Example beginner tasks mentioned include finding keys in a binary and implementing disk encryption on a Pi.

• Welcome quiz
• Join Discord

We reviewed the key subsystems of the CPS co-simulation environment, including GridLAB-D, PyPower, and HELICS communication using publications/subscriptions. We also went over the kickoff presentation expectations and delivered the device security overview, covering side channels, PUFs, fault injection, and hardware trojans. This week was our first Device Security team meeting. We introduced ourselves, shared our backgrounds, and discussed potential security topics for the kickoff presentation. We also scheduled the meeting for kickoff presentation.

Work on kickoff slides

• PUFs rely on transistor-level manufacturing variations, producing unique and reproducible startup patterns.
• Their main applications in CPS devices include key generation, secure storage, and device authentication.
• I reviewed the PUF slide from lecture and noted how SRAM inverter strength determines the startup state.

Prepare kickoff presentation

We focused on preparing for the kickoff presentation. Our group met to combine individual sections, and review slides. We reviewed each person’s part (timing attack, PUFs, fault injection, etc.) and checked for overlap. I refined my PUF section and added clearer explanations.

• I reviewed the full PUF section of our kickoff slides, including the mechanism, authentication flow, and limitations, and refined the explanations for SRAM-based device identity and key generation.
• I also finalized the PUF Subteam Goals slide by checking the accuracy of each goal (authentication, key generation, reliability testing) and ensuring terminology and technical descriptions matched lecture content.

I spent most of my time trying to understand what PUFs are and why they matter for our project. Hayden gave us some overall direction for the semester. We also talked a bit about what kinds of experiments we might run later on, like collecting SRAM startup patterns or testing reliability under different conditions.

https://www.synopsys.com/glossary/what-is-a-physical-unclonable-function.html file:///Users/soyoungmoon/Downloads/s41597-023-02225-9.pdf

• A Physical Unclonable Function (PUF) uses tiny manufacturing differences in hardware to generate a unique fingerprint for each device.

• For CPS devices, we mainly use SRAM PUFs, where each SRAM cell powers on to a predictable but device-unique 0 or 1 due to transistor mismatches.

• These patterns can be used for: ** device authentication ** generating cryptographic keys ** checking device integrity

• The instructor outlined our direction: ** Understand SRAM PUF behavior first. ** Then look into how to stabilize PUF output (e.g., helper data, error correction). ** Eventually try simple experiments on embedded devices.

We moved past the basic understanding phase and started digging into more serious research on PUF implementations. I spent time reading through two key resources to get a clearer picture of practical PUF designs, real-world constraints, and what actually makes certain architectures more reliable than others. During our meeting, we also discussed which specific chip we should use for our first round of experiments, and by the end of the week we decided to move forward with an SRAM-based chip for our PUF work.

https://data.embeddedcomputing.com/uploads/articles/whitepapers/14491.pdf https://ieeexplore.ieee.org/document/8824887

** Planned Steps After Receiving the SMPT32

1. Write initial firmware for the SMPT32

• Implement code to read SRAM startup values.
• Ensure proper memory allocation for both the program and data buffers.
• Confirm that the linker file has enough space allocated for reading raw memory regions.

2. Randomness Generation & Collection

• Create a simple program that extracts the raw randomness (startup pattern) from the chip.
• Use a debugging cable to stream all captured bits from the SMPT32 to the laptop.
• Save the raw bitstrings for later analysis.

3. Statistical Analysis Pipeline

• Develop a Python script to perform randomness and uniformity checks.

4. Visual Analysis (Heatmap)

• Generate a heatmap of the SRAM array to visualize spatial patterns.
• Identify clusters where bits are consistently 0 or consistently 1, which may indicate manufacturing non-uniformity.
• Mark “fuzzier” or less reliable regions and compare across multiple samples.

5. Environmental Stress Testing

• Apply temperature variation using a hair dryer or heat gun.
• Observe whether specific bits flip under heat changes.
• Compare stability across temperatures to evaluate reliability and environmental sensitivity.

• The Embedded Computing whitepaper highlighted how SRAM PUFs provide strong device uniqueness without requiring additional circuitry, which makes them suitable for low-power CPS nodes.
• The IEEE paper provided a deeper look into PUF reliability metrics — such as intra-/inter-Hamming distance, environmental drift, and helper-data schemes — giving me a better understanding of what we’ll need to test later.
• Based on the research and availability, we selected an SRAM chip whose startup state can be read directly, making it appropriate for capturing power-on patterns for PUF evaluation.

We focused on preparing for the midterm presentation. We discussed how to structure the flow of our presentation especially from PUF basics to the research we’ve done so far, our SRAM chip selection, and what we plan to test next. We also planned to study Rust, since Hayden mentioned it will be useful later when we start working closer to the hardware with Ros-helics. Also, we are waiting for the Raspberry pi to arrive.

• Reviewed key Rust concepts: ownership, borrowing, lifetimes, match syntax, and memory-safe low-level code patterns.
• Looked into how Rust can be used in embedded environments and how it interacts with hardware.
• Drafted my midterm slide section on SRAM PUFs, prior research, and our planned experiments.
• Verified chip documentation again while we wait for the Raspberry Pi to arrive so we can begin actual measurements once hardware is available.

This week, our team focused on preparing for the midterm presentation for the PUF sub team. We discussed the overall direction of the project and outlined the main experiments we wanted to run to evaluate SRAM PUF behavior, including startup stability, environmental stress effects, and randomness testing. We also identified three broader tasks for the team: learning Rust and Embedded Rust, running SRAM experiments on the STM32 boards, and eventually building a PUF-based key generation system.

I helped prepare and present the slides for the midterm presentation. I also started setting up my embedded Rust development environment and spent time reading through the Embedded Rust Book and Embassy documentation. As part of the setup process, I installed Rustup, the ST-Link drivers, and probe-rs so that the STM32 board could be recognized properly and used for logging and memory inspection.

This week, we focused on confirming that our development setup was working correctly and planning how to begin collecting SRAM data. After verifying that the Embassy workflow could run on the STM32 board, the next step was to start reading SRAM contents and think about how to log and compare those outputs across runs.

I successfully ran an Embassy example project and used it to confirm that the board compiled and executed correctly by blinking the onboard LED. After that, I created a small demo project that read one word from SRAM4 memory on the STM32. This helped me better understand the memory layout of the board, including how memory.x defines the available memory regions. We also discussed follow-up tasks such as writing output to a file, dumping all relevant memory, repeating trials, and comparing bit flips across runs and across boards.

The main focus this week was automating SRAM dumping and gathering enough data to begin more meaningful analysis. We aimed to repeatedly collect SRAM startup data from each board and organize it in a way that would make later processing easier.

I expanded the earlier memory-reading project into a more complete setup that dumped the bottom half of SRAM4 and collected 20 trials for each STM32 board. During this process, I ran into an RTT logging problem where the output started around the 130th memory address instead of the beginning. I fixed this by adding a 500 ms startup delay so the debugger would not interfere with the earliest part of execution. I also noticed that trying to log without the debugger caused corrupted ASCII-style output, so I continued using the probe-based workflow. In addition, I helped organize the project by uploading the code and collected data to the team GitHub repository.

This week, the project shifted more toward data analysis. The goal was to better understand how stable each SRAM bit was across repeated measurements and how results compared across different boards. At the same time, we began looking into error correction methods that could later support fuzzy extractor development.

Python scripts were developed to process the collected .bits files for each board and summarize the results into CSV outputs. These outputs included bit position, the number of zeros and ones observed across trials, the majority value, and the stability of each bit. This made it possible to see how reliable each bit was and whether the dominant value matched between boards. I also started researching error-correcting codes, since choosing an appropriate ECC would be important for dealing with noisy PUF responses in the next phase of the project.

Spring break, so there was not much active project work during this week.

Although there was no major development or experimentation, I continued reviewing ECC-related material in the background.

This week, we resumed active project work after spring break and started thinking more seriously about the fuzzy extractor portion of the project. However, progress on implementation depended on first choosing the right ECC scheme.

I began setting up a Rust-based framework for the fuzzy extractor, but a lot of the implementation had to wait until the ECC was selected. We discussed the need for better hardware-derived metrics, especially average bit instability and intra-chip Hamming distance, because those values would help determine what kind of ECC parameters would be appropriate for our SRAM PUF data.

This week, we collected additional data to make our analysis more reliable and started narrowing down the ECC direction for the project. With a larger dataset, we were in a better position to evaluate noise levels and make decisions about error correction.

We recorded 20 more trials for both the 1724 and 5223 STM32 boards, bringing the dataset to a larger and more reliable size. I updated the Python analysis scripts so they could report additional metrics, including average bit instability and intra-chip Hamming distance as a percentage. After discussing the results with Hayden, we decided that BCH codes would be a strong fit for this project because they are well suited for correcting the kind of random bit errors commonly seen in SRAM PUF outputs. From there, the next goal became finding BCH parameters that matched the noise characteristics of our data.

This week was mainly focused on BCH parameter selection and evaluating whether the fuzzy extractor approach would work with our measured SRAM behavior. A big part of the week involved refining our interpretation of the metrics so that the ECC design would be based on the right assumptions.

I created a script called find_bch_parameters.py to estimate BCH parameters that would satisfy a target failure probability. The script used a cumulative binomial distribution to determine how many bit errors would need to be corrected under different settings. At first, we treated intra-chip Hamming distance as if it were the bit error rate, but later realized that this was not the correct interpretation. After revisiting the definitions, it became clear that average bit instability was the more appropriate quantity to use when reasoning about BER. I also created a second script, test_bch_correction.py, to test how well BCH correction performed on our recorded SRAM trials using bchlib. This script simulated both enrollment and reproduction, using helper data generated from a reference bitstring and a secret key. We compared a single-trial reference against a majority-vote reference and found that majority voting gave more stable results. Based on the test outputs, the observed error count generally stayed around 30 bits or below, which helped guide the selection of the BCH correction capability.

This week was focused on wrapping up the project by preparing for the final presentation and organizing material for the written report.

I spent time consolidating the main parts of the project, including the SRAM dump workflow, the analysis of bit stability and variation, the BCH parameter study, and the fuzzy extractor testing results. The goal was to bring these pieces together into a clear final demo and a report that explained both the experimental process and the reasoning behind our design choices.