From b5ef8ac8fee5097fa448709e2bfb70076e4bc78e Mon Sep 17 00:00:00 2001
From: Unsuk Jung
Date: Tue, 29 Sep 2015 22:52:29 -0700
Subject: CDD: Add requirements for the Android Keystore System
REQUIRE hardware-backed keystore implemenations for devices with
a secure lock screen implementation and capable hardware.
REQUIRE keystore implementations to not limit the number
of keys.
REQUIRE rate-limiting the lock screen authentication attempts and
hardware-backed authentication to support base-line security of
authentication-bound keys.
Bug: 19359718
Bug: 22196335
Change-Id: Ib937d0fec43f0dd825a243552d4d2599b7ca8708
---
src/compatibility/android-cdd.html | 40 ++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/src/compatibility/android-cdd.html b/src/compatibility/android-cdd.html
index d0487dc0..d4bb5983 100644
--- a/src/compatibility/android-cdd.html
+++ b/src/compatibility/android-cdd.html
@@ -306,6 +306,8 @@
9.10. Verified Boot
+9.11. Keys and Credentials
+
10. Software Compatibility Testing
10.1. Compatibility Test Suite
@@ -4413,6 +4415,44 @@ If a device implementation is already launched without supporting verified boot
version of Android, such a device can not add support for this feature with a system software
update and thus are exempted from the requirement.
+9.11. Keys and Credentials
+
+The Android Keystore System
+[Resources, XX]
+allows app developers to store cryptographic keys in a container and use them in cryptographic
+operations through the KeyChain API
+[Resources, XX]
+or the Keystore API
+ [Resources, XX].
+
+
+All Android device implementations MUST meet the following requirements:
+
+
+- SHOULD not limit the number of keys that can be generated, and MUST at least allow more
+than 8,192 keys to be imported.
+- The lock screen authentication MUST rate limit attempts and SHOULD have an exponential
+ backoff algorithm as implemented in the Android Open Source Project.
+- When the device implementation supports a secure lock screen and has a secure hardware
+ such as a Secure Element (SE) where a Trusted Execution Environment (TEE) can be implemented,
+ then it:
+
+ - MUST back up the keystore implementation with the secure hardware. The upstream Android
+ Open Source Project provides the Keymaster Hardware Abstraction Layer (HAL) implementation
+ that can be used to satisfy this requirement.
+ - MUST perform the lock screen authentication in the secure hardware and only when successful
+ allow the authentication-bound keys to be used. The upstream Android Open Source Project
+ provides the Gatekeeper Hardware Abstraction Layer (HAL) that can be used to satisfy this
+ requirement
+ [Resources, XX].
+
+
+
+
+Note that if a device implementation is already launched on an earlier Android version and has
+ not implemented a trusted operating system on the secure hardware, such a device cannot meet
+ the above TEE-related requirements through a system software update and thus is exempted from these TEE-related requirements.
+
10. Software Compatibility Testing
--
cgit v1.2.3