Droidcedas : Keystore Redesign Inwards Android M

Oleh Didiet86

Thursday, July 26, 2018

Bagikan :

Tweet

Android M has been announced, as well as the start preview builds as well as documentation are straightaway older posts for some perspective.)

New keystore APIs

Android M officially introduces several novel keystore features into the framework API, but the underlying run to back upwards them has been going on for quite a piece inwards the AOSP master copy branch. The most visible novel characteristic is back upwards for generating as well as using symmetric keys that are protected past times the organisation keystore. Storing symmetric keys has been possible inwards previous versions too, but required using somebody (hidden) keystore APIs, as well as was thence non guaranteed to live on portable across versions. Android M introduces a keystore-backed symmetric KeyGenerator, as well as adds back upwards for the KeyStore.SecretKeyEntry JCA class, which allows storing as well as retrieving symmetric keys via the measure java.security.KeyStore JCA API. To back upwards this, Android-specific primal parameter classes as well as associated builders cause got been added to the Android SDK.

Here's how generating as well as retrieving a 256-bit AES primal looks when using the novel M APIs:

// primal generation KeyGenParameterSpec.Builder builder = novel KeyGenParameterSpec.Builder("key1",                     KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT); KeyGenParameterSpec keySpec = builder                     .setKeySize(256)                     .setBlockModes("CBC")                     .setEncryptionPaddings("PKCS7Padding")                     .setRandomizedEncryptionRequired(true)                     .setUserAuthenticationRequired(true)                     .setUserAuthenticationValidityDurationSeconds(5 * 60)                     .build(); KeyGenerator kg = KeyGenerator.getInstance("AES", "AndroidKeyStore"); kg.init(keySpec); SecretKey primal = kg.generateKey();  // primal retrieval KeyStore ks = KeyStore.getInstance("AndroidKeyStore"); ks.load(null);  KeyStore.SecretKeyEntry entry = (KeyStore.SecretKeyEntry)ks.getEntry("key1", null); primal = entry.getSecretKey(); 

This is pretty measure JCA code, as well as is inwards fact rattling similar to how asymmetric keys (RSA as well as ECDSA) are handled inwards previous Android versions. What is novel hither is, that at that spot are a lot to a greater extent than parameters yous tin give the axe fix when generating (or importing a key). Along amongst basic properties such every bit primal size as well as alias, yous tin give the axe straightaway specify the supported primal usage (encryption/decryption or signing/verification), block mode, padding, etc. Those properties are stored along amongst the key, as well as the organisation volition disallow primal usage which doesn't tally the key's attributes. This allows insecure primal usage patterns (ECB mode, or constant IV for CBC mode, for example) to live on explicitly forbidden, every bit good every bit constraining certainly keys to a particular purpose, which is of import inwards a multi-key cryptosystem or protocol. Key validity menses (separate for encryption/signing as well as decryption/verification) tin give the axe also live on specified.

Another major novel characteristic is requiring usage authentication earlier allowing a particular primal to live on used, as well as specifying the authentication validity period. Thus, a primal that protects sensitive data, tin give the axe require user authentication on each usage (e.g., decryption), piece a different primal may require exactly a unmarried authentication per session (say, every 10 minutes).

The newly introduced primal properties are available for both symmetric as well as asymmetric keys. An interesting particular is that evidently trying to usage a primal is straightaway the official agency (Cf. the Confirm Credential sample as well as related video) to banking concern check whether a user has authenticated within a given fourth dimension period. This quite a roundabout agency to verify user presence, particularly if yous app doesn't brand usage of cryptography inwards the start place. The newly introduced FingerprintManager authentication APIs also brand usage of cryptographic objects, so this may live on usage of a larger picture, which nosotros cause got yet to see.

Keystore as well as keymaster implementation

On a high level, primal generation as well as storage run the same every bit inwards previous versions: the organisation keystore daemon provides an AIDL interface, which framework classes as well as organisation services usage to generate as well as create out keys. The keystore AIDL has gained some new, to a greater extent than generic methods, every bit good back upwards for a 'fallback' implementation but is to a greater extent than oft than non unchanged.

The keymaster HAL as well as its reference implementation have, however, been completely redesigned. The 'old' keymaster HAL is retained for backward compatibility every bit version 0.3, piece the Android M version has been bumped to 1.0, as well as offers a completely different interface. The novel interface allows for setting fine-grained primal properties (also called 'key characteristics' internally), as well as supports breaking upwards cryptographic operations that manipulate information of unknown or large size into multiple steps using the familiar begin/update/finish pattern. Key properties are stored every bit a series of tags along amongst the key, as well as cast an ascendance fix when combined. AOSP includes a pure software reference keymaster implementation which implements cryptographic operations using OpenSSL as well as encrypts primal blobs using a provided master copy key. Let's cause got a to a greater extent than detailed aspect at how the software implementations handles primal blobs.

Key blobs

Keymaster v1.0 primal blobs are wrapped within keystore blobs, which are inwards plough stored every bit files inwards /data/misc/keystore/user_X, every bit earlier (where X is the Android user ID, starting amongst 0 for the primary user). Keymaster blobs are variable size as well as employ a tag-length-value (TLV) format internally. They include a version byte, a nonce, encrypted primal material, a tag for authenticating the encrypted key, every bit good every bit ii ascendance sets (enforced as well as unenforced), which comprise the key's properties. Key cloth is encrypted using AES inwards OCB mode, which automatically authenticates the cipher text as well as produces an authentication tag upon completion. Each primal blob is encrypted amongst a dedicated primal encryption primal (KEK), which is derived past times hashing a binary tag representing the key's origin of trust (hardware or software), concatenated amongst they key's ascendance sets. Finally, the resulting hash value is encrypted amongst the master copy primal to derive the blob's KEK. The electrical flow software implementation deliberately uses a 128-bit AES null key, as well as employs a constant, all-zero nonce for all keys. It is expected that the in conclusion implementation volition either usage a hardware-backed master-key, or live on completely TEE-based, as well as thence non direct accessible from Android.

The electrical flow format is quite slow to decrypt, as well as piece this volition probable alter inwards the in conclusion M version, inwards the hateful fourth dimension yous tin give the axe decrypt keymaster v1.0 blobs using the keystore-decryptor tool. The programme also supports primal blobs generated past times previous Android versions, as well as volition endeavor to parse (but non decrypt) encrypted RSA blobs on Qualcomm devices. Note that the tool may non run on devices that usage custom primal blob formats or otherwise customize the keystore implementation. keystore-decryptor takes every bit input the keystore's .masterkey file, the primal blob to decrypt, as well as a PIN/password, which is the same every bit the device's lockscreen credential. Here's a sample invocation:

$ coffee -jar ksdecryptor-all.jar .masterkey 10092_USRPKEY_ec_key4 1234 master copy key: d6c70396df7bfdd8b47913485dc0a885  EC key:   s: 22c18a15163ad13f3bbeace52c361150 (254)   params: 1.2.840.10045.3.1.7   primal size: 256   primal algorithm: EC   authorizations:  Hidden tags: tag=900002C0 TAG_KM_BYTES bytes: 5357 (2)  Enforced tags:  Unenforced tags: tag=20000001 TAG_KM_ENUM_REP 00000003 tag=60000191 TAG_KM_DATE 000002DDFEB9EAF0: Lord's Day November 24 11:10:25 JST 2069 tag=10000002 TAG_KM_ENUM 00000003 tag=30000003 TAG_KM_INT 00000100 tag=700001F4 TAG_KM_BOOL 1 tag=20000005 TAG_KM_ENUM_REP 00000000 tag=20000006 TAG_KM_ENUM_REP 00000001 tag=700001F7 TAG_KM_BOOL 1 tag=600002BD TAG_KM_DATE FFFFFFFFBD84BAF0: Friday December xix 11:10:25 JST 1969 tag=100002BE TAG_KM_ENUM 00000000 

Per-key authorization

As discussed inwards the 'New keystore APIs' section, the setUserAuthenticationRequired() method of the primal parameter builder allows yous to require that the user authenticates earlier they are authorized to usage a certainly primal (not different iOS's Keychain). While this is non a novel concept (system-wide credentials inwards Android 4.x require access to live on granted per-key), the interesting usage is how it is implemented inwards Android M. The organisation keystore service straightaway holds an authentication token table, as well as a primal functioning is exactly authorized if the tabular array contains a matching token. Tokens include an HMAC as well as thence tin give the axe supply a rigid guarantee that a user has truly authenticated at a given time, using a particular authentication method.

Authentication tokens are straightaway usage of Android's HAL, as well as currently back upwards ii authentication methods: password as well as fingerprint. Here's how tokens are  defined:

typedef enum {     HW_AUTH_NONE = 0,     HW_AUTH_PASSWORD = 1 << 0,     HW_AUTH_FINGERPRINT = 1 << 1,     HW_AUTH_ANY = UINT32_MAX, } hw_authenticator_type_t;  typedef struct __attribute__((__packed__)) {     uint8_t version;  // Current version is 0     uint64_t challenge;     uint64_t user_id;             // secure user ID, non Android user ID     uint64_t authenticator_id;    // secure authenticator ID     uint32_t authenticator_type;  // hw_authenticator_type_t, inwards network gild     uint64_t timestamp;           // inwards network gild     uint8_t hmac[32]; } hw_auth_token_t; 

Tokens are generated past times a newly introduced organisation component, called the gatekeeper. The gatekeeper issues a token later it verifies the user-entered password against a previously enrolled one. Unfortunately, the electrical flow AOSP master copy branch does non include the actual code that creates these tokens, but at that spot is a base of operations degree which shows how a typical gatekeeper powerfulness live on implemented: it computes an HMAC over the all fields of the hw_auth_token_t construction upwards to hmac using a dedicated key, as well as stores it inwards the hmac field. The serialized hw_auth_token_t structure so serves every bit an authentication token, as well as tin give the axe live on passed to other components that require to verify if the user is authenticated. Management of the token generation primal is implementation-dependent, but it is expected that it is securely stored, as well as inaccessible to other organisation applications. In the in conclusion gatekeeper implementation the HMAC primal volition probable live on backed past times hardware, as well as the gatekeeper module could execute alone within the TEE, as well as thence live on inaccessible to Android. The low-level gatekeeper interface is usage of Android M's HAL as well as is defined in hardware/gatekeeper.h.

As tin give the axe live on expected, the electrical flow Android M builds practise indeed include a gatekeeper binary, which is declared every bit follows inwards init.rc:

... service gatekeeperd /system/bin/gatekeeperd /data/misc/gatekeeper     degree principal     user organisation ... 

While the framework code that makes usage of the gatekeepr daemon is non yet available, it is expected that the Android M keyguard (lockscreen) implementation interacts amongst the gatekeeper inwards gild to obtain a token upon user authentication, as well as passes it to the system's keystore service via its addAuthToken() method. The fingerprint authentication module (possibly an choice keyguard implementation) probable industrial plant inwards the same way, but compares fingerprint scans against a previously enrolled fingerprint template instead of passwords.

Summary

Android M includes a redesigned keystore implementation which allows for fine-grained primal usage control, as well as supports per-key authorization. The novel keystore supports both symmetric as well as asymmetric keys, which are stored on disk every bit primal blobs. Key blobs include encrypted primal material, every bit good every bit a fix of primal tags, forming an ascendance set. Key cloth is encrypted amongst a per-blob KEK, derived from the key's properties as well as a mutual master copy key. The in conclusion keystore implementation is expected to usage a hardware-backed master copy key, as well as run alone within the confines of the TEE. 

Android M also includes a novel organisation component, called the gatekeeper, which tin give the axe number signed tokens to attest that a particular user has authenticated at a particular time. The gatekeeper has been integrated amongst the electrical flow PIN, pattern or password-based lockscreen, as well as is expected to integrate amongst fingerprint-based authentication inwards the in conclusion Android M version on supported devices. 

Tag : android security