Coldwave YUKI Block RSX1 — Security-Whitepaper

Produkt
Coldwave YUKI Block RSX1/LTE-M (YRX1) — LTE-M-/NB-IoT-Gateway für Modbus-RTU und BACnet-MS/TP
Firmware
coldwave-yukiblock-rsx1 (yrx1) 1.0.0
Plattform
Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault, auf coldwave-os
Feldbus
Modbus-RTU-Master und BACnet-MS/TP-Master über RS485; RS232/RS485 zur Laufzeit umschaltbar
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 · Open-Source-Lizenzen · Release Notes
Über dieses Dokument. Dieses Whitepaper beschreibt die Sicherheitsarchitektur, -mechanismen und -prozesse des Coldwave YUKI Block RSX1 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 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
  1. Zweck & Geltungsbereich
  2. Sicherheits-Architektur im Überblick
  3. Trust-Modell & Zonen
  4. Software-Integrität & Updates
  5. Transport & Backend-Anbindung
  6. Reduktion der Angriffsfläche
  7. Feldbus-Sicherheit (Modbus/BACnet) & Parser-Härtung
  8. Datenschutz & Datenminimierung
  9. Schwachstellen-Management (PSIRT)
  10. Transparenz: SBOM & Open Source
  11. Sicherheits-Support & Lifecycle
  12. Normen & Rahmenwerke
  13. Geteilte Verantwortung
  14. Außerbetriebnahme & Entsorgung
  15. Kontakt & Verweise

1. Zweck & Geltungsbereich

Der Coldwave YUKI Block RSX1 (kurz „YRX1") ist ein stationäres Industrie-IoT-Gateway auf Basis des Mikrocontrollers Silicon Labs EFR32MG26 (ARM Cortex-M33 mit Secure Vault). Es bindet einen seriellen Feldbus — wahlweise Modbus-RTU oder BACnet-MS/TP über RS485 (RS232/RS485 zur Laufzeit umschaltbar) — an das Coldwave-Backend an und überträgt die per Mapping-Tabelle ausgewählten Datenpunkte verschlüsselt über Mobilfunk (LTE-M / NB-IoT). Eine optionale, PLC-artige Script-VM (coldwave-script-vm) übernimmt die feldseitige Vorverarbeitung.

Das Gerät arbeitet als Modbus-RTU-Master bzw. BACnet-MS/TP-Master und ist so ausgelegt, dass es den Feldbus 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

SchutzzielMaßnahme im YRX1
Integrität der FirmwareSecure Boot (EFR32MG26 Secure Vault) + MCUboot-artiger Bootloader mit signierten Images (ECDSA-P256 / SHA-256), Versions-Monotonie
Authentizität der UpdatesZwei 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 TransportTLS 1.2/1.3 (mbedTLS) über LTE-M mit CA-basierter Server-Authentifizierung (CA-Provisionierung in finaler Härtung, siehe §5)
Reduktion der AngriffsflächeKeine offenen Netzwerkdienste, keine lokale Konsole, keine Default-Passwörter, Debug per Firmware gesperrt
SchlüsselablagePSA-Crypto-Keystore, hardwaregebunden (Secure Vault), nicht exportierbar
Robustheit der SchnittstellenGehärtete, host-getestete und fuzz-getestete Protokoll-/Mapping-Parser (ASan/UBSan)
Bus-DisziplinMaster-seitiges Timing/Rate-Limiting; das Gateway hält die Feldbus-Timings ein und stört den Bus nicht selbst
NachvollziehbarkeitSecurity-Events werden ins Backend gestreamt und dort vorgehalten (keine Operator-Logs am Gerät)

3. Trust-Modell & Zonen

Das YRX1 unterscheidet mehrere Vertrauenszonen. Alle von außen empfangenen Daten gelten bis zur Validierung als nicht vertrauenswürdig.

ZoneBeteiligteVertrauensannahme
Coldwave-Backend (B1)ImagineOn-Backend + Anlagen-Hersteller/Wartungsfirma via Tenant-AccountTLS-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
Feldbus Modbus/BACnet (B2)Modbus-RTU- bzw. BACnet-MS/TP-Knoten auf dem RS485-SegmentProtokollbedingt nicht kryptografisch authentifiziert → kompensiert durch die physische Vertrauenszone (verplombter Schaltschrank) + OT-Segmentierung
Modem-AT-Kanal (B3)Mobilfunk-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-PinsNur ü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, serielle Parameter, Feldbus-Modus) gepusht, signierte Skripte hochgeladen sowie OTA-Updates ausgelöst werden; Sollwerte/Steuerbefehle werden über die gemappten, beschreibbaren Register/Objekte an die Anlage weitergereicht. Das YRX1 implementiert keine eigene Sicherheitslogik auf Anlagenebene. Über den Feldbus selbst ist keine persistente Applikations-Konfigurationsänderung des Gateways möglich: Der Konfigurationszustand wird ausschließlich über den TLS-Kanal gesetzt.

4. Software-Integrität & Updates

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

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 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 (Schlüssel im HSM nicht löschbar, Multi-Region-Replikation, organisationsweite Policy-Leitplanken gegen Schlüssel-Löschung/-Deaktivierung, verpflichtendes Code-Owner-Review auf dem 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 Feldbus-Rolle des Geräts nicht.

5. Transport & Backend-Anbindung

6. Reduktion der Angriffsfläche

7. Feldbus-Sicherheit (Modbus-RTU / BACnet-MS/TP) & Parser-Härtung

Der serielle 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:

Da Modbus-RTU und BACnet-MS/TP protokollbedingt keine kryptografische Authentifizierung vorsehen, wird die Bus-Sicherheit durch die physische Vertrauenszone (verplombter Schaltschrank) und deployment-seitige OT-Segmentierung des Bussegments kompensiert — siehe §13. Störungen durch fremde Bus-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 Modbus-Register bzw. BACnet-Objekt-Werte) 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. 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 und serielle Parameter 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 MeldungPGP-Key — Fingerprint wird unter https://coldwave.io/.well-known/security.txt veröffentlicht
Empfangsbestätigunginnerhalb von 2 Arbeitstagen
Triage & Ersteinstufunginnerhalb 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
BewertungCVSS v3.1 mit OT-Kontext-Gewichtung

10. Transparenz: SBOM & Open Source

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 den Release Notes 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

RahmenwerkBezug für das YRX1
RED 2014/53/EU + Delegierte VO (EU) 2022/30Funkanlagen-Cybersecurity, Art. 3(3)(d)/(e)/(f)
EN 18031-1:2024Cybersecurity-Anforderungen an internet-verbundene Funkgeräte (Self-Assessment, Modul A)
ETSI EN 303 645Baseline-Anforderungen für Consumer-IoT — vorausschauend angewandt
IEC 62443-4-1Sicherer Entwicklungslebenszyklus (SDL), Geräteklasse RC-2
IEC 62443-4-2Technische 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; die EU-Konformitätserklärung ist unter EU-Konformitätserklärung verfügbar. Dieses Whitepaper trifft keine Aussage zur Konformität mit anlagenspezifischen Produktnormen der jeweiligen Applikation; das YRX1 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:

RolleVerantwortung
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-HerstellerSicherheit 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 / BetreiberPhysischer Schutz (verplombter Schaltschrank, OT-seitige Feldbus-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:

WEEE-Registrierungsnummer: DE 54689668 (ImagineOn GmbH).

15. Kontakt & Verweise


© 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 YUKI Block RSX1 — Security Whitepaper

Product
Coldwave YUKI Block RSX1/LTE-M (YRX1) — LTE-M / NB-IoT gateway for Modbus-RTU and BACnet-MS/TP
Firmware
coldwave-yukiblock-rsx1 (yrx1) 1.0.0
Platform
Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault, on coldwave-os
Field bus
Modbus-RTU master and BACnet-MS/TP master over RS485; RS232/RS485 runtime-selectable
Manufacturer
ImagineOn GmbH, Neusser Str. 27–29, 50670 Köln, Germany
Document version
1.0 — 2026
Security level
IEC 62443 SL-2 (target); device class RC-2 (effective; intrinsically RC-3)
Related docs
Vulnerability disclosure: §9 · Open-source licenses · Release notes
About this document. This whitepaper describes the security architecture, mechanisms and processes of the Coldwave YUKI Block RSX1 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: suspected vulnerabilities should be reported 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 rating 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 (bundled 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 roll-out window (typically 30 days).
Maturity. The firmware described here is at version 1.0.0. What is described is the process and architecture guarantee; individual controls are in final hardening ahead of GA release and are transparently flagged at the relevant places (§4, §5, §12).
Contents
  1. Purpose & scope
  2. Security architecture at a glance
  3. Trust model & zones
  4. Software integrity & updates
  5. Transport & backend connection
  6. Attack-surface reduction
  7. Field-bus security (Modbus/BACnet) & parser hardening
  8. Data protection & data minimisation
  9. Vulnerability management (PSIRT)
  10. Transparency: SBOM & open source
  11. Security support & lifecycle
  12. Standards & frameworks
  13. Shared responsibility
  14. Decommissioning & disposal
  15. Contact & references

1. Purpose & scope

The Coldwave YUKI Block RSX1 ("YRX1") is a stationary industrial IoT gateway built on the Silicon Labs EFR32MG26 microcontroller (ARM Cortex-M33 with Secure Vault). It attaches a serial field bus — either Modbus-RTU or BACnet-MS/TP over RS485 (RS232/RS485 runtime-selectable) — to the Coldwave backend and transmits the data points selected by the mapping table over cellular (LTE-M / NB-IoT) in encrypted form. An optional PLC-style script VM (coldwave-script-vm) handles field-side pre-processing.

The device operates as a Modbus-RTU master or BACnet-MS/TP master and is designed not to destabilise the field bus. It is developed under 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 carries the purely operational/lifecycle-oriented RC-3 controls. The cybersecurity assessment as an internet-connected radio device follows EN 18031-1.

2. Security architecture at a glance

ObjectiveMeasure in the YRX1
Firmware integritySecure Boot (EFR32MG26 Secure Vault) + MCUboot-style bootloader with signed images (ECDSA-P256 / SHA-256), version monotonicity
Update authenticityTwo independent signature checks (OTA handler + bootloader); signing key in a cloud-hosted hardware security module (HSM, FIPS 140-2 Level 3), non-extractable
Transport confidentialityTLS 1.2/1.3 (mbedTLS) over LTE-M with CA-based server authentication (CA provisioning in final hardening, see §5)
Attack-surface reductionNo open network services, no local console, no default passwords, debug locked by firmware
Key storagePSA-Crypto keystore, hardware-bound (Secure Vault), non-exportable
Interface robustnessHardened, host-tested and fuzz-tested protocol/mapping parsers (ASan/UBSan)
Bus disciplineMaster-side timing/rate-limiting; the gateway respects field-bus timing and does not itself disturb the bus
TraceabilitySecurity events are streamed to and retained in the backend (no operator logs on the device)

3. Trust model & zones

The YRX1 distinguishes several trust zones. All externally received data is treated as untrusted until validated.

ZonePartiesTrust assumption
Coldwave backend (B1)ImagineOn backend + plant manufacturer/service company via tenant accountTLS-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 does not see the payload
Field bus Modbus/BACnet (B2)Modbus-RTU or BACnet-MS/TP nodes on the RS485 segmentNot cryptographically authenticated by protocol design → compensated by the physical trust zone (sealed cabinet) + OT segmentation
Modem AT channel (B3)Cellular modem (UART)Modem responses/URCs are untrusted to the driver logic; line-buffer caps + watchdog
Enclosure / debug (B4)sealed device, locked debug pinsReachable only via OTA and the backend API
What the backend can do (blast radius). Through the Coldwave backend — with the corresponding tenant permission (cloud RBAC) — telemetry can be retrieved, configuration (mapping table, serial parameters, field-bus mode) can be pushed, signed scripts can be uploaded and OTA updates can be triggered; setpoints/control commands are passed to the plant via the mapped, writable registers/objects. The YRX1 implements no security logic of its own at plant level. No persistent application-configuration change of the gateway is possible via the field bus itself: configuration state is set exclusively over the TLS channel.

4. Software integrity & updates

Firmware integrity is secured across the whole boot chain:

Non-rotatable bootloader key (known residual risk). The bootloader verify-pubkey is written into the bootloader region at factory-provisioning time and is not rotatable in the field (no OTA path for the bootloader). The signing key must therefore remain unchanged in custody across the entire product lifetime. This is documented as an accepted residual risk and covered by operational measures (key non-deletable in the HSM, multi-region replication, 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 is preserved. An OTA update does not change the device's field-bus role.

5. Transport & backend connection

6. Attack-surface reduction

7. Field-bus security (Modbus-RTU / BACnet-MS/TP) & parser hardening

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

Because Modbus-RTU and BACnet-MS/TP provide no cryptographic authentication by protocol design, bus security is compensated by the physical trust zone (sealed cabinet) and deployment-side OT segmentation of the bus segment — see §13. Disturbances from foreign bus nodes are outside product control.

8. Data protection & data minimisation

Normal operation transmits only machine and operational data of the plant (Modbus registers or BACnet object values selected by the mapping table) 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. There is therefore no network exposure of personal data.

A local configuration backup by the operator is neither necessary nor possible: mapping table, script and serial parameters are held in the backend and re-rolled out on (re-)provisioning. ImagineOn deletes backend data at the tenant's request (GDPR Art. 17; see the Coldwave Cloud DPA).

9. Vulnerability management (PSIRT)

ImagineOn operates a product-security incident-response process per IEC 62443-4-1 (Practice 6 / DM-1..DM-5) and in preparation 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 reportPGP key — fingerprint published at https://coldwave.io/.well-known/security.txt
Acknowledgementwithin 2 business days
Triage & initial ratingwithin 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 (bundled into the next minor release)
Fix availability (Low)best-effort / bundled
ScoringCVSS v3.1 with OT-context weighting

10. Transparency: SBOM & open source

11. Security support & lifecycle

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

Updates arrive fully automatically via the Coldwave Cloud — no asset-owner action is needed to receive security patches. A working cellular connection is required; longer offline periods are not an acute security problem but mean security patches are missed.

12. Standards & frameworks

FrameworkRelevance for the YRX1
RED 2014/53/EU + Delegated Reg. (EU) 2022/30Radio-equipment cybersecurity, Art. 3(3)(d)/(e)/(f)
EN 18031-1:2024Cybersecurity requirements for internet-connected radio equipment (self-assessment, Module A)
ETSI EN 303 645Baseline requirements for consumer IoT — applied proactively
IEC 62443-4-1Secure development lifecycle (SDL), device class RC-2
IEC 62443-4-2Technical component security requirements, target SL-2; basis of the shared responsibility (§13)
EU CRA (Reg. (EU) 2024/2847)in preparation; full applicability from 2027-12-11, reporting obligations from 2026-09-11

Conformity assessment of the radio equipment 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 final hardware evidence (EMC/RF/safety) and closure of open cybersecurity findings; the EU Declaration of Conformity is available at EU Declaration of Conformity. This whitepaper makes no statement about conformity with application-specific product standards; the YRX1 is a radio connectivity component, not the plant controller.

13. Shared responsibility

Security in the field is a shared task (IEC 62443-4-2). The roles are distributed as follows:

RoleResponsibility
Manufacturer (ImagineOn)Firmware security, signing/update chain, PSIRT and security patches per SLA, SBOM/VEX, hardening of the device and backend interfaces.
Integrator / plant manufacturerSecurity of the Coldwave tenant account (strong authentication / MFA, least-privilege roles), safe integration into the plant, device-to-tenant assignment, responsibility for uploaded scripts and mapping tables.
Asset owner / operatorPhysical protection (sealed cabinet, OT-side field-bus segmentation, stable antenna seating), protection of portal access, timely reporting of anomalies, not permanently blocking updates by disabling the network.

14. Decommissioning & disposal

The device-individual keys reside hardware-bound in the microcontroller's PSA keystore (Secure Vault). On-site data erasure by the operator is not provided for (no operator interface). On de-installation we recommend:

WEEE registration number: DE 54689668 (ImagineOn GmbH).

15. Contact & references


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

Coldwave YUKI Block RSX1 — Livre blanc de sécurité

Produit
Coldwave YUKI Block RSX1/LTE-M (YRX1) — passerelle LTE-M / NB-IoT pour Modbus-RTU et BACnet-MS/TP
Micrologiciel
coldwave-yukiblock-rsx1 (yrx1) 1.0.0
Plateforme
Silicon Labs EFR32MG26 (ARM Cortex-M33) + Secure Vault, sur coldwave-os
Bus de terrain
Maître Modbus-RTU et maître BACnet-MS/TP via RS485 ; RS232/RS485 commutable à l'exécution
Fabricant
ImagineOn GmbH, Neusser Str. 27–29, 50670 Köln, Allemagne
Version du document
1.0 — 2026
Niveau de sécurité
IEC 62443 SL-2 (cible) ; classe d'appareil RC-2 (effective ; RC-3 intrinsèque)
Documents liés
Divulgation de vulnérabilités : §9 · Licences open source · Notes de version
À propos de ce document. Ce livre blanc décrit l'architecture, les mécanismes et les processus de sécurité du Coldwave YUKI Block RSX1 pour les exploitants, intégrateurs, responsables de la sécurité informatique et organismes notifiés. Il décrit délibérément des mécanismes et politiques — non des vulnérabilités concrètes, des registres internes de risques résiduels ou des détails d'infrastructure. Le processus associé de réponse aux incidents de sécurité produit (divulgation coordonnée des vulnérabilités) est décrit au §9 : les vulnérabilités présumées doivent être signalées à security@coldwave.io (empreinte PGP sur https://coldwave.io/.well-known/security.txt). ImagineOn accuse réception sous 2 jours ouvrés, effectue le tri et l'évaluation initiale sous 10 jours ouvrés, et fournit des correctifs 15 jours calendaires (Critical, CVSS ≥ 9) ou 30 jours calendaires (High, CVSS ≥ 7) après le tri ; Medium sous 90 jours calendaires (regroupés dans la prochaine version mineure), Low au mieux. 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 en version 1.0.0. Ce qui est décrit est la garantie de processus et d'architecture ; certaines mesures sont en durcissement final avant la mise en disponibilité générale et sont signalées de façon transparente aux endroits concernés (§4, §5, §12).
Sommaire
  1. Objet & périmètre
  2. Architecture de sécurité en un coup d'œil
  3. Modèle de confiance & zones
  4. Intégrité logicielle & mises à jour
  5. Transport & liaison backend
  6. Réduction de la surface d'attaque
  7. Sécurité du bus de terrain (Modbus/BACnet) & durcissement des parseurs
  8. Protection des données & minimisation
  9. Gestion des vulnérabilités (PSIRT)
  10. Transparence : SBOM & open source
  11. Support de sécurité & cycle de vie
  12. Normes & cadres
  13. Responsabilité partagée
  14. Mise hors service & élimination
  15. Contact & références

1. Objet & périmètre

Le Coldwave YUKI Block RSX1 (« YRX1 ») est une passerelle IoT industrielle stationnaire basée sur le microcontrôleur Silicon Labs EFR32MG26 (ARM Cortex-M33 avec Secure Vault). Il raccorde un bus de terrain série — au choix Modbus-RTU ou BACnet-MS/TP via RS485 (RS232/RS485 commutable à l'exécution) — au backend Coldwave et transmet les points de données sélectionnés par la table de mapping, chiffrés, via le réseau cellulaire (LTE-M / NB-IoT). Une VM de script optionnelle de type automate (coldwave-script-vm) assure le prétraitement côté terrain.

L'appareil fonctionne comme maître Modbus-RTU ou maître BACnet-MS/TP et est conçu pour ne pas déstabiliser le bus de terrain. 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 intrinsèque du risque donne RC-3 (LTE-M, bootloader, plusieurs parseurs, 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, qui assume les contrôles RC-3 purement opérationnels/de cycle de vie. L'évaluation de cybersécurité en tant qu'équipement radio connecté à Internet suit EN 18031-1.

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

ObjectifMesure dans le YRX1
Intégrité du micrologicielSecure Boot (EFR32MG26 Secure Vault) + bootloader de type MCUboot avec images signées (ECDSA-P256 / SHA-256), monotonie de version
Authenticité des mises à jourDeux vérifications de signature indépendantes (gestionnaire OTA + bootloader) ; clé de signature dans un module matériel de sécurité (HSM, FIPS 140-2 niveau 3) hébergé dans le cloud, non extractible
Confidentialité du transportTLS 1.2/1.3 (mbedTLS) via LTE-M avec authentification serveur basée sur AC (provisionnement AC en durcissement final, voir §5)
Réduction de la surface d'attaqueAucun service réseau ouvert, aucune console locale, aucun mot de passe par défaut, débogage verrouillé par le micrologiciel
Stockage des clésKeystore PSA-Crypto, lié au matériel (Secure Vault), non exportable
Robustesse des interfacesParseurs de protocole/mapping durcis, testés sur hôte et par fuzzing (ASan/UBSan)
Discipline de busCadencement/limitation de débit côté maître ; la passerelle respecte les temporisations du bus et ne le perturbe pas elle-même
TraçabilitéLes événements de sécurité sont transmis au backend et y sont conservés (pas de journaux opérateur sur l'appareil)

3. Modèle de confiance & zones

Le YRX1 distingue plusieurs zones de confiance. Toute donnée reçue de l'extérieur est considérée comme non fiable jusqu'à validation.

ZonePartiesHypothèse de confiance
Backend Coldwave (B1)Backend ImagineOn + fabricant d'installation/société de maintenance via compte tenantAccès authentifié par TLS à la télémétrie, à la configuration à distance, au téléversement de scripts et à la livraison OTA
Cellulaire LTE-M/NB-IoT (B1)Opérateur de réseau mobile (transparent)Ne transporte que des paquets chiffrés par TLS ; l'opérateur ne voit pas les données utiles
Bus de terrain Modbus/BACnet (B2)Nœuds Modbus-RTU ou BACnet-MS/TP sur le segment RS485Non authentifié cryptographiquement par conception du protocole → compensé par la zone de confiance physique (armoire scellée) + segmentation OT
Canal AT du modem (B3)Modem cellulaire (UART)Les réponses/URC du modem sont non fiables pour la logique du pilote ; plafonds de tampon de ligne + watchdog
Boîtier / débogage (B4)appareil scellé, broches de débogage verrouilléesAccessible 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 correspondante (RBAC cloud) — on peut récupérer la télémétrie, pousser la configuration (table de mapping, paramètres série, mode de bus de terrain), téléverser des scripts signés et déclencher des mises à jour OTA ; les consignes/commandes sont transmises à l'installation via les registres/objets mappés et inscriptibles. Le YRX1 n'implémente aucune logique de sécurité propre au niveau de l'installation. Aucune modification persistante de la configuration applicative de la passerelle n'est possible via le bus de terrain lui-même : l'état de configuration est défini exclusivement via le canal TLS.

4. Intégrité logicielle & mises à jour

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

Clé de bootloader non rotative (risque résiduel connu). La clé publique de vérification du bootloader est écrite dans la zone du bootloader au moment du provisionnement en usine et n'est pas rotative sur le terrain (aucun chemin OTA pour le bootloader). La clé de signature doit donc rester inchangée en garde sur toute la durée de vie du produit. Ceci est documenté comme risque résiduel accepté et couvert par des mesures opérationnelles (clé non supprimable dans le HSM, réplication multi-régions, 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 livrées exclusivement via la connexion backend chiffrée ; les données de mapping/script/configuration sont conservées. Une mise à jour OTA ne change pas le rôle de bus de terrain de l'appareil.

5. Transport & liaison backend

6. Réduction de la surface d'attaque

7. Sécurité du bus de terrain (Modbus-RTU / BACnet-MS/TP) & durcissement des parseurs

Le bus de terrain série (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 :

Comme Modbus-RTU et BACnet-MS/TP ne prévoient aucune authentification cryptographique par conception du protocole, la sécurité du bus est compensée par la zone de confiance physique (armoire scellée) et la segmentation OT côté déploiement du segment de bus — voir §13. Les perturbations dues à des nœuds de bus étrangers sont hors du contrôle du produit.

8. Protection des données & minimisation

Le fonctionnement normal ne transmet que des données machine et d'exploitation de l'installation (registres Modbus ou valeurs d'objets BACnet sélectionnés par la table de mapping) plus la télémétrie de l'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. Il n'y a donc aucune exposition réseau de données personnelles.

Une sauvegarde de configuration locale par l'exploitant n'est ni nécessaire ni possible : table de mapping, script et paramètres série sont conservés dans le backend et redéployés lors du (re)provisionnement. ImagineOn efface les données backend à la demande du tenant (RGPD art. 17 ; voir le DPA 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 en préparation du règlement européen sur la cyber-résilience (CRA). Veuillez ne pas signaler les vulnérabilités présumées via des issues, pull-requests ou discussions GitHub publiques.

Canal (PSIRT)security@coldwave.io
Signalement chiffréClé PGP — empreinte publiée sur https://coldwave.io/.well-known/security.txt
Accusé de réceptionsous 2 jours ouvrés
Tri & évaluation initialesous 10 jours ouvrés
Disponibilité du correctif (Critical, CVSS ≥ 9)15 jours calendaires après le tri
Disponibilité du correctif (High, CVSS ≥ 7)30 jours calendaires après le tri
Disponibilité du correctif (Medium)90 jours calendaires (regroupés dans la prochaine version mineure)
Disponibilité du correctif (Low)au mieux / regroupé
ÉvaluationCVSS v3.1 avec pondération de contexte OT

10. Transparence : SBOM & open source

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

ImagineOn fournit des mises à jour de micrologiciel pertinentes pour la 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 les notes de version et le portail Coldwave Cloud ; la durée dépasse le minimum 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'asset owner n'est nécessaire pour recevoir les correctifs de sécurité. Une connexion cellulaire fonctionnelle est requise ; de longues périodes hors ligne ne constituent pas un problème de sécurité aigu mais font manquer les correctifs de sécurité.

12. Normes & cadres

CadrePertinence pour le YRX1
RED 2014/53/UE + règl. délégué (UE) 2022/30Cybersécurité des équipements radio, art. 3(3)(d)/(e)/(f)
EN 18031-1:2024Exigences de cybersécurité pour les équipements radio connectés à Internet (auto-évaluation, module A)
ETSI EN 303 645Exigences de base pour l'IoT grand public — appliquées de façon anticipée
IEC 62443-4-1Cycle de développement sécurisé (SDL), classe d'appareil RC-2
IEC 62443-4-2Exigences techniques de sécurité des composants, cible SL-2 ; base de la responsabilité partagée (§13)
CRA UE (règl. (UE) 2024/2847)en préparation ; pleine applicabilité à partir du 2027-12-11, obligations de signalement à partir du 2026-09-11

Évaluation de la conformité de l'équipement radio au titre de la RED via le module A (contrôle interne de la production), sans intervention d'un organisme notifié. L'auto-évaluation EN 18031-1 et la déclaration UE de conformité (DoC) sont au stade des preuves matérielles finales (CEM/RF/sécurité) et de la clôture des points de cybersécurité ouverts ; la déclaration UE de conformité est disponible sous Déclaration UE de conformité. Ce livre blanc ne se prononce pas sur la conformité avec les normes produit spécifiques à l'application ; le YRX1 est un composant de connectivité radio, non le contrôleur de l'installation.

13. Responsabilité partagée

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

RôleResponsabilité
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'installationSécurité du compte tenant Coldwave (authentification forte / MFA, rôles au moindre privilège), intégration sûre dans l'installation, affectation appareil-tenant, responsabilité des scripts et tables de mapping téléversés.
Asset owner / exploitantProtection physique (armoire scellée, segmentation OT du bus de terrain, fixation stable de l'antenne), protection de l'accès au portail, signalement rapide des anomalies, ne pas bloquer durablement les mises à jour en coupant le réseau.

14. Mise hors service & élimination

Les clés propres à l'appareil résident, liées au matériel, dans le keystore PSA (Secure Vault) du microcontrôleur. Un effacement de données sur site par l'exploitant n'est pas prévu (pas d'interface opérateur). Lors de la désinstallation, il est recommandé :

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

15. Contact & références


© 2026 ImagineOn GmbH. Tous droits réservés. Ce 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 sont réservées.