Certificate Pinning in mobilen und Desktop-Anwendungen

Standard-TLS vertraut jedem Zertifikat, das von einer der etwa 150 im Betriebssystem vorinstallierten Root-CAs signiert wurde. Wird eine beliebige Root-CA kompromittiert oder unter Druck gesetzt, kann ein Angreifer ein Zertifikat für jede beliebige Domain erhalten und TLS-Datenverkehr abfangen. Certificate Pinning beschränkt das Vertrauen auf ein bestimmtes Zertifikat oder einen bestimmten öffentlichen Schlüssel – unabhängig davon, welche CA ihn signiert hat. Eine Anwendung mit Certificate Pinning weist Verbindungen zu ihren Servern zurück, wenn der Server nicht genau das erwartete Zertifikat oder den erwarteten Schlüssel vorlegt. Dieser Schutz ist besonders wertvoll für mobile Apps, da Benutzer den Netzwerkdatenverkehr nicht untersuchen können und unternehmenseigene MDM-Lösungen möglicherweise Enterprise-CA-Root-Zertifikate installieren.

Es gibt drei Ebenen des Pinnings: (1) Vollständiges Zertifikat-Pinning – das exakt DER-kodierte Zertifikat muss übereinstimmen. Dies ist am fragilsten: Jede Zertifikatserneuerung führt zu einem Fehler. (2) Public-Key-Pinning – nur die SubjectPublicKeyInfo (SPKI)-Bytes werden verglichen. Eine Zertifikatserneuerung wird überstanden, wenn dasselbe Schlüsselpaar beibehalten wird. (3) SPKI-Hash – statt des rohen Schlüssels wird SHA-256(SPKI) gespeichert. Dies entspricht dem Ansatz von HTTP Public Key Pinning (HPKP) und der Android Network Security Config. Public-Key-/SPKI-Pinning wird bevorzugt: Es übersteht CA-Rotationen und Zertifikatserneuerungen und erkennt weiterhin MITM-Angriffe mit einem anderen Schlüsselpaar.

Android (API 24+) bietet über Network Security Config XML einen deklarativen Pinning-Mechanismus. Die Datei res/xml/network_security_config.xml legt Pins pro Domain fest: pin-set mit digest="SHA-256" und dem base64-kodierten SPKI-Hash. Die App referenziert diese Datei in AndroidManifest.xml über android:networkSecurityConfig. Android erzwingt Pins für alle HTTP-Verbindungen, die über die standardmäßige HttpsURLConnection und OkHttp (bei Verwendung des Plattform-Trust-Managers) hergestellt werden. Das pin-set erfordert mindestens einen Backup-Pin (einen anderen Schlüssel oder CA-Pin), um eine Aussperrung zu verhindern, falls der primäre Schlüssel kompromittiert wird. Das Pin-Ablaufdatum (Attribut expiration) zwingt Apps zu einer Aktualisierung, bevor die Pins veralten.

iOS-Apps implementieren Pinning in den Delegates von NSURLSession. Die Delegate-Methode URLSession(_:didReceive:completionHandler:) erhält das Server-Trust-Objekt. Die App ruft SecTrustEvaluateWithError auf, um die Zertifikatskette zu validieren, extrahiert anschließend mit SecTrustGetCertificateAtIndex(trust, 0) das Leaf-Zertifikat, exportiert dessen SPKI-Bytes, hasht sie mit SHA-256 und vergleicht sie mit dem gespeicherten Pin. TrustKit (eine Open-Source-Bibliothek) kapselt dieses Muster mit konfigurationsbasiertem Pinning und unterstützt mehrere Pins, Subdomain-Matching und den Report-only-Modus. Apples App Transport Security (ATS) ist vom Pinning unabhängig – ATS erzwingt Mindestversionen für TLS, pinnt aber keine Schlüssel.

HTTP Public Key Pinning (HPKP, RFC 7469) sollte Pinning für Webbrowser über HTTP-Response-Header ermöglichen: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Der Browser hätte sich den Pin für die Dauer von max-age gemerkt und Verbindungen zu nicht übereinstimmenden Schlüsseln abgewiesen. HPKP wurde 2017 von Chrome als veraltet eingestuft und 2019 entfernt, da es zu katastrophalen Ausfällen kam: Eine einzige Fehlkonfiguration oder der Verlust eines Schlüssels konnte Benutzer dauerhaft von einer Website aussperren, ohne dass ein Wiederherstellungsweg bestand. HPKP ist für Webbrowser inzwischen praktisch obsolet; Pinning auf Anwendungsebene in mobilen Apps bleibt praktikabel, da App-Updates neue Pins ausliefern können.

OkHttp (eine auf Android weit verbreitete Bibliothek) unterstützt Pinning über CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Der zweite Pin ist der Backup-Pin. OkHttp überprüft, ob mindestens einer der Pins mit einem beliebigen Zertifikat in der Zertifikatskette des Servers übereinstimmt – mit dem Leaf-, Zwischen- oder Root-Zertifikat. Dadurch kann ein Zwischenzertifikat einer CA gepinnt werden (wodurch eine Rotation des Leaf-Zertifikats überstanden wird) oder die Root-CA (wodurch eine Rotation des Zwischenzertifikats überstanden wird). OkHttp löst eine SSLPeerUnverifiedException mit einer hilfreichen Meldung aus, die die tatsächlichen SPKI-Hashes des Servers auflistet, wodurch das Extrahieren von Pins während der Entwicklung unkompliziert wird.

Pinning erhöht die Hürde für das Abfangen von Datenverkehr, ist aber nicht unknackbar. Häufige Umgehungstechniken auf Mobilgeräten: (1) Frida-Hooks – JavaScript wird in den Anwendungsprozess eingeschleust, um die Pin-Verifikationsmethode abzufangen und bedingungslos true zurückzugeben. (2) SSLUnpinning-Tools – automatisierte Frida-/Objection-Skripte, die gängige Pinning-Bibliotheken (TrustKit, OkHttp, natives SecTrust) angreifen. (3) Custom-ROM – das Gerät rooten und den TLS-Stack modifizieren. (4) Repackaging – die APK dekompilieren, die Pinning-Konfiguration ändern und sie mit einem neuen Zertifikat neu paketieren. (5) Memory-Patching – den Verifikations-Bytecode zur Laufzeit patchen. Gegenmaßnahmen: Root-/Jailbreak-Erkennung, Code-Obfuskation und Integritätsprüfungen (SafetyNet/App Attest).

Das größte betriebliche Risiko von Certificate Pinning ist die selbst verursachte Aussperrung: Wenn der Produktionsschlüssel verloren geht oder das Zertifikat abläuft und das Backup nicht verfügbar ist, bleiben Benutzer ausgesperrt, bis ein App-Update veröffentlicht wird (Tage bis Wochen). Best Practices: (1) Pinnen Sie immer mindestens zwei Schlüssel – den aktuellen Schlüssel und einen vorab generierten Backup-Schlüssel, der offline (in einem HSM oder luftgetrennt) gespeichert wird. (2) Legen Sie ein Pin-Ablaufdatum fest und veröffentlichen Sie vor dessen Erreichen App-Updates. (3) Überwachen Sie Pin-Fehler zunächst im Report-only-Modus, bevor Sie das Pinning erzwingen. (4) Halten Sie eine Pipeline für Notfall-App-Updates (mit beschleunigter Prüfung) für Vorfälle bei der Pin-Rotation bereit. (5) Pinnen Sie auf der Ebene der Zwischen-CA und nicht des Leaf-Zertifikats, damit Leaf-Zertifikate ohne App-Updates rotiert werden können.

Desktop-Anwendungen, die mit Electron, Qt oder nativem Code geschrieben sind, können Pinning über die APIs ihres TLS-Stacks implementieren. Electron-Apps verwenden das app.on("certificate-error")-Ereignis und session.setCertificateVerifyProc() für eine benutzerdefinierte Verifikation. Qt-Netzwerkcode verwendet QSslSocket mit einem benutzerdefinierten Verifikations-Callback. .NET-Anwendungen verwenden ServicePointManager.ServerCertificateValidationCallback. Native Windows-Anwendungen verwenden WinHTTP mit einer manuellen Zertifikatsprüfung. Desktop-Anwendungen stehen vor zusätzlichen Herausforderungen: TLS-Inspektionen auf Betriebssystemebene durch Unternehmensproxys sind üblich, und Benutzer erwarten möglicherweise, dass die Proxy-Funktionalität funktioniert – daher ist zu entscheiden, ob Pinning nur für bestimmte Endpunkte gelten soll.

Certificate Pinning erschwert automatisierte Tests und CI/CD-Pipelines. Integrationstests, die echte HTTPS-Aufrufe an Staging-Server senden, müssen Testzertifikate verwenden, deren SPKI-Hashes in einer Testkonfiguration gepinnt sind. Mögliche Ansätze: (1) Build-Varianten – der Debug-/Staging-Build enthält Pins für den Staging-Server, der Release-Build Pins für die Produktion. (2) Überschreibungen der Network Security Config – Android erlaubt eine Pin-Konfiguration, die nur für Debug-Builds gilt. (3) Mock-Server – den Datenverkehr auf der HTTP-Client-Ebene vor TLS abfangen und das Pinning vollständig umgehen. (4) Selbstsignierte CA für CI – Testzertifikate von einer CI-CA ausstellen, deren Root nur in Test-Builds vertraut wird. Liefern Sie niemals einen Build mit deaktiviertem Pinning in der Produktion aus.

Zertifikat-Pins sind typischerweise Hashes öffentlicher RSA- oder EC-Schlüssel. Wenn die Post-Quanten-Migration beginnt, werden Server auf ML-DSA (CRYSTALS-Dilithium) oder hybride Schlüssel umstellen. Gepinnte SPKI-Hashes werden sich ändern, da sich Schlüsseltyp und Kodierung ändern. Apps, die Leaf-Zertifikate oder öffentliche Schlüssel pinnen, benötigen koordinierte Updates: (1) Veröffentlichen Sie vor der Servermigration eine neue App-Version mit dem Post-Quanten-SPKI-Hash als Backup-Pin. (2) Schließen Sie die Servermigration ab. (3) Veröffentlichen Sie ein Update, das den alten klassischen Pin entfernt. Das Übergangsfenster erfordert eine sorgfältige Koordination. Apps, die Zwischen- oder Root-CAs pinnen, sind weniger betroffen – nur der Schlüssel der CA ändert sich, und zwar nicht notwendigerweise im selben Zeitplan wie die Leaf-Zertifikate.

Zertifikat-Pinning beschränkt das TLS-Vertrauen auf ein bestimmtes Zertifikat oder einen bestimmten öffentlichen Schlüssel und schützt so vor der Kompromittierung von CAs und MITM-Angriffen. Das Pinning des SPKI-Hashes (SHA-256 von SubjectPublicKeyInfo) wird dem Pinning des vollständigen Zertifikats vorgezogen, weil es bei Erneuerungen robuster ist. Unter Android wird Network Security Config als XML verwendet; iOS nutzt einen URLSession-Delegate mit SecTrust-APIs; OkHttp unterstützt CertificatePinner. Fügen Sie immer einen Backup-Pin hinzu, um eine Selbstsperrung zu verhindern. HPKP (Browser-HTTP-Header) ist veraltet. Pinning kann durch Frida-Hooks und Änderungen am ROM umgangen werden. Die Migration zu Post-Quanten-Schlüsseln erfordert koordinierte App-Aktualisierungen, um die SPKI-Hashes zu aktualisieren.