Ihre Hardware-Sicherheit funktioniert. Daran liegt nicht das Problem.

Diese Einwendung hören wir regelmäßig in ähnlicher Form: „Wir verwenden bereits Android StrongBox. Wir haben ECDH-Schlüsselaustausch. Unsere Schlüssel verlassen niemals die Hardware. Warum sollten wir zusätzlich White-Box-Kryptographie benötigen?“ 

Das ist eine berechtigte Frage. StrongBox, der auf TEE basierende Keystore und ECDH sind zweifellos starke Technologien. Sie abzulehnen wäre intellektuell unredlich – und wenig hilfreich. Anstatt sie also zu verwerfen, sollten wir uns ansehen, was sie tatsächlich schützen und wo die Sicherheitslücken liegen.

Die Tresor-Analogie – und warum sie unvollständig ist 

Hardware-Sicherheitssysteme sind in einer Sache hervorragend: Schlüssel sicher aufbewahren safe StrongBox speichert Schlüssel in einem Tresorraum und führt kryptografische Operationen durch, ohne jemals das Rohmaterial der Schlüssel preiszugeben. Das ist echter Schutz und darauf kommt es an. 

Doch hier ist die Frage, die die meisten Sicherheitsarchitekten nicht stellen: Liegt der Tresor im Weg der wichtigsten Operationen? 

Für Android-Apps, die Standard-Serververbindungen herstellen – etwa über HttpsURLConnection, OkHttp oder ähnliche vom Betriebssystem verwaltete APIs – lautet die Antwort größtenteils nein. Der TLS-Stack von Android läuft über BoringSSL und Conscrypt, zwei Softwarebibliotheken, die den ECDH-Schlüsselaustausch vollständig in Software abwickeln, ohne StrongBox oder TEE Keystore zu verwenden. TLS-Sitzungsschlüssel liegen unabhängig von der Gerätehardware als Rohbytes im Speicher vor. 

Das ist kein Designfehler von Android – es ist eine architektonische Gegebenheit, die in den meisten Diskussionen über App-Sicherheit außer Acht gelassen wird. Ihr Tresor ist hervorragend. Bei TLS befindet sich der Tresor jedoch nicht im selben Gebäude. 

Wenn die Binärdatei die Angriffsfläche ist 

Lassen wir TLS einmal beiseite. Betrachten wir eine Anwendung, die für ihre eigenen kryptografischen Operationen hardwaregestützte Schlüssel verwendet – ordnungsgemäß bereitgestellt, von ECDH abgeleitet und sicher in StrongBox gespeichert. Das ist eine starke Konfiguration. 

Überlegen Sie nun, was ein Angreifer mit Ihrer App tatsächlich macht. Er versucht nicht, den Schlüssel aus StrongBox zu extrahieren – das ist schwierig. Er lädt Ihre App herunter, führt einen Disassembler aus und liest Ihren Code. 

Sie ermitteln die Logik des Authentifizierungshandshakes: das Protokoll, das Ihre App zur Kommunikation mit Ihrem Server verwendet, den Authentifizierungsablauf und die API-Struktur. Mit diesem Wissen benötigen sie Ihren Schlüssel nicht. Sie entwickeln eine modifizierte App, die einen legitim aussehenden Handshake von Grund auf neu durchführt. StrongBox on sind Das Gerät enthält nun einen Schlüssel, dem Ihr Server vertraut. 

Der schwerwiegendere Angriff besteht nicht im Auslesen der entschlüsselten Daten eines einzelnen Nutzers. Vielmehr geht es darum, Ihr Protokoll so gut zu verstehen, dass authentifizierte API-Anfragen gefälscht werden können – potenziell in großem Umfang und potenziell als beliebige Nutzer. Hardware-Sicherheit bietet hierfür keine Lösung, da der Angriff die Hardware selbst nicht berührt. 

Dies ist die Lösung für die Lücke in der White-Box-Kryptographie und der Anwendungshärtung: der Schutz der Protokolllogik selbst, nicht nur des Schlüssels. 

Das Fragmentierungsproblem (solange es anhält) 

Selbst wenn man die Problematik von BoringSSL außer Acht lässt, besteht bei der Hardware-Sicherheit unter Android ein Abdeckungsproblem. Laut der DroidCCT-Studie – einer von Experten begutachteten Analyse der Android-Gerätesicherheit – ist StrongBox nur auf 8.7 % der Premium-Geräte, 7.2 % der Mittelklasse-Geräte und lediglich 0.2 % der Einsteigergeräte verfügbar. Die meisten Ihrer Nutzer haben diese Software also nicht. 

Bei iOS sieht es anders aus: Secure Enclave ist auf allen aktuellen iOS-Geräten vorhanden und bietet einen starken, hardwarebasierten Schutz. Das Argument der Fragmentierung trifft hauptsächlich auf Android zu. 

Es ist wichtig zu beachten, dass dieses Argument nicht ewig gültig ist. Die Hardwareverfügbarkeit wird sich mit der Zeit verbessern, und einige Sicherheitsrichtlinien empfehlen bereits White-Box-Kryptografie als temporäre Ergänzung zu TEE, bis die Hardware-Einführung nachzieht. Die Argumente für binäres Reverse Engineering, Attestierung und Herstellerunabhängigkeit bleiben bestehen; die Fragmentierung ist das aktuell überzeugendste Argument. Für manche Organisationen – insbesondere solche mit regulatorischen oder Lieferkettenbeschränkungen – ist die Reduzierung der Abhängigkeit von der Sicherheitsimplementierung eines einzelnen Hardware-Herstellers selbst ein Designziel. 

Was „App-Layer-Attestierung“ tatsächlich bedeutet 

Eine weitere Lücke, die es wert ist, erwähnt zu werden: Ihr Server hat einen Handshake abgeschlossen, weiß aber nicht, mit wem er kommuniziert. 

Es kann nicht unterscheiden zwischen Ihrer legitimen App, die auf einem echten Gerät läuft, einer neu verpackten Version Ihrer App, die auf einem gerooteten Gerät läuft, und einem vollständig synthetischen Client, der Ihren Handshake nach dem Reverse Engineering Ihres Protokolls nachgeahmt hat. 

Die Google Play Integrity API hilft. MEETS_STRONG_INTEGRITY mit korrekter Nonce- und RequestHash-Bindung reduziert die Angriffsfläche für Umgehungen erheblich. Dennoch bleibt das Replay auf sauberen Proxy-Geräten unabhängig von der Integritätsstufe ein Restrisiko. 

White-Box-Kryptografie bietet eine Attestierung auf Anwendungsebene: einen kryptografischen Nachweis, dass die Anfrage von einer unveränderten Anwendung stammt, die geschützte Protokolllogik ausführt – unabhängig von Vertrauenssignalen des Betriebssystems oder der Hardware. Es handelt sich um ein zweites, unabhängiges Signal – kein Ersatz für Play Integrity, sondern die Ebene, die das abdeckt, was Play Integrity nicht leisten kann. 

Die ausgefeiltere Variante – und unserer Ansicht nach die Zukunft der Branche – ist die kontinuierliche Verhaltensüberwachung: Hat dieser Client seit seiner letzten Anfrage Manipulationserkennungen ausgelöst? Ein Server, der seine Antwort basierend auf dem Sicherheitsstatus eines Clients zur Laufzeit anpassen kann, ist deutlich robuster als ein Server, der bei Sitzungsaufbau eine binäre Entscheidung zwischen vertrauenswürdig und nicht vertrauenswürdig trifft. 

Das Gesamtbild 

Hardware-Sicherheit ist der Tresor. White-Box-Kryptographie und Anwendungshärtung sind der gepanzerte Transport – sie schützen alles, was den Tresor verlassen und in die reale Welt vordringen muss. 

Bei den meisten Android-TLS-Operationen befindet sich der Vault nicht im Übertragungspfad. Wo er sich im Übertragungspfad befindet, schützt er weder das Protokoll noch die Binärdatei oder die Attestierungsschicht. Dies sind keine Gründe, die Hardware-Sicherheit aufzugeben – sie sollten vielmehr als eine Ebene eines umfassenden Schutzsystems und nicht als die endgültige Lösung betrachtet werden. 

Dies sind vier der Argumente, die wir intern mit unseren Entwicklungs-, Sicherheits- und Kundenerfolgsteams auf Herz und Nieren geprüft haben. Es gibt noch mehr zu diesem Thema – unter anderem, wie dies auf spezifische Plattformen und Compliance-Rahmenwerke zutrifft (Digital.ai Key & Data Protection besitzt das FIPS 140-3-Zertifikat Nr. 4910 und erfüllt die Anforderungen der regulierten Branche. 

Wenn Sie den Schutz Ihrer App evaluieren und sich einen umfassenden Überblick über die Auswirkungen auf Ihre Umgebung verschaffen möchten, freuen wir uns auf das Gespräch. Fordern Sie noch heute eine Demo an