Home / Migrate / IoT Device Simulator

Service Info

Status--
Endpointhttp://docker:8085
PQC AlgorithmML-DSA-44 + ML-DSA-87
FIPS StandardFIPS 204 (ML-DSA)

Where PQC is Used

📱
Device Registration

Each device gets a unique ML-DSA-44 keypair. The public key serves as the device identity. Lightweight enough for microcontrollers.

ML-DSA-44 (FIPS 204, Level 2)
🔑
Device Authentication

Challenge-response: server sends a challenge, device signs it with ML-DSA-44 private key, server verifies. Proves the device is genuine.

ML-DSA-44 (FIPS 204, Level 2)
📡
Telemetry Signing

Device signs sensor data (temperature, humidity, etc.) before sending. The server verifies the signature to ensure data integrity and source authenticity.

ML-DSA-44 (FIPS 204, Level 2)
🔧
Firmware Verification

Vendor signs firmware with ML-DSA-87 (highest security). Device verifies the signature before applying the update. Prevents malicious firmware injection.

ML-DSA-87 (FIPS 204, Level 5)

Description

This service demonstrates quantum-safe IoT device security — the same patterns you'll implement using the Qudo JNI provider in your device firmware and IoT gateway.

Device (ML-DSA-44): provider.generateKeyPair("ML-DSA-44") — smallest signatures for constrained devices. Used for registration, authentication, and telemetry signing.
Vendor (ML-DSA-87): provider.sign(firmware, vendorKey, "ML-DSA-87") — highest security for firmware. Devices verify with provider.verify() before applying updates.

POST /api/iot/register-device Register a new IoT device
🔒 Qudo provider: provider.generateKeyPair("ML-DSA-44"). Returns deviceId + public key. Smallest ML-DSA for constrained devices.
POST /api/iot/authenticate Authenticate device (challenge-response)
🔒 Qudo provider: provider.sign(challenge, deviceKey, "ML-DSA-44") on device, provider.verify() on server. Proves device identity.
POST /api/iot/send-telemetry Send signed telemetry data
🔒 Qudo provider: provider.sign(telemetry, deviceKey, "ML-DSA-44") on device. Server calls provider.verify() to ensure data integrity.
POST /api/iot/firmware-update Verify and apply firmware update
🔒 Qudo provider: vendor calls provider.sign(firmware, vendorKey, "ML-DSA-87"). Device calls provider.verify() before applying update.
GET /api/iot/devices List all registered devices
🔒 Returns all devices with their ML-DSA-44 public keys and registration status.
GET /api/iot/health Service health + device count
🔒 Returns service status, ML-DSA-44 (device) and ML-DSA-87 (firmware) algorithm availability.

IoT Security Migration Reference

Secure IoT devices with quantum-safe authentication and firmware verification. Use this playground to try PQC device patterns, then use the Qudo JNI provider directly in your device firmware and IoT gateway.

1. Architecture 2. Try It (Interactive) 3. Algorithm Choice 4. Migrate Your System 5. Performance 6. Pitfalls 7. FAQ

1. IoT PQC Architecture

IoT Device                    IoT Gateway / Server              Vendor / OEM
  |                                |                                |
  |-- Register (get ML-DSA-44 keypair) --|                         |
  |                                |                                |
  |-- Auth: sign challenge ------>|                                |
  |   (ML-DSA-44)                  | verify signature              |
  |                                |                                |
  |-- Telemetry: sign data ------>|                                |
  |   (ML-DSA-44)                  | verify, store                 |
  |                                |                                |
  |                                |<--- Firmware signed --------- |
  |                                |     (ML-DSA-87 by vendor)     |
  |<-- Push firmware update -----  |                               |
  |   verify ML-DSA-87 signature   |                               |
  |   ACCEPTED / REJECTED          |                               |
Two algorithm levels by design: ML-DSA-44 (Level 2) for device-side operations — small signatures, fast, fits constrained hardware. ML-DSA-87 (Level 5) for vendor firmware signing — maximum security for updates that must stay safe for the device's entire lifetime.

2. Try It: Full Device Lifecycle

Run the complete PQC IoT lifecycle in sequence. Each step uses the output from the previous step.

1

Register a device

Click to generate an ML-DSA-44 keypair and register a new device.

2

Authenticate the device

Challenge-response: the device signs a challenge with its ML-DSA-44 private key.

3

Send signed telemetry

Device signs sensor data with ML-DSA-44. Server verifies authenticity.

4

Verify firmware update

Vendor signs firmware with ML-DSA-87 (Level 5). Device verifies before applying.

4. Migrate Your System

Replace classical device crypto with the Qudo JNI provider. Your MQTT/CoAP protocol stays the same — PQC changes are at the crypto layer only.

import com.qudo.crypto.QudoCrypto;
import com.qudo.crypto.QudoKeyPair;

QudoCrypto provider = QudoCrypto.create();

// ============================================================
// Device side: ML-DSA-44 (lightweight, constrained devices)
// ============================================================
// Registration: generate device identity
QudoKeyPair deviceKeys = provider.generateKeyPair("ML-DSA-44");
// Store deviceKeys.getPrivateKeyPem() securely on device
// Send deviceKeys.getPublicKeyPem() to server during registration

// Authentication: sign server challenge
byte[] challenge = receiveFromServer();
byte[] authSig = provider.sign(challenge, deviceKeys.getPrivateKeyPem(), "ML-DSA-44");
sendToServer(authSig);

// Telemetry: sign sensor data before sending
byte[] telemetry = "{\"temp\":22.5,\"humidity\":45}".getBytes();
byte[] telemetrySig = provider.sign(telemetry, deviceKeys.getPrivateKeyPem(), "ML-DSA-44");
sendToServer(telemetry, telemetrySig);

// ============================================================
// Vendor side: ML-DSA-87 (highest security for firmware)
// ============================================================
QudoKeyPair vendorKeys = provider.generateKeyPair("ML-DSA-87");
byte[] firmware = loadFirmwareBinary();
byte[] firmwareSig = provider.sign(firmware, vendorKeys.getPrivateKeyPem(), "ML-DSA-87");
// Distribute firmware + firmwareSig + vendorKeys.getPublicKeyPem()

// ============================================================
// Device side: verify firmware before applying
// ============================================================
boolean valid = provider.verify(firmware, firmwareSig, vendorPubKey, "ML-DSA-87");
if (valid) applyUpdate(firmware);  // FIRMWARE_ACCEPTED
else rejectUpdate();               // FIRMWARE_REJECTED
This is what runs on your device and gateway. ML-DSA-44 for device-side operations (small signatures, fast). ML-DSA-87 for vendor firmware signing (highest security). Your MQTT/CoAP/HTTP protocol stays the same.

What Changes vs What Stays

ComponentClassicalPQC (Qudo JNI)
Device identityECDSA P-256provider.generateKeyPair("ML-DSA-44")
AuthenticationECDSA challenge-responseprovider.sign(challenge, key, "ML-DSA-44")
Telemetry signingHMAC-SHA256 / ECDSAprovider.sign(data, key, "ML-DSA-44")
Firmware signingRSA-4096 / ECDSA P-384provider.sign(fw, vendorKey, "ML-DSA-87")
TLS transportECDHE / X25519X25519MLKEM768 (gateway NGINX config)
Protocol (MQTT/CoAP)SameSame — PQC is at crypto layer, not protocol

3. Algorithm Choice: Why Two Levels?

ML-DSA-44 (Device)ML-DSA-87 (Firmware)
Security LevelNIST Level 2NIST Level 5
Signature Size2,420 bytes4,627 bytes
Public Key Size1,860 bytes3,595 bytes
Sign Latency~118ms~125ms
Use CaseFrequent, bandwidth-constrainedInfrequent, security-critical
LifetimeSession-based authMust verify for 10-20 years
Rule: ML-DSA-44 for things the device does often (auth, telemetry). ML-DSA-87 for things the vendor does once and the device must trust for years (firmware).

5. Performance

OperationML-DSA-44ECDSA P-256Impact
Key generation~50ms~5msOne-time during provisioning
Sign telemetry~118ms~2msPer data packet (can batch)
Verify (server-side)~40ms~2msServer has more resources
Signature over wire2,420 bytes64 bytes~2.4KB extra per message
Optimization: For high-frequency telemetry (100+ readings/sec), sign a batch of readings rather than individual values. For low-frequency sensors (1 reading/min), the ~118ms overhead is negligible.

6. Pitfalls

Pitfall: ML-DSA-44 signatures are 2.4KB — too large for some IoT protocols

Impact: MQTT has no hard message size limit, but CoAP has a ~1KB payload recommendation. LoRaWAN has a 51-222 byte limit.
Mitigation: For extremely constrained protocols, sign at the gateway level rather than the device. Or batch multiple readings into one signed payload.

Pitfall: Device key provisioning must happen securely

Impact: If the ML-DSA-44 private key is extracted during manufacturing, the device identity is compromised.
Fix: Generate keys on-device (if the device has a secure element) or use a secure provisioning channel. Never transmit private keys over unencrypted connections.

Pitfall: Firmware signing uses ML-DSA-87, not ML-DSA-44

Why: Firmware updates must remain verifiable for the entire device lifetime (10-20 years). ML-DSA-87 (Level 5) provides the highest security margin against future advances in both classical and quantum computing.

Pitfall: Clock-less devices can't validate certificate expiry

Impact: Many IoT devices don't have a reliable clock, so certificate validity dates are meaningless.
Fix: Use raw public key authentication (device stores vendor's ML-DSA-87 public key directly) rather than X.509 certificates for firmware verification.

7. FAQ

Q: Can a microcontroller run ML-DSA-44?

A: ML-DSA-44 verification requires ~100KB RAM and ~200ms on a Cortex-M4 class MCU. Signing requires similar resources. For Cortex-M0 class devices (very low-end), consider signing at the gateway and using a simpler device authentication (e.g., pre-shared keys with AES-GCM).

Q: Should I sign every telemetry reading?

A: Depends on the use case. For safety-critical data (medical devices, industrial control), sign every reading. For non-critical data (temperature sensors), sign batches of readings to reduce overhead. The signature covers whatever data you include — one reading or one hundred.

Q: How do devices get firmware updates securely?

A: The vendor signs the firmware binary hash with ML-DSA-87. The signed hash is sent alongside the firmware. The device: 1) downloads firmware, 2) computes SHA-256 hash, 3) verifies the hash against the vendor's ML-DSA-87 signature, 4) applies only if FIRMWARE_ACCEPTED.

Q: What about MQTT over PQC TLS?

A: If the MQTT broker terminates TLS behind an NGINX gateway with X25519MLKEM768, all MQTT traffic gets quantum-safe transport automatically. The device signs telemetry at the application layer for end-to-end integrity regardless of the transport.

Q: Can I mix classical and PQC devices on the same network?

A: Yes. The server can verify both ECDSA and ML-DSA signatures. During migration, new devices use ML-DSA-44, existing devices keep ECDSA. The server checks the signature algorithm in the device record and verifies accordingly.

Crypto Inventory Scanner

Analyze any endpoint's cryptographic configuration. Enter a host:port to scan its TLS setup and identify what's quantum-safe vs what needs migration.

Scan Endpoint