Mithilfe des DeviceCheck-Frameworks können Entwickler das Risiko einer betrügerischen Nutzung ihrer App und damit ihrer Dienste reduzieren. Zum Prüfen der Integrität bieten die DeviceCheck-Dienste mit iOS/iPadOS 14 eine DCAppAttestService-API, die App-Entwickler in ihre Apps zur Validierung der Integrität einbauen können. Über diese kann eine App prüfen, ob sie in unberechtigter Art und Weise verändert wurde.

Die DCAppAttestService-API erzeugt dazu einen hardwarebasierten, kryptografischen Schlüssel der jeweils zu prüfenden App. Dieser Schlüssel wird mit Hilfe von Apple-Servern verwendet, um die Legitimität der App bei Serveranfragen für sensible oder Premium-Inhalte zu bestätigen. Die generateKey(completionHandler:)-Methode generiert daraufhin besagtes eindeutiges und auf dem Gerät basierendes kryptografisches Schlüsselpaar.

Bei Erfolg gibt der Completion Handler dieser Methode eine Schlüsselkennung zurück, die Apps später für den Zugriff auf den Schlüssel verwenden können. Den öffentlichen Schlüssel muss der App-Entwickler für seinen Serverdienst vorhalten. Den privaten Schlüssel speichert das iOS-Gerät automatisch in der Secure Enclave. Hier kann er nur über den App-Attest-Dienst zum Erstellen von Signaturen verwendet werden.

Zu beachten ist, dass nicht alle Geräte diesen neuen App-Attest-Dienst nutzen können. App-Entwicklern steht dazu zwar eine Kompatibilitätsprüfung zur Verfügung, allerdings ist das Ergebnis unter iOS / iPadOS hardcodiert und liefert immer "true" zurück.

Apple App Attest: Signierte Server Requests

Der App-Attest-Service bietet (auf kompatiblen Geräten) zusätzlich die Möglichkeit, sensitive Serveranfragen zu validieren. Dazu wird die Apple-eigene Infrastruktur verwendet, um die Requests an den Server vorher zu signieren. Apple ermöglicht App-Entwicklern somit eine Aussage über die Sicherheit der gesendeten Daten. Zur Sicherheit und Integrität des Geräts selbst gibt es keine Hinweise.

Als Resultat erhält die App eine Signierung für die Kommunikation, basierend auf ihren App ID. In der Dokumentation von Apple heißt es dazu: "To use the App Attest service, your app must have an app ID that you register on the Apple Developer website." Das gilt auch für Inhouse Apps. Da die App ID nicht nur für öffentlich verfügbare oder Custom Apps ermittelbar ist, sondern auch Enterprise Apps zur Verfügung steht, sollte dieser Dienst auch hier problemfrei funktionieren.

Durch das Zusammenspiel zwischen dem Attestierungsdienst von Apple und dem Gerät können so signierte Anfragen an das Backend gesendet werden. Weicht die Signierung bei einer Validierung durch den Server ab, kann dieser die Kommunikation zur App und damit zum Endgerät beenden. Ob eine App eventuell korrumpiert ist, kann man aber nicht zwingend von einem erfolgreichen Signing des Requests ableiten.

Apple räumt selbst ein, dass sie nicht sicher sagen können, ob ein Gerät, auf dem die App installiert ist, kompromittiert ist: "For example, App Attest can't definitively pinpoint a device with a compromised operating system." Ist ein Gerät durch einen Jailbreak kompromittiert, kann definitiv nicht mit hundertprozentiger Sicherheit ausgeschlossen werden, dass die App nicht kompromittiert ist. Denn ein kaputtes OS kann nicht sicher eine Binary verifizieren, beziehungsweise die Rückmeldungen von Apple abgreifen. Hier wird die Praxis zeigen, wie gut und sicher dieses Vorgehen funktioniert.

Attestierung: Vorsicht bei Unternehmens-Apps

Für eine Kategorie von Apps wird dieser Dienst unter Umständen ein nicht überwindbares Hindernis darstellen: Apps aus dem Apple AppStore, die mithilfe von App-Wrapping-Techniken - vermeintlich - sicher für den dienstlichen Einsatz gemacht werden. Viele MDM-Hersteller wie Microsoft (Intune), VMware Airwatch, MobileIron oder Blackberry bieten hierzu Lösungen an, um fehlende Sicherheitsfunktionen in bestehenden Apps durch Sicherheitsfunktionen in der Hülle zu patchen.

Allerdings setzt App-Wrapping selbst zur Absicherung auf Methoden, die Hacker nutzen, um Apps zu manipulieren und anzugreifen. Damit dieser Schutz nicht einfach entfernt wird, erfolgt eine Verankerung mit der "Wirts-App" nämlich meistens durch eine enge Verzahnung von Strings und Client-Zertifikaten zwischen der "Wirts-App" und der Wrapping-Bibliothek. Die "Zuverlässigkeit" einer solchen Verzahnung - und damit der Schutz - ist jedoch stark produktabhängig. Zwar werden API-Aufrufe aus der "Wirts-App" heraus abgefangen, aber Angriffe von außen nicht wirkungsvoll unterbunden. Gerade ein "unsicher" entwickelter Code ist trotzdem für einen Angreifer lesbar, da Themen wie Obfuscation (Verschleierung) hier keinerlei Anwendung finden und sich nicht nachträglich hinein patchen lassen.

Aufgrund dieses "Einpflanzens" in bestehende Apps kann es durchaus dazu kommen, dass Apple bei zukünftigen Apps beziehungsweise iOS-Updates ein Wrapping komplett verhindert. So ist denkbar, dass der neue App-Attestierungs-Service dem Treiben künftig ein Ende setzt, weil damit genau solche Manipulierungen erkannt werden können. (mb)