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.
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 |
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):
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.
Im Wörterbuch muss ein weiterer Eintrag “kSecAttrTokenID” hinzugefügt werden, welcher als Wert “kSecAttrTokenIDSecureEnclave” enthält.
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 |
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 | - |
[1] Android-api
[2] iOS-Api