Kryptografie scheitert selten daran, dass ein Algorithmus gebrochen ist, sondern an den Details drumherum: an einer Nonce, die sich wiederholt, an einem Zufallsgenerator, der mit der Uhrzeit initialisiert wird, an einer Signatur, die zwar geprüft, aber nicht an ihren Kontext gebunden wird, an einem Schlüssel, der korrekt abgeleitet und dann in ein Log geschrieben wird.
Diese Fehler fallen nicht auf. Das System funktioniert, die Tests laufen durch, und aus den Signaturen, die es bereits veröffentlicht hat, lässt sich ein privater Schlüssel zurückgewinnen. Wir prüfen das Design auf seine Annahmen und die Implementierung darauf, ob diese Annahmen zutreffen, und wir testen die Ausgaben, wo die Mathematik ein Urteil erlaubt: Signaturen, Zufallswerte und Chiffretexte.
01Umfang
Was wir testen
Protokolldesign: Authentifizierung, Schlüsselaustausch, Aufbau von Sitzungen
Signaturverfahren: Nonce-Erzeugung bei ECDSA und EdDSA, Malleability, Replay
Erzeugung, Ableitung, Speicherung, Rotation und Vernichtung von Schlüsseln
Erzeugung von Zufallszahlen und Entropiequellen
Betriebsarten der Verschlüsselung, Padding, Authentifizierung des Chiffretexts
Wallets und Verwahrung: Umgang mit Seeds, Ableitungspfade, Signaturabläufe
Schwellenwert- und Mehrparteienverfahren, Multi-Signatur-Konfigurationen
Integration von Hardware-Sicherheitsmodulen und Diensten zur Schlüsselverwaltung
Seitenkanäle in Software: Timing, Fehlerverhalten, Umgang mit dem Speicher
02Vorgehen
Wie die Arbeit abläuft
01
Review des Designs
Wir lesen die Spezifikation und halten fest, welche Sicherheitseigenschaften das Design beansprucht und von welchen Annahmen es abhängt.
02
Review der Implementierung
Der Code wird mit dem Design verglichen. Wir sehen uns an, wie Bibliotheken verwendet werden und wo die Implementierung von dem abweicht, was das Design verlangt.
03
Analyse der Ausgaben
Signaturen, Nonces und Zufallswerte, die das System erzeugt, werden mit gitterbasierten und statistischen Methoden auf Verzerrung, Wiederverwendung und Struktur untersucht.
04
Vorführung des Angriffs
Ist eine Schwäche ausnutzbar, führen wir den Angriff an Testschlüsseln vor, die eigens dafür erzeugt wurden. Schlüssel, die echte Werte schützen, sind nie Ziel einer Vorführung.
Schweregrad jedes Befunds als Punktwert und Vektor.
FIRST
06Fragen
Fragen zu dieser Leistung
Wir nutzen eine bekannte Bibliothek. Gibt es da etwas zu prüfen?
Ja. Die Bibliothek ist selten das Problem. Die Fehler liegen darin, wie sie aufgerufen wird, welche Parameter sie erhält und was vor und nach dem Aufruf mit den Schlüsseln geschieht.
Arbeiten Sie mit unseren produktiven Schlüsseln?
Nein. Wir arbeiten mit Testschlüsseln und mit öffentlichen Ausgaben wie Signaturen. Zeigt die Analyse öffentlicher Daten, dass ein produktiver Schlüssel gefährdet ist, werden Sie sofort informiert, und der Schlüssel wird nicht rekonstruiert.
Können Sie ein Protokoll prüfen, das es nur auf dem Papier gibt?
Ja, und das ist der günstigste Zeitpunkt dafür. Ein Designfehler, der vor der Implementierung gefunden wird, kostet eine Änderung an einem Dokument.
Tests von iOS- und Android-Apps zusammen mit ihrem Backend: Speicherung, Übertragung, Zusammenspiel mit der Plattform und Widerstand gegen Manipulation.
Anwendungssicherheit
08Anfrage
Sagen Sie uns, was getestet werden soll
Website-Check kostenlos
Antwort innerhalb von 1 Arbeitstag
NDA vor jedem technischen Detail
Festpreis für kostenpflichtige Projekte
Unverbindlich
Anfrage eingegangen
Referenznummer
Bewahren Sie die Referenznummer auf: Wir nennen diese Nummer in der gesamten weiteren Kommunikation mit Ihnen.
So geht es weiter
Ein Kundenbetreuer prüft die Anfrage und antwortet innerhalb von 1 Arbeitstag.
Wir vereinbaren den Prüfumfang, die Testregeln und einen sicheren Kanal für sensibles Material.
Sie erhalten ein Angebot mit Methode, Zeitplan und Festpreis. Für den kostenlosen Website-Check erhalten Sie die Genehmigung zur Unterschrift.
In der ersten Antwort bitten wir nie um Zahlung, Passwörter oder Fernzugriff.