01 / DEVICE & FIRMWARE

Industrial Device & Firmware Security Assessment

Physisches / eingebettetes Produkt im Scope

Security-Assessment vernetzter und eingebetteter Produkte, von physischen Schnittstellen, Hardware-Sicherheitskontrollen und Boot-Ketten über Firmware, Protokolle, Applikationen bis zu relevanten Backend-Komponenten.

Abhängig von der Produktarchitektur verbindet das Assessment Hardware- und Firmware-Analyse mit Penetrationstesting von Protokollen, Applikationen, APIs und angebundenen Backend-Diensten.

HardwareFirmwareBoot & UpdatesProtokolleBackendKryptografie
TARGET / EMBEDDED PRODUCT ASSESSMENT SURFACE
PHYSICAL
TRUSTED EXECUTION
CONNECTED PRODUCT
trust path note attack path: DEBUG → FIRMWARE → PROTOCOL → API → BACKEND
DEBUG / ACCESS
interface JTAG
lock state aktiv
lifecycle production
memory access blockiert
PRODUKT-VERTRAUENSGRENZEN

Ein Produkt. Mehrere Vertrauensgrenzen.

Ein Produkt selten an genau einer isolierten Schicht. Debug-Zugang kann Firmware freilegen. Firmware kann Credentials enthalten. Die Geräte-Identität kann Backend-Vertrauen beeinflussen. Update-Logik kann eine ansonsten korrekte Secure-Boot-Kette untergraben.

schicht ausgewählt
Secrets / Identität
Provisionierung, gespeicherte Credentials, Schlüsselmaterial, Geräte-Identität und Backend-Vertrauen.
PRÜFFLÄCHE

Was wir testen

Hardware & physischer Zugang

Debug-Schnittstellen, Wartungsschnittstellen, Speicherzugriff, Flash-Extraktion, Ausleseschutz, Lifecycle-Konfiguration und hardwaregestützte Kontrollen.

Boot- & Firmware-Trust

Boot-Stufen, Secure Boot, Recovery-Pfade, Rollback, Firmware-Verifikation und privilegiertes Startverhalten.

Firmware & Embedded-Software

Dateisysteme, Binaries, Parser, Dienste, privilegierte Komponenten, versteckte Wartungslogik und exponierte Funktionalität.

Identität, Secrets & Kryptografie

Geräte-Credentials, Schlüsselmaterial, Secure Storage, Provisionierung, Signatur, Geräte-Identität und kryptografische Vertrauensentscheidungen.

Protokolle & Schnittstellen

Proprietäre Protokolle, Authentisierung, State-Handling, Pairing, RF wo relevant, und Protokoll-Reverse-Engineering.

Applikationen & Backend-Pfade

Management-Applikationen, APIs und angebundene Dienste, wo sie die Sicherheit des Produkts beeinflussen.

Die konkrete Prüffläche folgt der Produktarchitektur. Nicht jedes Assessment braucht jede Schicht.

CROSS-LAYER-ANGRIFFSPFADE

Die spannenden Befunde liegen oft zwischen den Schichten.

01

Debug → Firmware → Backend

Eine Wartungsschnittstelle legt Firmware offen. Extrahierte Credentials ermöglichen Zugriff auf eine interne Produkt-API. Das Problem ist nicht mehr nur „Debug-Zugang“.

02

Update → Boot → Persistente Kompromittierung

Das Update-Paket ist signiert, aber der Recovery-Pfad akzeptiert ein älteres gültiges Image. Ein Rollback-Pfad führt einen bekannten angreifbaren Zustand wieder ein.

03

Geräte-Identität → Fleet-Impact

Credentials, die ein einzelnes Gerät identifizieren sollen, sind geteilt oder klonbar. Eine lokale Produktschwäche wird zum Flotten- oder Backend-Vertrauensproblem.

IM LABOR

Was am Gerät passiert, während wir es haben.

Ihr Gerät wird geöffnet, dokumentiert und auf seine Schnittstellen hin vermessen: Debug-Zugänge wie UART und JTAG, Speicherbusse wie SPI, Drahtlosverbindungen wie Bluetooth LE und Thread. Was existiert, was ist offen, was verrät der Zustand über die Produktionsversion?

Wir extrahieren die Firmware, wo der Schutz sie nicht zurückhält, und analysieren Boot-Kette, Update-Pfad und Ablage der Schlüssel. Am Logic Analyzer verfolgen wir, was das Gerät in den ersten Millisekunden nach dem Einschalten tatsächlich verifiziert. Verbindungen zu Backend-Diensten begleiten wir bis in die Protokollebene.

Eingriffe, die Geräte beschädigen können, etwa das Entfernen eines Speicherbausteins, erfolgen nur mit Ihrer schriftlichen Freigabe. Jeder Schritt wird dokumentiert. Ihr Gerät bleibt Ihr Gerät, zurückgegeben mit Abschlussprotokoll zum Gerätezustand.

Werkzeuge: Logic Analyzer · SPI/JTAG-Programmer · BLE/Thread-Sniffer · ChipWhisperer für Side-Channel-Analysen bei vereinbartem Bedarf. Je nach Prüfumfang: EM-Fault-Injektion, hochbandige Oszilloskopie, EM-Nahfeldanalyse; Decapsulation und Röntgen in Zusammenarbeit mit spezialisierten Partnern.

Scoping

Der Umfang folgt der Produktarchitektur.

Architektur

Produktarchitektur, Hardware-Plattform, Boot-Ablauf, Update-Pfad, Protokolle, Applikationen und angebundene Dienste.

Angreifer-Annahmen

Physischer Zugang, Netzwerkzugang, Credentials, Produktmuster, Firmware-Images, Source Code oder andere vereinbarte Startbedingungen.

Technische Tiefe

Wir wählen die Methoden, die die tatsächliche Sicherheitsfrage beantworten, statt das Produkt in eine feste Checkliste zu zwingen.

Ein vollständiges Architektur-Paket ist vor dem ersten Gespräch nicht erforderlich.

ERGEBNISSE

Was Sie erhalten

Reproduzierbare Befunde

Schritte, Nachweise und betroffene Komponenten, ausreichend, damit Engineering-Teams das Problem reproduzieren können.

Technische Auswirkung

Was die Schwäche unter den vereinbarten Angreifer-Annahmen tatsächlich ermöglicht.

Attack-Path-Kontext

Wie Befunde über die Produktschichten zusammenwirken, statt isolierter Scanner-Beobachtungen.

Remediation & Retest

Technischer Remediation-Kontext und Verifikation der Fixes gegen den ursprünglichen Angriffspfad, soweit Retesting im Umfang liegt.

FINDING 04
Recovery-Pfad akzeptiert gedowngradete Firmware
ACCESS
physisches Gerät
PATH
recovery → signiertes Legacy-Image → angreifbarer Dienst
IMPACT
persistente Ausführung angreifbarer Firmware
STATUS
reproduzierbar
Typische Anlässe

Wann dieses Assessment passt

Neues Gerät oder neue Embedded-Plattform vor dem Release
Größere Hardware-, SoC- oder Firmware-Architekturänderung
Neuer OTA- oder Firmware-Update-Mechanismus
Security-Assurance-Anforderung eines Kunden
CRA- / EN-18031- / IEC-62443-Nachweisanforderung
Bestehendes Produkt, das nie unterhalb der Applikationsschicht getestet wurde
Gemeldete Schwachstelle mit unklarem echten Produkt-Impact
Secure Boot, Geräte-Identität oder Key-Handling im Kontext bewerten
PRODUCT-SECURITY-ANFORDERUNGEN

Soll das Assessment eine regulatorische Anforderung stützen?

Wo erforderlich, lassen sich Assessment-Umfang und Befunde auf relevante technische Anforderungen aus CRA, EN 18031 und IEC 62443 mappen.

CRAEN 18031IEC 62443
Technisches Testen und Nachweise. Zertifizierung ist nicht Teil des Umfangs.
Dr. Ewan Fleischmann
Technische Leitung

Dr. Ewan Fleischmann

Gründer · Product Security & Kryptografie

22+ Jahre IT-Security · PhD Kryptografie · OSCP · OSCE · CISSP

Sie bauen ein Produkt, das ernsthaften Security-Testing braucht?

Sagen Sie uns, was Sie bauen, in welcher Phase es steht und was getestet werden soll. Der Umfang folgt aus dem Produkt.

Auf Wunsch zuerst NDA.