Authentication Service
ML-DSA (Dilithium) + HMAC-SHA384 Authentication Module
Cryptographic authentication module verifying digital signatures (post-quantum ML-DSA / Dilithium) on commands and firmware updates, and computing HMAC tags for integrity-protected telemetry — ensures every command and code update is from an authorized party.
Purpose
Prevent any unauthorized entity from commanding the Ark or installing modified firmware, with security holding against future quantum-capable adversaries.
Context
Uses signing/verification keys provided by L3-COM-CRYPT-KEY; cooperates with L3-COM-CRYPT-PROT (SDLS authentication mode) and L3-COM-CRYPT-ENC (encryption); authenticates everything from individual commands to whole firmware images for L3-CDH-SW.
Principles
- ▸Digital signatures provide non-repudiation: only holder of private key can sign; anyone with public key can verify
- ▸ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) is the NIST PQC signature standard with lattice-based security
- ▸SPHINCS+ (SLH-DSA, FIPS 205) is hash-based, slower but with conservative security assumptions — recommended for critical signatures
- ▸HMAC (RFC 2104) provides symmetric-key message authentication with a shared secret — used where signature size matters
- ▸Sequence counters in SDLS prevent replay attacks: tag includes a per-Security Association counter monotonically incremented
- ▸Timestamped authentication tags expire to prevent long-term key compromise enabling backdated commands
Typical implementations
- ▸NIST FIPS 204 ML-DSA (Module Lattice Digital Signature Algorithm) — formerly CRYSTALS-Dilithium, published Aug 2024
- ▸FIPS 205 SLH-DSA / SPHINCS+ for high-assurance signatures
- ▸CCSDS SDLS Authentication Service (HMAC-SHA-256 / HMAC-SHA-384)
- ▸TUF (The Update Framework) / Notary for signed firmware distribution
- ▸ESA's TT-Auth Protocol used on JUICE for command authentication
Lunar considerations
- ▸All command paths (Earth uplink, mesh injection, robot reprogramming) must terminate at this authenticator
- ▸Quantum-vulnerable RSA/ECDSA signatures cannot be trusted over 100-year mission — PQC mandatory from day one
- ▸Hybrid signing (PQC + classical) provides defense-in-depth during PQC algorithm maturation
- ▸Time-bounded validation requires synchronized time (L3-COM-TIME-DIST) to within seconds; design must tolerate clock outages without bypassing auth
- ▸Replay protection via sequence counters must be persisted across reboots in non-volatile storage
Specifications
Functional
| primary function | Sign outgoing data and verify signatures on incoming commands/firmware |
| inputs | Commands from L3-COM-EARTH-PROC / L3-COM-MESH-ROUT, Firmware update images from L3-CDH-SW, Signing keys from L3-COM-CRYPT-KEY, Verification public keys from L3-COM-CRYPT-KEY |
| outputs | Verification verdict (accept/reject) for each command, Signed telemetry tags, Authentication failure alerts to L3-CDH-AUTO, Audit log entries to L1-DVT |
| signature algorithms | ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-128s, Ed25519 (legacy) |
| mac algorithms | HMAC-SHA-384, HMAC-SHA-512 |
| max signatures per second | 100 |
| max verifications per second | 200 |
| replay window size | 1024 |
| sequence counter width bits | 64 |
Physical
| mass kg | 0.0 |
| dimensions | Software on L3-CDH-PROC with HSM offload |
| materials | Code on rad-hard NOR flash |
| operating temperature c | -40, 70 |
Operational
| power consumption w | 1.5 |
| thermal range c | -40, 70 |
| lifetime years | 100 |
| mtbf hours | 500000 |
Interfaces
Provides
- Authentication verdict for each command frame
- Authentication verdict for mesh-injected commands
- Authentication failure alerts (potential attack)
Requires
- Signing/verification keys
- Synchronized time for time-bounded validation
- Persistent replay counter storage
Cite this entry
Lunar Ark Codex. "Authentication Service" (L3-COM-CRYPT-AUTH). Retrieved 10 September 2026, from https://lunarark.com/entry/L3-COM-CRYPT-AUTH
Licensed CC-BY-SA 4.0. You may reuse and adapt this entry with attribution, under the same licence.