The scenario
The 2026 eCTF challenge tasks each team with building a Hardware Security Module (HSM), a dedicated embedded device for secure file storage and encrypted device-to-device file transfer. The HSM runs as firmware on the TI MSPM0L2228 microcontroller and exposes two distinct interfaces to the outside world.
Management Interface
PIN-protected channel for user interactions such as creating files, managing permissions, and retrieving status.
Transfer Interface
Device-to-device channel for secure file exchange between HSMs over a direct UART connection.
Host Interface
Serial connection to a host computer running organizer-provided tools to initiate operations and read results.
The security model is built around permission groups. Every file stored on an HSM belongs to a group, and each HSM holds differentiated permissions per group: receive (request files from other devices), write (create new files), and read (return file contents to an authorized user). Crucially, an HSM can store files it has no read permission for, deliberately separating data possession from data access.
The competition runs in two phases. During the design phase, teams implement and harden their HSM firmware, earning flags through an automated testing service that validates both functional correctness and security properties. In the attack phase, teams receive boards provisioned with every other team's firmware and attempt to break their security implementations to capture flags. Each team therefore defends its own design while actively attacking everyone else's.
Our design
Approach: a multi-layer security model built on wolfSSL / wolfCrypt hardware-optimized cryptography, pairing AES and elliptic-curve cryptography (ECC) with per-group key management and forward secrecy.
The team's HSM enforced three core principles. Confidentiality: every file stored on a device, and all sensitive HSM-to-HSM traffic, is AES encrypted. Authentication: no sensitive action succeeds without passing both PIN and permission checks and possessing the correct group-specific key. Forward secrecy: ephemeral keys per group and permission type limit the blast radius of any single compromised key.
Hybrid encryption & per-group keys
File storage used a hybrid scheme. Each file was encrypted with a freshly generated AES key and IV (AES-CBC); that AES key was then wrapped with the file group's ECC write (public) key and prepended to the ciphertext before being committed to flash. Only an HSM holding the group's ECC read (private) key can unwrap the AES key and recover the file. As a result, a device can physically store a file it is cryptographically unable to read. A second ECC key pair per group (verify / check) is used to prove an HSM actually holds receive permission for a group before any transfer occurs.
Authenticated transfer handshake
The receive operation used a two-step challenge–response handshake to stop a device from pulling files it isn't authorized for. The listening HSM answers a request with a struct binding the slot, file-group ID, and a runtime nonce, signed with AES-CMAC; the receiver must counter-sign with the group's ECC receive key before any data is sent. The nonce and signatures defeat replay attacks and block permission changes mid-transfer.
PIN protection & defenses
PINs are stored only as SHA-256 hashes and verified with a constant-time comparison, so a flash leak never exposes the PIN and timing analysis can't leak it byte by byte. A brute-force lockout with a cooldown, designed to persist across power cycles, blocks power-cycling attacks. UART read/write paths are bounded by explicit maximum lengths and slot indices are range-checked to prevent buffer and file-table overflows, and channel selection was made explicit so data is never leaked to the wrong interface.
My contributions
I joined the team this season, so my work centered on contributing to the collaborative design and hardening effort while taking the lead on a few specific explorations: one defensive, two offensive.
Hardening: unpredictable memory layout
On the defensive side, I explored randomizing the order of functions in the compiled binary so the firmware's memory layout is less predictable. Because the device runs a fixed image, runtime address randomization (ASLR) isn't available, but shuffling function placement at build time is a static analogue that makes it far harder for an attacker to reliably overflow a buffer into a known, useful location.
Attack phase: UART man-in-the-middle
During the attack phase I targeted teams that left their Transfer Interface unencrypted. By sitting in the middle of the UART link between two HSMs, I could intercept and relay traffic to capture sensitive data in transit, directly exploiting the missing confidentiality our own design was built to provide.
Attack phase: voltage fault injection
I also built a voltage fault-injection (glitching) rig aimed at the PIN check, using an external light source as a precision trigger to time the glitch. The goal was to corrupt execution at exactly the right moment and skip the instructions guarding the PIN comparison. I got close, landing glitches that skipped instructions around the check, but ran out of competition time before achieving a full bypass.
Tufts finished 19th in the 2026 competition.