Weitere Informationen

improve this page | report issue

Bitcode in iOS-Apps verwenden

  • Die Sicherheitsüberprüfung der Anwendungsauthentizität wird nicht mit Bitcode unterstützt.
  • Für watchOS-Anwendungen muss Bitcode aktiviert sein.

Navigieren Sie zum Aktivieren von Bitcode in Ihrem Xcode-Projekt zur Registerkarte Build Settings und setzen Sie Enable Bitcode auf Yes.

TLS-gesicherte Verbindungen in iOS-Apps erzwingen

Ab iOS 9 muss in allen Apps TLS (Transport Layer Security) Version 1.2 umgesetzt werden. Für Entwicklungszwecke können Sie dieses Protokoll inaktivieren und diese Anforderung von iOS 9 umgehen.

Apple ATS (App Transport Security) ist ein neues Feature von iOS 9, das für Verbindungen zwischen der App und dem Server bewährte Verfahren umsetzt. Standardmäßig werden mit diesem Feature bestimmte Verbindungsvoraussetzungen zur Erhöhung der Sicherheit durchgesetzt. Dazu gehören clientseitige HTTPS-Anforderungen und serverseitige Zertifikate und Verbindungsschlüssel gemäß Transport Layer Security (TLS) Version 1.2 mit zukunftssicherer Geheimhaltung.

Für Entwicklungszwecke können Sie das Standardverhalten außer Kraft setzen und in der Datei info.plist Ihrer App eine Ausnahme angeben (siehe “App Transport Security Technote”). In einer reinen Produktionsumgebung funktionieren jedoch sämtliche iOS-Apps nur, wenn sie TLS-gesicherte Verbindungen umsetzen.

Wenn Nicht-TLS-Verbindungen ermöglicht werden sollen, muss in der Datei Projektname-info.plist im Ordner Projektname\Resources die folgende Ausnahme erscheinen:

<key>NSExceptionDomains</key>
    <dict>
        <key>yourserver.com</key>
    
            <dict>
            <!-- Aufnehmen, um Unterdomänen zu ermöglichen -->
            <key>NSIncludesSubdomains</key>
            <true/>

            <!-- Aufnehmen, um nicht gesicherte HTTP-Anforderungen zu ermöglichen -->
            <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict>
    </dict>

Vorbereitung für die Produktion:

  1. Entfernen Sie Teile des oben aufgeführten Codes oder setzen Sie Teile des Codes auf Kommentar.
  2. Konfigurieren Sie den Client mit dem folgenden Verzeichniseintrag, sodass er HTTPS-Anforderungen sendet:

    <key>protocol</key>
    <string>https</string>
    
    <key>port</key>
    <string>10443</string>
    

    Die SSL-Portnummer wird auf dem Server in der httpEndpoint-Definition der Datei server.xml festgelegt.

  3. Konfigurieren Sie einen Server mit aktiviertem Protokoll TLS 1.2. Weitere Informationen finden Sie unter How to configure MobileFirst Server to enable TLS V1.2.
  4. Legen Sie Einstellungen für Verschlüsselungen und Zertifikate fest, soweit sie in Ihrem Setup anwendbar sind. Weitere Informationen finden Sie im technischen Hinweis zu ATS (App Transport Security) unter Secure communications using Secure Sockets Layer (SSL) und unter Enabling SSL communication in Liberty.

OpenSSL für iOS aktivieren

Das MobileFirst-iOS-SDK verwendet für die Verschlüsselung native iOS-APIs. Sie können die IBM Mobile Foundation so konfigurieren, dass in iOS-Apps die OpenSSL-Verschlüsselungsbibliothek verwendet wird.

Die Verschlüsselung/Entschlüsselung erfolgt mit den APIs WLSecurityUtils.encryptText() und WLSecurityUtils.decryptWithKey().

Option 1: Native Verschlüsselung und Entschlüsselung

Für die native Ver- und Entschlüsselung wird standardmäßig kein OpenSSL verwendet. Die entspricht der folgenden expliziten Festlegung des Ver- und Entschlüsselungsverhaltens:

WLSecurityUtils enableOSNativeEncryption:YES

Option 2: OpenSSL aktivieren

OpenSSL ist standardmäßig inaktiviert. Gehen Sie für die Aktivierung wie folgt vor:

  1. Installieren Sie die OpenSSL-Frameworks:
    • CocoaPods: Installieren Sie mit CocoaPods den Pod IBMMobileFirstPlatformFoundationOpenSSLUtils.
    • Xcode: Verbinden Sie die Frameworks IBMMobileFirstPlatformFoundationOpenSSLUtils und “openssl” manuell im Abschnitt “Link Binary With Libraries” der Registerkarte “Build Phases”.
  2. Mit dem folgenden Code wird die OpenSSL-Option für die Verschlüsselung/Entschlüsselung aktiviert:

    WLSecurityUtils enableOSNativeEncryption:NO
    

    Wenn der Code jetzt die OpenSSL-Implementierung findet, wird er sie verwenden. Sind die Frameworks nicht ordnungsgemäß installiert, gibt der Code einen Fehler aus.

Bei diesem Setup verwenden die Verschlüsselungs-/Entschlüsselungsaufrufe OpenSSL wie in früheren Vorgängerversionen des Produkts.

Migrationsoptionen

Wenn Sie ein Projekt in einer früheren Version der MobileFirst geschrieben haben, müssen Sie möglicherweise einige Änderungen vornehmen, um OpenSSL weiter verwenden zu können. * Wenn die Anwendung keine Verschlüsselungs-/Entschlüsselungs-APIs verwendet, und keine verschlüsselten Daten auf dem Gerät zwischengespeichert werden, ist keine Aktion erforderlich. * Verwendet die Anwendung Verschlüsselungs-/Enschlüsselungs-APIs, können Sie diese APIs mit oder ohne OpenSSL nutzen.

Umstellung auf native Verschlüsselung

  1. Stellen Sie sicher, dass die Standardoption für native Verschlüsselung/Entschlüsselung ausgewählt ist (siehe Option 1).
  2. Umstellung zwischengespeicherter Daten: Wenn in der bisherigen Installation der IBM Mobile Foundation verschlüsselte Daten mit OpenSSL auf dem Gerät gespeichert wurden, müssen die OpenSSL-Frameworks wie unter Option 2 beschrieben installiert werden. Wenn die Anwendung zum ersten Mal versucht, Daten zu entschlüsseln, wird sie wie gewohnt auf OpenSSL zurückgreifen, für die Verschlüsselung dann aber die native Verschlüsselung verwenden. Wenn das OpenSSL-Framework nicht installiert ist, wird ein Fehler ausgelöst. Auf diese Weise werden die Daten automatisch auf die native Verschlüsselung umgestellt. Außerdem ist es so möglich, dass spätere Releases ohne das OpenSSL-Framework funktionieren können.

Weiterverwendung von OpenSSL

Wenn OpenSSL erforderlich ist, verwenden Sie das unter Option 2 beschriebene Setup.

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on February 27, 2020