Cope with previously-emulated keys
If a device has upgraded Android versions then the KeyMint device
may also have been upgraded. If that's the case, then there may
be keyblobs that were created in software on the old device, because it
didn't support some feature.
Watch out for these keys, and if encountered, try to import them into
the current KeyMint device:
- extract the key material from the key blob
- add PKCS#8 wrapping for import
Bug: 283077822
Bug: 296403357
Test: tested with ARC upgrade, see b/296403357
Change-Id: I146f7cfdaac9fe22b7bb6850b7e48ea113945902
diff --git a/keystore2/src/security_level.rs b/keystore2/src/security_level.rs
index 830fbe1..8abff77 100644
--- a/keystore2/src/security_level.rs
+++ b/keystore2/src/security_level.rs
@@ -33,7 +33,7 @@
use crate::utils::{
check_device_attestation_permissions, check_key_permission,
check_unique_id_attestation_permissions, is_device_id_attestation_tag,
- key_characteristics_to_internal, uid_to_android_user, watchdog as wd,
+ key_characteristics_to_internal, uid_to_android_user, watchdog as wd, UNDEFINED_NOT_AFTER,
};
use crate::{
database::{
@@ -79,10 +79,6 @@
// Blob of 32 zeroes used as empty masking key.
static ZERO_BLOB_32: &[u8] = &[0; 32];
-// Per RFC 5280 4.1.2.5, an undefined expiration (not-after) field should be set to GeneralizedTime
-// 999912312359559, which is 253402300799000 ms from Jan 1, 1970.
-const UNDEFINED_NOT_AFTER: i64 = 253402300799000i64;
-
impl KeystoreSecurityLevel {
/// Creates a new security level instance wrapped in a
/// BnKeystoreSecurityLevel proxy object. It also enables