My MITRE eCTF 2026 Experience: Securing Bare-Metal Firmware on Arm Cortex-M0+

Competing in MITRE's embedded Capture the Flag (eCTF) 2026 was one of the most technically demanding and rewarding experiences of my academic journey. It pushed my understanding of cryptography, embedded systems, and hardware security in ways that coursework simply cannot replicate.

What Is eCTF?

The MITRE eCTF is an annual hardware security competition where university teams design and build secure embedded systems, then attempt to attack each other's designs. Unlike traditional CTFs that focus on exploiting pre-built systems, eCTF requires you to be both the designer and the attacker — you build something secure and then try to break everyone else's design.

The 2026 competition centered on designing a secure Hardware Security Module (HSM) firmware implementation on the MSPM0L2228 microcontroller, which uses an Arm Cortex-M0+ core.

The Challenge

Our target platform was a bare-metal environment — no operating system, no standard library, extremely limited memory (32KB RAM, 128KB flash). We needed to implement:

• Secure key storage and management
• Cryptographic authentication between components
• Protected communications with key derivation
• Tamper detection mechanisms

The constraints were harsh by design. Real HSMs operate in similarly constrained environments, and those constraints are part of what makes them secure — small attack surface, minimal code, no unnecessary services.

Our Cryptographic Architecture

Our team (NEU-1, "NeuSense") designed a system centered on three core primitives:

AES-256-CBC for symmetric encryption of sensitive data. We chose CBC mode over ECB because ECB is deterministically vulnerable to pattern analysis — identical plaintext blocks produce identical ciphertext blocks. CBC with a random IV doesn't have this weakness.

HMAC-SHA256 for message authentication. Every message in our system includes an HMAC computed using a session key. This ensures authenticity (only parties with the key can produce a valid MAC) and integrity (any modification invalidates the MAC).

HKDF (HMAC-based Key Derivation Function) for deriving session-specific keys from a master secret. Rather than using the master key directly for encryption — which would be catastrophic if ever exposed — HKDF derives purpose-specific keys. A key used for authentication is derived differently than a key used for encryption, even from the same master.

// Simplified HKDF extract phase
void hkdf_extract(const uint8_t *salt, size_t salt_len,
                  const uint8_t *ikm, size_t ikm_len,
                  uint8_t *prk) {
    hmac_sha256(salt, salt_len, ikm, ikm_len, prk);
}

// Expand phase to derive purpose-specific keys
void hkdf_expand(const uint8_t *prk, const uint8_t *info, 
                 size_t info_len, uint8_t *okm, size_t okm_len) {
    uint8_t t[32];
    uint8_t counter = 1;
    // ... expansion loop
}

The Hardest Part: Timing Side Channels

One of the most subtle challenges in embedded cryptography is timing side channels. If a MAC comparison function returns early when it finds a mismatch — as a naive implementation would — an attacker can measure how long the comparison takes and learn how many bytes of their guess were correct. Given enough queries, they can recover the full MAC byte by byte.

We implemented constant-time comparison:

int constant_time_compare(const uint8_t *a, const uint8_t *b, size_t len) {
    uint8_t result = 0;
    for (size_t i = 0; i < len; i++) {
        result |= a[i] ^ b[i];  // XOR — 0 only if all bytes match
    }
    return result == 0;  // No early return — always runs full loop
}

This runs in constant time regardless of input, revealing nothing through timing measurements.

Flash Memory and Secret Storage

Storing cryptographic secrets on a microcontroller is genuinely hard. Flash memory on these devices is readable by default — if an attacker gains code execution, they can dump flash and recover every secret. We applied several mitigations:

• Secrets are stored in regions marked with read protection flags
• Secrets are XOR-masked with a device-specific value before storage
• Session keys are ephemeral and never written to flash
• Critical functions implement stack zeroing to prevent key material lingering in RAM

Competing Against Other Teams

The second phase of eCTF — attacking other teams' implementations — was equally educational. We found several common vulnerability patterns in competing designs:

Predictable IVs: Several teams used sequential IVs for AES-CBC rather than random ones. With sequential IVs, you can mount chosen-plaintext attacks.

Missing MAC verification: Some implementations encrypted data but didn't authenticate it, making them vulnerable to bit-flipping attacks where you modify ciphertext in ways that predictably change the decrypted output.

Unsafe string operations: Bare-metal C without standard library protections is full of buffer overflow opportunities. Teams that used strcpy without bounds checking were vulnerable.

What eCTF Taught Me

This competition gave me something rare: hands-on experience building the kind of cryptographic infrastructure that secures real devices — medical equipment, automotive systems, payment terminals. The constraints of bare-metal development make every design decision matter. You can't rely on a library to fix your security problems. You have to understand each primitive deeply enough to implement it correctly yourself.

If you're a student interested in hardware security or embedded systems, eCTF is the most valuable technical experience you can get outside of an actual job in the field. Apply with your university team — or start one.

---

I competed as part of NEU-1 "NeuSense" at Northeastern University, with advisor Rolando Herrero. The competition ran during the 2025-2026 academic year.