• Virtually attended first class of semester, learned about the different subteams and started thinking about which specific team I wanted to join

• Decided which subteam I wanted to be a part of within device modeling (devices)
• Completed Kickoff Presentation
• Did research into DNP3 networking protocol https://www.dpstele.com/dnp3/index.php

• Completed Github Setup (for co-simulation environment)
• Did more research into the project by reading through notebooks https://github.com/cps-vip/cps-cosimulation-env/wiki/Xin-Zhao-Notebook#power-system
• Going to look into specific substation devices this upcoming week to choose which device I want to work on.

• Got familiar with the existing device models that the device modeling subteam has already completed
• Poked around Github to read through the implementation and thinking about what I can do to add to them
• Thinking about writing test cases for existing models (but there's no way to actually run the tests...)

• Discussed with my subteam what can be done at the moment
• Device modeling should be completed by the end of the semester, Maria and Chungman already working on the rest of the device models
• Looked into encryption for the existing device models

• Research paper draft due 2/20
• Researched AES-GCM-256 encryption for device models specifically, and why AES-GCM-256 should be used over other methods of encryption. Found that it is best for securing large amounts of traffic while ensuring that overhead is minimized, a https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf

• Discussed with Kaden and Sam the usefulness of encrypting device data and how to go about implementation
• Kaden suggested looking into disk encryption for the data at rest rather than AES encryption

• Researched into disk encryption and how it would be implemented to secure data at rest
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-111.pdf
• Disk encryption would be very hard to implement at this stage of the design process, but can be looked into in the future

• Kaden and I had a conversation about the DNP3 integration into the device models, and explored the documentation together to gain a better understanding of how our teams could work together to implement it.
• https://docs.stepfunc.io/dnp3/1.6.0/rust/dnp3/app/enum.Variation.html

spring break, no device modeling team meeting

• Outlined what variables needed to be updated for DNP3 implementation
• Outlined which priorities should be assigned to device models for different cases

• Outlined which variations should be assigned for each device data point

• Haven't had much time to work on anything recently, as I was away for a week for Collegiate Club Fencing Championships.

• Final presentation on 4/17
• Introduced the device modeling subteam during the presentation and the purpose of the VIP

• Wrote up the DNP3 APIs for devices portion for the final research paper, including information from the DNP3 Protocol Primer https://www.dnp.org/Portals/0/AboutUs/DNP3%20Primer%20Rev%20A.pdf

---

• As this was the last week of my internship, I was unable to attend class.

• Team prepared for the kickoff presentation, I decided to switch from the Devices team to the Security team.

• Started doing research into network security, looking into common vulnerabilities in DNP3 and the Sel-751 relay device & how it can be implemented in our existing device models.
• DNP3 vulnerabilities: https://ieeexplore.ieee.org/document/9850291
• SEL751: https://www.mdpi.com/1996-1073/18/17/4691?

• Continuing research into DNP3, security team decided to start doing research into vulnerabilities in existing device models. I am looking into the bay level devices, specifically the switchgear and bay controller. Talked to the device modeling team and they said the device models aren't based off of any specific device versions, so have just been doing general research into the devices used in real-world substations.
• Switchgear:
  • https://library.e.abb.com/public/cad573a9299c439db36c27d7953d8c55/1TGD082018B0201%20Low%20Voltage%20Switchgear%20cyber%20security%20aspects_white%20paper.pdf?x-sign=6YLeWdCYw1WvhhYZqef7DFUHM8MtEPwy1u9y2uv0DqsRBxbc94LaBvU2tgaulxd%2f
  • Key takeaways: controlling authorization is extremely important (no default credentials), minimize open ports that the switchgear is allowed to communicate on, use an allowlist instead of a blocklist.

• Bay Controller:
  • https://www.nozominetworks.com/blog/five-vulnerabilities-on-sel-451-allow-authentication-bypass-and-dos

• Wireshark demonstration by Will
• Led me to think about possible injection attacks that could alter the state of the device faster than the device would normally change state and how to potentially detect them.
  • Need to implement periodic checksum? to make sure that values aren't being changed past a given threshold.
    • Potential attacks: modifying station messages (with incorrect sensor measurements / instructions)
    • Timestamps also very important
  • Detect based on suspicious source IPs or replay attacks that occur through duplicated messages
  • Potential of creating detection rules based off of simulated abnormal activity in Wireshark?
    • ex: match only source IP of 10.0.0.10 (example SCADA Master) can send DNP3 control commands

• Preparation for midterm presentation- redid semester goal slides
• Discussed with team what we can do for the rest of the semester to model what the current threat landscape looks like within our subteam.

• Research into IEC61850 substation model
  • As we know, legacy protocols such as DNP3 and Modbus have significant weaknesses (no or weak encryption/authentication, poor logging).
  • IEC61850 provides more observability, which can help security by making the process of monitoring easier but it's not a 1 size fits all solution as it introduces more vulnerabilities through its connection to the internet.
  • IEC61850 is more reliable and automated, need to do more research into it but might not be a viable path for us based off of existing work.
• https://www.mdpi.com/2079-9292/12/15/3345
• https://ieeexplore.ieee.org/document/7066594

• Looking into issues with inheritance
• Since everything inherits from DNP3Outstation, they are inheriting access to the DNP3 control interface if I'm understanding it correctly (which gives an attacker root-level access if they have access to 1 device in the network)
  • No permission tiers resulting in devices having access to methods that can update thresholds and reset relays
  • If a bad actor gains access to 1 device in the network, they can potentially just start calling methods since there's no enforcing who's allowed to perform those actions.
  • Need to implement rw privileges / roles

• Worked on threat model
• Brainstorming what potential vulnerabilities could be exploited within the network
  • Mainly thinking about broken access control- since we have only a small number of people working on many devices, it's hard to implement access control to only the parts they are working on
  • But implementing access control should definitely be done in the future since this would put up blockers for a threat actor to move laterally though the network
• Also need to make sure default credentials aren't being used once we move past initial implementation stage.

• Worked on threat model
  • Looking into external entry points- from what the repo currently shows and what the networking team is trying to do, the DNP3 outstation level is the only place where the network can be accessed
  • Through previous research on device vulnerabilities, ensuring that the entry point is controlled is the most effective way of blocking attacks by implementing allow-lists instead of blocklists.
  • This ensures a zero-trust approach where we make sure that all traffic has to enter through specified port(s), rather than blocking ports that we think malicious traffic can come through.

• Fell sick this week, was unable to do much.

• Final presentation- detailed potential attack vectors and implementations to mitigate them in future semesters into the threat model and finalized the threat model diagram, wrote up bay controller and switchgear vulnerabilities.
• Discussed future directions for the team for upcoming semesters.

• Thanksgiving break

• Final paper- rewrote introduction and conclusion for security team's part for this semester, expanded the threat modeling with work we did this semester, wrote the conclusion for the device modeling paper.

---

• First week- decided to switch to device security team because I wanted to work more on hardware solutions, which is something that I haven't really been able to touch on in class but have an interest in.

• Discussed with new group mates how to split up work for the presentation.
• Researched into SRAM PUFs for the kickoff presentation, which is something that we are planning on working on during this semester.
  • In our project, we want to try to generate a secure cryptographic key from a SRAM PUF, providing a secure way for devices to authenticate to the SCADA system without having to deal with local key storage in memory, as SRAM PUFs are generated when the SRAM is powered on.
  • These keys would be truly random, since silicon chips have slight manufacturing differences that are impossible to replicate, expressed through 0's and 1's in the cells of the SRAM.
  • The uniqueness of the silicon chips allows them to create secure sequences, but an error correction algorithm still allows it to be reproduced whenever needed.
• sources:
  • https://www.design-reuse.com/article/61177-understanding-physical-unclonable-function-puf-/
  • https://www.synopsys.com/glossary/what-is-sram-puf.html

• Wasn't able to get much done this week due to interview prep (had interview on 2/5 so I was preparing for it the majority of this week).

• Did research into the 2 papers that Hayden sent
  • sram puf overview
    • Attacks with probes and side channel attacks have not led to any leakage of sensitive information
    • Doesn't require much space (only a few dozen bytes are needed to create a unique identifier)
  • poc for sram puf
    • Must choose more reliable cells in memory so that the key generation is consistent across every startup.
• Team decided to pivot to using STM32 microcontroller instead of Raspberry Pi, since it'll be a few weeks before we are all able to get Pi's to use.

• Started learning Rust through Rustlings so that we individually have the skill set to work with the microcontroller.
• Got through sections 00-04 (up to primitive types) on Rustlings.

• Midterm presentation- worked on editing the status of our team's goals, as well as the overview slide for our subteam and the introduction for device security team.

• Continued to learn Rust, got through to section 07 (structs).
• Spent some time going back over earlier sections like ownership and borrowing, since memory management is important in Rust
• Did some additional research into how SRAM PUF responses vary across temperature conditions, since it can affect startup values and introduce more bit errors than expected
  • Building a larger error correction margin into the fuzzy extractor or pre-selecting only the most stable cells helps with this problem
  • https://arxiv.org/html/2603.15320

• Continued working through Rustlings, got through to section 08 (enums) and starting to get a better idea of how Rust handles data types differently from the languages I'm used to using
• Did some more reading into fuzzy extractors and how they're used in PUF key generation to correct for bit errors that happen between power cycles
  • Since SRAM PUF responses aren't perfectly stable between startups, the fuzzy extractor takes the noisy response and reproduces a consistent cryptographic key using helper data that is stored separately
  • This is going to be important for our project since the key needs to be the same every time the device authenticates to the SCADA system.
  • https://arxiv.org/abs/1907.12144

• Started looking into BCH error correction for our key generation, since it can be tuned to specific needs
• To configure BCH, we need to work backwards from the maximum acceptable failure rate (the probability the key can't be reconstructed) and the bit error rate (the average percentage of bits that flip between power cycles)
  • https://link.springer.com/article/10.1007/s13389-020-00223-w

• Spring break

• Got back from spring break, picked up from where I left off on Rustlings and finished section 09 (strings).
• Did more research into BCH
  • BCH can be used with SHA256 to hash it into a usable key, with AES-128 for encryption and HMAC-SHA256 for authentication.
  • BCH(127,15,53) configuration can correct up to 20.5% of noisy bits, creating a 128-bit key.
    • https://eprint.iacr.org/2017/991.pdf

• Started putting together notes and findings for the final presentation slides. Looked back on the past semester's work, started coordinating with teammates to start splitting up parts for the final presentation.

• Went home for personal family reasons, wasn't able to get much done this week.

• Final week, preparing for final presentation
• Worked on slides for security subteam introduction, PUF team goals and description of the purpose of our subteam, and the status of our tasks.