Certificate Pinning

Mit dem Certificate Pinning können Sie Man-in-the-Middle-Attacken verhindern.

Bei der Kommunikation über öffentliche Netze ist es wesentlich, dass Informationen sicher gesendet und empfangen werden können. Ein weit verbreitetes Protokoll für den Schutz der Kommunikation ist SSL/TLS. (SSL bedeutet Secure Sockets Layer und TLS, der Nachfolger von SSL, bedeutet Transport Layer Security.) SSL/TLS verwendet digitale Zertifikate für Authentifizierung und Verschlüsselung. Damit ein Zertifikat als echt und gültig angesehen werden kann, wird es mit einem Stammzertifikat einer anerkannten Zertifizierungsstelle digital signiert. Betriebssysteme und Browser führen Listen mit Stammzertifikaten anerkannter Zertifizierungsstellen, sodass sie ohne großen Aufwand verifizieren können, dass Zertifikate von den Zertifizierungsstellen ausgegeben und signiert wurden.

Protokolle wie SSL/TLS, die sich auf die Verifizierung einer Zertifikatkette verlassen müssen, sind anfällig für eine Reihe gefährlicher Attacken, zu denen auch Man-in-the-Middle-Attacken gehören, bei denen eine nicht autorisierte Partei den gesamten Datenverkehr, der zwischen dem mobilen Gerät und den Back-End-Systemen übertragen wird, sehen und modifizieren kann.

Die IBM MobileFirst Platform Foundation stellt eine API bereit, die das Certificate Pinning ermöglicht. Sie wird in nativen iOS- und nativen Android-MobileFirst-Anwendungen sowie in plattformübergreifenden Cordova-MobileFirst-Anwendungen unterstützt.

Certificate-Pinning-Prozess

Beim Certificate Pinning wird einem Host sein erwarteter öffentlicher Schlüssel zugeordnet. Da Sie im Besitz des serverseitigen und clientseitigen Codes sind, können Sie Ihren Clientcode so konfigurieren, dass er nur ein bestimmtes Zertifikat für Ihren Domänennamen akzeptiert und nicht irgendein Zertifikat, das mit einem Stammzertifikat einer anerkannten Zertifizierungsstelle korrespondiert und vom Betriebssystem oder Browser erkannt wurde.
Eine Kopie des Zertifikats wird in Ihre Clientanwendung gestellt. Beim SSL-Handshake (d. h. bei der ersten Anforderung an den Server) verifiziert das Client-SDK der IBM MobileFirst Platform Foundation, dass der öffentliche Schlüssel des Serverzertifikats mit dem öffentlichen Schlüssel des in der App gespeicherten Zertifikats übereinstimmt.
Wichtiger Hinweis:
  • Es kann sein, dass einige Betriebssysteme für mobile Geräte das Ergebnis der Gültigkeitsprüfung des Zertifikats zwischenspeichern. Bevor Sie eine geschützte Anforderung senden, sollten Sie daher die Certificate-Pinning-API aufrufen. Andernfalls könnten die Gültigkeitsprüfung für das Zertifikat und die Pinning-Überprüfung bei nachfolgenden Anforderungen übergangen werden.
  • Wenn diese Methode ein zweites Mal aufgerufen wird, wird die vorherige Pinning-Operation außer Kraft gesetzt.

Bei erfolgreichem Pinning wird der öffentliche Schlüssel aus dem bereitgestellten Zertifikat verwendet, um die Integrität des MobileFirst-Server-Zertifikats während der geschützten SSL/TLS-Handshakeanforderung zu verifizieren. Schlägt das Pinning fehl, werden alle an den Server gerichteten SSL/TLS-Anforderungen von der Clientanwendung zurückgewiesen.

Zertifikat-Setup

Sie müssen ein von einer Zertifizierungsstelle gekauftes Zertifikat verwenden. Selbst signierte Zertifikate werden nicht unterstützt. Aus Gründen der Kompatibilität mit den unterstützten Umgebungen müssen Sie sicherstellen, dass das verwendete Zertifikat im DER-Format (Distinguished Encoding Rules) gemäß Standard X.690 der International Telecommunications Union codiert ist.

Sie müssen das Zertifikat wie folgt in den MobileFirst Server und in Ihre Anwendung aufnehmen:

  1. MobileFirst Server: (WebSphere Application Server, WebSphere Application Server Liberty oder Apache Tomcat). In der Dokumentation zu Ihrem Anwendungsserver finden Sie Informationen zum Konfigurieren von SSL/TLS und von Zertifikaten.
  2. Anwendung:
    • Natives iOS: Fügen Sie das Zertifikat zum Anwendungsbundle hinzu.
    • Natives Android: Stellen Sie das Zertifikat in den Ordner assets.
    • Plattformunabhängig (Cordova): Stellen Sie das Zertifikat in den Ordner App-Name\www\certificates.

Certificate-Pinning-API

Das Certificate Pinning ist eine API-Methode mit einem Parameter Zertifikatdateiname, d. h. dem Namen der Zertifikatdatei.

Natives Android
Android
Syntax:
public void pinTrustedCertificatePublicKey(String Zertifikatdateiname) throws IllegalArgumentException
Beispiel: 
WLClient.getInstance().pinTrustedCertificatePublicKey("myCertificate.cer");
Die Certificate-Pinning-Methode löst in zwei Fällen eine Ausnahme aus:
  • Die Datei ist nicht vorhanden.
  • Die Datei hat das falsche Format.
Natives iOS
iOS
Syntax:
pinTrustedCertificatePublicKeyFromFile:(NSString*) Zertifikatdateiname;
Beispiel: 
[[WLClient sharedInstance]pinTrustedCertificatePublicKeyFromFile:@"myCertificate.cer"];
Die Certificate-Pinning-Methode löst in zwei Fällen eine Ausnahme aus:
  • Die Datei ist nicht vorhanden.
  • Die Datei hat das falsche Format.
Plattformunabhängig (Cordova)
iOS
Android
Syntax:
WL.Client.pinTrustedCertificatePublicKey('Zertifikatdateiname').then(onSuccess,onFailure)
Die Certificate-Pinning-Methode gibt eine Zusicherung zurück:
  • Die Certificate-Pinning-Methode ruft die Methode onSuccess auf, wenn das Certificate Pinning erfolgreich war.
  • Die Certificate-Pinning-Methode löst in zwei Fällen den onFailure-Callback aus:
    • Die Datei ist nicht vorhanden.
    • Die Datei hat das falsche Format.
Beispiel: 
WL.Client.pinTrustedCertificatePublicKey('myCertificate.cer').then(onSuccess,onFailure)

Wenn später eine geschützte Anforderung an einen Server ohne fest zugeordnetes Zertifikat (Pinned Certificate) gerichtet wird, wird der onFailure-Callback der jeweiligen Anforderung (z. B. WL.Client.connect oder WLResourceRequest) aufgerufen.

Weitere Einzelheiten zur Certificate-Pinning-API finden Sie in den folgenden Referenzabschnitten:
Übergeordnetes Thema: Clientseite einer MobileFirst-Anwendung entwickeln