Vergleich der Mechanismen zur Gewährleistung der Geräteintegrität (A, iOS)

Die folgenden Abschnitte beschreiben die sicherheitsrelevanten Funktionalitäten zur Gewährleistung der Geräteintegrität für Android und iOS. Abschließend wird der Funktionsumfang gegenübergestellt und bewertet, inwieweit die Geräteintegrität dadurch gewährleistet werden kann.

Android: SafetyNet Attestation

SafetyNet bietet verschiedene Dienste und APIs, die Entwicklern helfen sollen, ihre Anwendungen gegen Sicherheitsbedrohungen abzusichern ([Q-A-3]). SafetyNet bietet die folgenden APIs, um Gerätemanipulation, bösartige URLs, potentiell schädliche Anwendungen und gefälschte Nutzer zu erkennen:

Im Rahmen der Betrachtung von Funktionen zur Gewährleistung der Geräteintegrität ist lediglich die SafetyNet Attestation API relevant, weshalb die verbleibenden APIs in dieser Sicherheitsanalyse nicht weiter berücksichtigt werden.

Mit der SafetyNet Attestation API können Entwickler das Mobilgerät, auf dem ihre Anwendung läuft, analysieren ([Q-A-1]). Android empfiehlt die Nutzung der SafetyNet Attestation API, um zu ermitteln, ob die Anwendungsserver mit einer echten Anwendung auf einem echten Androidgerät interagieren.

Die SafetyNet Attestation API bietet eine kryptographisch signierte Attestation, die die Integrität des Mobilgeräts bewertet. Um die Attestation zu erstellen, prüft dieAPI die Software- und Hardwareumgebung des Mobilgeräts, sucht nach Integritätsproblemen und vergleicht sie mit den Referenzdaten für zugelassene Androidgeräte. Die generierte Attestation ist an eine Nonce gebunden, die die Anwendung beim Aufruf der API übergibt. Außerdem enthält die Attestation Metadaten über die Anwendung sowie einen Zeitstempel für den Zeitpunkt der Generierung.

Workflow

Im Folgenden werden die allgemeinen Schritte bei der Verwendung der SafetyNet Attestation API beschrieben:

  1. Aus der Anwendung wird die SafetyNet Attestation API aufgerufen. Dabei wird eine Nonce übergeben, die den Attestationsvorgang identifiziert.
  2. Die SafetyNet Attestation API wertet die Laufzeitumgebung aus und fordert eine signierte Attestation der Bewertungsergebnisse von Googles Servern an.
  3. Googles Server senden eine signierte Attestation an die SafetyNet API auf dem Mobilgerät.
  4. Die SafetyNet Attestation API gibt die signierte Attestation an die Anwendung weiter.
  5. Die Anwendung sendet die signierte Attestation an den Anwendungsserver.
  6. Der Anwendungsserver verifiziert die Attestation und wertet diese aus. Das Ergebnis wird zurück an die Anwendung gesendet.

Worflow der Geräteattestation mit SafetyNet

Anfordern der Attestation

Um eine Attestation bei der SafetyNet Attestation API anzufordern, werden folgende Tokens benötigt:

Der API Schlüssel kann vom Entwickler bei Google angefordert werden ([Q-A-4]) und wird für die Verwendung von Google Play Diensten wie der SafetyNet Attestation API benötigt. Im Rahmen dieser Sicherheitsbetrachtung wird davon ausgegangen, dass der Entwickler Zugriff auf den API Schlüssel hat und dass Sicherheit der Nutzung des API Schlüssels von Google gewährleistet wird.

Neben der Verknpüfung von Anfrage und Antwort erhöht eine Nonce den Schutz gegen Replay-Angriffe. Android gibt folgende Empfehlungen für die Erzeugung einer Nonce: Ein Teil der Nonce sollte aus Informationen abgeleitet werden, die vom Server an die Anwendung gesendet wurden ([Q-A-6]).

Nachdem mit dem API Key eine Verbindung zu den Google Play Diensten hergestellt wurde und die Nonce erzeugt wurde, kann Attestation angefordert werden.

Verifikation des Attestationsergebnisses

Die SafetyNet Attestation API liefert neben dem Ergebnis der Attestation zusätzliche Informationen, mit denen die Integrität der Nachricht überprüft werden können. Das Ergebnis der Attestation sollte über eine sichere Verbindung an den Anwendungsserver übertragen werden, um dort verifiziert zu werden. Android warnt davor, die Verifikation direkt in der Anwendung durchzuführen, da Angreifer dort mehr Einfluss nehmen können als auf dem Anwendungsserver.

Mit den folgenden Schritten kann die Nachricht, die das Ergebnis der Attestation enthält, verifiziert werden:

  1. Aus der Nachricht wird die SSL-Zertifikatskette extrahiert.
  2. Die SSL-Zertifikatskette wird validiert und es wird verifiziert, dass das Blattzertifikat auf den Host attest.android.com ausgestellt wurde.
  3. Das Zertifikat wird genutzt, um die gesamte Nachricht (kryptografisch) zu verifizieren.
  4. Der Inhalt der Nachricht wird kontrolliert, um sicherzustellen, dass alle Informationen mit der ursprünglichen Anfrage übereinstimmen. Details zum Inhalt der Nachricht folgen im folgenden Abschnitt.
Auswertung des Attestationsergebnisses

Der folgende Auszug zeigt das Format des Attestationsergebnisses.

{
  "timestampMs": 9860437986543,
  "nonce": "R2Rra24fVm5xa2Mg",
  "apkPackageName": "com.package.name.of.requesting.app",
  "apkCertificateDigestSha256": ["base64 encoded, SHA-256 hash of the
                                  certificate used to sign requesting app"],
  "ctsProfileMatch": true,
  "basicIntegrity": true,
}

Die Nachricht enthält neben dem eigentlichen Ergebnis der Attestation die folgenden Felder:

Das Ergebnis der Attestation besteht aus zwei Feldern, die jeweils den Wert true oder false haben:

Die folgende Tabelle zeigt, wie sich der Gerätezustand eines Geräts auf die Felder ctsProfileMatch und basicIntegrity auswirkt:

Gerätezustand ctsProfileMatch basicIntegrity
Zertifiziertes, echtes Gerät, das die Android Kompatibilitätstests besteht true true
Zertifiziertes Gerät mit entsperrtem Bootloader false true
Echtes aber unzertifiziertes Gerät, z.B. wenn der Hersteller keine Zertifizierung beantragt hat false true
Gerät mit Custom ROM (nicht gerooted) false true
Emulator false false
Kein Gerät (z.B. ein Skript, das ein Protokoll emuliert) false false
Anzeichen eines Systemintegritätskompromisses, wie z.B. Rooting false false
Anzeichen anderen aktiven Angriffe, wie z.B. API Hooking false false

iOS: DeviceCheck

Mit der DeviceCheck-API ([Q-iOS-1]) können Entwickler Mobilgeräte, auf denen ihre Anwendung installiert wurde, eindeutig identifizieren, ohne dabei die Privatsphäre des Nutzers zu beinträchtigen. Der Fokus liegt dabei auf der Hardware des Mobilgeräts, sodass die Identifikation auch bei Neuinstallation der Anwendung oder Zurücksetzen des Mobilgeräts möglich ist.
Aus der Anwendung auf dem Mobilgerät wird mit der DeviceCheck-API ein Gerätetoken erzeugt, der das Mobilgerät für kurze Zeit eindeutig identifiziert. Dieser Gerätetoken kann dann verwendet werden, um Anfragen an Apples DeviceCheck-Server zu stellen, auf dem Informationen zum Mobilgerät gespeichert sind.

Anwendungsfall: Einmaliger Gutschein

Den Nutzern einer Anwendung soll einmalig ein Gutschein bereitgestellt werden, mit dem sie für einen bestimmten Zeitraum besondere Features in der Anwendung freischalten können. Damit der Gutschein durch Neuinstallation der Anwendung nicht wieder aktiviert werden kann, nutzt der Entwickler DeviceCheck, um auf dem DeviceCheck-Server die Information zu speichern, dass der Gutschein auf dem Mobilgerät bereits aktiviert wurde. Da DeviceCheck die Hardware des Mobilgeräts identifiziert, bleibt diese Information erhalten, auch wenn der Nutzer die Anwendung neu installiert oder das Mobilgerät zurücksetzt.

Anwendungsfall: Kompromittiertes Mobilgerät

Wenn der Entwickler einer Anwendung feststellt, dass das Mobilgerät eines Nutzers kompromittiert ist, kann es sinnvoll sein, diese Information auf dem DeviceCheck-Server zu speichern. Das hat den Vorteil, dass das kompromittierte Mobilgerät auch nach Neuinstallation der Anwendung und Zurücksetzen des Mobilgeräts noch identifiziert werden kann.

Workflow

Im Folgenden werden die allgemeinen Schritte bei der Verwendung von DeviceCheck beschrieben:

  1. Aus der Anwendung wird die DeviceCheck API aufgerufen, um den Gerätetoken zu erhalten.
  2. DeviceCheck erzeugt den Gerätetoken und übergibt ihn an die Anwendung.
  3. Die Anwendung sendet den Gerätetoken an den Anwendungsserver
  4. Der Anwendungsserver sendet eine Anfrage an Apples DeviceCheck Server. Die Anfrage enthält neben dem Gerätetoken auch denAuthentifizierungstoken des Entwicklers.
  5. Apples DeviceCheck Server sendet die Antwort auf die Anfrage an den Anwendungsserver. Die Antwort enthält die Informationen, die der Entwickler für das Mobilgerät hinterlegt hat.
  6. Auf dem Anwendungsserver werden die zum Mobilgerät erhaltenen Informationen ausgewertet und das Ergebnis wird zurück an die Anwendung gesendet.

Worflow der Geräteidentifikation mit DeviceCheck

Ermittlung der Tokens

Mit DeviceCheck kann ein Entwickler pro Mobilgerät zwei Bits anlegen und persistent auf dem DeviceCheck Server speichern. Mit diesen zwei Bits lassen sich so 2^2=4 verschiedene Zustände unterscheiden.
Die Informationen zu einem Mobilgerät werden auf Apples DeviceCheck Server gespeichert. Um eine Anfrage an den DeviceCheck Server zu stellen, werden zwei Tokens benötigt:

Der Authentifizierungstoken wird von Apple an den Entwickler ausgeliefert ([Q-iOS-5]) und dient zur Identifikation des Entwicklers gegenüber Apple. Im Rahmen dieser Sicherheitsbetrachtung wird davon ausgegangen, dass der Entwickler Zugriff auf den Authentifizierungstoken hat und das die Authentifizierung mittels des Tokens sicher ist.

Der Gerätetoken kann nur auf dem Mobilgerät des Nutzers erzeugt werden. Die Anwendung nutzt daher die DeviceCheck API, um den Gerätetoken zu generieren und sendet ihn an den Anwendungsserver (Backend). Der Gerätetoken ist kurzlebig und kann in der Regel nicht wiederverwendet werden. Stattdessen muss ein neuer Gerätetoken auf dem Mobilgerät erzeugt werden.

Zugriff auf die mobilgerätspezifischen Informationen

Liegen beide Tokens vor, kann eine Anfrage an den DeviceCheck Server gestellt werden. Apple bietet dafür zwei Endpunkte, mit denen auf die pro Mobilgerät gespeicherten Bits zugegriffen werden kann:

Beide Endpunkte erwarten Anfragen in Form eines HTTP POST Befehls. Dabei müssen alle Anfragen den Authentifizierungstoken sowie den Gerätetoken enthalten. Bei einer erfolgreichen Anfrage antwortet der Server mit den für das Mobilgerät gespeicherten Bits sowie dem Datum der letzten Änderung der Bits.

Zu beachten ist, dass es dem Entwickler überlassen ist, welche Informationen er in den gerätespezifischen Bits speichert. Apple kümmert sich lediglich um die Speicherung der Bits und bietet dem Entwickler Lese- und Schreibzugriff. Die Semantik der gespeicherten Informationen obliegt gänzlich dem Entwickler.

Interpretation der Serverantwort

Im letzten Abschnitt wurde erläutert, wie Anfragen an den DeviceCheck-Server gestellt werden können. Die resultierende Serverantwort enthält einen der in der folgenden Tabelle aufgelisteten Statuscodes ([Q-iOS-2]).

Code Beschreibung Bedeutung
200 OK (Lesezugriff) Die Transaktion war erfolgreich. Die Bits können in der Payload ausgelesen werden.
200 Bit State Not Found (Lesezugriff) Die Transaktion war erfolgreich. Die Bits wurden bisher noch nicht gesetzt.
400 Bad Device Token Der Gerätetoken fehlt oder ist falsch formatiert
400 Bad Bits (Schreibzugriff) Die Bits fehlen oder sind falsch formatiert
400 Bad Timestamp Der Zeitstempel fehlt oder ist falsch formatiert
400 Bad Authorization Token Der Authentifizierungstoken fehlt oder ist falsch formatiert
400 Bad Payload Die Payload fehlt oder ist falsch formatiert
401 Invalid Authorization Token Der Authentifizierungstoken kann nicht verifiziert werden
401 Authorization Token Expired Der Authentifizierungstoken ist abgelaufen
403 Forbidden Die spezifizierte Aktion ist nicht erlaubt
405 Method Not Allowed Der Endpoint wurde inkorrekt genutzt
429 Too Many Requests Es wurden zu viele Anfragen an den Server geschickt
500 Server Error Es gab einen Fehler auf dem Server
503 Service Unavailable Der Dienst ist nicht verfübar

Bewertung der Funktionalität

Im Folgenden wird der Funktionsumfang von SafetyNet und DeviceCheck zusammengefasst und hinsichtlich der dadurch möglichen Gewährleistung der Geräteintegrität bewertet.

Androids SafetyNet

SafetyNet ermöglicht die Attestation des Mobilgeräts durch Anwendung der Android Kompatibilitätstests ([Q-A-2]). Die Bewertung der Geräteintegrität ist jedoch nicht fehlerfrei: Nicht alle Geräte, für die die Attestation fehlschlägt, sind Angreifer und nicht für alle Angreifer schlägt die Attestation fehl ([Q-A-6]). Daher wird ausdrücklich davor gewarnt, die Integrität eines Mobilgeräts ausschließlich mit der SafetyNet Attestation API zu bewerten ([Q-A-1, Q-A-6]). Stattdessen soll es in Kombination mit Best Practises der Anwendungssicherheit ([Q-A-7]) und eigenen anwendungsspezifischen Maßnahmen zur Missbrauchsbekämpfung kombiniert werden.

Für Androids SafetyNet Attestation API lassen sich folgende Ergebnisse festhalten:

Apples DeviceCheck

Mit DeviceCheck bietet Apple die Möglichkeit, dass Entwickler Informationen gerätespezifisch speichern können. DeviceCheck ist allerdings nicht dafür vorgesehen, die Geräteintegrität des Mobilgeräts zu analysieren.
Generell bietet Apple keine Möglichkeit, den Gerätezustand des Mobilgeräts zu überprüfen, da iOS das bereits standardmäßig übernimmt ([Q-iOS-4, Q-iOS-6]).

Für Apples DeviceCheck API lassen sich folgende Ergebnisse festhalten:

Quellen

[Q-A-1] https://developer.android.com/training/safetynet/attestation
[Q-A-2] https://source.android.com/compatibility/cts
[Q-A-3] https://developer.android.com/training/safetynet
[Q-A-4] https://developer.android.com/training/safetynet/attestation#obtain-api-key
[Q-A-5] https://developer.android.com/training/safetynet/attestation#obtain-nonce
[Q-A-6] https://android-developers.googleblog.com/2017/11/10-things-you-might-be-doing-wrong-when.html
[Q-A-7] https://developer.android.com/topic/security/best-practices
[Q-iOS-1] https://developer.apple.com/documentation/devicecheck
[Q-iOS-2] https://developer.apple.com/documentation/devicecheck/accessing_and_modifying_per-device_data#2910408
[Q-iOS-3] https://support.apple.com/de-de/guide/security/sec35dd877d0/1/web/1
[Q-iOS-4] https://forums.developer.apple.com/message/157492#157492
[Q-iOS-5] https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/establishing_a_token-based_connection_to_apns
[Q-iOS-6] https://support.apple.com/de-de/guide/security/welcome/web