CDD: StrongBox requirements
- Tighten the security by supporting StrongBox.
- Clarifying the requirements if StrongBox is supported.
Bug: 73002261
Test: N/A
Change-Id: I9834ced2e697bee013cb0725f31745826da1f0c5
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index d409563..67338a6 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -6,7 +6,7 @@
or the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
Device implementations:
-* [C-0-1] MUST at least allow more than 8,192 keys to be imported.
+* [C-0-1] MUST allow at least 8,192 keys to be imported or generated.
* [C-0-2] The lock screen authentication MUST rate-limit attempts and MUST
have an exponential backoff algorithm. Beyond 150 failed attempts, the delay
MUST be at least 24 hours per attempt.
@@ -14,7 +14,8 @@
When the device implementation supports a secure lock screen, it:
-* [C-1-1] MUST back up the keystore implementation with secure hardware.
+* [C-1-1] MUST back up the keystore implementation with an isolated
+ execution environment.
* [C-1-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic
algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support
the Android Keystore system's supported algorithms in an area that is securely
@@ -41,10 +42,10 @@
a different key MAY be used for each 100,000 units.
Note that if a device implementation is already launched on an earlier Android
-version, such a device is exempted from the requirement to have a
-hardware-backed keystore and support the key attestation, unless it declares
-the `android.hardware.fingerprint` feature which requires a hardware-backed
-keystore.
+version, such a device is exempted from the requirement to have a keystore
+backed by an isolated execution environment and support the key attestation,
+unless it declares the `android.hardware.fingerprint` feature which requires a
+keystore backed by an isolated execution environment.
### 9.11.1\. Secure Lock Screen
@@ -132,7 +133,7 @@
password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
method with a more restrictive quality constant than
`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
-* [SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
+* [C-SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
that are equal to or stronger than what is required for a fingerprint sensor as
described in section 7.3.10.
@@ -164,3 +165,75 @@
[`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
* [C-7-4] MUST NOT authenticate access to keystores if the application has
called [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
+
+### 9.11.2\. StrongBox
+
+The [Android Keystore System](
+https://developer.android.com/training/articles/keystore.html) allows
+app developers to store cryptographic keys in a dedicated secure processor as
+well as the isolated execution environment described above.
+
+Device implementations:
+
+* [C-SR] Are STRONGLY RECOMMENDED to support StrongBox.
+
+If device implementations support StrongBox, they:
+
+* [C-1-1] MUST declare [FEATURE_STRONGBOX_KEYSTORE](
+https://developer.android.com/reference/kotlin/android/content/pm/PackageManager#FEATURE_STRONGBOX_KEYSTORE%3Akotlin.String).
+
+* [C-1-2] MUST provide dedicated secure hardware that is used to back
+keystore and secure user authentication.
+
+* [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors
+or other core resources with the application processor (AP).
+
+* [C-1-4] MUST ensure that any peripherals shared with the AP cannot alter
+StrongBox processing in any way, or obtain any information from the StrongBox.
+The AP MAY disable or block access to StrongBox.
+
+* [C-1-5] MUST have an internal clock with reasonable accuracy (+-10%)
+that is immune to manipulation by the AP.
+
+* [C-1-6] MUST have a true random number generator that produces
+uniformly-distributed and unpredictable output.
+
+* [C-1-7] MUST have tamper resistance, including resistance against
+physical penetration, and glitching.
+
+* [C-1-8] MUST have side-channel resistance, including resistance against
+leaking information via power, timing, electromagnetic radiation, and thermal
+radiation side channels.
+
+* [C-1-9] MUST have secure storage which ensures confidentiality,
+integrity, authenticity, consistency, and freshness of the
+contents. The storage MUST NOT be able to be read or altered, except
+as permitted by the StrongBox APIs.
+
+* To validate compliance with [C-1-3] through [C-1-9], device
+ implementations:
+
+ * [C-1-10] MUST include the hardware that is certified against the
+ Secure IC Protection Profile [BSI-CC-PP-0084-2014](
+ https://www.commoncriteriaportal.org/files/ppfiles/pp0084b_pdf.pdf) or
+ evaluated by a nationally accredited testing laboratory incorporating
+ High attack potential vulnerability assessment according to the
+ [Common Criteria Application of Attack Potential to Smartcards](
+ https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+ * [C-1-11] MUST include the firmware that is evaluated by a
+ nationally accredited testing laboratory incorporating High attack
+ potential vulnerability assessment according to the
+ [Common Criteria Application of Attack Potential to Smartcards](
+ https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+ * [C-SR] Are STRONGLY RECOMMENDED to include the hardware that is
+ evaluated using a Security Target, Evaluation Assurance Level
+ (EAL) 5, augmented by AVA_VAN.5. EAL 5 certification will likely
+ become a requirement in a future release.
+
+* [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR),
+which means that an insider with access to firmware signing keys cannot produce
+firmware that causes the StrongBox to leak secrets, to bypass functional
+security requirements or otherwise enable access to sensitive user data. The
+recommended way to implement IAR is to allow firmware updates only when the
+primary user password is provided via the IAuthSecret HAL. IAR will likely
+become a requirement in a future release.
\ No newline at end of file