Die drei stärksten Argumente gegen White-Box-Kryptographie – und warum sie am Kern der Sache vorbeigehen.

In Teil 1 der Serie Wir haben untersucht, wo die Hardware-Sicherheit an ihre Grenzen stößt: Warum der TLS-Stack von Android StrongBox vollständig umgeht, warum Hardware-Fragmentierung die meisten Nutzer ungeschützt lässt und warum Hardware-Sicherheit die Protokollschicht nicht vor binärem Reverse Engineering schützen kann. Falls Sie den Artikel noch nicht gelesen haben, ist dieser Kontext hier wichtig. 

Dieser Beitrag richtet sich an eine andere Art von Skeptiker – nicht an diejenigen, die Hardware-Sicherheit für ausreichend halten, sondern an diejenigen, die White-Box-Kryptografie bereits gänzlich abgelehnt haben. Dies sind die drei Argumente, die wir am häufigsten hören, und sie verdienen eine klare Antwort. 

Argument 1: „Die WBC verstößt gegen das Kerckhoffsche Prinzip. Sie ist Scharlatanerie.“ 

Die akademische Kritik lautet wie folgt: Kerckhoffs Prinzip besagt, dass ein kryptografisches System selbst dann sicher sein sollte, wenn alles darüber – außer dem Schlüssel – öffentlich bekannt ist. White-Box-Kryptografie (WBC) verbirgt die Implementierung, um den Schlüssel zu schützen, was bedeutet, dass ihre Sicherheit auf der Geheimhaltung beruht. Das ist keine echte Sicherheit. Jede öffentliche WBC-Implementierung in Capture-the-Flag-Wettbewerben wie WhibOx wird innerhalb weniger Tage geknackt. Es ist ein unwissenschaftlicher Trick. 

Diese Kritik verkennt, was WBC tatsächlich tut – und wendet dabei das Prinzip, auf das sie sich beruft, falsch an. 

WBC verbirgt den Algorithmus nicht. AES in White-Box-Form ist weiterhin AES – dieselben Eingaben, dieselben Ausgaben, dieselben mathematischen Operationen. Der Algorithmus ist vollständig öffentlich und unverändert. WBC ändert lediglich die Art und Weise, wie der Schlüssel gespeichert und verwendet wird, indem er so in die transformierte Implementierung eingebettet wird, dass seine Extraktion deutlich erschwert wird. Der Algorithmus bleibt öffentlich. Der Schlüssel bleibt geheim. Genau das fordert Kerckhoffs Prinzip. 

Die Kritiker verwechseln „die Implementierung ist gehärtet“ mit „der Algorithmus ist geheim“. Das ist nicht dasselbe. Die Härtung einer Implementierung zum Schutz des Schlüssels ist ein Schlüsselschutzmechanismus – keine Verletzung des Prinzips, sondern dessen Erfüllung. 

Stellen Sie sich nun vor, was ohne diesen Schutz passiert. Der Angreifer hat Ihre App. Er hat Zugriff auf das Gerät. Das Extrahieren eines Schlüssels ist kein komplexer Angriff – es ist kinderleicht. Suchen Sie die ARM-AES-Anweisung im Binärcode. Setzen Sie einen Haltepunkt. Führen Sie die App durch die Operation. Lesen Sie den Schlüssel aus dem Register. Fertig, in wenigen Minuten, mit frei verfügbaren Tools. An diesem Punkt greift Kerckhoffs Prinzip nicht mehr – der Schlüssel ist verloren. 

WBC ist das, was Kerckhoffs' Prinzip in einer feindlichen Umgebung anwendbar macht. Es ist der Mechanismus, der den Schlüssel geheim hält, selbst wenn der Angreifer Ihre Binärdatei und Ihr Gerät besitzt. 

Es ist erwähnenswert, dass derselbe Breakpoint-Angriff auch gegen OpenSSL funktioniert: Man findet die AES-Anweisung, setzt einen Breakpoint und liest das Register aus. Niemand veranstaltet CTF-Wettbewerbe, um die Schlüsselextraktion von OpenSSL oder anderen Open-Source-Kryptobibliotheken zu knacken, da diese nie für den Schutz von Schlüsseln in einer feindlichen Laufzeitumgebung konzipiert wurden. WBC wird an einen Standard angelegt, den keine gängige Kryptobibliothek erfüllt. Der Unterschied besteht darin, dass WBC aktiv versucht, das Problem zu lösen. 

Die Kritik von WhibOx verdient eine direkte Antwort: Ja, CTF-Implementierungen können Sicherheitslücken aufweisen. Kommerzielle Implementierungen stellen jedoch eine andere Kategorie dar. Bekannte DFA-Schwachstellen in unseren RSA/AES-Implementierungen wurden 2019 im Rahmen von TFIT behoben. Gegen unsere Elliptic-Curve-Implementierungen wurden bisher keine DFA-Angriffe nachgewiesen. Unser Produkt verfügt über das FIPS-140-3-Zertifikat Nr. 4910 – eine unabhängige Validierung, die für akademische CTF-Beiträge nicht verfügbar ist. 

Noch wichtiger ist, dass WBC nicht isoliert agiert. Produkte zur App-Härtung – Verschleierung, Erkennung dynamischer Instrumentierung, Debugger-Erkennung und Hooking-Erkennung – blockieren aktiv die Werkzeuge, die ein Angreifer für Seitenkanalangriffe benötigt, um ungeschützte Implementierungen zu knacken. Ein Angreifer, der Frida gegen eine gehärtete Anwendung einsetzt, sieht sich nicht einem verschleierten Algorithmus gegenüber, sondern einem System, das seine Werkzeuge erkennt und darauf reagiert. Das ist keine Sicherheit durch Verschleierung, sondern eine mehrschichtige Verteidigung. 

Argument 2: „Die Aufhebung des Regelwerks macht den WBC wertlos.“ 

Dieser Tipp stammt von Sicherheitsarchitekten, die ihr Fachgebiet beherrschen. Die Argumentation: Selbst wenn man den Rohschlüssel nicht aus einer White-Box-Implementierung extrahieren kann, ist das auch nicht nötig. Man kopiert einfach den gesamten Binärcode der White-Box-Anwendung und führt ihn auf dem eigenen Server aus. Damit hat man ein fertiges Entschlüsselungstool. Eine Schlüsselextraktion ist nicht erforderlich. 

Es handelt sich um einen echten Angriff. Gegen eine naive Implementierung ohne serverseitige Validierung funktioniert er. 

Bei einer ordnungsgemäß implementierten Bereitstellung scheitert es an der Servergrenze – und hier ist der Grund dafür. 

Eine kopierte Binärdatei ist nicht Ihre App. Sie verfügt nicht über die Laufzeitsicherheit Ihrer App, die auf einem legitimen, unveränderten Gerät ausgeführt wird. App-Härtungsmechanismen generieren Verhaltensdaten: Hat dieser Client Manipulationserkennungen ausgelöst? Ist die Ausführungsumgebung sauber? Handelt es sich um eine verifizierte Laufzeitumgebung? 

Ein kopiertes White-Box-Modul, das auf dem Server eines Angreifers ausgeführt wird, besteht diese Prüfungen nicht. Es verfügt über keine App-Aware-Telemetriedaten und kann die Verhaltensprüfung nicht bestehen. Der Server kann – und sollte – seine Reaktion an den Sicherheitsstatus des Clients zur Laufzeit anpassen. Ein Client, der wie eine kopierte Binärdatei aussieht, wird entsprechend behandelt. 

Neben der Verhaltensbestätigung bedeutet der gerätespezifische Schlüsselaustausch, dass eine auf der Bereitstellung eines Geräts basierende White-Box-Implementierung nicht für ein anderes Zielgerät funktioniert. Der extrahierte Schlüssel ist nur für die spezifische Serverinteraktion, aus der er stammt, nutzbar – nicht als allgemeines Entschlüsselungswerkzeug. 

Code-Lifting ist ein realer Angriffsvektor, der eine entsprechende architektonische Reaktion erfordert. Diese Reaktion besteht in der Verhaltensbestätigung und der eindeutigen Schlüsselverwendung pro Gerät – nicht darin, den Angriff zu ignorieren. 

Argument 3: „Hardware-Sicherheit macht Software-Schutz überflüssig.“ 

Dieses Argument stammt von Plattformbetreibern und Hardwareherstellern: Da StrongBox, TEE-basierte Keystores und Secure Enclaves mittlerweile ausgereift sind, gilt softwarebasierter kryptografischer Schutz als überholt. Anwendungen sollten auf Hardware-Isolationsmechanismen zurückgreifen. Software-Verschleierung ist redundant. 

Die technischen Grundlagen dieses Arguments haben wir in Teil 1 behandelt, aber es lohnt sich, hier Klartext zu reden: Die Prämisse ist falsch, und zwar nachweislich. 

Der TLS-Stack von Android – der von jeder App genutzt wird, die standardmäßige HTTPS-Verbindungen über HttpsURLConnection oder OkHttp herstellt – verarbeitet den ECDH-Schlüsselaustausch vollständig in Software über BoringSSL und Conscrypt. Er nutzt weder StrongBox noch den TEE-Keystore. TLS-Sitzungsschlüssel liegen auf jedem Android-Gerät als Rohdaten im Speicher vor, unabhängig von den vorhandenen Hardware-Sicherheitsfunktionen. 

Dies ist keine rein theoretische Lücke. Sie ist im BoringSSL-Quellcode, in den Diskussionen der Conscrypt-Entwickler und in Fachartikeln dokumentiert. Hardwarebasierte Sicherheitslösungen schützen gespeicherte Schlüssel hervorragend bei bestimmten hardwaregestützten Operationen. Sie sind jedoch für die gängigsten kryptografischen Operationen in den meisten Android-Apps nicht relevant. 

Über die TLS-Lücke hinaus schützt Hardware-Sicherheit Ihre Binärdatei nicht vor Reverse Engineering. Sie verhindert nicht, dass Angreifer Ihr Protokoll verstehen und authentifizierte Anfragen fälschen. Sie bietet keine Attestierung auf Anwendungsebene. Sie behebt keine Schwachstellen in der Laufzeitumgebung. 

Hardware-Sicherheit ist der Tresor. White-Box-Kryptografie und Anwendungshärtung sind der gepanzerte Transport – sie schützen alles, was den Tresor verlassen und in die reale Welt gelangen muss. Tresor und gepanzerter Transport ergänzen sich. Die Behauptung, ein guter Tresor mache den gepanzerten Transport überflüssig, verkennt die jeweilige Funktion. 

Die ehrliche Zusammenfassung 

White-Box-Kryptografie ist nicht unknackbar. Kein seriöser Anbieter behauptet das. Ihr Anspruch ist vielmehr eine Kostenasymmetrie: Die Kosten und der Aufwand für einen erfolgreichen Angriff werden so hoch angesetzt, dass die meisten Angreifer zu einfacheren Zielen übergehen. Erfolgreiche Angriffe erfordern Ressourcen, die sonst nur bei staatlich geförderten oder hochspezialisierten Operationen üblich sind – und nicht etwa bei Anfängern mit Scriptkiddies wie Frida. 

Die akademische Kritik an WBC ist gegenüber naiven, eigenständigen Implementierungen berechtigt. Sie trifft jedoch nicht auf eine ordnungsgemäß konzipierte Bereitstellung zu, die WBC mit Anwendungshärtung, Verhaltensattestierung und gerätespezifischer Schlüsselidentifizierung kombiniert. 

Dies sind drei der Argumente, die wir mit unseren Entwicklungs-, Sicherheits- und Kundenservice-Teams eingehend geprüft haben. Wenn Sie den Schutz Ihrer Anwendung evaluieren und erfahren möchten, wie dies auf Ihre spezifische Umgebung und Ihr Bedrohungsmodell zutrifft, freuen wir uns auf ein Gespräch mit Ihnen. Fordern Sie noch heute eine Demo an