Certificate Pinning: Was es ist, Mechanismus und Fixierungsmethoden

Was ist Certificate Pinning?

Certificate Pinning ist eine Sicherheitstechnik, bei der eine Anwendung den Fingerabdruck eines vertrauenswürdigen Zertifikats speichert und ihn als alleiniges Kriterium für den Aufbau einer HTTPS-Verbindung verwendet. Im Standard-TLS-Modell überprüft der Client, ob das Serverzertifikat von einer vertrauenswürdigen Root-CA signiert wurde — einer der Hunderten von vorinstallierten Zertifizierungsstellen im System. Certificate Pinning ersetzt diese Kette durch eine direkte Prüfung: Das Zertifikat muss mit der gespeicherten Probe übereinstimmen oder den erwarteten öffentlichen Schlüssel enthalten.

Das Problem des Standardmodells wurde nach CA-Kompromittierungsvorfällen deutlich — DigiNotar (2011), Comodo (2011), TrustCor (2022). Wenn eine CA ein gefälschtes Zertifikat für Ihre Domain ausstellt, akzeptiert der Browser oder die Anwendung es als gültig. Certificate Pinning verhindert diesen Angriff: Selbst ein perfekt signiertes gefälschtes Zertifikat wird zurückgewiesen, da sein Fingerabdruck nicht mit dem in der Anwendung fixierten übereinstimmt.

Der Begriff Pinning stammt von Pin — „Stift“ oder „Fixierer“: Der Entwickler fixiert ein vertrauenswürdiges Zertifikat, und jede Abweichung davon blockiert die Verbindung. Laut der Studie von Mitre CWE-295 bleibt die unsachgemäße Zertifikatsprüfung einer der 10 gefährlichsten Sicherheitsfehler in mobilen Anwendungen, und Certificate Pinning ist eine direkte Methode, dies zu verhindern.

Geschichte und Entwicklung von Certificate Pinning

Ursprünglich wurde Certificate Pinning in Browsern über den HPKP-Mechanismus (HTTP Public Key Pinning) verwendet, der in RFC 7469 standardisiert wurde. Der Entwickler sandte einen HTTP-Header Public-Key-Pins mit Hashes der erwarteten Schlüssel, und der Browser speicherte sie für einen bestimmten Zeitraum. HPKP erwies sich jedoch als gefährlich: Ein einziger Konfigurationsfehler konnte eine Site für Monate sperren. 2018 stellte Chrome die Unterstützung für HPKP ein, und der aktuelle Standard wurde zur clientseitigen Implementierung — innerhalb einer mobilen Anwendung oder Browsererweiterung.

Wie funktioniert Certificate Pinning?

Der Certificate-Pinning-Prozess umfasst drei Schlüsselphasen: Fingerabdruckberechnung, Verbindungsprüfung und Fehlerbehandlung. Während der Vorbereitung ruft der Entwickler den SHA-256-Hash des Produktionsserverzertifikats oder des öffentlichen Schlüssels ab. Für GDPR- und PCI DSS-konforme Anwendungen müssen auch die Fingerabdrücke der Zwischen-CAs in der Kette fixiert werden.

Bei jeder HTTPS-Anfrage fängt die Anwendung den TLS-Authentifizierungs-Callback ab, extrahiert das Serverzertifikat und berechnet seinen SHA-256-Hash. Dieser Hash wird mit der gespeicherten Liste vertrauenswürdiger Fingerabdrücke verglichen. Bei einer Übereinstimmung wird die Verbindung fortgesetzt. Wenn nicht, muss die Anwendung die Verbindung trennen und den Fehler melden, ohne dem Angreifer Implementierungsdetails preiszugeben.

fun validateCertificate(certificate: X509Certificate,
    expectedHash: String): Boolean {
    val digest = MessageDigest.getInstance("SHA-256")
    val hash = Base64.encodeToString(
        digest.digest(certificate.publicKey.getEncoded()),
        Base64.DEFAULT
    ).trim()
    return hash == expectedHash
}

Die Funktion nimmt ein X509Certificate-Objekt vom Server und den erwarteten Hash entgegen. Zuerst wird der öffentliche Schlüssel des Zertifikats extrahiert, der SHA-256-Hash berechnet und in Base64 kodiert. Das Ergebnis wird mit dem erwarteten Fingerabdruck verglichen. In der Produktion sollte eine Prüfung gegen ein Array von 2–3 Fingerabdrücken hinzugefügt werden, um Rotation zu unterstützen.

Certificate Pinning vs Public Key Pinning

Bei der Implementierung von Pinning muss entschieden werden, welches kryptografische Objekt fixiert werden soll. Certificate Pinning bindet an das X.509-Zertifikat selbst — seine Seriennummer, Gültigkeitsdauer und die gesamte Kette. Public Key Pinning fixiert nur den öffentlichen Schlüssel innerhalb des Zertifikats und ignoriert die anderen Felder. Diese Wahl hat erhebliche Auswirkungen auf die Betriebskosten.

Public Key Pinning ist die bevorzugte Wahl für die meisten Projekte. Die öffentlichen Schlüssel von Servern bleiben bei der Neuausstellung eines Zertifikats in der Regel unverändert — das Unternehmen signiert einfach den alten Schlüssel mit einem neuen Zertifikat. Dies bedeutet, dass die Anwendung nach einem Zertifikatswechsel kein Update benötigt, wenn sich das Schlüsselpaar nicht geändert hat. Certificate Pinning hingegen wird für Szenarien empfohlen, in denen der Entwickler sowohl den Server als auch den Client-Code vollständig kontrolliert, wie bei Unternehmensanwendungen mit einem strengen Update-Zyklus.

Trust On First Use (TOFU)

TOFU ist eine Strategie, bei der Certificate Pinning nicht im Voraus konfiguriert wird, sondern sich das Zertifikat bei der ersten Verbindung zum Server merkt. Dieser Ansatz ist praktisch für Anwendungen, die nicht im Voraus wissen, mit welchem Server sie sich verbinden werden. Der Nachteil ist die Anfälligkeit für einen Erstangriff: Wenn die erste Verbindung abgefangen wird, wird ein gefälschtes Zertifikat als vertrauenswürdig akzeptiert. TOFU wird in SSH-Verbindungen und einigen P2P-Protokollen verwendet.

Implementierung auf iOS und Android

Auf beiden Plattformen wird Certificate Pinning durch Abfangen der TLS-Verbindung auf Netzwerkstack-Ebene implementiert. Auf iOS wird der URLSession-Delegat oder Alamofire ServerTrustManager verwendet. Auf Android ist die bevorzugte Methode OkHttp CertificatePinner, das in beliebte HTTP-Clients integriert ist und die Konfiguration mehrerer Fingerabdrücke für jede Domain unterstützt.

func validate(serverTrust: SecTrust,
    pinnedHash: String) -> Bool {
    guard let certificates = SecTrustCopyCertificateChain(serverTrust)
        as? [SecCertificate] else { return false }

    for certificate in certificates {
        let data = SecCertificateCopyData(certificate)
        var hash = Data(repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
        data.withUnsafeBytes {
            CC_SHA256($0.baseAddress,
                CC_LONG(data.count), &hash)
        }
        if hash.base64EncodedString() == pinnedHash {
            return true
        }
    }
    return false
}

In der Swift-Funktion wird die Zertifikatskette aus serverTrust extrahiert, für jedes Zertifikat ein SHA-256-Hash berechnet und das Ergebnis mit dem erwarteten verglichen. Die Iteration durch alle Zertifikate in der Kette ermöglicht Pinning auf Zwischen-CA-Ebene — stimmt ein Zwischenzertifikat überein, wird die Verbindung akzeptiert. Dies bietet Flexibilität bei der Rotation von Blattzertifikaten.

Benutzerdefinierter TrustManager für Android

Wenn die Anwendung OkHttp nicht verwendet, kann Certificate Pinning über einen benutzerdefinierten X509TrustManager implementiert werden. Diese Methode erfordert mehr Code, bietet aber volle Kontrolle über den Prüfprozess. Der TrustManager überschreibt die Methode checkServerTrusted, in der der Entwickler manuell die Serverzertifikate überprüft und über Vertrauen entscheidet. Sie wird nur für spezifische Szenarien empfohlen, in denen die OkHttp-Bibliothek nicht verfügbar ist.

Häufige Fehler bei der Implementierung von Certificate Pinning

Der häufigste Fehler ist das Fehlen von Backup-Pins. Ein Entwickler hinterlegt einen einzigen Zertifikats-Fingerabdruck, und wenn dieser abläuft, verlieren die Benutzer massenhaft die Verbindung. Die minimal akzeptable Konfiguration sind zwei Fingerabdrücke: das aktuelle Zertifikat und ein Backup. Ideal sind drei: das aktuelle, ein Backup und der Fingerabdruck der Root-CA als Fallback.

Der zweite Fehler ist die Speicherung von Pins im Klartext im Code. Ein Angreifer mit Zugriff auf eine APK oder IPA kann Fingerabdrücke leicht extrahieren und ersetzen. Hash-Verschleierung wird empfohlen: Teilen Sie die Zeichenfolge auf, speichern Sie sie in verschlüsselten Ressourcen oder berechnen Sie sie zur Laufzeit. Für Android ist ProGuard mit Verschleierung von String-Konstanten effektiv.

Der dritte Fehler ist Pinning auf Ebene des Entwicklungsszertifikats. Entwicklungs- und Produktionszertifikate sind in der Regel unterschiedlich, aber Entwickler vergessen oft, die Pins beim Erstellen eines Release-Builds umzuschalten. Das Ergebnis ist, dass die Produktionsanwendung keine Verbindung zum Server herstellen kann. Die Lösung sind separate Pin-Konfigurationen für Debug und Release über BuildConfig oder Flavorspezifische Ressourcen.

• Ignorieren der Zertifikatskette — nur das Blattzertifikat prüfen, ohne Zwischen-CAs zu berücksichtigen, was die Verbindung bei Rotation unterbricht
• Hartcodierte Daten — hartcodierte Zertifikatsablaufdaten, die sich nach Updates nicht ändern
• Keine Überwachung — fehlende Warnungen bei Certificate-Pinning-Fehlern, sodass Probleme nur von Benutzern entdeckt werden
• TOFU ohne Validierung — Verwendung von Trust On First Use ohne zusätzliche Prüfung, wodurch der erste MITM-Angriff ein gefälschtes Zertifikat fixieren kann