Coldwave Yuki Module (YMOD) — Security-Whitepaper

Produkt: Coldwave Yuki Module (YMOD) — zellulares Connectivity-Modul
Firmware: YMOD 1.0.0 (auf coldwave-os 2.2.0)
Mikrocontroller: Silicon Labs EFR32MG26 (ARM Cortex-M33)
Modem-Varianten: Quectel EG912 (LTE Cat-1, Standard) · Quectel BG77 (LTE-M/NB-IoT + GNSS)
Hersteller: ImagineOn GmbH, Neusser Str. 27–29, 50670 Köln, Deutschland
Dokumentversion: 1.0 — 2026
Sicherheitsniveau: IEC 62443 SL-2 (Ziel), Geräteklasse RC-2

Über dieses Dokument. Dieses Whitepaper beschreibt die Sicherheitsarchitektur, -mechanismen und -prozesse des Coldwave Yuki Module (YMOD) für OEM-Integratoren (Host-MCU-Hersteller), Betreiber, IT-Sicherheitsverantwortliche und benannte Stellen. Es beschreibt bewusst Mechanismen und Richtlinien — keine konkreten Schwachstellen, internen Restrisiko-Register oder Infrastruktur-Details.

Inhalt

Zweck & Geltungsbereich
Sicherheits-Architektur im Überblick
Trust-Modell & Zonen
Software-Integrität & Updates
Transport & Backend-Anbindung
Reduktion der Angriffsfläche
UART-Protokoll-Server — primäre Angriffsfläche
Bedrohungsmodell im Überblick
Datenschutz & Datenminimierung
Schwachstellen-Management (PSIRT)
Transparenz: SBOM & Komponenten
Sicherheits-Support & Lifecycle
Normen & Rahmenwerke
Geteilte Verantwortung
Außerbetriebnahme & Entsorgung
Kontakt & Verweise

1. Zweck & Geltungsbereich

Das Coldwave Yuki Module (YMOD) ist ein zellulares Connectivity-Modul auf Basis eines Mikrocontrollers (Silicon Labs EFR32MG26, ARM Cortex-M33). Es bindet einen Host-MCU über ein gehärtetes UART-Protokoll an das Coldwave-Cloud-Backend an; die Backend-Strecke läuft über Mobilfunk (LTE) und einen DTLS-Tunnel. Die Firmware ist die einzige Software auf dem Chip; sie läuft auf coldwave-os 2.2.0 und wird aus einem einzigen Quellbaum in zwei Modem-Varianten gebaut: eg912 (Quectel EG912, LTE Cat-1, Standard) und bg77 (Quectel BG77, LTE-M/NB-IoT, mit GNSS).

Was YMOD ist — und was nicht. YMOD ist ein Anbindungs-Modul, kein Feldbus-Gateway. Es enthält keinen Modbus-/BACnet-Stack, keine On-Device-Script-VM, keinen supercap-gestützten Power-Fail-Pfad, keine batteriegepufferte RTC und kein On-Device-Datenbudget. Die primäre lokale Angriffsfläche ist der UART-Protokoll-Server gegenüber dem Host-MCU (siehe §7); die zweite externe Fläche ist der LTE/DTLS-Backend-Kanal (§5).

Das Modul wird nach einem sicheren Entwicklungslebenszyklus gemäß IEC 62443-4-1 entwickelt und ist auf das Sicherheitsniveau SL-2 (effektive Geräteklasse RC-2) ausgelegt. Die Cybersecurity-Bewertung als internet-verbundenes Funkgerät erfolgt nach EN 18031-1.

2. Sicherheits-Architektur im Überblick

Schutzziel	Maßnahme im YMOD
Integrität der Firmware	Secure Boot / MCUboot-artiger Bootloader (coldwave-os) mit ECDSA-P256-Signaturprüfung vor der Ausführung
Authentizität der Updates	Signaturprüfung des OTA-Images vor dem Swap; Signaturschlüssel in einem cloud-gehosteten Hardware-Sicherheitsmodul (HSM; FIPS 140-2 Level 3), nicht extrahierbar
Vertraulichkeit im Transport	DTLS-verschlüsselter Backend-Kanal über LTE mit zertifikatsbasierter Server-Authentifizierung
Reduktion der Angriffsfläche	Kein exponierter lokaler TLS-Server, keine lauschenden Netzwerkdienste, keine lokale Konsole/Login, keine Default-Passwörter
Schlüsselablage	PSA-Crypto-Keystore, hardwaregestützt über das EFR32MG26-Sicherheitssubsystem (Gecko Secure Element / Secure Vault), nicht exportierbar
Robustheit der Schnittstellen	Gehärteter UART-Protokoll-Parser: TLV-Framing + CRC-16/CCITT-FALSE, strikte Längen-Bounds, host- und fuzz-getestet
Geräteidentität	ED25519-Device-Key im PSA-Keystore; Claim-Code = `base58(SHA-256(pubkey\|imei\|iccid))`

3. Trust-Modell & Zonen

Das YMOD unterscheidet mehrere Vertrauensgrenzen. Alle von außen empfangenen Bytes gelten bis zur Validierung als nicht vertrauenswürdig.

Grenze / Zone	Beteiligte	Vertrauensannahme
B1 — Lokales UART (Host-MCU)	Host-MCU an serieller Leitung	Primäre lokale Angriffsfläche. Alle eingehenden TLV-Frames untrusted bis CRC- und Längen-Validierung (§7)
B2 — LTE/DTLS-Backend	Coldwave-Backend (UDP/DTLS)	Nur DTLS-verschlüsselte Pakete; Server-Authentifizierung gegen eingebettete Coldwave-PKI-Root-CA
B3 — Modem-AT / SIM	Quectel-Modem (AT-Kanal) + SIM	AT-Antworten/URCs und SIM-gelieferte Werte (IMEI/ICCID) untrusted; dürfen Treiber nicht kompromittieren
B4 — Physisch / Debug	Gehäuse, JTAG/SWD, RTT, Flash	Durch das EFR32MG26-Sicherheitssubsystem und die Einbaulage im Host-Gerät begrenzt

Was das Backend bewirken kann (Blast-Radius). Über das Coldwave-Backend können Telemetrie abgerufen, Konfiguration gepusht und ein OTA-Update ausgelöst werden. YMOD implementiert keine eigene Steuer- oder Sicherheitslogik und keine Aktor-Mapping-Engine. Die Wirkung auf die Anlagenseite beschränkt sich auf die exponierten GPIO-Service-Tags (Status-/Tag-Signale zum Host); die Anwendungs- und Sicherheitslogik verbleibt im Host-MCU und ist vom YMOD nicht überschreibbar.

4. Software-Integrität & Updates

Die Integrität der Firmware ist über die gesamte Startkette abgesichert:

Secure Boot & Bootloader: Der MCUboot-artige Bootloader von coldwave-os verifiziert die kryptographische Signatur des Firmware-Images beim Start (Code-Integrität), bevor es ausgeführt wird.
Signaturverfahren: Images werden mit ECDSA-P256 / SHA-256 signiert. Der private Signaturschlüssel liegt in einem cloud-gehosteten Hardware-Sicherheitsmodul (HSM; FIPS 140-2 Level 3) und ist nicht extrahierbar; der zugehörige Verifikations-Public-Key ist im Bootloader eingebettet und ab Werk provisioniert.
Verifikation vor dem Swap: Ein neu geladenes OTA-Image wird vor dem Aktivieren geprüft; bei ungültiger oder fehlender Signatur wird das Update verworfen und in das zuletzt gültige Image zurückgefallen (getrennte Primary-/Secondary-Slots).
Anti-Rollback: Ein Herabstufen auf ältere, bekannt verwundbare Stände wird über die Anti-Rollback-Konfiguration des MCUboot-Bootloaders verhindert; YMOD sorgt für die Versions-Monotonie über den Versions-String.

Updates werden ausschließlich über den DTLS-authentifizierten Backend-Kanal ausgelöst. Der Bootloader-Verifikations-Public-Key ist im Feld nicht per OTA austauschbar; ein Schlüsselwechsel erfordert Werks-Refurbishment (dokumentiert und mit Management-Freigabe als akzeptiertes Restrisiko).

5. Transport & Backend-Anbindung

Die Kommunikation mit dem Coldwave-Backend ist DTLS-verschlüsselt (mbedTLS in Verbindung mit dem PSA-Crypto-/Gecko-Secure-Element und einem Hardware-Zufallszahlengenerator; delegiert an coldwave-os).
Die Verbindung nutzt eine zertifikatsbasierte Server-Authentifizierung: Das Gerät validiert den Backend-Server gegen eine zur Build-Zeit in die Firmware eingebettete Coldwave-PKI-Root-CA.
Das Gerät identifiziert sich über seine IMEI als Device-ID; die Bindung an einen Tenant erfolgt applikativ über den geräteindividuellen Claim-Code (§7).
Zusätzliche Absicherung durch eine Private-APN-Bindung; der Mobilfunkprovider transportiert ausschließlich verschlüsselte Pakete.
Es besteht ausschließlich eine ausgehende Verbindung vom Gerät zum Backend. YMOD betreibt keinen lokalen TLS-Server (der optionale lokale Router-Dienst auf Port 9986 ist im Build inaktiv und nicht exponiert) — siehe §6.

6. Reduktion der Angriffsfläche

Keine offenen Netzwerkdienste: kein SSH, Telnet, HTTP-Server oder MQTT-Broker; das Gerät bietet keine lauschenden Ports und keinen lokalen TLS-Server an. Die einzige remote erreichbare Fläche ist der ausgehende, DTLS-gesicherte Backend-Kanal.
Keine lokale Benutzer-Authentifizierung/Konsole: kein lokales Login. Die serielle Diagnose-CLI und der UART-Protokoll-Server sind die einzigen lokalen Schnittstellen; letzterer ist die primäre Angriffsfläche und entsprechend gehärtet (§7).
Keine Default-Passwörter und keine kundenseitig veränderbaren Zugangsdaten auf dem Gerät.
Hardwaregestützter Debug-Schutz: Der EFR32MG26 stellt einen Debug-Lock über das Gecko Security Element bereit; die geräteindividuellen Schlüssel liegen hardwaregebunden und nicht exportierbar im PSA-Keystore und bleiben dadurch geschützt. Die Aktivierung des Debug-Locks ist eine Provisioning-Maßnahme im Rahmen der Fertigung/Härtung.
Reduzierte Codebasis: Es sind keine Feldbus-Master (Modbus/BACnet), keine Script-VM, kein RS232/RS485-Mux und keine Power-Fail-/Budget-Pfade vorhanden — die Angriffsfläche ist damit gegenüber einem Feldbus-Gateway deutlich kleiner.

7. UART-Protokoll-Server — primäre Angriffsfläche

Das lokale UART-Protokoll zum Host-MCU ist die wichtigste lokale Eingangsschnittstelle und der Fokus der Sicherheits-Härtung. Alle vom Host empfangenen Bytes werden als nicht vertrauenswürdig behandelt, bis sie validiert sind:

TLV-Framing & CRC-Siegel: Jeder Frame besteht aus einem 2-Byte-Header (Typ ≤ 0x7F + Längenfeld), einer Payload von bis zu 511 Byte und einer CRC-16/CCITT-FALSE-Prüfsumme (Polynom 0x1021, Init 0xFFFF) über Header und Payload. Bei CRC-Mismatch wird der Frame verworfen (errno=EPROTO).
Strikte Längen-Bounds: Ein Längenfeld über dem Maximum wird abgewiesen (EPROTO), ein Typ über 0x7F ebenfalls (EINVAL) — Überläufe der internen Puffer werden dadurch ausgeschlossen.
Keine Verarbeitung partieller Frames: Der Byte-Leser bricht bei kurzem oder abgebrochenem Read ab; unvollständige Frames werden nicht weiterverarbeitet.
Payload-Validierung im Parser: Die SET-/UUID-Kommando-Parser prüfen Mindest- und exakte Payload-Längen; nicht plausible Längen werden mit einem Argumentfehler abgewiesen (kein Weiterreichen an die Handler).
Isolierter Parser: Der Frame-Empfang ist von der Kommando-Ausführung entkoppelt; die Handler liegen in einem separaten Modul.
Test & Fuzzing: Der Framing-/CRC-Parser und die Payload-Dekodierung sind host-getestet (RoundTrip, CRC/Malformed/Overlong/Truncated abgewiesen, SET-Payload-Bounds) und mit Speicher-Sanitizern (ASan/UBSan) über eine libFuzzer-Harness auf dem Frame-Empfangspfad fuzz-getestet — ohne Crash.

Geräteidentität & Claim-Code. Über den UART-Server wird der öffentliche ED25519-Device-Key (im PSA-Keystore gehalten) exportiert. Der Claim-Code = base58(SHA-256(pubkey|imei|iccid)) (auf die ersten acht Byte gekürzt) bindet die Geräteidentität kryptographisch an den geräteindividuellen Schlüssel und ist nicht aus IMEI/ICCID allein ableitbar.

Warum diese Fläche im Fokus steht. Der UART-Protokoll-Server ist der einzige Pfad, über den untrusted lokale Daten in die On-Device-Laufzeit gelangen. Jeder Fehler, der aus einem manipulierten Host-Frame einen OOB-Read/-Write, eine persistente Korruption oder einen Kontroll-Bypass erzeugt, wird als Sicherheitsdefekt der höchsten Prioritätsklasse behandelt.

8. Bedrohungsmodell im Überblick

Die Bedrohungsanalyse folgt STRIDE auf einem Level-1-Datenflussdiagramm mit den vier Vertrauensgrenzen aus §3. Die folgende Übersicht fasst den Bedrohungskatalog zusammen; sie beschreibt Mechanismen, keine ausnutzbaren Details.

ID	Angriffsfläche	Bedrohung	Wesentliche Gegenmaßnahme
T-UART	UART-Server (B1)	Manipulierte Host-Frames → OOB-Read/-Write, State-Confusion	CRC-16-Siegel, strikte Längen-Bounds, Payload-Validierung; host- und fuzz-getestet (§7)
T-BACKEND	Backend-DTLS (B2)	DTLS-MITM / gefälschter Backend-Server	DTLS mit Server-Zertifikatsprüfung gegen eingebettete Coldwave-Root-CA; Private-APN-Bindung
T-OTA	OTA / Bootloader (B2)	Unsigniertes / manipuliertes Firmware-Image	ECDSA-P256-Verifikation vor dem Swap; Anti-Rollback; Fallback in vorheriges Image
T-MODEM	Modem-AT / SIM (B3)	Bösartige SIM / fabrizierte AT-Antworten → Treiber-Overflow, Reconnect-Loop	Line-Buffer-Caps im Modem-Treiber; Watchdog + Recovery-Ladder; IMEI-Plausibilitätscheck
T-IMEI	Geräteidentität (B3/B4)	Identitäts-Spoofing (fremde IMEI vortäuschen)	IMEI-Plausibilitätscheck (15 Ziffern) vor Persistenz; Claim-Code an ED25519-Device-Key gebunden

Härtungsdetails der delegierten Abhängigkeiten (coldwave-os DTLS-/OTA-/Modem-Treiber, libflake) werden in deren eigener IEC-62443-4-1-Evidenzkette geführt; YMOD übernimmt die dort freigegebenen RC-2-Mitigationen als Annahme und spiegelt Upstream-Advisories in sein Schwachstellen-Tracking.

9. Datenschutz & Datenminimierung

Der Regelbetrieb überträgt ausschließlich Maschinen-Telemetrie sowie geräteidentifizierende Werte (IMEI, ICCID, LTE-Zellinfo) — keine personenbezogenen Daten im Sinne der DSGVO. Die IMEI identifiziert das Gerät, nicht eine Person. Es findet keine Netz-Exposition personenbezogener Daten durch das Modul statt.

10. Schwachstellen-Management (PSIRT)

ImagineOn betreibt einen Product-Security-Incident-Response-Prozess in Anlehnung an IEC 62443-4-1 (Practice 6, DM-1 … DM-5) und vorbereitend auf den EU-Cyber-Resilience-Act (CRA). Bitte keine öffentlichen GitHub-Issues, Pull-Requests oder Discussions für Sicherheitsthemen verwenden.

Meldekanal	security@coldwave.io
Verschlüsselte Meldung	PGP; der aktuelle Schlüssel/Fingerprint wird in der `security.txt` unter `https://coldwave.io/.well-known/security.txt` bereitgestellt (bzw. auf Anfrage bei der PSIRT)
Empfangsbestätigung	innerhalb von 2 Arbeitstagen
Triage & Ersteinstufung	innerhalb von 5 Arbeitstagen
Fix-Bereitstellung (Critical/High, CVSS ≥ 7)	innerhalb von 90 Tagen
Fix-Bereitstellung (Medium/Low)	innerhalb von 180 Tagen (gebündelt im nächsten Minor-Release)
Bewertung	CVSS v3.1

Für eine Meldung sind hilfreich: die YMOD-Firmware-Version (Release-Tag, z. B. v1.0.0, oder Commit-Hash), die Modem-Variante (eg912 oder bg77) und — bei UART-Protokoll-Themen — eine minimale Byte-Sequenz (das libFuzzer-Korpusformat ist ideal). Meldungen sind in Deutsch oder Englisch möglich.

Coordinated Disclosure: Offenlegung erfolgt koordiniert, nach Verfügbarkeit eines Fixes und einer angemessenen Ausrollzeit für Integratoren (typisch 30 Tage). Melder werden auf Wunsch namentlich genannt; es besteht derzeit kein bezahltes Bug-Bounty-Programm.
CRA/ENISA: Bei einer aktiv ausgenutzten Schwachstelle kann eine Meldung an die ENISA innerhalb von 24 Stunden erforderlich sein (CRA-Meldepflichten ab 2026-09-11). Solche Meldungen werden ohne Triage-Warteschlange vorrangig bearbeitet und im Changelog mit [Security] gekennzeichnet.
Ein Critical/High-Fehler im Frame-Empfangspfad des UART-Protokoll-Servers (TLV/CRC-Parse + Handler) wird als höchste Prioritätsklasse behandelt — es ist der einzige Pfad für untrusted lokale Daten.

11. Transparenz: SBOM & Komponenten

Für jede ausgelieferte Firmware-Version wird eine CycloneDX-SBOM geführt und auf Anfrage bereitgestellt.
Zu öffentlich diskutierten CVEs, die verwendete Komponenten betreffen könnten, stellt ImagineOn CycloneDX-VEX-Statements bereit; Upstream-Advisories von coldwave-os, libflake und coldwave-yuki-core werden in das Schwachstellen-Tracking gespiegelt.
Der YMOD-Anwendungscode ist vollständig ImagineOn-authored; es gibt keinen vendored Third-Party-Quellcode im Image außer dem coldwave-os-SDK.

Komponente	Version	Rolle
coldwave-os (FU-Image)	2.2.0	RTOS, Netzwerk, DTLS, OTA, FS, PSA
coldwave-os (Bootloader)	2.2.0	MCUboot-artige Image-Verifikation
libflake	(über OS)	Property-Layer, IPC
coldwave-yuki-core	1.0.0	Connectivity-Supervisor + Recovery + LTE-Quality

12. Sicherheits-Support & Lifecycle

ImagineOn stellt sicherheitsrelevante Firmware-Updates im Einklang mit den Anforderungen des EU-Cyber-Resilience-Act bereit. Die definierte Support-Periode (Defined Support Period) wird produktbezogen separat veröffentlicht und im Rahmen der CRA-Konformität festgelegt; sie deckt Firmware-Revisionen derselben Hardware-Generation ab. Nach dem Ende des Sicherheits-Supports sollten betroffene Geräte ersetzt oder in eine Netz-Quarantäne überführt werden.

Der aktuelle Gate-Status der 1.0.0-Baseline (SAST 0 Fehler, Host-Testsuite und Security-Tests grün, Zeilenabdeckung ≥ 60 %) wird über die Host-Quality-Pipeline gemessen; offene Release-Punkte werden vor dem Inverkehrbringen abgeschlossen.

13. Normen & Rahmenwerke

Rahmenwerk	Bezug für das YMOD
RED 2014/53/EU + Delegierte VO (EU) 2022/30	Funkanlagen-Cybersecurity, Art. 3(3)(d)/(e)/(f)
EN 18031-1:2024	Cybersecurity-Anforderungen an internet-verbundene Funkgeräte (Self-Assessment)
IEC 62443-4-1	Sicherer Entwicklungslebenszyklus (SDL), Geräteklasse RC-2
IEC 62443-4-2	Technische Sicherheitsanforderungen an Komponenten, Ziel SL-2; Grundlage der geteilten Verantwortung (§14)
EU-CRA (VO (EU) 2024/2847)	vorbereitend; volle Anwendbarkeit ab 2027-12-11, Meldepflichten ab 2026-09-11
EN 62368-1 · EN 50665 · EN 301 489-Familie · EN 301 908-Familie	Gerätesicherheit, HF-Exposition und EMV/Funk der beiden Modem-Varianten
ETSI EN 303 645	vorausschauend angewandt (Consumer-IoT-Baseline)

Konformitätsbewertung der Funkanlage nach RED über Modul A (interne Fertigungskontrolle), ohne Einbindung einer benannten Stelle. Dieses Whitepaper trifft keine Aussage zur Konformität mit anwendungsspezifischen Produktnormen des Host-Systems; YMOD ist eine zellulare Anbindungskomponente, nicht das Host-Endgerät.

14. Geteilte Verantwortung

Sicherheit im Feld ist eine gemeinsame Aufgabe (IEC 62443-4-2). Die Rollen verteilen sich wie folgt:

Rolle	Verantwortung
Hersteller (ImagineOn)	Firmware-Sicherheit, Signatur-/Update-Kette, Härtung des UART-Protokoll-Servers und des Backend-Kanals, PSIRT und Sicherheits-Patches gemäß SLA, SBOM/VEX.
OEM-Integrator (Host-MCU-Hersteller)	Sichere Einbindung des Moduls in das Host-Gerät, korrekte Nutzung des UART-Protokolls, physischer Schutz und Einbaulage (Debug-Zugang), Sicherheit des Coldwave-Tenant-Accounts (starke Authentifizierung/MFA, Least-Privilege), Geräte-zu-Tenant-Zuordnung.
Asset Owner / Betreiber	Schutz des Portal-Zugangs, zeitnahe Meldung von Auffälligkeiten, Updates nicht dauerhaft durch Netzabschaltung blockieren.

15. Außerbetriebnahme & Entsorgung

Die geräteindividuellen Schlüssel (ED25519-Device-Key, DTLS-Trust-Anchor, OTA-Verifikationsschlüssel) liegen hardwaregebunden und nicht exportierbar im PSA-Keystore des Mikrocontrollers. Eine On-Site-Datenlöschung durch den Betreiber ist nicht vorgesehen (kein Betreiber-Interface). Bei Deinstallation wird empfohlen, das Gerät im Coldwave-Portal zu deprovisionieren und — wo möglich — an ImagineOn zurückzugeben; im Werks-Refurbishment werden die Schlüssel sicher gelöscht. Andernfalls sind das Modul bzw. das integrierende Host-Gerät als Elektroaltgerät (WEEE) fachgerecht zu entsorgen; die Schlüssel sind an die Hardware gebunden und werden mit deren Zerstörung unbrauchbar.

WEEE-Registrierungsnummer: DE 54689668 (ImagineOn GmbH).

16. Kontakt & Verweise

Sicherheits-/Schwachstellen-Meldung: security@coldwave.io (PGP über https://coldwave.io/.well-known/security.txt)
Konformität: compliance@imagineon.de · Web: www.imagineon.de
SBOM/VEX: auf Anfrage über die Konformitäts-Adresse

© 2026 ImagineOn GmbH. Alle Rechte vorbehalten. Dieses Whitepaper beschreibt Sicherheitsmechanismen und -prozesse zum Zeitpunkt der Veröffentlichung; Änderungen im Zuge der Produktpflege bleiben vorbehalten.

Coldwave Yuki Module (YMOD) — Security Whitepaper

Translation note. This English version is a translation of the German original. In case of any discrepancy or ambiguity, the German version prevails as the legally authoritative text.

Product: Coldwave Yuki Module (YMOD) — cellular connectivity module
Firmware: YMOD 1.0.0 (on coldwave-os 2.2.0)
Microcontroller: Silicon Labs EFR32MG26 (ARM Cortex-M33)
Modem variants: Quectel EG912 (LTE Cat-1, default) · Quectel BG77 (LTE-M/NB-IoT + GNSS)
Manufacturer: ImagineOn GmbH, Neusser Str. 27–29, 50670 Cologne, Germany
Document version: 1.0 — 2026
Security level: IEC 62443 SL-2 (target), device class RC-2

About this document. This whitepaper describes the security architecture, mechanisms and processes of the Coldwave Yuki Module (YMOD) for OEM integrators (host-MCU manufacturers), operators, IT-security officers and notified bodies. It deliberately describes mechanisms and policies — not specific vulnerabilities, internal residual-risk registers or infrastructure details.

Contents

Purpose & scope
Security architecture at a glance
Trust model & zones
Software integrity & updates
Transport & backend connection
Attack-surface reduction
UART protocol server — primary attack surface
Threat model summary
Data protection & data minimisation
Vulnerability management (PSIRT)
Transparency: SBOM & components
Security support & lifecycle
Standards & frameworks
Shared responsibility
Decommissioning & disposal
Contact & references

1. Purpose & scope

The Coldwave Yuki Module (YMOD) is a cellular connectivity module built on a microcontroller (Silicon Labs EFR32MG26, ARM Cortex-M33). It attaches a host MCU to the Coldwave cloud backend through a hardened UART protocol; the backend leg runs over cellular (LTE) and a DTLS tunnel. The firmware is the only software on the chip; it runs on coldwave-os 2.2.0 and is built from a single source tree in two modem variants: eg912 (Quectel EG912, LTE Cat-1, default) and bg77 (Quectel BG77, LTE-M/NB-IoT, with GNSS).

What YMOD is — and is not. YMOD is a connectivity module, not a field-bus gateway. It contains no Modbus/BACnet stack, no on-device scripting VM, no supercap-backed power-fail path, no battery-backed RTC and no on-device data budget. The primary local attack surface is the UART protocol server facing the host MCU (see §7); the second external surface is the LTE/DTLS backend conduit (§5).

The module is developed following a secure development lifecycle per IEC 62443-4-1 and is designed for security level SL-2 (effective device class RC-2). Its cybersecurity assessment as internet-connected radio equipment follows EN 18031-1.

2. Security architecture at a glance

Objective	Measure in the YMOD
Firmware integrity	Secure Boot / MCUboot-style bootloader (coldwave-os) with ECDSA-P256 signature verification before execution
Update authenticity	OTA image signature verified before swap; signing key held in a cloud-hosted hardware security module (HSM; FIPS 140-2 Level 3), non-extractable
Transport confidentiality	DTLS-encrypted backend conduit over LTE with certificate-based server authentication
Attack-surface reduction	No exposed local TLS server, no listening network services, no local console/login, no default passwords
Key storage	PSA Crypto keystore, hardware-backed by the EFR32MG26 security subsystem (Gecko Secure Element / Secure Vault), non-exportable
Interface robustness	Hardened UART protocol parser: TLV framing + CRC-16/CCITT-FALSE, strict length bounds, host- and fuzz-tested
Device identity	ED25519 device key in the PSA keystore; claim code = `base58(SHA-256(pubkey\|imei\|iccid))`

3. Trust model & zones

The YMOD distinguishes several trust boundaries. All externally received bytes are treated as untrusted until validated.

Boundary / zone	Parties	Trust assumption
B1 — Local UART (host MCU)	Host MCU on a serial line	Primary local attack surface. All inbound TLV frames untrusted until CRC and length validation (§7)
B2 — LTE/DTLS backend	Coldwave backend (UDP/DTLS)	Only DTLS-encrypted packets; server authentication against the embedded Coldwave PKI root CA
B3 — Modem AT / SIM	Quectel modem (AT channel) + SIM	AT responses/URCs and SIM-supplied values (IMEI/ICCID) untrusted; must not compromise the driver
B4 — Physical / debug	Enclosure, JTAG/SWD, RTT, flash	Constrained by the EFR32MG26 security subsystem and the mounting inside the host device

What the backend can do (blast radius). Through the Coldwave backend, telemetry can be retrieved, configuration pushed and an OTA update triggered. YMOD implements no control or safety logic of its own and no actuator-mapping engine. Its effect on the installation side is limited to the exposed GPIO service tags (status/tag signals to the host); the application and safety logic remains in the host MCU and cannot be overridden by YMOD.

4. Software integrity & updates

Firmware integrity is protected across the entire boot chain:

Secure Boot & bootloader: the MCUboot-style coldwave-os bootloader verifies the cryptographic signature of the firmware image at start-up (code integrity) before it is executed.
Signature scheme: images are signed with ECDSA-P256 / SHA-256. The private signing key is held in a cloud-hosted hardware security module (HSM; FIPS 140-2 Level 3) and is non-extractable; the corresponding verify public key is embedded in the bootloader and provisioned at the factory.
Verification before swap: a newly loaded OTA image is verified before activation; on an invalid or missing signature the update is discarded and the device falls back to the last valid image (separate primary/secondary slots).
Anti-rollback: downgrading to older, known-vulnerable builds is prevented via the MCUboot bootloader's anti-rollback configuration; YMOD ensures version monotonicity through the version string.

Updates are triggered exclusively over the DTLS-authenticated backend channel. The bootloader verify public key is not field-updatable via OTA; a key change requires factory refurbishment (documented and management-approved as accepted residual risk).

5. Transport & backend connection

Communication with the Coldwave backend is DTLS-encrypted (mbedTLS together with the PSA Crypto / Gecko Secure Element and a hardware random-number generator; delegated to coldwave-os).
The connection uses certificate-based server authentication: the device validates the backend server against a Coldwave PKI root CA embedded into the firmware at build time.
The device identifies itself via its IMEI as device ID; binding to a tenant happens at application level through the device-individual claim code (§7).
Additional hardening via a private-APN binding; the mobile network operator transports only encrypted packets.
Only an outbound connection from device to backend exists. YMOD runs no local TLS server (the optional local router service on port 9986 is inactive in the build and not exposed) — see §6.

6. Attack-surface reduction

No open network services: no SSH, Telnet, HTTP server or MQTT broker; the device offers no listening ports and no local TLS server. The only remotely reachable surface is the outbound, DTLS-protected backend channel.
No local user authentication/console: no local login. The serial diagnostics CLI and the UART protocol server are the only local interfaces; the latter is the primary attack surface and is hardened accordingly (§7).
No default passwords and no operator-changeable credentials on the device.
Hardware-backed debug protection: the EFR32MG26 provides a debug lock via the Gecko Security Element; the device-individual keys are held hardware-bound and non-exportable in the PSA keystore and thereby stay protected. Enabling the debug lock is a provisioning measure during manufacturing/hardening.
Reduced code base: there are no field-bus masters (Modbus/BACnet), no scripting VM, no RS232/RS485 mux and no power-fail/budget paths — the attack surface is markedly smaller than a field-bus gateway.

7. UART protocol server — primary attack surface

The local UART protocol to the host MCU is the most important local input interface and the focus of the security hardening. All bytes received from the host are treated as untrusted until validated:

TLV framing & CRC seal: each frame consists of a 2-byte header (type ≤ 0x7F + length field), a payload of up to 511 bytes and a CRC-16/CCITT-FALSE checksum (polynomial 0x1021, init 0xFFFF) over header and payload. On a CRC mismatch the frame is discarded (errno=EPROTO).
Strict length bounds: a length field above the maximum is rejected (EPROTO), a type above 0x7F as well (EINVAL) — internal buffer overflows are thereby precluded.
No processing of partial frames: the byte reader aborts on a short or truncated read; incomplete frames are not processed further.
Payload validation in the parser: the SET/UUID command parsers check minimum and exact payload lengths; implausible lengths are rejected with an argument error (never handed to the handlers).
Isolated parser: frame receive is decoupled from command execution; the handlers live in a separate module.
Testing & fuzzing: the framing/CRC parser and payload decoding are host-tested (round-trip, CRC/malformed/overlong/truncated rejected, SET-payload bounds) and fuzz-tested with memory sanitizers (ASan/UBSan) through a libFuzzer harness on the frame-receive path — with no crash.

Device identity & claim code. The public ED25519 device key (held in the PSA keystore) is exported over the UART server. The claim code = base58(SHA-256(pubkey|imei|iccid)) (truncated to the first eight bytes) binds the device identity cryptographically to the device-individual key and cannot be derived from IMEI/ICCID alone.

Why this surface is the focus. The UART protocol server is the only path through which untrusted local data enters the on-device runtime. Any bug that turns a malformed host frame into an OOB read/write, persistent corruption or a control bypass is treated as the highest-priority class of security defect.

8. Threat model summary

The threat analysis follows STRIDE on a level-1 data-flow diagram with the four trust boundaries from §3. The overview below summarises the threat catalogue; it describes mechanisms, not exploitable details.

ID	Attack surface	Threat	Key mitigation
T-UART	UART server (B1)	Malformed host frames → OOB read/write, state confusion	CRC-16 seal, strict length bounds, payload validation; host- and fuzz-tested (§7)
T-BACKEND	Backend DTLS (B2)	DTLS MITM / spoofed backend server	DTLS with server-certificate verification against the embedded Coldwave root CA; private-APN binding
T-OTA	OTA / bootloader (B2)	Unsigned / tampered firmware image	ECDSA-P256 verification before swap; anti-rollback; fallback to previous image
T-MODEM	Modem AT / SIM (B3)	Malicious SIM / fabricated AT responses → driver overflow, reconnect loop	Line-buffer caps in the modem driver; watchdog + recovery ladder; IMEI plausibility check
T-IMEI	Device identity (B3/B4)	Identity spoofing (faking a foreign IMEI)	IMEI plausibility check (15 digits) before persistence; claim code bound to the ED25519 device key

Hardening details of the delegated dependencies (coldwave-os DTLS/OTA/modem driver, libflake) are maintained in their own IEC 62443-4-1 evidence chain; YMOD adopts the RC-2 mitigations released there as an assumption and mirrors upstream advisories into its vulnerability tracking.

9. Data protection & data minimisation

Normal operation transmits only machine telemetry and device-identifying values (IMEI, ICCID, LTE cell info) — no personal data in the sense of the GDPR. The IMEI identifies the device, not a person. No personal data is exposed over the network by the module.

10. Vulnerability management (PSIRT)

ImagineOn operates a Product Security Incident Response process aligned with IEC 62443-4-1 (Practice 6, DM-1 … DM-5) and preparing for the EU Cyber Resilience Act (CRA). Please do not use public GitHub issues, pull requests or discussions for security matters.

Reporting channel	security@coldwave.io
Encrypted report	PGP; the current key/fingerprint is provided in the `security.txt` at `https://coldwave.io/.well-known/security.txt` (or on request from the PSIRT)
Acknowledgement	within 2 business days
Triage & initial severity	within 5 business days
Fix availability (Critical/High, CVSS ≥ 7)	within 90 days
Fix availability (Medium/Low)	within 180 days (batched into the next minor release)
Scoring	CVSS v3.1

Helpful in a report: the YMOD firmware version (release tag, e.g. v1.0.0, or commit hash), the modem variant (eg912 or bg77) and — for UART-protocol issues — a minimal byte sequence (the libFuzzer corpus format is ideal). Reports may be filed in English or German.

Coordinated disclosure: disclosure is coordinated, after a fix is available and integrators have had a reasonable rollout window (typically 30 days). Reporters are credited on request; there is currently no paid bug-bounty programme.
CRA/ENISA: for an actively exploited vulnerability, notification to ENISA within 24 hours may be required (CRA reporting obligations from 2026-09-11). Such reports are handled with priority without a triage queue and flagged [Security] in the changelog.
A Critical/High issue in the UART protocol server frame-receive path (TLV/CRC parse + handlers) is treated as the highest-priority class — it is the only path for untrusted local data.

11. Transparency: SBOM & components

A CycloneDX SBOM is maintained for every shipped firmware version and provided on request.
For publicly discussed CVEs that might affect components used, ImagineOn provides CycloneDX VEX statements; upstream advisories from coldwave-os, libflake and coldwave-yuki-core are mirrored into the vulnerability tracking.
The YMOD application code is entirely ImagineOn-authored; there is no vendored third-party source in the image other than the coldwave-os SDK.

Component	Version	Role
coldwave-os (FU image)	2.2.0	RTOS, network, DTLS, OTA, FS, PSA
coldwave-os (bootloader)	2.2.0	MCUboot-style image verify
libflake	(via OS)	Property layer, IPC
coldwave-yuki-core	1.0.0	Connectivity supervisor + recovery + LTE quality

12. Security support & lifecycle

ImagineOn provides security-relevant firmware updates in line with the requirements of the EU Cyber Resilience Act. The defined support period is published separately per product and set as part of CRA conformity; it covers firmware revisions of the same hardware generation. After end-of-security-support, affected devices should be replaced or placed into network quarantine.

The current gate status of the 1.0.0 baseline (SAST 0 errors, host test suite and security tests green, line coverage ≥ 60 %) is measured by the host quality pipeline; open release items are closed before placing on the market.

13. Standards & frameworks

Framework	Relevance for the YMOD
RED 2014/53/EU + Delegated Reg. (EU) 2022/30	Radio-equipment cybersecurity, Art. 3(3)(d)/(e)/(f)
EN 18031-1:2024	Cybersecurity requirements for internet-connected radio equipment (self-assessment)
IEC 62443-4-1	Secure development lifecycle (SDL), device class RC-2
IEC 62443-4-2	Technical security requirements for components, target SL-2; basis of the shared-responsibility model (§14)
EU CRA (Reg. (EU) 2024/2847)	preparatory; fully applicable from 2027-12-11, reporting obligations from 2026-09-11
EN 62368-1 · EN 50665 · EN 301 489 family · EN 301 908 family	Equipment safety, RF exposure and EMC/radio of the two modem variants
ETSI EN 303 645	applied forward-looking (consumer-IoT baseline)

Radio-equipment conformity assessment under RED via Module A (internal production control), without involvement of a notified body. This whitepaper makes no claim of conformity with application-specific product standards of the host system; YMOD is a cellular connectivity component, not the host end device.

14. Shared responsibility

Field security is a shared task (IEC 62443-4-2). Roles are distributed as follows:

Role	Responsibility
Manufacturer (ImagineOn)	Firmware security, signing/update chain, hardening of the UART protocol server and the backend channel, PSIRT and security patches per SLA, SBOM/VEX.
OEM integrator (host-MCU manufacturer)	Secure integration of the module into the host device, correct use of the UART protocol, physical protection and mounting (debug access), security of the Coldwave tenant account (strong authentication/MFA, least privilege), device-to-tenant binding.
Asset owner / operator	Protection of portal access, prompt reporting of anomalies, not blocking updates by permanently disconnecting the network.

15. Decommissioning & disposal

The device-individual keys (ED25519 device key, DTLS trust anchor, OTA verify key) are held hardware-bound and non-exportable in the microcontroller's PSA keystore. On-site data erasure by the operator is not provided (no operator interface). On removal it is recommended to deprovision the device in the Coldwave portal and — where possible — return it to ImagineOn; keys are securely erased during factory refurbishment. Otherwise the module or the integrating host device is to be disposed of properly as electronic waste (WEEE); the keys are bound to the hardware and become unusable with its destruction.

WEEE registration number: DE 54689668 (ImagineOn GmbH).

16. Contact & references

Security / vulnerability reporting: security@coldwave.io (PGP via https://coldwave.io/.well-known/security.txt)
Conformity: compliance@imagineon.de · Web: www.imagineon.de
SBOM/VEX: on request via the conformity address

Coldwave Yuki Module (YMOD) — Livre blanc de sécurité

Avis de traduction. La présente version française est une traduction de l'original allemand. En cas de divergence ou d'ambiguïté, la version allemande prévaut en tant que texte de référence faisant foi.

Produit: Coldwave Yuki Module (YMOD) — module de connectivité cellulaire
Micrologiciel: YMOD 1.0.0 (sur coldwave-os 2.2.0)
Microcontrôleur: Silicon Labs EFR32MG26 (ARM Cortex-M33)
Variantes de modem: Quectel EG912 (LTE Cat-1, par défaut) · Quectel BG77 (LTE-M/NB-IoT + GNSS)
Fabricant: ImagineOn GmbH, Neusser Str. 27–29, 50670 Cologne, Allemagne
Version du document: 1.0 — 2026
Niveau de sécurité: IEC 62443 SL-2 (cible), classe d'appareil RC-2

À propos de ce document. Le présent livre blanc décrit l'architecture, les mécanismes et les processus de sécurité du Coldwave Yuki Module (YMOD) à l'intention des intégrateurs OEM (fabricants de MCU hôte), exploitants, responsables de la sécurité informatique et organismes notifiés. Il décrit délibérément des mécanismes et des politiques — et non des vulnérabilités concrètes, des registres internes de risques résiduels ou des détails d'infrastructure.

Sommaire

Objet & périmètre
Architecture de sécurité en un coup d'œil
Modèle de confiance & zones
Intégrité logicielle & mises à jour
Transport & liaison backend
Réduction de la surface d'attaque
Serveur de protocole UART — surface d'attaque principale
Synthèse du modèle de menaces
Protection des données & minimisation
Gestion des vulnérabilités (PSIRT)
Transparence : SBOM & composants
Support de sécurité & cycle de vie
Normes & cadres
Responsabilité partagée
Mise hors service & élimination
Contact & références

1. Objet & périmètre

Le Coldwave Yuki Module (YMOD) est un module de connectivité cellulaire reposant sur un microcontrôleur (Silicon Labs EFR32MG26, ARM Cortex-M33). Il raccorde un MCU hôte au backend cloud Coldwave via un protocole UART durci ; la liaison backend passe par le cellulaire (LTE) et un tunnel DTLS. Le micrologiciel est le seul logiciel présent sur la puce ; il s'exécute sur coldwave-os 2.2.0 et est construit à partir d'un unique arbre de sources en deux variantes de modem : eg912 (Quectel EG912, LTE Cat-1, par défaut) et bg77 (Quectel BG77, LTE-M/NB-IoT, avec GNSS).

Ce qu'est le YMOD — et ce qu'il n'est pas. Le YMOD est un module de raccordement, pas une passerelle de bus de terrain. Il ne contient aucun stack Modbus/BACnet, aucune VM de script embarquée, aucun chemin de coupure d'alimentation à supercondensateur, aucune RTC sauvegardée par pile et aucun budget de données embarqué. La surface d'attaque locale principale est le serveur de protocole UART face au MCU hôte (voir §7) ; la seconde surface externe est le canal backend LTE/DTLS (§5).

Le module est développé selon un cycle de développement sécurisé conforme à IEC 62443-4-1 et est conçu pour le niveau de sécurité SL-2 (classe d'appareil effective RC-2). Son évaluation de cybersécurité en tant qu'équipement radio connecté à Internet suit la norme EN 18031-1.

2. Architecture de sécurité en un coup d'œil

Objectif	Mesure dans le YMOD
Intégrité du micrologiciel	Secure Boot / bootloader de type MCUboot (coldwave-os) avec vérification de signature ECDSA-P256 avant exécution
Authenticité des mises à jour	Signature de l'image OTA vérifiée avant le swap ; clé de signature conservée dans un module matériel de sécurité (HSM ; FIPS 140-2 niveau 3) hébergé dans le cloud, non extractible
Confidentialité du transport	Canal backend chiffré DTLS sur LTE avec authentification serveur par certificat
Réduction de la surface d'attaque	Aucun serveur TLS local exposé, aucun service réseau en écoute, aucune console/login local, aucun mot de passe par défaut
Stockage des clés	Keystore PSA Crypto, adossé au matériel via le sous-système de sécurité EFR32MG26 (Gecko Secure Element / Secure Vault), non exportable
Robustesse des interfaces	Analyseur de protocole UART durci : trame TLV + CRC-16/CCITT-FALSE, bornes de longueur strictes, testé sur hôte et par fuzzing
Identité de l'appareil	Clé d'appareil ED25519 dans le keystore PSA ; code de rattachement = `base58(SHA-256(pubkey\|imei\|iccid))`

3. Modèle de confiance & zones

Le YMOD distingue plusieurs frontières de confiance. Tous les octets reçus de l'extérieur sont considérés comme non fiables jusqu'à validation.

Frontière / zone	Parties	Hypothèse de confiance
B1 — UART local (MCU hôte)	MCU hôte sur liaison série	Surface d'attaque locale principale. Toutes les trames TLV entrantes non fiables jusqu'à validation CRC et longueur (§7)
B2 — Backend LTE/DTLS	Backend Coldwave (UDP/DTLS)	Uniquement des paquets chiffrés DTLS ; authentification serveur contre la Root-CA PKI Coldwave embarquée
B3 — AT modem / SIM	Modem Quectel (canal AT) + SIM	Réponses/URC AT et valeurs fournies par la SIM (IMEI/ICCID) non fiables ; ne doivent pas compromettre le pilote
B4 — Physique / débogage	Boîtier, JTAG/SWD, RTT, flash	Limité par le sous-système de sécurité EFR32MG26 et le montage à l'intérieur de l'appareil hôte

Ce que le backend peut faire (rayon d'impact). Via le backend Coldwave, la télémétrie peut être récupérée, la configuration poussée et une mise à jour OTA déclenchée. Le YMOD n'implémente aucune logique de commande ou de sécurité propre ni moteur de mappage d'actionneurs. Son effet côté installation se limite aux tags de service GPIO exposés (signaux d'état/tag vers l'hôte) ; la logique applicative et de sécurité reste dans le MCU hôte et ne peut pas être outrepassée par le YMOD.

4. Intégrité logicielle & mises à jour

L'intégrité du micrologiciel est protégée sur toute la chaîne de démarrage :

Secure Boot & bootloader : le bootloader coldwave-os de type MCUboot vérifie la signature cryptographique de l'image au démarrage (intégrité du code) avant son exécution.
Procédé de signature : les images sont signées en ECDSA-P256 / SHA-256. La clé privée de signature est conservée dans un module matériel de sécurité (HSM ; FIPS 140-2 niveau 3) hébergé dans le cloud et n'est pas extractible ; la clé publique de vérification correspondante est embarquée dans le bootloader et provisionnée en usine.
Vérification avant le swap : une nouvelle image OTA est vérifiée avant activation ; en cas de signature invalide ou absente, la mise à jour est rejetée et l'appareil revient à la dernière image valide (slots primary/secondary distincts).
Anti-rollback : la rétrogradation vers d'anciennes versions vulnérables connues est empêchée via la configuration anti-rollback du bootloader MCUboot ; le YMOD assure la monotonie des versions via la chaîne de version.

Les mises à jour sont déclenchées exclusivement via le canal backend authentifié DTLS. La clé publique de vérification du bootloader n'est pas modifiable sur le terrain par OTA ; un changement de clé exige un reconditionnement en usine (documenté et approuvé par la direction en tant que risque résiduel accepté).

5. Transport & liaison backend

La communication avec le backend Coldwave est chiffrée DTLS (mbedTLS avec le PSA Crypto / Gecko Secure Element et un générateur de nombres aléatoires matériel ; déléguée à coldwave-os).
La connexion utilise une authentification serveur par certificat : l'appareil valide le serveur backend contre une Root-CA PKI Coldwave embarquée dans le micrologiciel à la compilation.
L'appareil s'identifie par son IMEI comme identifiant d'appareil ; le rattachement à un tenant se fait au niveau applicatif via le code de rattachement propre à l'appareil (§7).
Durcissement supplémentaire par une liaison APN privée ; l'opérateur de réseau mobile ne transporte que des paquets chiffrés.
Seule une connexion sortante de l'appareil vers le backend existe. Le YMOD n'exploite aucun serveur TLS local (le service de routage local optionnel sur le port 9986 est inactif dans le build et non exposé) — voir §6.

6. Réduction de la surface d'attaque

Aucun service réseau ouvert : pas de SSH, Telnet, serveur HTTP ni broker MQTT ; l'appareil n'ouvre aucun port en écoute ni serveur TLS local. La seule surface joignable à distance est le canal backend sortant sécurisé par DTLS.
Aucune authentification/console utilisateur locale : pas de login local. La CLI de diagnostic série et le serveur de protocole UART sont les seules interfaces locales ; ce dernier est la surface d'attaque principale et est durci en conséquence (§7).
Aucun mot de passe par défaut ni identifiant modifiable par l'exploitant sur l'appareil.
Protection de débogage adossée au matériel : l'EFR32MG26 fournit un verrou de débogage via le Gecko Security Element ; les clés propres à l'appareil sont conservées, liées au matériel et non exportables, dans le keystore PSA et restent ainsi protégées. L'activation du verrou de débogage est une mesure de provisionnement lors de la fabrication/du durcissement.
Base de code réduite : il n'y a aucun maître de bus de terrain (Modbus/BACnet), aucune VM de script, aucun mux RS232/RS485 ni chemin de coupure d'alimentation/budget — la surface d'attaque est nettement plus réduite que celle d'une passerelle de bus de terrain.

7. Serveur de protocole UART — surface d'attaque principale

Le protocole UART local vers le MCU hôte est l'interface d'entrée locale la plus importante et le point focal du durcissement de sécurité. Tous les octets reçus de l'hôte sont traités comme non fiables jusqu'à validation :

Trame TLV & sceau CRC : chaque trame comprend un en-tête de 2 octets (type ≤ 0x7F + champ de longueur), une charge utile jusqu'à 511 octets et une somme de contrôle CRC-16/CCITT-FALSE (polynôme 0x1021, init 0xFFFF) sur l'en-tête et la charge utile. En cas de non-concordance du CRC, la trame est rejetée (errno=EPROTO).
Bornes de longueur strictes : un champ de longueur au-dessus du maximum est rejeté (EPROTO), un type au-dessus de 0x7F également (EINVAL) — les débordements des tampons internes sont ainsi exclus.
Aucun traitement de trames partielles : le lecteur d'octets s'interrompt en cas de lecture courte ou tronquée ; les trames incomplètes ne sont pas traitées davantage.
Validation de la charge utile dans l'analyseur : les analyseurs de commandes SET/UUID vérifient les longueurs de charge utile minimales et exactes ; les longueurs non plausibles sont rejetées avec une erreur d'argument (jamais transmises aux gestionnaires).
Analyseur isolé : la réception de trame est découplée de l'exécution des commandes ; les gestionnaires se trouvent dans un module séparé.
Tests & fuzzing : l'analyseur de trame/CRC et le décodage de la charge utile sont testés sur hôte (aller-retour, CRC/malformé/surdimensionné/tronqué rejetés, bornes de charge utile SET) et soumis au fuzzing avec des sanitizers mémoire (ASan/UBSan) via une harness libFuzzer sur le chemin de réception des trames — sans plantage.

Identité de l'appareil & code de rattachement. La clé d'appareil ED25519 publique (conservée dans le keystore PSA) est exportée via le serveur UART. Le code de rattachement = base58(SHA-256(pubkey|imei|iccid)) (tronqué aux huit premiers octets) lie cryptographiquement l'identité de l'appareil à la clé propre à l'appareil et ne peut être dérivé de l'IMEI/ICCID seuls.

Pourquoi cette surface est prioritaire. Le serveur de protocole UART est le seul chemin par lequel des données locales non fiables entrent dans l'exécution embarquée. Tout défaut transformant une trame hôte malformée en lecture/écriture hors limites, en corruption persistante ou en contournement de contrôle est traité comme la classe de défaut de sécurité de plus haute priorité.

8. Synthèse du modèle de menaces

L'analyse des menaces suit STRIDE sur un diagramme de flux de données de niveau 1 avec les quatre frontières de confiance du §3. La synthèse ci-dessous résume le catalogue de menaces ; elle décrit des mécanismes, non des détails exploitables.

ID	Surface d'attaque	Menace	Contre-mesure essentielle
T-UART	Serveur UART (B1)	Trames hôte malformées → lecture/écriture hors limites, confusion d'état	Sceau CRC-16, bornes de longueur strictes, validation de charge utile ; testé sur hôte et par fuzzing (§7)
T-BACKEND	DTLS backend (B2)	MITM DTLS / serveur backend usurpé	DTLS avec vérification du certificat serveur contre la Root-CA Coldwave embarquée ; liaison APN privée
T-OTA	OTA / bootloader (B2)	Image micrologicielle non signée / falsifiée	Vérification ECDSA-P256 avant le swap ; anti-rollback ; repli sur l'image précédente
T-MODEM	AT modem / SIM (B3)	SIM malveillante / réponses AT fabriquées → débordement du pilote, boucle de reconnexion	Plafonds de tampon de ligne dans le pilote modem ; watchdog + échelle de récupération ; contrôle de plausibilité IMEI
T-IMEI	Identité de l'appareil (B3/B4)	Usurpation d'identité (simuler un IMEI étranger)	Contrôle de plausibilité IMEI (15 chiffres) avant persistance ; code de rattachement lié à la clé d'appareil ED25519

Les détails de durcissement des dépendances déléguées (pilotes DTLS/OTA/modem de coldwave-os, libflake) sont maintenus dans leur propre chaîne de preuves IEC 62443-4-1 ; le YMOD reprend les mitigations RC-2 qui y sont validées comme hypothèse et répercute les avis amont dans son suivi des vulnérabilités.

9. Protection des données & minimisation

L'exploitation normale transmet uniquement de la télémétrie machine ainsi que des valeurs identifiant l'appareil (IMEI, ICCID, info cellule LTE) — aucune donnée à caractère personnel au sens du RGPD. L'IMEI identifie l'appareil, non une personne. Aucune donnée à caractère personnel n'est exposée sur le réseau par le module.

10. Gestion des vulnérabilités (PSIRT)

ImagineOn exploite un processus de réponse aux incidents de sécurité produit (PSIRT) aligné sur IEC 62443-4-1 (Practice 6, DM-1 … DM-5) et préparant le règlement européen sur la cyber-résilience (CRA). Merci de ne pas utiliser d'issues, pull-requests ou discussions GitHub publiques pour les sujets de sécurité.

Canal de signalement	security@coldwave.io
Signalement chiffré	PGP ; la clé/l'empreinte actuelle est fournie dans la `security.txt` sous `https://coldwave.io/.well-known/security.txt` (ou sur demande auprès du PSIRT)
Accusé de réception	sous 2 jours ouvrés
Triage & première évaluation	sous 5 jours ouvrés
Disponibilité du correctif (Critical/High, CVSS ≥ 7)	sous 90 jours
Disponibilité du correctif (Medium/Low)	sous 180 jours (regroupés dans la prochaine version mineure)
Cotation	CVSS v3.1

Utile dans un signalement : la version du micrologiciel YMOD (tag de version, p. ex. v1.0.0, ou hash de commit), la variante de modem (eg912 ou bg77) et — pour les problèmes de protocole UART — une séquence d'octets minimale (le format de corpus libFuzzer est idéal). Les signalements peuvent être rédigés en allemand ou en anglais.

Divulgation coordonnée : la divulgation est coordonnée, après disponibilité d'un correctif et un délai de déploiement raisonnable pour les intégrateurs (typiquement 30 jours). Les auteurs de signalements sont crédités sur demande ; il n'existe pas actuellement de programme de prime aux bogues rémunéré.
CRA/ENISA : pour une vulnérabilité activement exploitée, une notification à l'ENISA sous 24 heures peut être requise (obligations de signalement CRA à compter du 2026-09-11). De tels signalements sont traités en priorité sans file de triage et marqués [Security] dans le changelog.
Un défaut Critical/High dans le chemin de réception des trames du serveur de protocole UART (analyse TLV/CRC + gestionnaires) est traité comme la classe de plus haute priorité — c'est le seul chemin pour des données locales non fiables.

11. Transparence : SBOM & composants

Une SBOM CycloneDX est tenue à jour pour chaque version de micrologiciel livrée et fournie sur demande.
Pour les CVE discutées publiquement susceptibles de concerner des composants utilisés, ImagineOn fournit des déclarations VEX CycloneDX ; les avis amont de coldwave-os, libflake et coldwave-yuki-core sont répercutés dans le suivi des vulnérabilités.
Le code applicatif YMOD est entièrement rédigé par ImagineOn ; il n'y a aucun code source tiers vendored dans l'image en dehors du SDK coldwave-os.

Composant	Version	Rôle
coldwave-os (image FU)	2.2.0	RTOS, réseau, DTLS, OTA, FS, PSA
coldwave-os (bootloader)	2.2.0	Vérification d'image de type MCUboot
libflake	(via l'OS)	Couche de propriétés, IPC
coldwave-yuki-core	1.0.0	Superviseur de connectivité + récupération + qualité LTE

12. Support de sécurité & cycle de vie

ImagineOn fournit des mises à jour de sécurité conformément aux exigences du règlement européen sur la cyber-résilience. La période de support définie (Defined Support Period) est publiée séparément par produit et fixée dans le cadre de la conformité CRA ; elle couvre les révisions de micrologiciel de la même génération matérielle. Après la fin du support de sécurité, les appareils concernés doivent être remplacés ou placés en quarantaine réseau.

L'état actuel des gates de la baseline 1.0.0 (SAST 0 erreur, suite de tests hôte et tests de sécurité au vert, couverture de lignes ≥ 60 %) est mesuré par la pipeline qualité hôte ; les points de version ouverts sont clos avant la mise sur le marché.

13. Normes & cadres

Cadre	Pertinence pour le YMOD
RED 2014/53/UE + règlement délégué (UE) 2022/30	Cybersécurité des équipements radio, art. 3(3)(d)/(e)/(f)
EN 18031-1:2024	Exigences de cybersécurité pour les équipements radio connectés à Internet (auto-évaluation)
IEC 62443-4-1	Cycle de développement sécurisé (SDL), classe d'appareil RC-2
IEC 62443-4-2	Exigences techniques de sécurité pour les composants, cible SL-2 ; base du modèle de responsabilité partagée (§14)
CRA UE (règlement (UE) 2024/2847)	préparatoire ; pleinement applicable à compter du 2027-12-11, obligations de signalement à compter du 2026-09-11
EN 62368-1 · EN 50665 · famille EN 301 489 · famille EN 301 908	Sécurité des équipements, exposition RF et CEM/radio des deux variantes de modem
ETSI EN 303 645	appliquée de manière prospective (baseline IoT grand public)

Évaluation de conformité de l'équipement radio au titre de la RED via le module A (contrôle interne de la fabrication), sans intervention d'un organisme notifié. Le présent livre blanc ne formule aucune affirmation de conformité avec des normes produit spécifiques à l'application du système hôte ; le YMOD est un composant de connectivité cellulaire, et non l'appareil hôte final.

14. Responsabilité partagée

La sécurité sur le terrain est une tâche partagée (IEC 62443-4-2). Les rôles se répartissent comme suit :

Rôle	Responsabilité
Fabricant (ImagineOn)	Sécurité du micrologiciel, chaîne de signature/mise à jour, durcissement du serveur de protocole UART et du canal backend, PSIRT et correctifs de sécurité selon SLA, SBOM/VEX.
Intégrateur OEM (fabricant du MCU hôte)	Intégration sûre du module dans l'appareil hôte, utilisation correcte du protocole UART, protection physique et montage (accès de débogage), sécurité du compte de tenant Coldwave (authentification forte/MFA, moindre privilège), rattachement de l'appareil au tenant.
Propriétaire / exploitant	Protection de l'accès au portail, signalement rapide des anomalies, ne pas bloquer les mises à jour en coupant durablement le réseau.

15. Mise hors service & élimination

Les clés propres à l'appareil (clé d'appareil ED25519, ancre de confiance DTLS, clé de vérification OTA) sont conservées, liées au matériel et non exportables, dans le keystore PSA du microcontrôleur. Un effacement des données sur site par l'exploitant n'est pas prévu (aucune interface exploitant). Lors de la dépose, il est recommandé de déprovisionner l'appareil dans le portail Coldwave et — dans la mesure du possible — de le retourner à ImagineOn ; les clés sont effacées de manière sûre lors du reconditionnement en usine. Sinon, le module ou l'appareil hôte intégrant doit être éliminé correctement en tant que déchet électronique (DEEE) ; les clés sont liées au matériel et deviennent inutilisables avec sa destruction.

Numéro d'enregistrement DEEE : DE 54689668 (ImagineOn GmbH).

16. Contact & références

Signalement de sécurité / vulnérabilité : security@coldwave.io (PGP via https://coldwave.io/.well-known/security.txt)
Conformité : compliance@imagineon.de · Web : www.imagineon.de
SBOM/VEX : sur demande via l'adresse de conformité

© 2026 ImagineOn GmbH. Tous droits réservés. Le présent livre blanc décrit les mécanismes et processus de sécurité à la date de publication ; des modifications dans le cadre de la maintenance du produit demeurent réservées.