Cryptography Review
Review der kryptografischen Architektur und Implementierung, von Schlüsselgenerierung, Provisionierung und Speicherung bis zu Signatur, Geräte-Identität, Secure Boot, Firmware-Updates und Protokoll-Sicherheit.
Wo die Implementierung die Sicherheit des Trust-Modells bestimmt, folgen wir ihr in Firmware, Source Code oder Protokoll-Verhalten.
Kryptografie ist ein System, kein Algorithmus.
Starke Primitive kompensieren keine schwache Schlüssel-Handhabung, gebrochene Vertrauensannahmen oder fehlerhafte Implementierung. Ein sicheres Design hängt davon ab, wo Schlüssel entstehen, wo sie leben, wer sie nutzen kann und wie sich Vertrauen über den Produkt-Lebenszyklus ändert.
Die entscheidende Frage ist nicht „Nutzen wir einen starken Algorithmus?“, sondern: Bleibt der komplette Trust- und Schlüssel-Lebenszyklus im echten Produkt sicher?
Was wir reviewen
Kryptografische Architektur
Algorithmen, Protokolle, Trust-Anker, Schlüsselhierarchie, Sicherheitsannahmen und wo kryptografische Entscheidungen getroffen werden.
Schlüssel-Lebenszyklus
Generierung, Entropie-Quellen, Provisionierung, Verteilung, Speicherung, Zugriff, Rotation, Revocation und Stilllegung.
Signatur & Verifikation
Firmware-Signierung, Update-Autorisierung, Secure Boot, Zertifikate, Trust-Anker-Handling und Signatur-Prüflogik.
Geräte-Identität
Geräte-individuelle Credentials, PKI, Provisionierung in der Fertigung, Klon-Widerstand, Authentisierung, Backend-Vertrauen und Revocation für Offline-Fleets.
Protokoll-Kryptografie
Handshake-Design, Authentisierung, Verschlüsselung, Nonce-Handling, Replay-Schutz, Session-Aufbau und Schlüsselableitung.
Implementierung
Krypto-APIs, Zufall, Secret-Handling, Vergleichslogik, Parser-Verhalten und Implementierungsfehler in Firmware oder Source Code.
Der Review kann auf Architektur-Ebene bleiben oder ausgewählten Trust-Pfaden in Implementierung, Firmware und Protokolle folgen.
Die Primitive kann korrekt sein, während das System bricht.
Provisionierung → Geteilte Identität → Fleet-Impact
Geräte-Credentials werden korrekt erzeugt, aber über eine Produktlinie wiederverwendet. Die Kompromittierung eines Geräts ermöglicht die Impersonation anderer.
Signatur → Update → Persistente Kompromittierung
Firmware-Signaturen werden korrekt verifiziert, aber ein alter, vertrauter Schlüssel oder Rollback-Pfad autorisiert weiterhin angreifbare Firmware.
Protokoll → Nonce-Wiederverwendung → Key Recovery
Der Verschlüsselungsalgorithmus ist solide, aber der Protokoll-Zustand führt unter einer behebbaren Fehlerbedingung zur Nonce-Wiederverwendung.
Der Umfang folgt dem Trust-Modell.
Architektur
Schlüssel, Identitäten, Signatur-Systeme, Trust-Anker, Protokolle, Produkt-Lebenszyklus und die Komponenten, die kryptografische Operationen ausführen.
Angreifer-Annahmen
Physischer Gerätezugang, extrahierte Firmware, kompromittierter Client, Netzwerk-Angreifer, böswilliger Nutzer, geleakter Credential oder ein anderer vereinbarter Startpunkt.
Technische Tiefe
Wir reviewen zuerst das Trust-Modell und folgen den Bereichen, in denen die Implementierung entscheidet, ob die kryptografischen Annahmen tatsächlich halten.
Source Code ist nützlich, aber nicht immer erforderlich. Auch Firmware, Protokoll-Mitschnitte, Architektur-Dokumentation und Testgeräte liefern die nötige Evidenz. Wo die Trust-Frage Firmware, Protokolle oder Gerätearchitektur berührt, folgt der Review diesen Implementierungspfaden nach Bedarf.
Was Sie erhalten
Trust-Modell-Befunde
Wo kryptografische Annahmen über Komponenten oder Lebenszyklus-Zustände hinweg brechen.
Implementierungs-Befunde
Konkrete Schwächen in Key-Handling, Verifikationslogik, Protokoll-Verhalten oder kryptografischer Implementierung.
Exploitability-Kontext
Was ein Angreifer tatsächlich gewinnt und welche Annahmen dafür nötig sind.
Remediation-Pfad
Die technischen Änderungen in Architektur, Schlüssel-Lebenszyklus oder Implementierung, mit Retest, wo angebracht.
- TRUST
- Geräte-Zertifikat
- PATH
- Credential extrahieren → Identität klonen → Backend authentisieren
- IMPACT
- Geräte-Impersonation
- SCOPE
- flottenweit
Wann dieser Review passt
Soll der Review eine regulatorische Anforderung stützen?
Kryptografische Kontrollen, Key Management, sichere Updates und Identitäts-Mechanismen können Teil von Product-Security-Anforderungen sein. Wo nützlich, lassen sich Befunde auf relevante technische Anforderungen mappen.
Dr. Ewan Fleischmann
PhD Kryptografie · 25+ wissenschaftliche Publikationen · 22+ Jahre IT-Security
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.