Sicherheitsmechanismen der Android-Plattform

Die folgenden Abschnitte beschreiben Sicherheitsmechanismen der Andorid-Plattform.

Das Android KeyStore System

Der Android KeyStore [1] bietet Mechanismen zum sicheren Erzeugen, Speichern und Verwenden von kryptografischen Schlüsseln. Schlüssel werden innerhalb eines geschützten Containers erzeugt und gespeichert, um die Extraktion aus dem Mobilgerät einem potentiellen Angreifer zu erschweren. Des Weiteren bietet er Sicherheitsmechanismen, welche unter anderem die möglichen Nutzungsszenarien eines kryptografischen Schlüssels eingrenzen (siehe Absicherung kryptografischer Schlüssel (A)). Auch wenn die Anbindung des KeyStore Systems durch die KeyChain-Api für einen Entwickler Transparent ist, unterscheiden sich die Sicherheitsstufen verschiedener Mobilgeräte je nach zugrundeliegender Technologie:

  1. Software-basierte Schlüsselcontainer
  2. Trusted Execution Environment (TEE)
  3. Hardware Security Module (HSM) basiertes Schlüsselmanagement mit zusätzlicher TEE Unterstützung

Vor allem auf Basis sicherer Hardware (Varianten 2 und 3) lässt sich Schlüsselmaterial sicher an ein Mobilgerät binden. Zusätzlich kann durch die Hardware die Schlüsselnutzung an einen bestimmten Zweck (z.B. Signieren oder Ver-/Entschlüsseln), eine bestimmte Applikation oder einen bestimmten Nutzer gebunden werden. Im Folgenden wird das Keystore System auf Basis sicherer Hardware betrachtet. Variante 1 wird nicht weiter berücksichtigt.

Varianten des Android KeyStore-Systems

Keymaster - Trusted Execution Environment (TEE)

Die TEE schützt kryptografisches Schlüsselmaterial während der Laufzeit, auch im Falle einer Kernel-Kompromittierung [15]. Selbst mit einem vollständig kompromittierten Kernel kann ein Angreifer kein Schlüsselmaterial auslesen, das im Keymaster gespeichert ist. Anwendungen können ausdrücklich verlangen, dass kryptografische Schlüssel, die hardware-basiert in der TEE gesichert sind, erst nach einer erfolgreichen Nutzerauthentifizierung am Mobilgerät zugänglich sind. Des Weiteren können Anwendungen ein Attestierungszertifikat zur Überprüfung der Schlüsseleigenschaften und des Speicherorts anfordern [16].

StrongBox Keymaster

Seit Android Version 9 unterstützt das KeyStore System den StrongBox Keymaster. Bei dem <StrongBox Keymaster handelt es sich um ein Hardware Sicherheitsmodul (HSM), welches laut Google eine eigene CPU, sicheren Speicher, einen echten Zufallszahlengenerator sowie einen Schutzmechanismus gegen das Installieren von unauthorisierten Anwendungen und das manipulieren von Paketen. Um StrongBox-Implementierungen auf einem geringeren Energieniveau (bzgl. des Verbrauchs) zu ermöglichen, unterstützt das HSM nur eine Untermenge an Algorithmen und Schlüssellängen [1,3]:

Der Einsatz der StrongBox mildert unter anderem die Auswirkung starker Angreifer ab, bei welchen das Gerät

ist. Dabei schützt die StrongBox auch vor Cold-Boot-Angriffen auf den Arbeitsspeicher [12, 33] und spekulativen Seitenkanalangriffen auf Hardwarefehler wie z.B. Spectre [13] und Meltdown [14], welche sogar einen Durchbruch der Speicherabschottung der TEE ermöglichen. Eine Detaillierte Diskussion des Sicherheitsmodells der Android-Plattform ist in [10] zu finden.

Key Attestation

Über den Key Attestation-Mechanismus ist der hardware-basierte Erzeugungs- und Spericherort asymmetrischer kryptografischer Schlüssel innerhalb des Android KeyStores zu verifizieren. Durch das verfahren kann somit ermittelt werden, ob ein Schlüssel durch die TEE bzw. die StrongBox geschützt ist. Bei der Erstellung eines asymmetrischen Schlüsselpaars wird durch die Hardware zusätzlich ein Schlüssel-Attestierungszertifikat erzeugt, welches neben dem öffentlichen Teil des Schlüssel auch die Information des Schlüsselspeicherorts enthält. Zur Ausstellung des Schlüssel-Attestierungszertifiakts sind in das Gerät ein RSA-Schlüssel sowie ein ECDSA-Schlüssel und ihre korrespondierenden Zertifikate sicher eingebettet. Welcher Schlüssel zu Attestierung gewählt wird hängt von dem im KeyStore erzeugten Schlüssel ab (Attestierung über RSA für RSA-Schlüssel; Attestierung über ECDSA für EC-Schlüssel). Die Zertifikate sind im X.509-Format [27]. Das Attestierungszertifikat wird an eine anfragende Anwendung stets mit vollständiger Zertifizierungskette übergeben. Bevor eine Anwendung den gespeicherten Schlüssel verwendet, müssen folgende Eigenschaften verifiziert werden:

  1. Das Stammzertifikat der Zertifikatskette ist durch den Attestierungsstammschlüssel von Google signiert.
  2. Das Attribut attestationSecurityLevel des Stammzertifikats ist auf die Sicherheitsstufe TrustedEnvironment festgelegt.
  3. Alle Signaturen in der Zertifikatskette können erfolgreich verifiziert werden.
  4. Alle als kritisch definierten Attribute der Zertifikate können erfolgreich verifiziert werden (z.B. ihre zeitliche Gültigkeit).
  5. Keines der Zertifikate der Kette wurde über die jeweils in ihnen hinterlegten Zertifikatsrevokationslisten (CRL) widerrufen.

Sind nicht alle der genannten Verifikationsschritte erfolgreich, oder wurden Zertifikate widerrufen, ist die Vertrauenswürdigkeit eines Schlüssels mit der eines in Software erzeugten Schlüssels vergleichbar (siehe Android KeyStore System Variante 1) [2, 27]. Auch, wenn sich dadurch kein negativer Indikator für die Vertrauenswürdigkeit eines Schlüssels ergibt, ist er im Movi-Kontext nicht mehr als gültig zu betrachten - er muss abgelehnt werden.

Mindestanforderungen an Android-Mobilgeräte im Movi-Kontext

Der Einsatz der beschrieben Sicherheitsmechanismen setzt Mindestanforderungen an das Android-Mobilgerät voraus:

Sicherheitsbetrachtung

In der Vergangenheit sind immer wieder verschiedenen Schwachstellen in der Android-Plattform gefunden worden, die es Angreiferinnen ermöglicht haben einzelne Sicherheitsmechanismen zu umgehen oder das gesamte System zu kompromittieren. Prinzipiell muss in zwei Angriffsklassen unterschieden werden:

  1. Angriffe, die physikalischen Zugriff auf das Mobilgerät voraussetzen. Hierzu gehören beispielsweise Angriffe auf den Bootvorgang eines Geräts [7] oder Angriffe auf die Mechanismen zur Absicherung des Zugriffs auf ein Gerät, wie z.B. die Fälschung/das Kopieren von biometrischen Charakteristika.

  2. Angriffe, die keinen physikalischen Zugriff auf das Mobilgerät voraussetzen. Hierzu gehören vor allem Angriffe auf das Betriebssystem, welche es einem Angreifer ermöglichen unautorisierte Operationen auf dem Gerät auszuführen [8].

Wird zur Absicherung kryptografischer Schlüssel eine TEE eingesetzt, können vor allem die Auswirkungen software-basierter Angriffe abgemildert werden. Selbst bei der Kompromittierung des Betriebssystems kann das kryptografische Schlüsselmaterial nicht “einfach so” ausgelesen werden, da es durch weitere hardware-basierte Sicherheitsmaßnahmen geschützt ist. Festzuhalten ist jedoch, dass es in der Vergangenheit erfolgreiche Angriffe auf explizite Schwachstellen der Android-TEE gab, welche die Extraktion oder die unbemerkte Verwendung von kryptografischen Schlüsseln ermöglichten [9].

Ein Beispiel dafür sind z.B. die spekulativen Seitenkanalangriffe Spectre [13] und Meltdown [14], für die Android zwar Patches und Sicherheitsempfehlungen in [17] veröffentlicht, da es sich bei den Schwachstellen jedoch um Fehler im Hardwaredesign handelt diese Maßnahmen nur eine Abschwächung des Angriffsvektors erreichen können. Festzuhalten ist, dass es, in Bezug auf die genannten Schwachstellen, keine Berichte über erfolgreich in der Praxis durchgeführten Angriffe auf Android-Geräte gab [17].

Monatliche Updates zu aktuellen sicherheitskritischen Schwachstellen und Angriffe auf Geräte die Android betreiben, sowie die notwendige Gegenmaßnahmen, werden von Android über [18] verteilt. Diese Gegenmaßnahmen geziehen sich meist auf Updates für das Betriebssystem selbst. Updates die den Microcode betreffen werden von den Geräte-/Hardwareherstellern selbst verteilt: Google (Pixel/Nexus) [19], Huawei [20], LG [21], Motorola [22], Nokia [23] und Samsung [24]. Um das Maximum der möglichen Sicherheit zu erreichen, ist ein Gerät stets aktuell zu halten.

Wird zur Absicherung kryptografischer Schlüssel ein dediziertes HSM eingesetzt ist ein Angreifer selbst bei vollständiger Übernahme des Betriebssystems nicht in der Lage die im HSM gesicherten Schlüssel auszulesen. Im Falle des von Google entwickelten Titan M Sicherheitschips werden die Sicherheitsfunktionen eines “klassischen” HSM um die Funktionen Trusted User Presence (siehe Absicherung kryptografischer Schlüssel (A)) und Protected Confirmation erweitert [25].

Safetynet

Bypassed by Magisk (device rooting) -> [28, 29, 30] Siehe Android: SafetyNet Attestation

Protected Confirmation

Die Funktion Protected Confirmation erweitert die Sicherheitseigenschaften des StrongBox Keymasters durch einen direkten und geschlossenen Schaltkreis zwischen dem dedizierten Titan M Sicherheitschip und einem Hardwareschalter an der Seite des Mobilgeräts. Das führt dazu, dass ein Angreifer die Aktivierung der Schaltfläche, welche vor der Ausführung zuvor definierter kryptografischer Operationen notwendig ist, nicht in Software emulieren kann. Dieses Feature steht auch Drittanwendungen, wie zum Beispiel FIDO U2F [26], zur Verfügung [4, 25].

Sicheres speichern von Zugriffstokens

shared preferences -> per default nur im App-Kontext verfügbar. Schwierig bei gerooteten Geräten Account Manager -> Weden dort im Klartext gespeichert

Grundlegende Überlegungen: WhiteBox-Kryptografie für Mobilgeräte ohne TEE/HSM

Wird WhiteBox Kryptografie (WBC) eingesetzt, sind kryptografische Schlüssel nicht direkt im Arbeitsspeicher zu adressieren und auszulesen. Ein Angreifer muss die WBC-Implementierung kennen (z.B. die Anzahl der Runden, Ein- und Ausgaben). Zu allen wissenschaftlichen Ansätze zur WhiteBox Kryptografie wurden Angriffe veröffentlicht [31]. Es hat sich gezeigt, dass die Kenntnis über die Art und Weise der Schlüsseltransformation ausreicht, um einen kryptografischen Schlüssel wiederherzustellen. Die WBC setzt voraus, das die Art und Weise der Schlüsseltransformation dem Angreifer nicht bekannt ist, was bei unbekannten WBC-Implementierungen in der Praxis auch der Fall zu sein scheint, da die Implementierungen häufig stark obfuskiert sind.

Auch, wenn durch WBC eine Steigerung des Sicherheitsniveaus Software-basierter Schlüssel-Schutzmechanismen (siehe Android KeyStore Variante 1) erreicht werden kann, da der Schlüssel zur Laufzeit im Arbeitsspeicher nicht an einem Stück im Klartext vorliegt, ist das Niveau nicht mit dem Hardware-basierter Schutzmechanismen vergleichbar (verstecken des Schlüssels vs. schützen des Schlüssels). Unabhängig der konkreten WBC-Implementierung ist das Sicherheitsniveau im Movi-Kontext zwischen Variante 1 und Variante 2 des Android KeyStore-Systems anzusiedeln. WBC kann aktuell nicht die Sicherheit klassischer (BlackBox-basierter) Verfahren erreichen, und es ist auch nicht zu erwarten, dass das in naher Zukunft der Fall sein wird [32].

Im Allgemeinen gilt, dass der Angriffsvektor bei WBC-Verfahren wesentlich höher ist: Auswertung des Arbeitsspeichers, Unterbrechung von CPU-Calls, Debugging, Reverse-engineering, Code tampering

Gedanke: WBC schützt nicht, oder nur bedingt, vor Duplizierung (in der Literatur auch code lifting genannt) in Bezug auf eIDAS 2.2.1 Sicherheitsniveau Hoch.
|-> Der Schlüssel wird in den Code der Anwendung “eingearbeitet”, ergo muss er zum Zeitpunk des Kompilierens bekannt sein. -> WBC wohl eher geeignet um verteilte Schlüssel zu verstecken, nicht um auf Seiten eines Nutzers neue zu erstellen. Auch das Thema der Revokation ist unklar - Muss die ganze App revoziert werden?

Quellen

[1] https://developer.android.com/training/articles/keystore
[2] https://developer.android.com/training/articles/security-key-attestation
[3] https://developer.android.com/about/versions/pie/android-9.0#security
[4] https://developer.android.com/training/articles/security-android-protected-confirmation
[5] https://developer.android.com/about/versions/10/features#tls-1.3
[6] https://developer.android.com/about/versions/10/behavior-changes-all#tls-1.3
[7] https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-redini.pdf
[8] https://www.blackhat.com/docs/us-15/materials/us-15-Drake-Stagefright-Scary-Code-In-The-Heart-Of-Android.pdf
[9] https://www.blackhat.com/docs/us-15/materials/us-15-Shen-Attacking-Your-Trusted-Core-Exploiting-Trustzone-On-Android-wp.pdf
[10] https://arxiv.org/pdf/1904.05572.pdf
[11] https://source.android.com/security/keystore/
[12] https://www.usenix.org/legacy/event/sec08/tech/full_papers/halderman/halderman.pdf
[13] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8835233
[14] https://arxiv.org/pdf/1801.01207.pdf
[15] https://source.android.com/security/keystore/
[16] https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec
[17] https://source.android.com/security/bulletin/2018-01-01
[18] https://source.android.com/security/bulletin/index.html
[19] https://source.android.com/security/bulletin/pixel/
[20] https://consumer.huawei.com/en/support/bulletin/
[21] https://lgsecurity.lge.com/security_updates_mobile.html
[22] https://motorola-global-portal.custhelp.com/app/software-security-page/g_id/6806
[23] https://www.nokia.com/phones/en_int/security-updates
[24] https://security.samsungmobile.com/securityUpdate.smsb
[25] https://android-developers.googleblog.com/2018/10/building-titan-better-security-through.html
[26] https://fidoalliance.org/specifications/
[27] https://source.android.com/security/keystore/attestation
[28] https://pure.tugraz.at/ws/portalfiles/portal/23614047/SECRYPT_2019_97_CR.pdf
[29] https://magiskroot.net/bypass-safetynet-issue-cts/
[30] http://selab.fbk.eu/ceccato/papers/2019/ssprew2019.pdf [31] https://www.blackhat.com/docs/eu-15/materials/eu-15-Sanfelix-Unboxing-The-White-Box-Practical-Attacks-Against-Obfuscated-Ciphers-wp.pdf [32] https://dl.acm.org/doi/pdf/10.1145/3015135.3015139?download=true [33] Lest We Remember: Cold Boot Attacks on Encryption Keys