Coldwave Yukiblock CAN — Security-Whitepaper

Produkt: Coldwave Yukiblock CAN (YCAN) — LTE-M-/NB-IoT-CANopen-Gateway
Firmware: coldwave-yukiblock-can (ycan) 1.0.0
Plattform: Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault
Feldbus: CANopen (Classic CAN 2.0, über externen MCP2518FD-SPI-Controller)
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 (effektiv; intrinsisch RC-3)
Zugehörige Doku: Schwachstellen-Offenlegung: §9 (in diesem Dokument) · Asset-Owner-Sicherheitshinweise (auf Anfrage)

Über dieses Dokument. Dieses Whitepaper beschreibt die Sicherheitsarchitektur, -mechanismen und -prozesse des Coldwave Yukiblock CAN für Betreiber, Integratoren, IT-Sicherheitsverantwortliche und benannte Stellen. Es beschreibt bewusst Mechanismen und Richtlinien — keine konkreten Schwachstellen, internen Restrisiko-Register oder Infrastruktur-Details. Der zugehörige Product-Security-Incident-Response-Prozess (koordinierte Schwachstellen-Offenlegung) ist inline in §9 dieses Dokuments beschrieben: Vermutete Schwachstellen sind an security@coldwave.io zu melden (PGP-Fingerprint unter https://coldwave.io/.well-known/security.txt). ImagineOn bestätigt den Eingang innerhalb von 2 Arbeitstagen, führt Triage und Ersteinstufung innerhalb von 10 Arbeitstagen durch und stellt Fixes 15 Kalendertage (Critical, CVSS ≥ 9) bzw. 30 Kalendertage (High, CVSS ≥ 7) nach Triage bereit; Medium innerhalb von 90 Kalendertagen (gebündelt im nächsten Minor-Release), Low nach Best-Effort. Die Offenlegung erfolgt koordiniert, sobald ein Fix verfügbar ist und die betroffenen Geräte eine angemessene Ausrollzeit (typisch 30 Tage) hatten.

Reifegrad. Die hier beschriebene Firmware steht auf dem Stand 1.0.0. Beschrieben ist die Prozess- und Architektur-Garantie; einzelne Kontrollen befinden sich in der finalen Härtung vor der GA-Freigabe und sind an den entsprechenden Stellen (§4, §5, §12) transparent gekennzeichnet.

Inhalt

Zweck & Geltungsbereich
Sicherheits-Architektur im Überblick
Trust-Modell & Zonen
Software-Integrität & Updates
Transport & Backend-Anbindung
Reduktion der Angriffsfläche
CANopen-Bus-Sicherheit & Parser-Härtung
Datenschutz & Datenminimierung
Schwachstellen-Management (PSIRT)
Transparenz: SBOM & Open Source
Sicherheits-Support & Lifecycle
Normen & Rahmenwerke
Geteilte Verantwortung
Außerbetriebnahme & Entsorgung
Kontakt & Verweise

1. Zweck & Geltungsbereich

Der Coldwave Yukiblock CAN (kurz „YCAN") ist ein stationäres Industrie-IoT-Gateway auf Basis des Mikrocontrollers Silicon Labs EFR32MG26 (ARM Cortex-M33 mit Secure Vault). Es liest über einen externen MCP2518FD-SPI-Controller die Datenpunkte eines CANopen-Feldbusses (Classic CAN 2.0) aus — z. B. Temperaturen, Drehzahlen, Betriebsstunden aus Anlagen der Heizungs-, Lüftungs- und Klimatechnik oder aus kompakten Industrieaggregaten — und überträgt sie über Mobilfunk (LTE-M / NB-IoT) verschlüsselt an das Coldwave-Backend. Eine optionale, PLC-artige Script-VM (coldwave-script-vm) übernimmt die feldseitige Vorverarbeitung.

Das Gerät arbeitet ausschließlich als CANopen-Slave und ist so ausgelegt, dass es den Bus nicht destabilisiert. Es wird nach einem sicheren Entwicklungslebenszyklus gemäß IEC 62443-4-1 entwickelt; das Sicherheitsziel ist SL-2. Die intrinsische Risikoklassifikation ergibt RC-3 (LTE-M, Bootloader, mehrere Parser, OTA); die effektive Geräteklasse ist RC-2 unter der dokumentierten Annahme, dass das Gerät ausschließlich gegen das RC-3-zertifizierte Coldwave-Backend betrieben wird, das die rein operativen/lifecycle-orientierten RC-3-Kontrollen übernimmt. Die Cybersecurity-Bewertung als internet-verbundenes Funkgerät erfolgt nach EN 18031-1.

2. Sicherheits-Architektur im Überblick

Schutzziel	Maßnahme im YCAN
Integrität der Firmware	Secure Boot (EFR32MG26 Secure Vault) + MCUboot-Bootloader mit signierten Images (ECDSA-P256 / SHA-256), Versions-Monotonie
Authentizität der Updates	Zwei unabhängige Signaturprüfungen (OTA-Handler + Bootloader); Signaturschlüssel in einem cloud-gehosteten Hardware-Sicherheitsmodul (HSM; FIPS 140-2 Level 3), nicht extrahierbar
Vertraulichkeit im Transport	TLS 1.2/1.3 (mbedTLS) über LTE-M mit CA-basierter Server-Authentifizierung (CA-Provisionierung in finaler Härtung, siehe §5)
Reduktion der Angriffsfläche	Keine offenen Netzwerkdienste, keine lokale Konsole, keine Default-Passwörter, Debug per Firmware gesperrt, BLE in der CAN-Variante deaktiviert
Schlüsselablage	PSA-Crypto-Keystore, hardwaregebunden (Secure Vault), nicht exportierbar
Robustheit der Schnittstellen	Gehärtete, host-getestete und fuzz-getestete Protokoll-/Mapping-Parser (ASan/UBSan)
Bus-Disziplin	Single-TX-Pfad, Rate-Limiting, kontrollierte Bus-off-Recovery — das Gateway destabilisiert den CAN-Bus nicht selbst
Nachvollziehbarkeit	Security-Events werden ins Backend gestreamt und dort vorgehalten (keine Operator-Logs am Gerät)

3. Trust-Modell & Zonen

Das YCAN unterscheidet mehrere Vertrauenszonen (Trust Boundaries B1–B4 gemäß Bedrohungsmodell). Alle von außen empfangenen Daten gelten bis zur Validierung als nicht vertrauenswürdig.

Zone	Beteiligte	Vertrauensannahme
Coldwave-Backend (B1)	ImagineOn-Backend + Anlagen-Hersteller/Wartungsfirma via Tenant-Account	TLS-authentifizierter Zugriff auf Telemetrie, Remote-Konfiguration, Skript-Upload und OTA-Auslieferung
Mobilfunk LTE-M/NB-IoT (B1)	Mobilfunkprovider (transparent)	Trägt nur TLS-verschlüsselte Pakete; der Provider sieht die Nutzdaten nicht
CANopen-Feldbus (B2)	CANopen-Knoten der Anlage auf dem Zweidraht-Bus	Protokollbedingt (Classic CAN 2.0) nicht kryptografisch authentifiziert → kompensiert durch die physische Vertrauenszone (verplombter Schaltschrank) + OT-Segmentierung
Modem-AT-Kanal (B3)	Quectel-BG77-Modem (UART)	Modem-Antworten/URCs sind gegenüber der Treiber-Logik untrusted; Line-Buffer-Caps + Watchdog
Gehäuse / Debug (B4)	versiegeltes Gerät, gesperrte Debug-Pins	Nur über OTA und Backend-API erreichbar

Was das Backend bewirken kann (Blast-Radius). Über das Coldwave-Backend können — mit entsprechender Tenant-Berechtigung (Cloud-RBAC) — Telemetrie abgerufen, die Konfiguration (Mapping-Tabelle, CAN-Bitrate, Node-ID) gepusht, signierte Skripte hochgeladen sowie OTA-Updates ausgelöst werden; Sollwerte/Steuerbefehle werden über die gemappten, beschreibbaren Properties an die Anlage weitergereicht. Das YCAN implementiert keine eigene Sicherheitslogik und steuert die Bus-Topologie nicht aktiv (CANopen-Slave). Über den CANopen-Bus selbst ist keine persistente Applikations-Konfigurationsänderung möglich: das SDO-Server-Objekt 0x1200 ist busseitig read-only, und es existieren keine remote-schreibbaren Applikations-OD-Parameter.

4. Software-Integrität & Updates

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

Secure Boot & Bootloader: Der Secure Boot des EFR32MG26 (Secure Vault) und der MCUboot-basierte Bootloader (Teil des vendored coldwave-os) verifizieren vor Ausführung bzw. vor dem Slot-Swap die kryptographische Signatur des App-Images.
Signaturverfahren: Applikations-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, ECC_NIST_P256) und ist nicht extrahierbar; die Signatur wird durch den externen Signaturaufruf berechnet, das Schlüsselmaterial verlässt das HSM nie.
Zwei unabhängige Prüfungen: Ein neu geladenes OTA-Image wird sowohl vom coldwave-os-OTA-Handler als auch vom Bootloader geprüft. Nur gültig signierte Images werden aktiviert.
Anti-Rollback: Die YCAN-Firmware setzt Versions-Monotonie über das Firmware-Versionsfeld durch — ältere Stände werden nicht akzeptiert. Die Durchsetzung im Bootloader (MCUboot-Version-Monotonie) ist eine Eigenschaft des zertifizierten coldwave-os-Bootloaders und wird über dessen Build-Konfiguration getragen.
A/B-Image-Slots & Auto-Rollback: Updates werden in den zweiten Slot geschrieben (atomarer Swap); startet das neue Image nicht sauber, rollt das Gerät automatisch auf die zuletzt lauffähige Version zurück.
Signierter Release-Prozess: Das Signieren erfolgt automatisiert in der CI/CD-Pipeline (eine föderierte Signatur-Pipeline mit kurzlebigen Anmeldedaten), abgesichert durch PSO-signierte, geschützte Git-Tags und einen manipulationssicheren Audit-Trail jedes Sign-Vorgangs.

Nicht rotierbarer Bootloader-Schlüssel (bekanntes Restrisiko). Der Bootloader-Verify-Pubkey wird zur Werks-Provisioning-Zeit fest in den Bootloader-Bereich geschrieben und ist im Feld nicht rotierbar (kein OTA-Pfad für den Bootloader). Der HSM-Signaturschlüssel muss daher über die gesamte Produkt-Lebenszeit unverändert in Custody bleiben. Dies ist als akzeptiertes Restrisiko dokumentiert und durch operative Maßnahmen abgesichert (HSM-Schlüssel non-deletable per Key-Policy, Multi-Region-Replica, organisationsweite Policy-Leitplanken gegen Schlüssel-Löschung/-Deaktivierung, verpflichtendes Code-Owner-Review für das Schlüsselmaterial, dokumentierter Compromise-Response-Runbook).

Updates werden ausschließlich über die verschlüsselte Backend-Verbindung ausgeliefert; die Mapping-/Skript-/Konfigurationsdaten bleiben erhalten. Ein OTA-Update verändert die CANopen-Rolle des Geräts nicht.

5. Transport & Backend-Anbindung

Die Kommunikation mit dem Coldwave-Backend erfolgt TLS-1.2/1.3-verschlüsselt (mbedTLS mit PSA-Crypto-/Gecko-Secure-Element-Beschleunigung und Hardware-Zufallszahlengenerator).
Server-Authentifizierung (CA-Status, transparent): Die TLS-Server-Authentifizierung mit Hostname-Verifizierung und VERIFY_REQUIRED ist im Code-Pfad implementiert. Die CA-Zertifikats-Provisionierung an der Initialisierungs-Schnittstelle wird für die GA-Freigabe final gehärtet. Als Interim-Kompensation wird das Gerät ausschließlich ausschließlich über eine private, zugangsbeschränkte Mobilfunk-APN betrieben. Es wird ausdrücklich kein Zertifikats-Pinning behauptet; die Absicherung beruht auf CA-basierter Server-Authentifizierung.
Das Gerät identifiziert sich über seine IMEI als Geräte-ID; die Zuordnung eines Geräts zu einem Tenant erfolgt backend-seitig bei der Erstanmeldung (Provisioning über die gemeldete IMEI/Seriennummer).
Der Mobilfunkprovider transportiert ausschließlich verschlüsselte Pakete und hat keinen Einblick in die Nutzdaten.
Es besteht ausschließlich eine ausgehende Verbindung vom Gerät zum Backend; es werden keine eingehenden IP-Netzwerkdienste bereitgestellt (siehe §6).
Datenbudget: Ein Hard-Cap auf das monatliche Datenkontingent plus Budget-Tracking begrenzt Kosten- und Verbindungs-DoS durch überhöhte Sync-Frequenz.

6. Reduktion der Angriffsfläche

Keine offenen Netzwerkdienste: kein SSH, Telnet, HTTP-Server oder MQTT-Broker; das Gerät bietet keine lauschenden IP-Ports an.
Keine lokale Konfigurations-/Wartungsschnittstelle: keine Weboberfläche, kein USB-Konfig-Pfad, kein Konfigurations-Taster. Konfiguration erfolgt ausschließlich über die Coldwave-Service-Tag-Schnittstelle (Backend).
Keine Default-Passwörter und keine kundenseitig veränderbaren Zugangsdaten auf dem Gerät.
Debug gesperrt: Der JTAG-/SWD-Debug-Zugang ist im Release-Build per Firmware gesperrt (code-erzwungener Gecko-Debug-Lock über die coldwave-os-Sysconfig); ein Zurücksetzen ist nur durch vollständiges Löschen des Chips möglich.
BLE deaktiviert: Der im SoC vorhandene Bluetooth-LE-Funkteil ist in der ausgelieferten CAN-Variante per Firmware deaktiviert.
Fest verbautes Modem: Das Mobilfunk-Modul (Quectel BG77) ist auf der Platine verlötet; kein SIM-Kartenschacht, kein Wechsel des Mobilfunk-Profils vor Ort.
Skript-Sandbox: Die optionale Script-VM (coldwave-script-vm, MEDIUM-Profil) läuft in einer speicherbegrenzten Sandbox ohne direkten Hardware-/Raw-IO-Zugriff; Skripte werden ausschließlich signiert über die Cloud durch den Anlagen-Hersteller eingespielt, nicht durch den Betreiber.

7. CANopen-Bus-Sicherheit & Parser-Härtung

Der CANopen-Feldbus (B2) und die vom Backend gelieferte Mapping-Tabelle (B1) sind die beiden zentralen untrusted-Eingangsflächen. Alle vom Bus empfangenen Frames sowie jede Mapping-Konfiguration werden als nicht vertrauenswürdig behandelt:

Empfangspfad (SDO/PDO/NMT/EMCY): Der vendored CANopenNode-Stack verarbeitet die Bus-Frames; Frame-/Längen-Validierung erfolgt im Empfangspfad. Der SDO-Server ist zwar am Bus erreichbar (CANopenNode-Default), das SDO-Server-Parameter-Objekt 0x1200 ist jedoch read-only und es existieren keine remote-schreibbaren Applikations-OD-Parameter — der remote mutierbare Zustand ist damit stark begrenzt.
SDO-Client-Härtung: Das SDO-Client-Parameter-Objekt 0x1280 (COB-IDs) wurde auf read-only gesetzt, um einen COB-ID-Redirect des Clients durch einen Bus-Peer mit physischem Zugang zu unterbinden.
Mapping-Deserialisierung: Die Mapping-Tabelle ist die einzige Trust-Boundary, die vom Backend in die persistente On-Device-Konfiguration schreibt. Die TT-Stream-Deserialisierung validiert Stream-Größen (Buffer-Guards) und Per-Mapping-Limits und ist mit einem libFuzzer-Ziel sowie Buffer-Guard-Unit-Tests abgedeckt.
Bus-Disziplin (TX): Single-TX-Pfad-Disziplin, globales Rate-Limiting, SDO-Client-Throttling und kontrollierte Bus-off-Recovery mit Backoff stellen sicher, dass das Gateway den Bus nicht selbst destabilisiert.
Test & Fuzzing: Mapping-Parser und sicherheitsrelevante Pfade sind host-getestet und mit Speicher-Sanitizern (ASan/UBSan) fuzz-getestet; der CANopen-Empfangs-/Parser-Pfad bleibt Angriffsfläche und ist als noch auszuweitende Fuzz-Abdeckung dokumentiert.

Da CANopen (Classic CAN 2.0) protokollbedingt keine kryptografische Authentifizierung vorsieht, wird die Bus-Sicherheit durch die physische Vertrauenszone (verplombter Schaltschrank) und deployment-seitige OT-Segmentierung des Bussegments kompensiert — siehe §13. Störungen durch fremde CANopen-Knoten liegen außerhalb der Produktkontrolle.

8. Datenschutz & Datenminimierung

Der Regelbetrieb überträgt ausschließlich Maschinen- und Betriebsdaten der Anlage (per Mapping-Tabelle ausgewählte CANopen-Objekt-Werte, SDO/PDO-Datenpunkte) sowie Geräte-Telemetrie (LTE-Zellinfo, Statuswerte). Personenbezogene Daten im Sinne der DSGVO werden nicht verarbeitet — die IMEI identifiziert das Gerät, nicht eine Person (Risikoklassifikation K8 = 0). Eine Netz-Exposition personenbezogener Daten findet somit nicht statt.

Ein lokales Konfigurations-Backup durch den Betreiber ist nicht nötig und nicht möglich: Mapping-Tabelle, Skript, CAN-Bitrate und Node-ID werden im Backend gehalten und beim (Re-)Provisioning erneut ausgerollt. Backend-Daten löscht ImagineOn auf Anforderung des Tenants (DSGVO Art. 17; siehe Coldwave-Cloud-AVV).

9. Schwachstellen-Management (PSIRT)

ImagineOn betreibt einen Product-Security-Incident-Response-Prozess gemäß IEC 62443-4-1 (Practice 6 / DM-1..DM-5) und vorbereitend auf die EU-Cyber-Resilience-Act (CRA). Bitte melden Sie vermutete Schwachstellen nicht über öffentliche GitHub-Issues, Pull-Requests oder Diskussionen.

Kanal (PSIRT)	security@coldwave.io
Verschlüsselte Meldung	PGP-Key — Fingerprint wird unter `https://coldwave.io/.well-known/security.txt` veröffentlicht
Web-Formular	geplant: `https://coldwave.io/security/report`
Empfangsbestätigung	innerhalb von 2 Arbeitstagen
Triage & Ersteinstufung	innerhalb von 10 Arbeitstagen
Fix-Bereitstellung (Critical, CVSS ≥ 9)	15 Kalendertage nach Triage
Fix-Bereitstellung (High, CVSS ≥ 7)	30 Kalendertage nach Triage
Fix-Bereitstellung (Medium)	90 Kalendertage (gebündelt im nächsten Minor-Release)
Fix-Bereitstellung (Low)	Best-Effort / gebündelt
Bewertung	CVSS v3.1 mit OT-Kontext-Gewichtung

Coordinated Disclosure: Offenlegung erfolgt koordiniert, nach Verfügbarkeit eines Fixes und einer angemessenen Ausrollzeit für betroffene Geräte (typisch 30 Tage). Melder werden auf Wunsch namentlich genannt; es besteht derzeit kein bezahltes Bug-Bounty-Programm.
Delegierte/vendored Abhängigkeiten: Defekte in coldwave-os (TLS/OTA/MCUboot/PSA-Keystore), libflake, coldwave-script-vm oder CANopenNode werden beim jeweiligen Upstream/PSIRT verfolgt; die YCAN-Firmware spiegelt Fixes über die Versions-Pins und führt ein CVE-Tracking mit VEX-Klassifikation.
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). Meldungen mit dem Betreff-Kennzeichen [ACTIVE EXPLOIT] umgehen die Triage-Warteschlange.

10. Transparenz: SBOM & Open Source

Für jede ausgelieferte Firmware-Version wird eine CycloneDX-SBOM (Software Bill of Materials) geführt und auf Anfrage bereitgestellt.
Zu öffentlich diskutierten CVEs, die verwendete/delegierte Komponenten betreffen könnten, stellt ImagineOn auf Anfrage CycloneDX-VEX-Statements (Vulnerability Exploitability eXchange) bereit — inklusive begründeter Nicht-Anwendbarkeit (z. B. ein CANopenNode-Defekt, der über die YCAN-Build-Konfiguration nicht auslösbar ist).
Die verwendeten Open-Source-/vendored-Komponenten samt Lizenztexten sind in der Produkt-LICENSE.md aufgeführt (u. a. mbedTLS, FreeRTOS, MCUboot, CANopenNode, MCP2518FD-Treiber).

11. Sicherheits-Support & Lifecycle

ImagineOn stellt sicherheitsrelevante Firmware-Updates 10 Jahre ab dem ersten Inverkehrbringen bereit. Das Ende der Sicherheits-Update-Versorgung pro Hardware-Revision wird in der CHANGELOG.md und im Coldwave-Cloud-Portal dokumentiert; der Zeitraum übertrifft das CRA-Mindestmaß. Nach dem Support-Ende (End-of-Security-Support) sollten betroffene Geräte ersetzt oder in eine Netz-Quarantäne überführt werden.

Updates kommen vollautomatisch über die Coldwave-Cloud — es ist keine Aktion des Asset Owners nötig, um Sicherheitspatches zu erhalten. Voraussetzung ist eine funktionierende Mobilfunkverbindung; längere Offline-Phasen bedeuten kein akutes Sicherheitsproblem, führen aber dazu, dass Sicherheits-Patches verpasst werden.

12. Normen & Rahmenwerke

Rahmenwerk	Bezug für das YCAN
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, Modul A)
ETSI EN 303 645	Baseline-Anforderungen für Consumer-IoT — vorausschauend angewandt
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 (§13)
EU-CRA (VO (EU) 2024/2847)	vorbereitend; volle Anwendbarkeit ab 2027-12-11, Meldepflichten ab 2026-09-11

Konformitätsbewertung der Funkanlage nach RED über Modul A (interne Fertigungskontrolle), ohne Einbindung einer benannten Stelle. Die EN-18031-1-Selbstbewertung sowie die EU-Konformitätserklärung (DoC) befinden sich im Stadium der finalen HW-Nachweise (EMV/RF/Safety) und der Schließung offener Cybersecurity-Findings; sie werden auf Anfrage bereitgestellt (compliance@imagineon.de). Dieses Whitepaper trifft keine Aussage zur Konformität mit anlagenspezifischen Produktnormen der jeweiligen Applikation; das YCAN ist eine Funk-Anbindungskomponente, nicht die Anlagensteuerung.

13. 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, PSIRT und Sicherheits-Patches gemäß SLA, SBOM/VEX, Härtung der Geräte- und Backend-Schnittstellen.
Integrator / Anlagen-Hersteller	Sicherheit des Coldwave-Tenant-Accounts (starke Authentifizierung / MFA, Least-Privilege-Rollen), sichere Einbindung in die Anlage, Zuordnung von Gerät zu Tenant, Verantwortung für hochgeladene Skripte und Mapping-Tabellen.
Asset Owner / Betreiber	Physischer Schutz (verplombter Schaltschrank, OT-seitige CAN-Bus-Segmentierung, stabiler Antennensitz), Schutz des Portal-Zugangs, zeitnahe Meldung von Auffälligkeiten, Updates nicht dauerhaft durch Netzabschaltung blockieren.

14. Außerbetriebnahme & Entsorgung

Die geräteindividuellen Schlüssel liegen hardwaregebunden im PSA-Keystore (Secure Vault) des Mikrocontrollers. Eine On-Site-Datenlöschung durch den Betreiber ist nicht vorgesehen (kein Operator-Interface). Bei Deinstallation wird empfohlen:

das Gerät im Coldwave-Portal zu deprovisionieren (über den Anlagen-Hersteller) und erst danach stromfrei zu schalten;
das Gerät — wo möglich — an ImagineOn zurückzugeben; im Werks-Refurbishment werden die Provisioning-Schlüssel sicher gelöscht;
andernfalls das Gerät als Elektroaltgerät (WEEE) fachgerecht zu entsorgen. Die Schlüssel sind an die Hardware gebunden und werden mit deren Zerstörung unbrauchbar. Das Mobilfunk-Modul ist verlötet — keine separate SIM-Behandlung nötig.

WEEE-Registrierungsnummer: DE 54689668 (ImagineOn GmbH).

15. Kontakt & Verweise

Sicherheits-/Schwachstellen-Meldung: security@coldwave.io (PGP: https://coldwave.io/.well-known/security.txt)
Konformität / EU-Konformitätserklärung (DoC): compliance@imagineon.de
Coordinated-Disclosure-Policy & SLAs: inline in §9 dieses Dokuments · öffentlich unter https://coldwave.io/.well-known/security.txt
Hersteller: ImagineOn GmbH, Neusser Str. 27–29, 50670 Köln — www.imagineon.de

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

Coldwave Yukiblock CAN — 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 Yukiblock CAN (YCAN) — LTE-M / NB-IoT CANopen gateway
Firmware: coldwave-yukiblock-can (ycan) 1.0.0
Platform: Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault
Field bus: CANopen (Classic CAN 2.0, via external MCP2518FD SPI controller)
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 (effective; intrinsic RC-3)
Related document: Vulnerability disclosure: §9 (in this document) · Asset Owner security guidance (on request)

About this document. This whitepaper describes the security architecture, mechanisms and processes of the Coldwave Yukiblock CAN for operators, integrators, IT-security officers and notified bodies. It deliberately describes mechanisms and policies — not specific vulnerabilities, internal residual-risk registers or infrastructure details. The associated product-security incident-response process (coordinated vulnerability disclosure) is described inline in §9 of this document: report suspected vulnerabilities to security@coldwave.io (PGP fingerprint at https://coldwave.io/.well-known/security.txt). ImagineOn acknowledges receipt within 2 business days, performs triage and initial severity within 10 business days, and provides fixes 15 calendar days (Critical, CVSS ≥ 9) or 30 calendar days (High, CVSS ≥ 7) after triage; Medium within 90 calendar days (batched into the next minor release), Low on a best-effort basis. Disclosure is coordinated once a fix is available and affected devices have had a reasonable rollout window (typically 30 days).

Maturity. The firmware described here is at revision 1.0.0. What is described is the process and architecture guarantee; individual controls are in final hardening before GA and are marked transparently at the relevant points (§4, §5, §12).

Contents

Purpose & scope
Security architecture at a glance
Trust model & zones
Software integrity & updates
Transport & backend connection
Attack-surface reduction
CANopen bus security & parser hardening
Data protection & data minimisation
Vulnerability management (PSIRT)
Transparency: SBOM & open source
Security support & lifecycle
Standards & frameworks
Shared responsibility
Decommissioning & disposal
Contact & references

1. Purpose & scope

The Coldwave Yukiblock CAN (short: “YCAN”) is a stationary industrial-IoT gateway built on the Silicon Labs EFR32MG26 microcontroller (ARM Cortex-M33 with Secure Vault). Through an external MCP2518FD SPI controller it reads the data points of a CANopen field bus (Classic CAN 2.0) — e.g. temperatures, speeds, operating hours from heating, ventilation and air-conditioning plants or from compact industrial units — and transmits them, encrypted, to the Coldwave backend over cellular (LTE-M / NB-IoT). An optional PLC-style script VM (coldwave-script-vm) performs field-side pre-processing.

The device operates exclusively as a CANopen slave and is designed not to destabilise the bus. It is developed following a secure development lifecycle per IEC 62443-4-1; the security target is SL-2. The intrinsic risk classification yields RC-3 (LTE-M, bootloader, multiple parsers, OTA); the effective device class is RC-2 under the documented assumption that the device is operated exclusively against the RC-3-certified Coldwave backend, which assumes the purely operational / lifecycle-oriented RC-3 controls. Its cybersecurity assessment as internet-connected radio equipment follows EN 18031-1.

2. Security architecture at a glance

Objective	Measure in the YCAN
Firmware integrity	Secure Boot (EFR32MG26 Secure Vault) + MCUboot bootloader with signed images (ECDSA-P256 / SHA-256), version monotonicity
Update authenticity	Two independent signature checks (OTA handler + bootloader); signing key held in a cloud-hosted hardware security module (HSM; FIPS 140-2 Level 3), non-extractable
Transport confidentiality	TLS 1.2/1.3 (mbedTLS) over LTE-M with CA-based server authentication (CA provisioning in final hardening, see §5)
Attack-surface reduction	No open network services, no local console, no default passwords, debug locked by firmware, BLE disabled in the CAN variant
Key storage	PSA Crypto keystore, hardware-bound (Secure Vault), non-exportable
Interface robustness	Hardened, host-tested and fuzz-tested protocol / mapping parsers (ASan/UBSan)
Bus discipline	Single-TX path, rate limiting, controlled bus-off recovery — the gateway does not destabilise the CAN bus itself
Traceability	Security events are streamed to and retained in the backend (no operator logs on the device)

3. Trust model & zones

The YCAN distinguishes several trust zones (trust boundaries B1–B4 per the threat model). All externally received data is treated as untrusted until validated.

Zone	Parties	Trust assumption
Coldwave backend (B1)	ImagineOn backend + plant manufacturer / maintenance company via tenant account	TLS-authenticated access to telemetry, remote configuration, script upload and OTA delivery
Cellular LTE-M/NB-IoT (B1)	Mobile network operator (transparent)	Carries only TLS-encrypted packets; the operator cannot see the payload
CANopen field bus (B2)	The plant's CANopen nodes on the two-wire bus	Not cryptographically authenticated by protocol design (Classic CAN 2.0) → compensated by the physical trust zone (sealed control cabinet) + OT segmentation
Modem AT channel (B3)	Quectel BG77 modem (UART)	Modem responses / URCs are untrusted to the driver logic; line-buffer caps + watchdog
Enclosure / debug (B4)	sealed device, locked debug pins	Reachable only via OTA and the backend API

What the backend can do (blast radius). Through the Coldwave backend — with appropriate tenant permission (cloud RBAC) — telemetry can be retrieved, configuration (mapping table, CAN bitrate, node-ID) pushed, signed scripts uploaded and OTA updates triggered; setpoints / control commands are relayed to the plant via the mapped, writable properties. The YCAN implements no safety logic of its own and does not actively drive the bus topology (CANopen slave). Over the CANopen bus itself, no persistent application-configuration change is possible: the SDO server object 0x1200 is read-only on the bus, and there are no remote-writable application OD parameters.

4. Software integrity & updates

Firmware integrity is protected across the entire boot chain:

Secure Boot & bootloader: the EFR32MG26 Secure Boot (Secure Vault) and the MCUboot-based bootloader (part of the vendored coldwave-os) verify the cryptographic signature of the app image before execution / before the slot swap.
Signature scheme: application 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, ECC_NIST_P256) and is non-extractable; the signature is computed externally via the remote signing operation and the key material never leaves the HSM.
Two independent checks: a newly loaded OTA image is verified by both the coldwave-os OTA handler and the bootloader. Only validly signed images are activated.
Anti-rollback: the YCAN firmware enforces version monotonicity via the firmware version field — older builds are not accepted. Enforcement in the bootloader (MCUboot version monotonicity) is a property of the certified coldwave-os bootloader and is carried by its build configuration.
A/B image slots & auto-rollback: updates are written to the second slot (atomic swap); if the new image fails to start cleanly, the device automatically rolls back to the last working version.
Signed release process: signing is automated in the CI/CD pipeline (a federated, short-lived-credential signing pipeline), protected by PSO-signed, protected Git tags and a tamper-evident audit trail of every sign operation.

Non-rotatable bootloader key (known residual risk). The bootloader verify pubkey is written into the bootloader region at factory-provisioning time and is not field-rotatable (no OTA path for the bootloader). The HSM signing key must therefore remain unchanged in custody for the entire product lifetime. This is documented as accepted residual risk and mitigated by operational controls (HSM key non-deletable via key policy, multi-region replica, organization-level policy guardrails against key deletion/disabling, mandatory code-owner review on the key material, a documented compromise-response runbook).

Updates are delivered exclusively over the encrypted backend connection; the mapping / script / configuration data are preserved. An OTA update does not change the device's CANopen role.

5. Transport & backend connection

Communication with the Coldwave backend is TLS 1.2/1.3-encrypted (mbedTLS with PSA Crypto / Gecko Secure Element acceleration and a hardware random-number generator).
Server authentication (CA status, stated transparently): TLS server authentication with hostname verification and VERIFY_REQUIRED is implemented in the code path. The CA-certificate provisioning at the initialisation entry point is being finalised (hardened) for GA. As an interim compensation the device is operated exclusively over a private, access-controlled cellular APN. Certificate pinning is expressly not claimed; protection rests on CA-based server authentication.
The device identifies itself via its IMEI as the device ID; a device is bound to a tenant backend-side at first registration (provisioning via the reported IMEI / serial number).
The mobile network operator transports only encrypted packets and has no visibility into the payload.
Only an outbound connection from device to backend exists; no inbound IP network services are offered (see §6).
Data budget: a hard cap on the monthly data quota plus budget tracking limits cost / connectivity DoS from an excessive sync frequency.

6. Attack-surface reduction

No open network services: no SSH, Telnet, HTTP server or MQTT broker; the device offers no listening IP ports.
No local configuration / maintenance interface: no web UI, no USB config path, no configuration button. Configuration is performed exclusively via the Coldwave service-tag interface (backend).
No default passwords and no operator-changeable credentials on the device.
Debug locked: JTAG/SWD debug access is locked by firmware in release builds (code-enforced Gecko debug-lock via the coldwave-os sysconfig); resetting it requires a full chip erase.
BLE disabled: the Bluetooth-LE radio present in the SoC is disabled by firmware in the shipped CAN variant.
Soldered modem: the cellular module (Quectel BG77) is soldered to the board; no SIM slot, no on-site change of the cellular profile.
Script sandbox: the optional script VM (coldwave-script-vm, MEDIUM profile) runs in a memory-capped sandbox without direct hardware / raw-IO access; scripts are uploaded signed via the cloud by the plant manufacturer only, not by the operator.

7. CANopen bus security & parser hardening

The CANopen field bus (B2) and the backend-delivered mapping table (B1) are the two central untrusted input surfaces. All frames received from the bus and every mapping configuration are treated as untrusted:

Receive path (SDO/PDO/NMT/EMCY): the vendored CANopenNode stack processes the bus frames; frame / length validation is performed in the receive path. The SDO server is reachable on the bus (CANopenNode default), but the SDO server parameter object 0x1200 is read-only and there are no remote-writable application OD parameters — the remotely mutable state is thus strongly bounded.
SDO client hardening: the SDO client parameter object 0x1280 (COB-IDs) was set read-only to prevent a COB-ID redirect of the client by a bus peer with physical access.
Mapping deserialization: the mapping table is the only trust boundary that writes from the backend into persistent on-device configuration. The TT-stream deserialization validates stream sizes (buffer guards) and per-mapping limits and is covered by a libFuzzer target and buffer-guard unit tests.
Bus discipline (TX): single-TX-path discipline, global rate limiting, SDO-client throttling and controlled bus-off recovery with backoff ensure the gateway does not destabilise the bus itself.
Testing & fuzzing: the mapping parser and security-relevant paths are host-tested and fuzz-tested with memory sanitizers (ASan/UBSan); the CANopen receive / parser path remains attack surface and is documented as fuzz coverage still to be extended.

Since CANopen (Classic CAN 2.0) provides no cryptographic authentication by protocol design, bus security is compensated by the physical trust zone (sealed control cabinet) and deployment-side OT segmentation of the bus segment — see §13. Disturbances caused by foreign CANopen nodes are outside product control.

8. Data protection & data minimisation

Normal operation transmits only machine and operating data of the plant (mapping-selected CANopen object values, SDO/PDO data points) plus device telemetry (LTE cell info, status values). No personal data within the meaning of the GDPR is processed — the IMEI identifies the device, not a person (risk-classification criterion K8 = 0). No personal data is therefore exposed over the network.

A local configuration backup by the operator is neither necessary nor possible: mapping table, script, CAN bitrate and node-ID are held in the backend and re-deployed on (re-)provisioning. ImagineOn deletes backend data on the tenant's request (GDPR Art. 17; see the Coldwave Cloud data-processing agreement).

9. Vulnerability management (PSIRT)

ImagineOn operates a product-security incident-response process per IEC 62443-4-1 (Practice 6 / DM-1..DM-5) and preparing for the EU Cyber Resilience Act (CRA). Please do not report suspected vulnerabilities via public GitHub issues, pull requests or discussions.

Channel (PSIRT)	security@coldwave.io
Encrypted report	PGP key — fingerprint to be published at `https://coldwave.io/.well-known/security.txt`
Web form	planned: `https://coldwave.io/security/report`
Acknowledgement	within 2 business days
Triage & initial severity	within 10 business days
Fix availability (Critical, CVSS ≥ 9)	15 calendar days after triage
Fix availability (High, CVSS ≥ 7)	30 calendar days after triage
Fix availability (Medium)	90 calendar days (batched into the next minor release)
Fix availability (Low)	best effort / batched
Scoring	CVSS v3.1 with OT-context weighting

Coordinated disclosure: disclosure is coordinated, after a fix is available and affected devices have had a reasonable rollout window (typically 30 days). Reporters are credited by name on request; there is currently no paid bug-bounty programme.
Delegated / vendored dependencies: defects in coldwave-os (TLS/OTA/MCUboot/PSA keystore), libflake, coldwave-script-vm or CANopenNode are tracked with the respective upstream / PSIRT; the YCAN firmware mirrors fixes via the version pins and maintains CVE tracking with a VEX classification.
CRA/ENISA: for an actively exploited vulnerability, notification to ENISA within 24 hours may be required (CRA; reporting obligations from 2026-09-11). Reports flagged [ACTIVE EXPLOIT] in the subject bypass the triage queue.

10. Transparency: SBOM & open source

A CycloneDX SBOM (software bill of materials) is maintained for every shipped firmware version and provided on request.
For publicly discussed CVEs that might affect components used / delegated, ImagineOn provides CycloneDX VEX statements (Vulnerability Exploitability eXchange) on request — including reasoned non-applicability (e.g. a CANopenNode defect not triggerable through the YCAN build configuration).
The open-source / vendored components used, together with their license texts, are listed in the product LICENSE.md (incl. mbedTLS, FreeRTOS, MCUboot, CANopenNode, MCP2518FD driver).

11. Security support & lifecycle

ImagineOn provides security-relevant firmware updates for 10 years from first placing on the market. The end of security-update provision per hardware revision is documented in the CHANGELOG.md and the Coldwave Cloud portal; the period exceeds the CRA minimum. After end-of-security-support, affected devices should be replaced or placed into network quarantine.

Updates arrive fully automatically over the Coldwave Cloud — no action by the asset owner is required to receive security patches. The only prerequisite is a working cellular connection; longer offline periods are not an acute security problem but mean security patches are missed.

12. Standards & frameworks

Framework	Relevance for the YCAN
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, Module A)
ETSI EN 303 645	Baseline requirements for consumer IoT — applied on a forward-looking basis
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 (§13)
EU CRA (Reg. (EU) 2024/2847)	preparatory; fully applicable from 2027-12-11, reporting obligations from 2026-09-11

Radio-equipment conformity assessment under RED via Module A (internal production control), without involvement of a notified body. The EN 18031-1 self-assessment and the EU Declaration of Conformity (DoC) are at the stage of finalising the HW evidence (EMC/RF/safety) and closing open cybersecurity findings; they are provided on request (compliance@imagineon.de). This whitepaper makes no claim of conformity with application-specific product standards of the respective installation; the YCAN is a radio-connectivity component, not the plant controller.

13. 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, PSIRT and security patches per SLA, SBOM/VEX, hardening of the device and backend interfaces.
Integrator / plant manufacturer	Security of the Coldwave tenant account (strong authentication / MFA, least-privilege roles), secure integration into the installation, binding device to tenant, responsibility for uploaded scripts and mapping tables.
Asset owner / operator	Physical protection (sealed control cabinet, OT-side CAN-bus segmentation, stable antenna seating), protection of portal access, prompt reporting of anomalies, not blocking updates by permanently disconnecting the network.

14. Decommissioning & disposal

The device-individual keys are held hardware-bound in the microcontroller's PSA keystore (Secure Vault). 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 (via the plant manufacturer) and only then power it down;
where possible, return the device to ImagineOn; the provisioning keys are securely erased during factory refurbishment;
otherwise dispose of the device properly as electronic waste (WEEE). The keys are bound to the hardware and become unusable with its destruction. The cellular module is soldered — no separate SIM handling is needed.

WEEE registration number: DE 54689668 (ImagineOn GmbH).

15. Contact & references

Security / vulnerability reporting: security@coldwave.io (PGP: https://coldwave.io/.well-known/security.txt)
Conformity / EU Declaration of Conformity (DoC): compliance@imagineon.de
Coordinated-disclosure policy & SLAs: inline in §9 of this document · published at https://coldwave.io/.well-known/security.txt
Manufacturer: ImagineOn GmbH, Neusser Str. 27–29, 50670 Cologne — www.imagineon.de

© 2026 ImagineOn GmbH. All rights reserved. This whitepaper describes security mechanisms and processes as of the date of publication for firmware 1.0.0; changes in the course of product maintenance are reserved.

Coldwave Yukiblock CAN — 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 Yukiblock CAN (YCAN) — passerelle CANopen LTE-M / NB-IoT
Micrologiciel: coldwave-yukiblock-can (ycan) 1.0.0
Plateforme: Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault
Bus de terrain: CANopen (Classic CAN 2.0, via contrôleur SPI MCP2518FD externe)
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 (effective ; intrinsèque RC-3)
Document associé: Divulgation des vulnérabilités : §9 (dans ce document) · Consignes de sécurité pour l'exploitant (sur demande)

À propos de ce document. Le présent livre blanc décrit l'architecture, les mécanismes et les processus de sécurité du Coldwave Yukiblock CAN à l'intention des exploitants, intégrateurs, 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. Le processus de réponse aux incidents de sécurité produit associé (divulgation coordonnée des vulnérabilités) est décrit en ligne au §9 du présent document : signalez les vulnérabilités suspectées à security@coldwave.io (empreinte PGP sur https://coldwave.io/.well-known/security.txt). ImagineOn accuse réception sous 2 jours ouvrés, réalise le triage et la première évaluation sous 10 jours ouvrés et fournit les correctifs 15 jours calendaires (Critical, CVSS ≥ 9) ou 30 jours calendaires (High, CVSS ≥ 7) après triage ; Medium sous 90 jours calendaires (regroupés dans la prochaine version mineure), Low au meilleur effort. La divulgation est coordonnée dès qu'un correctif est disponible et que les appareils concernés ont bénéficié d'un délai de déploiement raisonnable (typiquement 30 jours).

Maturité. Le micrologiciel décrit ici est à la révision 1.0.0. Ce qui est décrit est la garantie de processus et d'architecture ; certaines mesures sont en phase de durcissement final avant la mise à disposition générale et sont signalées de façon transparente aux endroits pertinents (§4, §5, §12).

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
Sécurité du bus CANopen & durcissement des analyseurs
Protection des données & minimisation
Gestion des vulnérabilités (PSIRT)
Transparence : SBOM & open source
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 Yukiblock CAN (en abrégé « YCAN ») est une passerelle IoT industrielle fixe reposant sur le microcontrôleur Silicon Labs EFR32MG26 (ARM Cortex-M33 avec Secure Vault). Via un contrôleur SPI MCP2518FD externe, elle lit les points de données d'un bus de terrain CANopen (Classic CAN 2.0) — p. ex. températures, vitesses de rotation, heures de fonctionnement d'installations de chauffage, ventilation et climatisation ou d'agrégats industriels compacts — et les transmet, chiffrés, au backend Coldwave via une liaison cellulaire (LTE-M / NB-IoT). Une Script-VM optionnelle de type API (coldwave-script-vm) assure le prétraitement côté terrain.

L'appareil fonctionne exclusivement comme esclave CANopen et est conçu pour ne pas déstabiliser le bus. Il est développé selon un cycle de développement sécurisé conforme à IEC 62443-4-1 ; l'objectif de sécurité est SL-2. La classification de risque intrinsèque donne RC-3 (LTE-M, bootloader, plusieurs analyseurs, OTA) ; la classe d'appareil effective est RC-2 sous l'hypothèse documentée que l'appareil est exploité exclusivement contre le backend Coldwave certifié RC-3, lequel assume les contrôles RC-3 purement opérationnels / liés au cycle de vie. 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 YCAN
Intégrité du micrologiciel	Secure Boot (EFR32MG26 Secure Vault) + bootloader MCUboot avec images signées (ECDSA-P256 / SHA-256), monotonie des versions
Authenticité des mises à jour	Deux vérifications de signature indépendantes (gestionnaire OTA + bootloader) ; 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	TLS 1.2/1.3 (mbedTLS) sur LTE-M avec authentification serveur basée sur CA (provisionnement CA en durcissement final, voir §5)
Réduction de la surface d'attaque	Aucun service réseau ouvert, aucune console locale, aucun mot de passe par défaut, débogage verrouillé par le micrologiciel, BLE désactivé dans la variante CAN
Stockage des clés	Keystore PSA Crypto, lié au matériel (Secure Vault), non exportable
Robustesse des interfaces	Analyseurs de protocole / de mapping durcis, testés sur hôte et par fuzzing (ASan/UBSan)
Discipline de bus	Chemin TX unique, limitation de débit, reprise bus-off contrôlée — la passerelle ne déstabilise pas elle-même le bus CAN
Traçabilité	Les événements de sécurité sont transmis au backend et y sont conservés (aucun journal exploitant sur l'appareil)

3. Modèle de confiance & zones

Le YCAN distingue plusieurs zones de confiance (frontières de confiance B1–B4 selon le modèle de menaces). Toutes les données reçues de l'extérieur sont considérées comme non fiables jusqu'à validation.

Zone	Parties	Hypothèse de confiance
Backend Coldwave (B1)	Backend ImagineOn + fabricant d'installation / société de maintenance via compte de tenant	Accès authentifié TLS à la télémétrie, à la configuration à distance, au téléversement de scripts et à la distribution OTA
Cellulaire LTE-M/NB-IoT (B1)	Opérateur de réseau mobile (transparent)	Ne transporte que des paquets chiffrés TLS ; l'opérateur ne voit pas les données utiles
Bus de terrain CANopen (B2)	Nœuds CANopen de l'installation sur le bus deux fils	Non authentifié cryptographiquement par conception du protocole (Classic CAN 2.0) → compensé par la zone de confiance physique (armoire plombée) + segmentation OT
Canal AT du modem (B3)	Modem Quectel BG77 (UART)	Les réponses / URC du modem sont non fiables vis-à-vis de la logique du pilote ; plafonds de tampon de ligne + chien de garde
Boîtier / débogage (B4)	appareil scellé, broches de débogage verrouillées	Accessible uniquement via OTA et l'API backend

Ce que le backend peut faire (rayon d'impact). Via le backend Coldwave — avec l'autorisation de tenant appropriée (RBAC cloud) — la télémétrie peut être récupérée, la configuration (table de mapping, débit CAN, node-ID) poussée, des scripts signés téléversés et des mises à jour OTA déclenchées ; les consignes / commandes sont relayées à l'installation via les propriétés mappées et inscriptibles. Le YCAN n'implémente aucune logique de sécurité propre et ne pilote pas activement la topologie du bus (esclave CANopen). Via le bus CANopen lui-même, aucune modification de configuration applicative persistante n'est possible : l'objet serveur SDO 0x1200 est en lecture seule côté bus, et il n'existe aucun paramètre OD applicatif inscriptible à distance.

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 Secure Boot de l'EFR32MG26 (Secure Vault) et le bootloader basé sur MCUboot (partie du coldwave-os intégré) vérifient la signature cryptographique de l'image applicative avant exécution / avant l'échange de slot.
Procédé de signature : les images applicatives 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, ECC_NIST_P256) hébergé dans le cloud et n'est pas extractible ; la signature est calculée en externe via l'opération de signature distante et le matériel de clé ne quitte jamais le HSM.
Deux vérifications indépendantes : une nouvelle image OTA est vérifiée à la fois par le gestionnaire OTA de coldwave-os et par le bootloader. Seules les images valablement signées sont activées.
Anti-rollback : le micrologiciel YCAN impose la monotonie des versions via le champ de version du micrologiciel — les versions antérieures ne sont pas acceptées. L'application dans le bootloader (monotonie de version MCUboot) est une propriété du bootloader coldwave-os certifié et est portée par sa configuration de build.
Banques d'image A/B & retour automatique : les mises à jour sont écrites dans le second slot (échange atomique) ; si la nouvelle image ne démarre pas correctement, l'appareil revient automatiquement à la dernière version fonctionnelle.
Processus de release signé : la signature est automatisée dans la chaîne CI/CD (un pipeline de signature fédéré à identifiants éphémères), protégée par des tags Git signés par le PSO et protégés, ainsi qu'une piste d'audit infalsifiable de chaque opération de signature.

Clé de bootloader non rotative (risque résiduel connu). La clé publique de vérification du bootloader est écrite dans la zone du bootloader lors du provisionnement en usine et n'est pas rotative sur le terrain (aucun chemin OTA pour le bootloader). La clé de signature du HSM doit donc rester inchangée sous garde pendant toute la durée de vie du produit. Ceci est documenté comme risque résiduel accepté et atténué par des mesures opérationnelles (clé HSM non supprimable par la politique de clé, réplique multi-régions, des garde-fous de politique au niveau de l'organisation contre la suppression/désactivation de clé, revue obligatoire par les propriétaires du code sur le matériel de clé, runbook de réponse à la compromission documenté).

Les mises à jour sont exclusivement distribuées via la liaison backend chiffrée ; les données de mapping / script / configuration sont conservées. Une mise à jour OTA ne modifie pas le rôle CANopen de l'appareil.

5. Transport & liaison backend

La communication avec le backend Coldwave est chiffrée TLS 1.2/1.3 (mbedTLS avec accélération PSA Crypto / Gecko Secure Element et un générateur de nombres aléatoires matériel).
Authentification serveur (état CA, indiqué en toute transparence) : l'authentification serveur TLS avec vérification du nom d'hôte et VERIFY_REQUIRED est implémentée dans le chemin de code. Le provisionnement du certificat CA au point d'entrée d'initialisation est en cours de durcissement final pour la mise à disposition générale. À titre de compensation intérimaire, l'appareil est exploité exclusivement via un APN cellulaire privé à accès restreint. L'épinglage de certificat n'est expressément pas revendiqué ; la protection repose sur une authentification serveur basée sur CA.
L'appareil s'identifie par son IMEI comme identifiant d'appareil ; un appareil est rattaché à un tenant côté backend lors du premier enregistrement (provisionnement via l'IMEI / le numéro de série signalé).
L'opérateur de réseau mobile ne transporte que des paquets chiffrés et n'a aucune visibilité sur les données utiles.
Seule une connexion sortante de l'appareil vers le backend existe ; aucun service réseau IP entrant n'est proposé (voir §6).
Budget de données : un plafond strict sur le quota mensuel de données plus un suivi de budget limitent le DoS de coût / de connectivité dû à une fréquence de synchronisation excessive.

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 IP en écoute.
Aucune interface locale de configuration / maintenance : pas d'interface web, pas de chemin de configuration USB, pas de bouton de configuration. La configuration s'effectue exclusivement via l'interface de service-tag Coldwave (backend).
Aucun mot de passe par défaut ni identifiant modifiable par l'exploitant sur l'appareil.
Débogage verrouillé : l'accès de débogage JTAG/SWD est verrouillé par le micrologiciel dans les builds de release (Gecko debug-lock imposé par le code via la sysconfig coldwave-os) ; sa réinitialisation exige un effacement complet de la puce.
BLE désactivé : la partie radio Bluetooth-LE présente dans le SoC est désactivée par le micrologiciel dans la variante CAN livrée.
Modem soudé : le module cellulaire (Quectel BG77) est soudé sur la carte ; pas d'emplacement SIM, pas de changement du profil cellulaire sur site.
Bac à sable de script : la Script-VM optionnelle (coldwave-script-vm, profil MEDIUM) s'exécute dans un bac à sable à mémoire limitée, sans accès matériel / raw-IO direct ; les scripts sont téléversés signés via le cloud par le fabricant d'installation uniquement, non par l'exploitant.

7. Sécurité du bus CANopen & durcissement des analyseurs

Le bus de terrain CANopen (B2) et la table de mapping fournie par le backend (B1) sont les deux surfaces d'entrée non fiables centrales. Toutes les trames reçues du bus et chaque configuration de mapping sont traitées comme non fiables :

Chemin de réception (SDO/PDO/NMT/EMCY) : la pile CANopenNode intégrée traite les trames du bus ; la validation de trame / de longueur est effectuée dans le chemin de réception. Le serveur SDO est accessible sur le bus (défaut CANopenNode), mais l'objet paramètre du serveur SDO 0x1200 est en lecture seule et il n'existe aucun paramètre OD applicatif inscriptible à distance — l'état mutable à distance est ainsi fortement borné.
Durcissement du client SDO : l'objet paramètre du client SDO 0x1280 (COB-ID) a été mis en lecture seule pour empêcher une redirection de COB-ID du client par un pair du bus disposant d'un accès physique.
Désérialisation du mapping : la table de mapping est la seule frontière de confiance qui écrit depuis le backend dans la configuration persistante embarquée. La désérialisation TT-stream valide les tailles de flux (gardes de tampon) et les limites par mapping et est couverte par une cible libFuzzer et des tests unitaires de gardes de tampon.
Discipline de bus (TX) : la discipline de chemin TX unique, la limitation de débit globale, l'étranglement du client SDO et la reprise bus-off contrôlée avec backoff garantissent que la passerelle ne déstabilise pas elle-même le bus.
Tests & fuzzing : l'analyseur de mapping et les chemins relatifs à la sécurité sont testés sur hôte et soumis au fuzzing avec des sanitizers mémoire (ASan/UBSan) ; le chemin de réception / d'analyse CANopen reste une surface d'attaque et est documenté comme couverture de fuzzing encore à étendre.

Comme CANopen (Classic CAN 2.0) ne prévoit aucune authentification cryptographique par conception, la sécurité du bus est compensée par la zone de confiance physique (armoire plombée) et la segmentation OT du segment de bus côté déploiement — voir §13. Les perturbations causées par des nœuds CANopen étrangers sont hors du contrôle du produit.

8. Protection des données & minimisation

L'exploitation normale transmet uniquement des données machine et d'exploitation de l'installation (valeurs d'objets CANopen sélectionnées par la table de mapping, points de données SDO/PDO) ainsi que de la télémétrie d'appareil (info cellule LTE, valeurs d'état). Aucune donnée à caractère personnel au sens du RGPD n'est traitée — l'IMEI identifie l'appareil, pas une personne (critère de classification de risque K8 = 0). Aucune donnée à caractère personnel n'est donc exposée sur le réseau.

Une sauvegarde locale de configuration par l'exploitant n'est ni nécessaire ni possible : table de mapping, script, débit CAN et node-ID sont conservés dans le backend et redéployés lors du (re)provisionnement. ImagineOn supprime les données backend à la demande du tenant (RGPD art. 17 ; voir l'accord de traitement des données Coldwave Cloud).

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

ImagineOn exploite un processus de réponse aux incidents de sécurité produit conforme à 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 signaler les vulnérabilités suspectées via des issues, pull requests ou discussions GitHub publiques.

Canal (PSIRT)	security@coldwave.io
Signalement chiffré	Clé PGP — empreinte à publier sur `https://coldwave.io/.well-known/security.txt`
Formulaire web	prévu : `https://coldwave.io/security/report`
Accusé de réception	sous 2 jours ouvrés
Triage & première évaluation	sous 10 jours ouvrés
Disponibilité du correctif (Critical, CVSS ≥ 9)	15 jours calendaires après triage
Disponibilité du correctif (High, CVSS ≥ 7)	30 jours calendaires après triage
Disponibilité du correctif (Medium)	90 jours calendaires (regroupés dans la prochaine version mineure)
Disponibilité du correctif (Low)	meilleur effort / regroupé
Cotation	CVSS v3.1 avec pondération de contexte OT

Divulgation coordonnée : la divulgation est coordonnée, après disponibilité d'un correctif et un délai de déploiement raisonnable pour les appareils concernés (typiquement 30 jours). Les auteurs de signalements sont crédités nommément sur demande ; il n'existe actuellement pas de programme de prime aux bogues rémunéré.
Dépendances déléguées / intégrées : les défauts de coldwave-os (TLS/OTA/MCUboot/keystore PSA), libflake, coldwave-script-vm ou CANopenNode sont suivis auprès de l'upstream / PSIRT respectif ; le micrologiciel YCAN reflète les correctifs via les épingles de version et tient un suivi CVE avec classification VEX.
CRA/ENISA : pour une vulnérabilité activement exploitée, une notification à l'ENISA sous 24 heures peut être requise (CRA ; obligations de signalement à compter du 2026-09-11). Les signalements portant la mention [ACTIVE EXPLOIT] en objet contournent la file de triage.

10. Transparence : SBOM & open source

Une SBOM CycloneDX (nomenclature logicielle) 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 / délégués, ImagineOn fournit des déclarations VEX CycloneDX (Vulnerability Exploitability eXchange) sur demande — y compris une non-applicabilité motivée (p. ex. un défaut CANopenNode non déclenchable via la configuration de build YCAN).
Les composants open source / intégrés utilisés, ainsi que leurs textes de licence, sont listés dans le LICENSE.md du produit (dont mbedTLS, FreeRTOS, MCUboot, CANopenNode, pilote MCP2518FD).

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

ImagineOn fournit des mises à jour de sécurité pendant 10 ans à compter de la première mise sur le marché. La fin de la fourniture de mises à jour de sécurité par révision matérielle est documentée dans le CHANGELOG.md et le portail Coldwave Cloud ; la période dépasse le minimum du CRA. Après la fin du support de sécurité, les appareils concernés doivent être remplacés ou placés en quarantaine réseau.

Les mises à jour arrivent de façon entièrement automatique via le Coldwave Cloud — aucune action de l'exploitant n'est nécessaire pour recevoir les correctifs de sécurité. La seule condition est une connexion cellulaire fonctionnelle ; les périodes hors ligne prolongées ne constituent pas un problème de sécurité aigu mais signifient que des correctifs de sécurité sont manqués.

12. Normes & cadres

Cadre	Pertinence pour le YCAN
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, module A)
ETSI EN 303 645	Exigences de base pour l'IoT grand public — appliquées de manière prospective
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 (§13)
CRA UE (règlement (UE) 2024/2847)	préparatoire ; pleinement applicable à compter du 2027-12-11, obligations de signalement à compter du 2026-09-11

É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é. L'auto-évaluation EN 18031-1 et la déclaration UE de conformité (DoC) sont au stade de la finalisation des preuves matérielles (CEM/RF/sécurité) et de la clôture des findings de cybersécurité ouverts ; elles sont fournies sur demande (compliance@imagineon.de). Le présent livre blanc ne formule aucune affirmation de conformité avec des normes produit spécifiques à l'application concernée ; le YCAN est un composant de raccordement radio, et non le contrôleur de l'installation.

13. 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, PSIRT et correctifs de sécurité selon SLA, SBOM/VEX, durcissement des interfaces appareil et backend.
Intégrateur / fabricant d'installation	Sécurité du compte de tenant Coldwave (authentification forte / MFA, rôles à moindre privilège), intégration sûre dans l'installation, rattachement de l'appareil au tenant, responsabilité des scripts et tables de mapping téléversés.
Propriétaire / exploitant	Protection physique (armoire plombée, segmentation OT du bus CAN, serrage stable de l'antenne), protection de l'accès au portail, signalement rapide des anomalies, ne pas bloquer les mises à jour en coupant durablement le réseau.

14. Mise hors service & élimination

Les clés propres à l'appareil sont conservées, liées au matériel, dans le keystore PSA (Secure Vault) 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 (via le fabricant d'installation) et seulement ensuite le mettre hors tension ;
dans la mesure du possible, retourner l'appareil à ImagineOn ; les clés de provisionnement sont effacées de manière sûre lors du reconditionnement en usine ;
sinon, éliminer l'appareil correctement en tant que déchet électronique (DEEE). Les clés sont liées au matériel et deviennent inutilisables avec sa destruction. Le module cellulaire est soudé — aucun traitement SIM séparé n'est nécessaire.

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

15. Contact & références

Signalement de sécurité / vulnérabilité : security@coldwave.io (PGP : https://coldwave.io/.well-known/security.txt)
Conformité / déclaration UE de conformité (DoC) : compliance@imagineon.de
Politique de divulgation coordonnée & SLA : en ligne au §9 du présent document · publiée sur https://coldwave.io/.well-known/security.txt
Fabricant : ImagineOn GmbH, Neusser Str. 27–29, 50670 Cologne — www.imagineon.de

© 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 pour le micrologiciel 1.0.0 ; des modifications dans le cadre de la maintenance du produit demeurent réservées.