Vergleich der Mechanismen zur Absicherung des Zugriffs auf kryptografischer Schlüssel (A, iOS)

Die folgenden Abschnitte beschreiben die sicherheitsrelevanten Api-Funktionalitäten zur Absicherung kryptografischer Schlüssel und der Zugriffsmöglichkeiten auf diese für Android und iOS. Abschließend wird der Funktionsumfang gegenüber gestellt, um zu ermitteln, ob ein äquivalentes Sicherheitsniveau, in Bezug auf die Zugriffskontrolle, zwischen den beiden Plattformen prinzipiell zu etablieren ist. Die Sicherheit der zugrundeliegenden Hardware und des Betriebssystems wird nicht evaluiert und gegenübergestellt.

Absicherung kryptografischer Schlüssel (A)

Androids Keychain-Api ermöglicht die Konfiguration von Schlüsselpaaren mit Hilfe von Parametern (Q-A-1). Die im Folgenden aufgelisteten Methoden sind in der Klasse KeyGenSpec.Builder (Q-A-2) enthalten und werden genutzt, um relevante Parameter geeignet zu wählen.

Nr. Beschreibung Android-Api
A-01 Legt fest, ob dieser Schlüssel nur verwendet werden darf, wenn der Benutzer authentifiziert wurde. Der Schlüssel kann nur generiert werden, wenn ein sicherer Sperrbildschirm eingerichtet ist. setUserAuthenticationRequired
A-02 Legt fest, ob dieser Schlüssel, sofern vorhanden, durch einen StrongBox/HSM-Sicherheitschip geschützt werden soll. setIsStrongBoxBacked
A-03 Legt die Zeitspanne (Sekunden) fest, für die dieser Schlüssel nach erfolgreicher Authentifizierung des Benutzers verwendet werden darf. Dies hat Auswirkungen, wenn für den Schlüssel eine Benutzerauthentifizierung erforderlich ist (siehe A-01). Wenn eine Benutzerauthentifizierung erforderlich ist, muss diese standardmäßig bei jeder Verwendung des Schlüssels erfolgen. setUserAuthenticationValidityDurationSeconds
A-04 Legt den Zeitpunkt fest, nach dem der Schlüssel nicht mehr gültig ist. setKeyValidityEnd
A-05 Der Schlüssel wird irreversibel ungültig, sobald der sichere Sperrbildschirm deaktiviert oder die sichere Sperre zwangsweise zurückgesetzt wird. Wenn für den Schlüssel außerdem eine Benutzerauthentifizierung für jede Verwendung des Schlüssels erforderlich ist (siehe A-01), wird er nach der Registrierung einer neuen Biometrie, oder wenn keine Biometrie mehr konfiguriert ist, irreversibel ungültig, es sei denn, setInvalidatedByBiometricEnrollment wird verwendet, um die Gültigkeit danach zuzulassen. setInvalidatedByBiometricEnrollment
A-06 Legt fest, ob das Verschlüsselungsverfahren nicht-deterministisch sein muss, d.h. ob wiederkehrende Klartexte zu unterschiedlichen Ciphertexten verschlüsselt werden müssen. Die damit verbundene kryptografische Eigenschaft ist "indistinguishability under chosen-plaintext attack" (IND-CPA). setRandomizedEncryptionRequired
A-07 Legt die Menge der zulässigen Padding Schemata fest, mit denen der Schlüssel zum Signieren oder Verifizieren genutzt werden darf. Versuche, den Schlüssel mit einem anderen Padding Schema zu verwenden, werden zurückgewiesen. setSignaturePaddings
A-08 Legt fest, ob der Keystore einen entsperrten Bildschirm erfordert, bevor mit diesem Schlüssel entschlüsselt werden darf. Ist diese Option aktiviert, werden Versuche mit diesem Schlüssel zu entschlüsseln oder signieren scheitern, solange der Bildschirm gesperrt ist. Auch mit gesperrtem Bildschirm kann der Schlüssel zum Verschlüsseln und Verifizieren genutzt werden. setUnlockedDeviceRequired
A-09 Legt fest, ob der Schlüssel nur dann für die gegebene Zeitspanne (setUserAuthenticationValidityDurationSeconds) authorisiert bleibt, solange das Gerät nicht vom Körper des Nutzers entfernt wird. Sobald das Gerät vom Körper des Nutzers entfernt wird, gilt der Schlüssel als unauthorisiert und der Nutzer muss sich zur Nutzung des Schlüssels erneut authentifizieren. Für Schlüssel ohne On-Body Sensor hat dieser Parameter keinen Einfluss. setUserAuthenticationValidWhileOnBody
A-10 Legt fest, ob der Schlüssel nur für Nachrichten, die vom Nutzer bestätigt wurden, authorisiert ist. Diese Bestätigung ist unabhängig von der Nutzer Authentifizierung (setUserAuthenticationRequired). Die Bestätigung verifiziert, dass ein Nutzer, der physikalischen Zugriff auf das Gerät hat, eine angezeigte Nachricht freigegeben hat. Dieser Parameter beeinflusst nur Operation mit privaten bzw. geheimen Schlüsseln. Operationen mit öffentlichen Schlüsseln werden davon nicht eingeschränkt (ConfirmationPrompt). setUserConfirmationRequired
A-11 Legt fest, ob zwischen den Methodenaufrufen von Signature.initSign() und Signature.sign() geprüft werden muss, ob der Nutzer am Gerät anwesend ist. Das setzt voraus, dass es der Keystore-Implementierung möglich ist, die Anwesenheit des Nutzers direkt zu überprüfen, wie z.B. über einen mit der StrongBox verbundenen Schaltfläche (siehe Protected Confirmation). setUserPresenceRequired
A-12 Legt fest, ob für das Schlüsselpaar ein Attestation-Zertifikat erzeugt wird und welcher Challenge-Wert im Zertifikat hinterlegt wird. Die Attestation-Zertifikatskette kann über KeyStore.getCertificateChain abgerufen werden. Wenn eine Attestation-Challenge übergeben wird, enthält das Public-Key-Zertifikat eine Erweiterung, in der Details der Schlüsselkonfiguration und -authorisierung sowie der Attestation-Challenge-Wert enthalten sind. Wenn der Schlüssel in sicherer Hardware hinterlegt ist und die sichere Hardware Attestation unterstützt, wird das Zertifikat durch eine Kette von Zertifikaten signiert, die auf einem vertrauenswürdigen CA-Schlüssel basieren. Andernfalls wird die Kette auf einem nicht vertrauenswürdigen Zertifikat basieren. setAttestationChallenge


Absicherung kryptografischer Schlüssel (iOS)

Für die Erzeugung eines asymmetrischen Schlüssels wird zunächst ein Attribut-Wörterbuch angelegt. Dieses muss mindestens Attribute zu Typ (kSecAttrKeyType) und Größe (kSecAttrKeySizeInBits) des Schlüssels enthalten. Darüber hinaus kann der Parameter kSecPrivateKeyAttrs hinzugefügt werden, der auf ein Unterwörterbuch verweist, in dem Eigenschaften des privaten Schlüssels festgelegt werden. Analog dazu kann über den Parameter kSecPublicKeyAttrs auch ein Unterwörterbuch für den öffentlichen Schlüssel hinzugefügt werden.

Seit dem iPhone 5S liefert Apple mit der Secure Enclave einen hardwarebasierten, vom Hauptprozessor isolierten Schlüsselmanager aus, in dem ebenfalls Schlüssel abgelegt werden können(Q-iOS-5). Soll ein Schlüssel in der SecureEnclave erzeugt werden, müssen die Attribute drei Anforderungen erfüllen (Q-iOS-3):

  1. In der Secure Enclave können nur 256-Bit Schlüssel mit elliptischen Kurven speichern, weshalb als Typ nur die drei Optionen “kSecAttrKeyTypeECDSA”, “kSecAttrKeyTypeEC” und “kSecAttrKeyTypeECSECPrimeRandom” gewählt werden können. Q-iOS-4 listet unterstützte Schlüsselgrößen auf und enthält für elliptische Kurven die Optionen “secp192r1”, “secp256r1”, “secp384r1” und “secp521r1”. Da die Secure Enclave nur 256-Bit Schlüssel erzeugen kann, muss es sich um bei der verwendeten Kurve um “secp256r1” handeln.

  2. Im Wörterbuch muss ein weiterer Eintrag “kSecAttrTokenID” hinzugefügt werden, welcher als Wert “kSecAttrTokenIDSecureEnclave” enthält.

  3. Im Wörterbuch muss ein weiterer Eintrag hinzugefügt werden, der als Wert ein Objekt enthält, das die Zugriffskontrolle spezifiziert. Dieses kann mit der Funktion SecAccessControlCreateWithFlags erzeugt werden, die als Parameter unter anderem eine der Schutzklassen (iOS-101 - iOS-105) als “protection” sowie die Spezifikation erlaubter Operationen durch geeignete Kombination der Attribute iOS-111 - iOS-115 als “flags” erwartet. Um den Schlüssel in der SecureEnclave abzulegen, sollen “kSecAttrAccessibleWhenUnlockedThisDeviceOnly” als Schutzklasse und “kSecAccessControlPrivateKeyUsage” als Flag gesetzt werden.

Nr. Beschreibung iOS-Api Wörterbuchschlüssel
iOS-001 Der zugehörige Wert gibt den verwendeten Algorithmus an. kSecAttrKeyType
iOS-002 Der zugehörige Wert gibt die Anzahl der Bits des Schlüssels an. kSecAttrKeySizeInBits
iOS-003 Der zugehörige Wert ist ein Wörterbuch mit Attributen des privaten Schlüssels. kSecPrivateKeyAttrs
iOS-004 Der zugehörige Wert ist ein Wörterbuch mit Attributen des öffentlichen Schlüssels. kSecPublicKeyAttrs
iOS-005 Der zugehörige Wert definiert das Label des Schlüssels. Dieses wird verwendet, um erzeugte Schlüssel zu unterscheiden. kSecAttrLabel
iOS-006 Der zugehörige Wert gibt an, dass sich der Schlüssel in einem externen Store befindet. kSecAttrTokenID
iOS-007 Der zugehörige Wert gibt an, ob der Schlüssel permanent ist. kSecAttrIsPermanent
iOS-008 Der zugehörige Wert gibt an, ob der Schlüssel zum Verschlüsseln verwendet werden darf. kSecAttrCanEncrypt
iOS-009 Der zugehörige Wert gibt an, ob der Schlüssel zum Entschlüsseln verwendet werden darf. kSecAttrCanDecrypt
iOS-010 Der zugehörige Wert gibt an, ob der Schlüssel zum Ableiten eines anderen Schlüssels verwendet werden darf. kSecAttrCanDerive
iOS-011 Der zugehörige Wert gibt an, ob der Schlüssel zum Signieren verwendet werden darf. kSecAttrCanSign
iOS-012 Der zugehörige Wert gibt an, ob der Schlüssel zum Verifizieren verwendet werden darf. kSecAttrCanVerify
iOS-013 Der zugehörige Wert gibt an, ob der Schlüssel zum Verpacken eines anderen Schlüssels verwendet werden darf. kSecAttrCanWrap
iOS-014 Der zugehörige Wert gibt an, ob der Schlüssel zum Entpacken eines anderen Schlüssels verwendet werden darf. kSecAttrCanUnwrap
iOS-101 Vor dem Zugriff muss der Nutzer sich mittels Code authentifizieren. kSecAccessControlDevicePasscode
iOS-102 Vor dem Zugriff muss der Nutzer sich mittels Touch ID oder Face ID authentifizieren. kSecAccessControlBiometryAny
iOS-103 Vor dem Zugriff muss der Nutzer sich mittels Touch ID oder Face ID authentifizieren. Wird ein neuer Finger zu Touch ID hinzugefügt oder Face ID erneut eingerichtet wird, wird das geschützte Element ungültig. kSecAccessControlBiometryCurrentSet
iOS-104 Vor dem Zugriff muss der Nutzer sich mittels Touch ID, Face ID oder Code authentifizieren. kSecAccessControlUserPresence
iOS-105 Vor dem Zugriff muss der Nutzer sich über eine gekoppelte Apple Watch mit watchOS 6 oder neuer authentifizieren. kSecAccessControlWatch
iOS-111 Zugriff ist nur möglich, wenn ein Code eingerichtet ist und das Gerät entsperrt ist. Elemente mit diesem Attribut werden nie auf ein neues Gerät migiert, beim Einrichten eines neuen Geräts durch Wiederherstellen eines Backups gehen diese Elemente verloren. kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
iOS-112 Zugriff ist nur möglich, wenn das Gerät entsperrt ist. Elemente mit diesem Attribut werden nie auf ein neues Gerät migiert, beim Einrichten eines neuen Geräts durch Wiederherstellen eines Backups gehen diese Elemente verloren. kSecAttrAccessibleWhenUnlockedThisDeviceOnly
iOS-113 Zugriff ist nur möglich, wenn das Gerät entsperrt ist. Beim Einrichten eines neuen Geräts durch Wiederherstellen eines Backups werden Elemente mit diesem Attribut übernommen. kSecAttrAccessibleWhenUnlocked
iOS-114 Nach einem Neustart ist der Zugriff erst dann möglich, nachdem das Gerät vom Nutzer entsperrt wurde. Elemente mit diesem Attribut werden nie auf ein neues Gerät migiert, beim Einrichten eines neuen Geräts durch Wiederherstellen eines Backups gehen diese Elemente verloren. kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
iOS-115 Nach einem Neustart ist der Zugriff erst dann möglich, nachdem das Gerät vom Nutzer entsperrt wurde. Beim Einrichten eines neuen Geräts durch Wiederherstellen eines Backups werden Elemente mit diesem Attribut übernommen. kSecAttrAccessibleAfterFirstUnlock

Zuordnung der Sicherheitsfunktionen - Äquivalenzklassen

Es wird überprüft, ob das durch die Android-Sicherheitsfunktionen im Movi-Kontext erreichte Sicherheitsniveau zum Absichern des Zugriffs auf kryptografische Schlüssel auch auf iOS-Plattformen zu erreichen ist. Dazu wird der sicherheits-bezogene Funktionsumfang der beiden Programmierschnittstellen gegenübergestellt. Aus der Zielsetzung des Projektes ergibt sich Android als Ausgangspunkt - welche iOS-Funktion(en) werden benötigt, um ein äquivalentes Sicherheitsniveau in Bezug auf den Zugriffsschutz zu erreichen.

Typ/Klasse-Beschreibung Android-Api iOS-Api
Schlüssel darf nur von authentifiziertem Nutzer verwendet werden. A-01 iOS-104
Schlüssel wird in sicherer Hardware hinterlegt. A-02 TokenID: kSecAttrTokenIDSecureEnclave (iOS-006)
Nutzer bleibt nur für eine gewisse Zeitspanne authentifiziert. A-03 Standard: bis iPhone gesperrt
Zeitpunkt nach dem Schlüssel nicht mehr gültig ist A-04 iOS-107
Schlüssel wird ungültig, wenn Authentifizierungsmechanismus zurückgesetzt wird. A-05 iOS-103
Verschlüsselungsverfahren muss nicht-deterministisch sein. A-06 -
Festlegen der zulässigen Padding Schemata beim Signieren/Verifizieren. A-07 -
Schlüssel darf nur bei entsperrtem Bildschirm verwendet werden. A-08 iOS-101, iOS-102
Nutzer bleibt nur authentifiziert, wenn das Gerät nicht vom Körper entfernt wird. A-09 -
Der Schlüssel darf nur für Nachrichten verwendet werden, wenn der Nutzer dies explizit bestätigt. A-10 -
Zwischen Einleiten des Signierens und dem tatsächlichen Signieren muss geprüft werden, dass der Nutzer physikalisch am Gerät anwesend ist. A-11 -
Festlegen, ob für das Schlüsselpaar ein Attestation-Zertifikat erzeugt wird. A-12 -

Quellen

[1] Android-api
[2] iOS-Api