Building AegisLEO: Post-Quantum Cryptography for Satellite Telemetry in a Home Lab

Post-quantum crypto, real hardware, real adversary. Everything that broke along the way, and how it all came together.

The Spark

My interest in space began as a child watching NASA Space Shuttle launches. That early wonder grew over time into something more specific: a deep fascination with space technology, defense systems, and the rapid advancement of autonomous and AI-driven systems. When you grow up watching those launches, you don’t just see a rocket. You see communication links, telemetry downlinks, encrypted command channels. You wonder who secures all of that.

The ethos that built AegisLEO: curiosity over permission.

Years later I served in the Wisconsin Army National Guard as a 13E Fire Direction Specialist, the soldier responsible for computing and transmitting fire missions to artillery pieces. Part of that role was maintaining the section computers and networking links that connected the fire direction center to the broader operational picture, including sensor based systems. When you work with those links in an operational context, you stop thinking of them as background infrastructure. They are life-or-death systems. The people on the other end depend on the integrity of every packet.

I held a Secret-level security clearance throughout that service. That experience, and the responsibility that came with it — never left me.

While pursuing my M.S. in Cybersecurity at the University of Delaware, I took Applied Cryptography (CPEG 672). This course pushed me to study the quantum threat in earnest — not the hand-wavy “quantum computers are coming someday” version. The specific, technical version.

Shor’s algorithm doesn’t weaken RSA and elliptic curve cryptography. It breaks them. NIST finalized two post-quantum standards in 2024: FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). I went looking for real implementations of these standards applied to satellite telemetry. Academic papers, yes. Production deployments? Almost nothing.

The driving question wasn’t whether it could be done — it could. The question was how, and the only way I know how to learn something is to build it myself. So I did.

Why It Matters Now

GPS, weather, military comms — all running pre-quantum crypto. The clock is running.

This isn’t a theoretical problem with a comfortable timeline.

Right now, adversaries are recording encrypted satellite telemetry. Classical cryptography, RSA, ECDH, ECDSA, is secure today. But the harvest now, decrypt later attack is already underway: capture the ciphertext today, wait for a cryptographically relevant quantum computer, decrypt everything retroactively. For GPS, weather satellites, ISR systems, and programs like Starshield, SpaceX’s national security satellite platform, this is existential.

CNSA 2.0 mandates post-quantum cryptography for national security satellite systems by 2030. Most operational satellites flying right now run classical crypto. The clock is running.

AegisLEO is my attempt to answer the practical question: are the standards ready, and can the hardware handle them?

The Hardware Testbed

The full AegisLEO testbed: Raspberry Pi 5, Jetson Orin Nano Super, and Waveshare SX1262 LoRa HATs. Real hardware, real RF link.

The name is intentional: Aegis, from the shield of Greek mythology and the U.S. Navy’s missile defense system, applied to LEO — low earth orbit. A shield for satellites.

The physical system ended up as three nodes:

• Satellite Node: Raspberry Pi 5 + Waveshare SX1262 LoRa HAT
• Ground Station: NVIDIA Jetson Orin Nano Super running Docker + PyTorch
• Adversary Node: Kali Linux VM on Proxmox, same VLAN as the ground station
• RF Link: 868 MHz LoRa (SF7, BW125) — the same chipset used in real CubeSat systems like TinyGS

Not rented cloud infrastructure. Physical hardware on my workbench, connected by a real radio link, with a real machine trying to break it.

The Technical Stack

Post-Quantum Cryptography

Traditional public-key crypto will be broken by quantum computers using Shor’s algorithm. AegisLEO implements NIST-standardized post-quantum algorithms throughout the pipeline:

• ML-KEM-1024 (FIPS 203) — key encapsulation based on Module-LWE lattices. Replaces ECDH. Ciphertext: 1,568 bytes.
• ML-DSA-65 (FIPS 204) — lattice-based digital signatures. Replaces ECDSA. Signature size: 3,309 bytes.
• AES-256-GCM — authenticated symmetric encryption using session keys derived via HKDF-SHA256.

A full session initialization packet in AegisLEO is 6,716 bytes — 42 chunks over a 240-byte LoRa frame limit. That’s a real engineering cost. It’s also the price of post-quantum security on a constrained RF link, and understanding that tradeoff is the point.

CCSDS-Inspired Framing

AegisLEO uses a CCSDS Space Packet Protocol-inspired framing layer — the international standard used by NASA, ESA, and most satellite operators. Key elements: APID routing, sequence counters for replay protection, TAI timestamps, byte-stuffed transport framing, and CRC32 chunk integrity checks.

Dual-Layer Defense: Crypto + Autoencoder

AegisLEO extends the CIA triad with a fourth node: behavioral Authenticity via ML anomaly detection.

Cryptography verifies authenticity. It says nothing about whether the values inside a packet make physical sense. If a satellite’s onboard firmware is compromised — or if a future quantum computer breaks a session key — a valid signature on anomalous sensor values still reaches the ground station.

AegisLEO closes that gap with a second, independent defense layer:

• Crypto Layer: ML-DSA-65 signatures reject forged or tampered packets at the authentication boundary.
• Behavioral Layer: A PyTorch sequence autoencoder (11→32→16→32→11) trained on 2,000 nominal telemetry samples. It learns what normal looks like and flags deviations via reconstruction error. Anomaly threshold: mean + 3σ = 5.27.

These two layers are intentionally independent.

Two independent defense layers. If one fails, the other still fires.

The sequence autoencoder: train on 2,000 nominal samples, flag anything that doesn’t reconstruct cleanly.

If one fails, the other still fires.

Adversarial Evaluation

Testing assumed the ground station network had already been compromised. A Kali Linux adversary node on the same VLAN simulated realistic post-breach attacks: replay attacks, malformed CCSDS frames, forged signatures, and injected telemetry with anomalous sensor values (temperature 85°C, battery 12%, bus voltage 2.1V).

The Trials

I want to be honest about this part, because this is where most project write-ups go quiet.

Trial 1: The RF problem that cost me a weekend.

The Waveshare SX1262 LoRa HAT — 868 MHz, the same chipset used in real CubeSat systems

I had the Pi and Jetson sitting 18 inches apart on my desk. The framing code looked right. Unit tests passed. The receiver saw nothing but garbage. I spent an entire weekend debugging byte-stuffing logic, serial buffers, and frame delimiters, convinced the software was broken.

Root cause: near-field RF saturation. The SX1262 modules were so close together that the signal was overwhelming the receiver’s front end. The radio was working perfectly. The geometry was wrong. I moved the Pi across the room. Everything worked immediately.

The lesson: in a hardware-in-the-loop system, the bug is often not where you’re looking.

Trial 2: The PyTorch/CUDA mismatch on the Jetson.

The ground station: NVIDIA Jetson Orin Nano Super running Docker + PyTorch. Midnight debugging optional but frequent.

Getting PyTorch running on the Jetson Orin with JetPack 6.2 and CUDA 12.6 was a multi-day ordeal. The standard pip wheel was built for CUDA 13.0. NVIDIA’s Jetson-specific wheel had dependency conflicts. There was a missing library — libcusparseLt.so.0 — that I eventually resolved by compiling a no-op ELF stub.

The constraint I had to respect throughout: TensorFlow, Keras, NumPy, and all nvidia-* PyPI packages could not be upgraded. One wrong pip install and the entire ML stack on the Jetson would break. Every dependency decision was a careful negotiation with a system that did not want to cooperate.

Trial 3: The TTL bug that cost the most hours.

One number. SESSION_INIT_TTL_SECONDS = 600.0. Hours lost

During the CypherCon preparation run, chunk reassembly would accumulate to 30 chunks and then silently reset to zero. The session never completed. I read every line of reassembly code. I checked the NACK logic. I added logging at every stage.

Root cause: two TTL constants in two different files that had drifted out of sync. receiver.py had SESSION_INIT_TTL = 120 seconds. reassembly.py had SESSION_INIT_TTL = 25 seconds. The reassembly factory was expiring the session buffer before the receiver knew the session was dead.

One number. 25.0 → 600.0. Hours lost.

The lesson: in a multi-file system with shared state, inconsistent constants are invisible until they’re catastrophic.

Results

Autoencoder training on the Jetson, convergence in under 30 seconds on CPU. Threshold auto-tuned at 5.27.

The cryptographic pipeline works on constrained hardware.

ML-KEM-1024 and ML-DSA-65 operate at acceptable latency on the Pi 5 and Jetson Orin at AegisLEO’s telemetry cadence. Session initialization (~5 minutes) is a one-time cost per session. Per-packet overhead after key exchange is dominated by AES-256-GCM — negligible.

The dual-layer defense works as designed.

The autoencoder trained to convergence in under 30 seconds on CPU. Results from the system running during talk preparation:

Normal telemetry: 0.9–3.0. Kali injection: 863. That’s 163× over threshold.

ML anomaly scores during adversarial testing. Normal telemetry stayed well below threshold. Kali injections weren’t close

The crypto layer rejected the forged signatures before the ML layer ran. The ML layer would have caught them independently on payload values alone. That independence is the design goal.

Defense layer 1: ML-DSA-65 rejects the forgery. Kali has no satellite private key.

The self-healing protocol works under real RF loss.

The chunk/NACK retransmission protocol handled ~20% packet loss throughout testing. Session init reassembled across 7 NACK cycles. 12 of 16 telemetry packets delivered over 94 minutes of operation.

Defense layer 2: the autoencoder catches it independently — even with stolen keys, anomalous values still fire the alert.

The system worked.

Session ID 4bfadbd0b927a984. Crypto: VALID. ML: NOMINAL. Score: 2.97. Threshold: 5.27. Latitude: 43.040, Longitude: -87.907, Altitude: 550.1km.

Session 4bfadbd0b927a984. Crypto: VALID. ML: NOMINAL. Score: 2.97. Milwaukee.

Seeing it run cleanly after everything it took to get there made the whole thing worth it.

Relevance to Aerospace and Defense

AegisLEO demonstrates that NIST post-quantum standards are viable today on small satellite class hardware, can be integrated with CCSDS-style protocols, and can be paired with behavioral ML defense suitable for autonomous and high-stakes systems.

Key capabilities delivered:

• Full PQC implementation (ML-KEM-1024 + ML-DSA-65) on constrained embedded platforms
• CCSDS-inspired framing with robust RF self-healing via chunk/NACK
• Defense-in-depth using independent behavioral anomaly detection
• Realistic adversarial evaluation assuming network compromise (post-breach scenario)

The threat model I built AegisLEO around, harvest-now-decrypt-later against satellite downlinks, is the same problem Starshield needs to solve before CNSA 2.0’s 2030 mandate. That’s not a stretch. That’s the point.

What’s Next

AegisLEO v2.0 is on the roadmap:

• HackRF One + RTL-SDR v4 — replace LoRa with true over-the-air RF testing
• GNU Radio — Doppler shift and AWGN channel modeling
• InfluxDB + Grafana — live ThreatScore dashboards
• Hailo-10H — on-board LLM for health reasoning before downlink

Closing

I built AegisLEO out of curiosity, learning in my home lab on nights and weekends. The standards exist. The libraries exist. I just wanted to build it myself and see how it all fit together on real hardware. I presented this work at CypherCon 9 in Milwaukee and the conversations afterward were the best part of the whole experience.

If this intersects with what you’re building or researching, whether it’s post-quantum cryptography, satellite security, or edge ML on constrained hardware, I’d genuinely enjoy the conversation.

The repo is public and MIT licensed:

**github.com/JamieGrunewald/AegisLEO**

The full CypherCon 9 talk is in the repo under docs/.

Jamie Grunewald — U.S. Army Veteran · M.S. Cybersecurity, University of Delaware (NSA CAE) · CypherCon 2026

The reading list that help built AegisLEO.

#PostQuantum #SatelliteSecurity #SpaceCyber #EmbeddedCrypto #AerospaceDefense #Starshield #OpenSource