Repository navigation
Galadriel Cho's Notebook
- First week of class, chose to stick with device security team again.
- Decided on doing disk encryption again. Once I get a Raspberry Pi, I think a good goal for this semester is to set up disk encryption that is unlocked via SSH. Goal for this week is to do research on how to do that.
- Worked on the Kickoff Presentation slides for disk encryption, wrote slides and recorded voiceovers
- I picked up the Raspberry Pi this week but I don't have an ethernet cable. So, I took the time to really understand the process written out in this tutorial: https://pidiylab.com/full-disk-encryption-raspberry-pi-headless-unlock/. The headings are taken from the tutorial steps, and then I wrote out my notes and things I looked up as I read through it
-
Prepare the Pi and Install Packages I plan on connecting to the Pi via ssh (since there's nothing I need to do that requires visual aid) to install the packages. The packages being installed as cryptsetup, cryptsetup-initramfs, and dropbear-initramfs. initramfs is the temporary filesystem image used to help mount the Linux filesystem.cryptsetup will be used to manage the disk encryption itself and uses LUKS and dm-crypt.
-
Identify Partitions and Back Up Data
- I don't need to back up data since there isn't anything on the Raspberry Pi image to lose (we can just re-flash it haha)
- Identify the layout of the disk-- should look for something like /dev/mmcblk0p1 (boot, FAT32) and /dev/mmcblk0p2 (root, ext4)
- FAT32: the boot partition, contains firmware, config, and kernel parameters for boot. The permanent hardcoded bootloader in the RP cannot natively read a complex filesystem like ext4
- ext4: the Linux file system
- Shrink the Root Partition
- The tutorial wants me to shrink the root partition to make space for the LUKS header, but you cannot resize a mounted root partition. I'm going to have to figure out how to address this.
- Encrypt the Root Partition with LUKS2
- I'll try follow the process for this based on the process I wrote out last semester. I also want to consider what cipher to use. The default is aes-xts-plain64, which is the industry standard for full disk encryption because it combines the specialized sector-level security of XTS (used by Windows BitLocker, macOS FileVault) with a modern 64-bit sector counter that safely supports large modern drives
- Configure crypttab and cmdline.txt
- Not sure if I need to do this since I am not going to shrink the root partition while I'm mounted on it.
- Configure Dropbear for Headless Unlock
- Dropbear runs as an SSH server inside initramfs. It is needed to initialize the network card to accept an SSH connection before the main hard drive is decrypted(/unlocked) since we haven't yet.
- Rebuild initramfs and Test
- Hopefully at this point I will just be able to enter in my password to the initramfs and the RPI will just unlock!
I just asked Hayden for an ethernet cable, but I will try to acquire one on my own as well. I also need to consider the issue of how to encrypt the root partition while it is currently being mounted.
Diagram from the tutorial I want to loosely follow:
- Carrying out the steps outlined above!
- I need to figure out how to encrypt the root directory, but this is impossible to do while it is mounted. After some research, I think I want to try:
- putting a temporary Linux OS on another sd card / usb stick
- changing the boot order of the raspberry pi to prefer this temporary os) booting the raspberry pi from the temporary Linux OS, then using LUKS2 (cryptsetup) to encrypt the SD card root partition Some documentation to change boot order
- configuring initramfs / dropbear for encrypted boot/unlock
- shutdown, remove the temporary sd card/usb stick
- reboot pi with the original SD card and hopefully unlock it
A blocker is that I do not have an ethernet cable/usb stick. I'll try to get one on my own but if possible I do hope to get one from the team!
- I was going to use a USB stick where I previously flashed Ubuntu 24.04.4 LTS, but upon further research, I found out that a generic Ubuntu will not boot on a Raspberry Pi. (I'm going with an Ubuntu LTS version because it's a stable, modern kernel with LUKS2 features and the cryptsetup reencrypt binary out of the box).
- The generic Ubuntu is configured to start up with traditional BIOS/UEFI. But a Raspberry Pi strictly requires a FAT32 partition with all the firmware files (bootcode and device tree stuff and others). Also, Raspberry Pi uses a ARM64 processor, and my Ubuntu image is for x86_64 processors.
Reflashing...
- Before I do anything, I also want to make a note of what OS the Raspberry Pi uses (
cat /etc/os-release) so that I know what to reflash the SD card to if anything goes wrong
Other commands I also want to run:
uname -m: Double check the cpu architecture is the one I flashed for
lsblk -f: See the format of the SD card, determining which partition is boot (FAT32) vs root (ext4)
findmnt: Just to confirm which filesystems are mounted where
- Been pretty caught up with work...
- I was able to obtain an ethernet cable/ethernet-to-c adapter/usb so I tested connecting to the pi
- Following the network setup instructions from the wiki, I opened up a terminal and went along with the provided steps
-
nmcli connection show: Had no issues identifying my ethernet connection as I only had the Pi plugged in - Had no issues exporting the variable with the connection name, modifying the connection to be saved, and deactivating the connection
- Could not activate the connection, had to run
journalctl -xe NM_CONNECTION={connection} + NM_DEVICE={device}to check the logs
- Error was
ip:shared4: could not start dnsmasq: Could not find "dnsmasq" binary - I use Arch Linux so I just went ahead and installed the dnsmasq package with
sudo pacman -S dnsmasq
- After that, activation was successful. But when I attempted to run
ssh pi@192.168.2.2 "ping google.com"I got the errorssh: connect to host 192.168.2.2 port 22: No route to host:(
Troubleshooting network setup:
- I ran
nmcli connection show --activeand the ethernet connection was in fact active - Ran
ip -4 addrand the ethernet connection section had the lineinet 192.168.2.1/24 brd 192.168.2.255 scope global noprefixroute enp6s0f4u1. So the IP address is correctly configured - Trying to reach the Pi through pinging/checking the neighbor status
- Then I noticed that my Pi's light is solid and not flashing the rhythmic, repeating pattern Google says it's supposed to-- I might try reflashing it
- Tried reflashing it, my laptop didn't register it in disk management when I inserted it into the slot
- Running
lsblkdoes not reveal the SD card while it's plugged in to either my laptop's SD card slot or to the SD card readers I borrowed from the library - Ran
sudo dmesg -wto view kernel ring buffer to diagnose issues:
- "Media removed, stopped polling" message.. something is not right
- When I start up my RPI without the microSD card inserted, the board remains cool to touch, but when I plug in the card, the SD card slot immediately gets burning hot.
- I think my SD card is not functional...
I tried reflashing it but inserting it into either my laptop's native SD card reader or borrowed SD card readers from the school library but the SD card still doesn't show up in my laptop's disk management.
- Hayden reflashed the SD card of my Raspberry Pi-- there had been a bug in the network setup causing the RPI to not have an IP address.
- It worked!! I was finally able to remote into the Pi's desktop via the guide on the wiki
- I have struggled in vain :( Jude and I followed the setup steps together and connecting to the VNC server did not succeed
- Next, I attempted to connect via Remote Desktop Connection. I received the error message "already have another console session in progress" error. I restarted my computer but no improvements were made
I also ran the following commands from Hayden's investigation:
netsh advfirewall firewall add rule name="ICMP Allow" protocol=icmpv4:8,any dir=in action=allow
Restart-Service SharedAccess
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "IPEnableRouter" -Value 1
I restarted my computer, and then ran:
Set-NetConnectionProfile -InterfaceAlias "Wi-Fi" -NetworkCategory Private
After that, I restarted my computer again. Unfortunately, I still wasn't able to connect to the RPi :(
Spring break!! :)
- Working on setting up the physical RPI... ran into issues with setting it up. I followed instructions for the network setup and the remote desktop setup for me, running noVNC hasn't been successful. I just get a timeout (refused to connect) message.
- Finally got a physical Raspberry Pi!! :))
- Looking into methods of unlocking a disk-encrypted headless RPi 5
- While it would be most ideal to have the RPI unlock itself upon bootup with something like the TPM, our RPIs do not have one
- So, after a conversation with Hayden, we decided that for now a good goal to have for the end of semester is to disk encrypt a physical Raspberry Pi and then remotely unlock it via SSH
Remote SSH Resources: https://pidiylab.com/full-disk-encryption-raspberry-pi-headless-unlock/ https://github.com/ViRb3/pi-encrypted-boot-ssh
- Still occupied by personal matters, but I got to start with Rustlings
- Installed and set up Rustlings
- Completed some Rustlings exercises (all of 00_intro, 01_variables,
Notes while going through Rustlings/Rust book
- Metaprogramming: writing computer programs that write or manipulate other programs (or themselves) as data. Stack Overflow thread
- Calling a macro in Rust-- name!()
- Rust is an ahead-of-time compiled language
- Cargo: Rust's build system and package manager. Builds code, downloads libraries, and builds these libraries.
- In Rust, variables are immutable by default. Make variables mutable by adding
mutin front of the variable name (we are not allowed to mutate a variable's type) - constants are bound to a name and not allowed to change-- they're ALWAYS immutable.
- can be declared in any scope
- valid for entire time a program runs, within the scope of where they were declared
- types must be explicitly declared
- shadowing: you can declare a new variable with the same name as a previous variable. the first variable is shadowed by the second, the second variable takes any use of the variable name to itself until it itself is shadowed or the scope ends.
- different from mut because we effectively create a new variable when we use the let keyword again-- can change type of the variable
- Had to rush home for family matters. ODS letter sent by email to instructors.
- Created slides for Device Security Disk Encryption subteam
- Still no Raspberry Pis... :( Going to take some time to do some research into the Linux filesystem, device mapper system
Notes:
- Unix systems have a single directory tree, so all accessible storage must have an associated location to some location in the tree
- Mounting is the act of associating a storage device to a particular location in the directory tree. Mounting also associates the device containing the data with a filesystem driver.
Sources: Mounting
- Now that I had the Raspberry Pi OS running in my VM, I went on to experiment with setting up disk encryption!!
The steps I took:
- Just in case I messed things up, I created and added a new virtual disk in VirtualBox. Running the lsblk (list block devices) command allowed me to double check that my process had worked (we can see it listed as sbd).
- Checked if I needed to install or update to cryptsetup (utility to set up disk encryption with dm-crypt)
sudo apt update
sudo apt install cryptsetup
- Initialized LUKS on the new disk. Pretty straightforward! :)
- Setting up the file system mount
-
sudo cryptsetup open /dev/sdb encrypted_disk:- Used sudo since disk operations need root privilege. Gave unlocked mapping a new name
-
sudo mkfs.ext4 /dev/mapper/encrypted_disk: Created ext4 file system within the disk. -
sudo mkdir /mnt/encrypted: Created new directory -sudo mount /dev/mapper/encrypted_disk /mnt/encrypted: Mounted the decrypted onto previously created file system onto the encrypted /mnt/encrypted-- now we can put stuff in our new file system by putting it in /mnt/encrypted/. Everything will be encrypted!! -
sudo touch /mnt/encrypted/testfile.txt: Created a file that is theoretically encrypted
- Testing to make sure things work~ notice key word LUKS: success! :)
Explorations to think about later...
- how does the Linux device-mapper system work?
- I decided to try working with the Raspberry Pi OS instead, since that's what we'll be working with. Followed along to this tutorial... installation took a while
- Installed VirtualBox to run VM in, then created new Ubuntu Desktop 24.04.4 LTS VM
- Because the purpose of this VM is solely to play around with disk encryption, I only allocated limited resources (2GB RAM, 1 core, 15 GB disk space)
- Issue: VM screen goes completely black after seeing Ubuntu loading screen... no visible issues in log
- Solution found to deal with black screen (and get the actual Ubuntu GUI)
- Powered off VM
- Changed graphics settings as follows: set Graphics Controller to VBoxSVGA, Video Memory to 128 MB, and disabled 3D Acceleration
- Ensured UEFI was unchecked in motherboard settings
- gave CPU 2 cores, enabled PAE/NX
- upon starting up VM again, selected Try or Install Ubuntu (safe graphics)
- Issue fixed and GUI is visible!! Success :)))
Familiarized self with LUKS, read through this paper on full disk encryption with LUKS
Notes:
- LUKS uses a two level hierarchy with a strong master key that encrypts/decrypts the entire system, with multiple user keys that are used to decrypt the master key
- Anti-forensic splitter is utilized to inflate and split the master key before storing it on disk and uses hash function with diffusion element (so cipher + AF-splitter used to compute master key from user key)
- LUKS combines the ideas salt and key derivation function to mitigate the problem of brute force attacks based on weak user passwords. But salt parameter is known and user password may be guessed, so focus on iteration counts in order to slow down brute force attacks
- User keys should have a minimum length requirement in order to prevent a brute force attack
- In order to mitigate attacks, increase default iteration counts whenever a user key is define
- Joined Device Security Subteam
- Divided into 3 teams-- PUFs, Side Channel Attacks, Disk Encryption (joined)
- Created goals and tasks for Disk Encryption team slides for kickoff presentation
Since I'm starting out with knowing nothing about disk encryption, I started by doing some preliminary research on what disk encryption is.
Notes:
Full-disk encryption protects sensitive data at the hardware level on a disk drive. Data is automatically converted from a readable plaintext to a ciphertext that isn’t readable unless converted back to plaintext with an authentication key. Even if the hard drive is put in another machine, the data remains inaccessible unless the right key is provided.
Pros:
- Data can’t be extracted without device password AND encryption key
- No special attention from end users needed after the initial unlocking of their computer. (Written data is automatically encrypted and automatically decrypted when read).
- Protects data from cyber attacks and data leaks
Cons
- Encryption and decryption process can slow down data access time
- If password and recovery key forgotten, device becomes inaccessible
Terminology side notes:
block-level encryption- method of encrypting fixed-sized data blocks full disk encryption- applies block-level encryption to the scope of the entire drive
Sources: Initial background reading to understand what disk encryption is
- Joined the Cyber-Physical Systems Discord
- Learned introductory information about power systems (i.e. substations, distribution systems)
- Learned about simulation: HELICS, PYPOWER
- Learned more about how simulation is performed as a part of the Cyber-Physical Systems team (ROS, HELICS)
- Learned more about the different subteams (device modeling vs ROS/HELICS)
- Determined a weekly meeting time with the ROS/HELICS team
-
Learned about the Device Modeling team's past work and goals for the semester
-
Presented with the ROS/HELICS team on past work and goals for the semester
-
Discussed potential security threats (need for encryption, protection from Man-in-the-Middle attacks)
-
Joined the security team
-
Watched an introductory ROS video
-
Learned about the ROS network and the Pub/Sub model of topics and messages between nodes.
-
Learned about services, parameters, remapping, launching, packages, workspaces, and Quality of Service (QoS)
-
Downloaded the Docker container and setup the environment in accordance to the ROS2 Docs
Ran into some issues with mismatched sources (ROS vs ROS2) when trying to run sudo apt upgrade (or update).
I changed "ros" to "ros2" in sudo vim /etc/apt/sources.list.d/ros2.list, which fixed the issue and allowed me to upgrade my ROS2 packages.
- Worked through the talker-listener demo listed in the docs
- Completed "Getting Ready to Build Robots with ROS series" by Articulated Robotics
- Learned about how Denial of Service, Man in the Middle, and MAC Flooding is performed through ARP Poisoning Attacks through this article.
Summary of my notes: ARP (Address Resolution Protocol)
- An ARP Request: Computer A asks network who has the IP address
- An ARP Reply: Computer B tells A they have the IP and discloses its MAC address
- A Reverse ARP Request (RARP): Computer A asks who has this MAC address
- A RARP Reply: Computer B tells A it has that MAC address and what its IP address is. All network devices have an ARP table: short-term memory of all the IP addresses and MAC addresses the device has already matched together, so that ARP requests are not repeated. PROBLEM: No authentication method: simply trusts that the ARP reply comes from the correct device
Man in the Middle ARP Attack: A hacker can intercept network traffic between two devices in your network. Sending a malicious ARP “reply” to your router, associating his computer’s MAC address .Router thinks the hacker’s computer is your computer. Hacker sends malicious ARP reply to your computer, associating his MAC address with router. Now machine thinks the hacker’s computer is your router. hacker turns on IP forwarding, forwarding any network traffic it receives from your computer to the router. intercepting all network traffic, sniffing clear text passwords, hijacking your secured internet sessions
- Completed ROS tutorial playlist
- Learned about Gazebo, LIDAR, depth cameras, SLAM
- Learned the basics of UNIX terminal during class
- Downloaded and set up Wireshark
- Read "Security on ROS: analyzing and exploiting vulnerabilities of ROS-based systems" by Teixeira, Maurell, Drews-Jr and learned about how an ARP Poisoning MITM attack can compromise the confidentiality, integrity, and availability of a ROS system's data
- Investigated pcap file of a timing critical system of robot system (taking note of frequent small packets being sent, broadcast messages being favored)
- Familiarized self with past subteam work and technology terms used (GridLab-D, ROS2, Gazebo) by reading last semester's midterm paper "Enhancing Power Line Maintenance through Integration of ROS and HELICS for Line Inspection Robots"
- Wrote background research section in Fall 2025 Midterm Paper about ARP attacks
- Edited other sections of Fall 2025 Midterm Paper
- Practiced and prepared for Fall 2025 Midterm Presentation
- Presented Fall 2025 Midterm Presentation
- Read up on MitM and ARP attacks in general, particularly came across the paper “A Comprehensive Approach for Detecting and Handling MitM-ARP Spoofing Attacks”
- Network host solution to detect MitM-ARP spoofing attack:
- Based on the destination host’s IP address, capture initial snapshots of the destination host’s MAC address and its maximum RTT from five pings
- Monitoring: observe ping RTT anomalies within a 1-second time interval. If there is a ping RTT anomaly where the current ping RTT to the destination host is greater than the snapshot ping RTT, then send an ARP request to the destination host.
- Check for change in MAC address of the destination host in the ARP reply. If there is one, fix the host’s poisoned ARP cache by overwriting the poisoned entry with the previously saved snapshot.
- To make sure this was correct, the solution should ping the destination host again after using the static ARP entry
- A plus for this solution is that there is no modification to existing ARP, no additional hardware or servers, no complementary protocol, and no installation required on all hosts
- Researched about SROS in order to better understand the security work Shrayes did last semester
- Read through https://ubuntu.com/blog/what-is-sros-2 and other sites, some summarizations:
- DDS-Security is a spec that defines five plugins:
- Authentication: verifying the identity of a given domain participant
- Access Control: enforcing restrictions on DDS-related operations that can be performed by a participant
- Cryptography: encryption/signing/hashing
- Logging: providing the ability to audit DDS-Security-related events
- Data tagging: provide the ability to add tags to data samples
- ROS2’s security features only utilize the first three
- ROS2 uses Data Distribution Service (DDS) as its middleware
- DDS-Security is a spec that defines five plugins:
- Downloaded Wireshark into the Docker container
- Attempted to start Wireshark with sudo so that I could capture packets live within Wireshark, but I ran into issues with displaying the GUI
- Since I want to get started on writing code, I've decided to return to tackling how to capture packets within Wireshark later. I'll utilize tcpdump to capture packets and then analyze them with Wireshark
- Utilizing tcpdump, I captured UDP packets from the talker/listener demo
- I opened up the pcap file in Wireshark and began investigating the structure of the captured packets. Particularly, I was looking for the plain-text message being stored in the packet data. I spent a good amount of looking but could not find it.
- I eventually realized that these were discovery packets, aka how ROS nodes advertise their presence to other nodes. These were the only packets in the pcap.
- I filtered the port range of the tcpdump packet collection to only include non-discovery packets, and as suspected, no packets containing actual messages had been captured.
- After doing some investigation, I realized that ROS 2 uses a DDS implementation that supports shared memory transport for efficiency when nodes are on the same host.
- Took some work to discover the right commands to pinpoint the middleware, but eventually running
dpkg -l | grep rmwhelped. The line "ros-foxy-rmw-fastrtps-shared-cpp" reveals that FastDDS is the one being used.
- Now that I know that FastDDS is the DDS implementation being used, this gives me a good starting point of how to disable shared memory when nodes are on the same host so that I can actually capture the message packets.
- Experimented with several different ways of disabling shared memory, including:
- Tinkering with environment variables for FastDDS such as:
export FASTDDS_SHM_TRANSPORT=offexport FASTDDS_SHM_POOL_SIZE=0
- Tinkered a bunch with CycloneDDS as well
- Tinkering with environment variables for FastDDS such as:
- After an unfortunate amount of time poured into this, I realized the version of both FastDDS and CycloneDDS in ROS Foxy is too old to disable SHM when nodes are deployed from the same host
- Considered running the docker container with --net=host to remove network isolation, but I realized that Windows does not have this
- Eventually decided on running multiple images on different ports and utilizing CycloneDDS for reliable node discovery
- This is accomplished by running the two Docker contains on the same Docker user network with different ports
My CycloneDDS xml file:
Running the talker node / capturing packets with tcpdump / opening up the pcap file in Wireshark:
Running the listener node:
(Note that the ports are different, 6081 and 6082 respectively)
- Class final presentation! Talked about my talker-listener nodes MITM exploration. Discussed Docker networking allowing for packets to be sent between containers, the issues with Windows not allowing for the net=host argument.