Certificate Pinning: Was es ist, Methoden der Zertifikatsbindung und wie man es implementiert

Vor- und Nachteile von Certificate Pinning

Certificate Pinning erhöht die Sicherheit mobiler Anwendungen erheblich, belastet aber das Entwicklungsteam operativ. Es ist wichtig, die Sicherheitsvorteile gegen die Risiken der Verbindungssperrung aufgrund fehlerhafter Implementierung abzuwägen.

Der Hauptvorteil ist der Schutz vor Man-in-the-Middle-Angriffen, einschließlich Fällen von CA-Kompromittierung. Pinning macht gefälschte Zertifikate, die von einem Angreifer ausgestellt wurden, nutzlos: Selbst wenn eine CA eine Fälschung signiert hat, wird die Anwendung sie ablehnen. Ein zusätzlicher Vorteil ist der Schutz vor Unternehmens-Proxyservern, die Zertifikate zur Verkehrsinspektion austauschen. Laut Google Security Blog (2023) haben Anwendungen mit Pinning eine 86% geringere Wahrscheinlichkeit, durch Verkehrsabfangen kompromittiert zu werden, im Vergleich zu Anwendungen, die nur die standardmäßige TLS-Prüfung verwenden.

Der Hauptnachteil des Pinning ist das Risiko der Selbstsperrung: Wenn sich das Serverzertifikat (Erneuerung, Anbieterwechsel, Schlüsselrotation) vor der Veröffentlichung des Anwendungsupdates ändert, verlieren Benutzer den Zugriff auf den Server. Zusätzliche Nachteile: Debugging-Komplexität (jede Konfigurationsänderung erfordert Pin-Updates), APK-Größensteigerung um 5–15 KB bei Verwendung von TrustKit und die Unmöglichkeit, Änderungen ohne neue Version schnell rückgängig zu machen. Zur Risikominimierung werden Backup-Pins, automatische Rotation alle 2–3 Monate und eine Schonfrist verwendet, in der die Anwendung sowohl das alte als auch das neue Zertifikat akzeptiert. Es ist auch wichtig zu beachten, dass während der Entwicklung mit aktiviertem Pinning keine Proxy-Tools (Burp Suite, Charles) zum Debuggen von Netzwerkanfragen verwendet werden können — für Entwicklungs-Builds muss Pinning über das BuildConfig.DEBUG-Flag deaktiviert werden, und QA-Tests sollten mit der Release-Signatur bei aktiviertem Schutz durchgeführt werden. Einige Teams verwenden eine Staging-Domain mit einem separaten Pinning-Zertifikat für die Entwicklungsumgebung, um den Schutz auch während der Entwicklung aufrechtzuerhalten.

Implementierung von Certificate Pinning unter Android

Betrachten wir ein Beispiel zur Implementierung von Certificate Pinning unter Android mit OkHttp — der Standardbibliothek für Netzwerkanfragen. OkHttp bietet einen integrierten CertificatePinner, der SHA-256-Hashes öffentlicher Schlüssel akzeptiert.

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .add(
        "api.example.com",
        "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Im obigen Code fügen wir zwei Pins für die Domain api.example.com hinzu: den primären (aktuelles Zertifikat) und einen Backup-Pin (für Rotation). OkHttp überprüft automatisch, ob das Serverzertifikat mit einem der angegebenen SHA-256-Fingerabdrücke übereinstimmt. Um den SHA-256-Fingerabdruck des Zertifikats zu erhalten, verwenden Sie den Befehl: openssl s_client -connect api.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64. Es ist wichtig, Fingerabdrücke nicht als Klartext im Code zu speichern, sondern verschlüsselt oder verschleiert: Die statische Analyse von MobSF findet leicht rohe SHA-256-Strings in DEX-Dateien. Es wird empfohlen, Pins in res/raw-Ressourcen, verschlüsselt über AES, zu speichern und sie beim Start der Anwendung über nativen Code (NDK/JNI) zu entschlüsseln.

iOS-Implementierung über TrustKit

Unter iOS ist das wichtigste Werkzeug für Certificate Pinning die Open-Source-Bibliothek TrustKit. Anders als OkHttp wird TrustKit deklarativ über Info.plist konfiguriert, was Pin-Änderungen ohne Neukompilierung der Anwendung ermöglicht. Die Konfiguration umfasst ein Wörterbuch mit Domains und ein Array von SHA-256-Fingerabdrücken öffentlicher Schlüssel. TrustKit fängt automatisch NSURLSession-Anfragen ab und überprüft Zertifikate vor Beginn der Datenübertragung. Eine entscheidende Funktion von TrustKit ist die Unterstützung von Pin-Validierungsberichten: Die Bibliothek kann bei Pin-Ungleichheit Berichte an einen bestimmten Endpunkt senden, was eine schnelle Reaktion auf Zertifikatsanomalien ermöglicht. Apple bietet ab iOS 14 auch einen nativen NSPinnedDomains-Mechanismus in Info.plist, aber TrustKit bleibt aufgrund der flexibleren Konfiguration, Berichtsunterstützung und der Möglichkeit zum heißen Austausch von Pins ohne OS-Updates die bevorzugte Wahl. Es ist wichtig zu beachten, dass TrustKit über den didReceiveChallenge-Delegaten in URLSession integriert wird und bei erfolgreicher Pin-Überprüfung .performDefaultHandling und bei Nichtübereinstimmung .cancelAuthenticationChallenge zurückgibt. Zur Überwachung von Pin-Validierungsberichten wird empfohlen, einen separaten Endpunkt einzurichten, der die Fehlerhäufigkeit analysiert: Wenn die Anzahl der Berichte stark ansteigt — kann dies auf einen MitM-Angriff oder ein bevorstehendes Zertifikatsablaufen hindeuten, das sofortige Pin-Updates erfordert.