Wireless & Protocol Security
Security-Testing drahtloser Schnittstellen und Produktprotokolle, von RF-Kommunikation, Discovery und Pairing bis zu Authentisierung, Protokoll-Reverse-Engineering, State-Handling und Implementierungsfehlern.
Wir testen den Kommunikationspfad als Teil des Produkts, einschließlich des Protokolls dahinter und der Komponenten, die den resultierenden Nachrichten oder Identitäten vertrauen.
Der Funkpfad ist erst der Anfang.
Wireless-Sicherheit hängt von mehr ab als vom Transport selbst. Discovery, Pairing, Identität, Protokoll-Zustand und die Produktfunktionen hinter der Schnittstelle bestimmen, was ein Angreifer tatsächlich erreichen kann.
Die engere Frage „Ist der Funk verschlüsselt?“ wird ersetzt durch: Kann ein Angreifer zum vertrauenswürdigen Peer werden, den Protokoll-Zustand manipulieren oder privilegiertes Produktverhalten auslösen?
Was wir testen
Funk-Schnittstellen & RF
Drahtlose Kommunikationspfade, Funktransport, Over-the-Air-Interaktion, exponierte Schnittstellen und produktspezifisches Wireless-Verhalten.
Discovery, Pairing & Enrollment
Geräte-Discovery, Onboarding, Peer-Binding, Erst-Vertrauen, Re-Pairing, Reset und Recovery-Verhalten.
Authentisierung & Autorisierung
Identitätsprüfung, Challenge-Response-Logik, Rollen, Controller-Vertrauen, privilegierte Kommandos und Trust-Übergänge.
Replay, Spoofing & State-Manipulation
Frische, Sequenz-Handling, Replay-Widerstand, gefälschte Peers, Session-Recovery und unerwartete Protokoll-Zustandsübergänge.
Protokoll-Reverse-Engineering
Nachrichtenformate, Kommandostruktur, Framing, Feld-Semantik, Checksummen, State Machines und undokumentiertes Verhalten.
Protokoll-Implementierung
Parser-Verhalten, malformed input, Protokoll-Kryptografie, Nachrichten-Validierung, Memory-Safety und Implementierungslogik in Firmware oder Produktsoftware.
Die konkrete Prüffläche folgt dem Kommunikationspfad. Das Testing kann auf der Funk-Schnittstelle bleiben oder dem Protokoll in Firmware, Applikationen und Backend-Komponenten folgen, wo die Vertrauensgrenze weiterläuft.
Produktspezifische Transporte können geprüft werden, wo der erforderliche Testaufbau verfügbar ist.
Wenn das Protokoll undokumentiert ist, rekonstruieren wir es.
Proprietäre Kommunikation muss oft verstanden werden, bevor sie sinnvoll angegriffen werden kann. Wir rekonstruieren Nachrichtenformate, Kommando-Semantik, Zustandsübergänge und Vertrauensentscheidungen, damit sich das Protokoll als System testen lässt.
Eine Wireless-Schwäche kann zur Produkt-Kompromittierung werden.
Pairing → Vertrauenswürdiger Controller → Geräte-Kontrolle
Ein Pairing-Workflow verifiziert das Gerät, bindet den Controller aber nicht stark. Ein Angreifer enrollt einen neuen Peer und erhält Zugriff auf privilegierte Produktfunktionen.
RF-Capture → Replay → Produkt-Zustandsänderung
Ein zustandsänderndes Funk-Kommando lässt sich mitschneiden und wiederholen, weil Frische nicht erzwungen wird. Das Gerät akzeptiert das wiederholte Kommando als legitim.
Protokoll-Frame → Parser → Firmware-Ausführung
Eine malformed drahtlose Nachricht erreicht einen Parser in einer privilegierten Firmware-Komponente. Ein Implementierungsfehler macht aus der Kommunikation Code-Ausführung auf dem Gerät.
Der Umfang folgt dem Kommunikationspfad.
Architektur
Funk-Schnittstellen, Transporte, Protokolle, Applikationen, Firmware, kommunizierende Komponenten und angebundene Backend-Dienste.
Angreifer-Annahmen
Lokale Nähe, mitgeschnittener Funkverkehr, unauthentisierter Controller, kompromittierter Peer, Netzwerkzugang, physischer Gerätezugang oder ein anderer vereinbarter Startpunkt.
Technische Tiefe
Wir klären zuerst, wie Funkkommunikation und Protokoll funktionieren, und testen dann die Vertrauensentscheidungen, Zustandsübergänge und Implementierungspfade, über die ein Angreifer das Produkt beeinflussen kann.
Vollständige Protokoll-Dokumentation ist nützlich, aber nicht erforderlich. Auch Testgeräte, Traffic-Mitschnitte, Client-Applikationen, Firmware und Live-Kommunikation liefern die Evidenz zur Rekonstruktion.
Was Sie erhalten
Wireless-/Protokoll-Modell
Eine technische Beschreibung des relevanten Kommunikationsflusses, der Protokollstruktur, Zustände und Vertrauensentscheidungen, soweit Reverse-Engineering Teil des Auftrags ist.
Reproduzierbare Befunde
Frames, Sequenzen, Captures, Requests, Skripte oder andere Nachweise, ausreichend, damit Engineering-Teams das Problem reproduzieren können.
Exploitability-Kontext
Was ein Angreifer erreicht, welche Nähe oder welcher Zugang nötig ist und ob die Schwäche in Firmware, Applikationen oder Backend-Dienste hineinreicht.
Remediation & Retest
Technischer Remediation-Kontext für Pairing, Protokoll-Design oder Implementierung, gefolgt von Verifikation der Fixes, soweit Retesting im Umfang liegt.
- ACCESS
- lokale RF-Nähe
- PATH
- discovery → Pairing → Controller-Enrollment → privilegiertes Kommando
- IMPACT
- unautorisierte Geräte-Kontrolle
- STATUS
- reproduzierbar
Wann dieses Assessment passt
Soll das Assessment eine regulatorische Anforderung stützen?
Authentisierung, Zugangskontrolle, sichere Kommunikation und Widerstand gegen Protokoll-Angriffe können Teil von Product-Security-Anforderungen sein. Wo nützlich, lassen sich Befunde auf relevante technische Anforderungen mappen.
Dr. Ewan Fleischmann
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.