• Completed the welcome quiz and sub-team selection quiz
• Attended class
• Met teammates and worked on setting a meeting outside of class

• Spoke with Hayden and Sam about getting more info about the hardware that was procured for the side-channels sub-team of the device security team
• Coordinated a time for meeting outside of class
• 

• Followed up with Hayden Cook for information about the ChipWhisperer and any other hardware procured for the team

• 

• Accidentally emailed the William Stuckey by mistake about the prior topic

• Completed and submitted the Notebook Self-Evaluation

• Worked on Slides for Kickoff Presentation
• Recorded audio for Kickoff Presentation
• Joined side-channels sub-sub-team
• 

• Decided on a time for the full group to meet outside of class
• Had a discussion with the team about what we want to get started on next

• Working on picking up from where last semester's team left off
• No image or tool for this week as we were gearing up for getting started this week and really syncing up. We will start in earnest next week

• Reviewed Hayden’s suggestions about collecting repeated timing measurements, investigating variation, and accounting for CPU core selection and context switching
• Created a deliberately vulnerable password checker that returns when it encounters an incorrect character
• Used the synthetic password cabd and alphabet abcd for a controlled experiment

• Implemented a native C measurement backend for Windows, with Python handling the experiment and saving results
• Recorded TSC ticks, Windows thread cycle counts, and elapsed nanoseconds as separate measurements
• Pinned the experiment to logical CPU 0 to reduce migration and recorded endpoint migration indicators
• Learned that TSC ticks are not necessarily actual CPU execution cycles

• Implemented an attack that tests each possible character and selects the one with the highest median timing
• Collected 400 batches per candidate, with 1,000 checker calls per batch
• Successfully recovered cabd without artificial timing amplification
• Measured ca at 16.334 median TSC ticks per call, compared with approximately 12.01 for cb, cc, and cd

• Tested a fixed-work comparison checker that examines every character instead of returning at the first mismatch
• The comparison attack guessed adcc, which failed verification; both correctness tests passed
• Compared timing distributions and saved the raw measurements for further analysis
• Planned repeated experiments with different passwords and sessions before investigating a machine-learning model
• Mac support and explicit context-switch measurement remain future work

• Prepared for the final presentation.
• Made the slides. Practiced the slides.

• I built a differential timing oracle in Rust that uses raw RDTSC cycle counting with _mm_lfence memory fences on both sides of the check, giving me cycle-accurate measurements instead of relying on system timers
• From there I implemented a z-score filter that throws out any samples beyond 3 standard deviations before taking the median, which strips out OS jitter and cache noise that would otherwise drown the signal
• I then built off that to do a character-by-character password recovery — for each position I measure every candidate in the charset against a baseline character, subtract the medians, and pick whichever character produces the largest positive timing delta, recovering the secret one byte at a time

* Alas it was not working correctly so I had to scrap it, but fortunately one of my other team members was able to get something similar working that we were able to use to get meaningful statistics from.

• We discussed using the chip whisperer to work out another side channel attack. We weren't fully sure about what we would have to implement in order to pull off a side channel attack with the chip whisperer, so this meeting we decided that we would do research and then bring up the idea with the professors.

* - ChipWhisperer is a fully open-source toolchain for hardware security research built around a capture board and a target board, made by NewAE Technology Inc. - Focuses on power analysis using a device's power consumption as well as voltage and clock glitching attacks that briefly disrupt power or clock signals to cause unintended behavior like skipping a password check - Primarily used to evaluate security of integrated circuits like microcontrollers and its open-source nature fosters collaboration across the hardware security community - The Nano version uses a dedicated 8-bit ADC chip interfaced to a SAM4S microcontroller to sample the power rail and feed data back to the software for timing and frequency analysis while the target runs its algorithms - A CPA attack on the Nano has been demonstrated to successfully extract a full AES 128-bit secret key by capturing power traces and correlating them with the Hamming weight of the S-box output, which ties directly into what we're doing with the code - Ships with Jupyter-based documentation covering password bypass and AES attacks - Modular design lets it run on other hardware like FPGA boards - Power consumption model is based on Hamming distance of data being processed relative to a constant reference state - SPA works when the leak is obvious enough for visual inspection, DPA and CPA use statistical analysis across many measurements - Can also capture EM emissions from a target device which leak keys the same way power does - Supports electromagnetic fault injection too where EM pulses are injected to induce faults - The correlation attack in our code, computing SBOX[pt[i] XOR key_guess], grabbing Hamming weight, running Pearson correlation against timing — is the exact same methodology ChipWhisperer uses in hardware, just simulated in software instead of pulled physically off a real chip's power rail

• I have pasted my research into the wiki because that seemed like the easiest thing to do.

* I looped over all 256 possible key byte candidates and for each one computed what the Hamming weight should be if that guess were correct. * I then built off that to run a Pearson correlation between those predicted weights and the actual oracle timings I'd collected, scoring every guess. * The guess with the highest correlation score I flagged as the recovered key byte — which collapses what would be a 2¹²⁸ brute-force search down to just 16 × 256 operations.

* I built a timing oracle that XORs the plaintext byte with the key byte, then runs it through the S-box to extract the Hamming weight as my leakage signal. * From there, I used that Hamming weight to construct a data-dependent timing delay, directly mimicking the cache-miss behavior you'd see in real hardware. * I then layered in Gaussian noise on top of that to simulate CPU jitter, so the signal is realistic but still statistically recoverable with enough samples.

• I was busy with religious obligations in the month of Ramadan, I spoke with Sam about this in class briefly.

• Met in the group meeting and discussed the possible side channel attacks against AES-128.
• We need to do some research into AES and how to compromise it and what we can do, as well as what would be an AES implementation that we can create that would be vulnerable to attack in a reasonable amount of time.
• Need to investigate black-box, block cipher, and other aspects of AES.

• I ended up helping out for the Rust password checker. The Rust password checker was running and would assume that the password was a stored static string. It would check each character one after the next and would exit if there was anything that was not matching up. This was where the leak was present.

* In the attack I helped in order to refine the attack script. The script generates a password based on the most likely character and appends it to the end of a best guess. The longer a password takes to return a fail means that more characters were correct. We ran into some issues with Rust types and updating variables in Rust since Rust variables are not mutable. * The timer requires that after every check, the checker rest for several milliseconds (8 ms optimally) otherwise the attack executes on the order of nanoseconds and the timing implementation is unable to keep up. Future steps involve figuring out how to decrease the time, and possibly changing the implementation to counting clock cycles instead of measuring time elapsed.

• We have decided to work on a password checker using a side-channel analysis of the time it takes to check a password and log in. We are splitting into two groups. One group, Carter and Estelle, will work on using Rust in order to execute this attack. Piper and I are using python to the same effect. The idea is to use a password checker that terminates when it finds a faulty character in a password. If we guess more correct values, it will take longer to terminate telling us that at least a few of our characters are correct.
• Did team-meeting to discuss preliminary ideas.

• Finished up slides for Kickoff Presentation, divided the slides up and recorded the audio for the slides
• Set up meeting time for team and had our first meeting online, and decided on a time to meet in person each week
• Gave each person a responsibility to work on and started initial research

• Divided into subteams and made a means of communications
• Worked on Kickoff Presentation

• Did the Welcome Quiz and Team Selection quiz
• Went through the introduction presentation
• Joined the Security Team

• Joined the Cyber-Physical Systems Discord
• Learned introductory information about power systems (i.e. substations, distribution systems)
• Learned about federates

• Set up a time for the group to meet
• Submitted Welcome Quiz and Subteam Quiz
• Discussed initial plan for Security subteam

• Presented kickoff presentation to class for network team
• Worked on Conclusions slide
• Listened to presentation of ROS/HELICS team

• Met with Sam Litchfield regarding the future of the Security subteam

• Began researching on existing device models in order to threat model.
• Initial step is to look at SEL-751 relay and find what exploits are currently in it

• Researched on Masterpact MTZ circuit breaker. https://docs.google.com/document/d/1fMJtIl8VHr83QIbiypQGUMjSZ1i8g3dCZYMAzMZe8cg/edit?tab=t.0#heading=h.gdp9zy78n52o

• Began to prepare for the Midterm Presentation and add slides

• Was planning to present the slides, but was unable to due to personal circumstance

• Spoke with Sam about different topics in cybersecurity to work on in the VIP project

• Began research into DNP3 Secure and its applications
• Researched how it DNP3 is currently implemented in our project

• Begin working on Final Presentation Slides
• Worked on making a script for the presentation

• Presented the Final Presentation

• Thanksgiving Break

• Worked on and completed the Final Paper and ensured that it was submitted timely.