Closed davidz25 closed 1 year ago
Btw, the https://github.com/google/identity-credential/tree/keystore-abstraction branch contains work towards this feature. It's not quite ready for review or finished but the bulk of the credential storage and keystore abstraction work is there.
The work in the branch is almost complete but it's too big to land as a single PR so going to land this in pieces. PR #288 is the first part which introduces storage and keystore abstractions.
Been making a lot of progress here, the chunk of functionality is landing as PR #297. After that, just a couple of PRs for presentation using this new store (code is already written but needs PR #293 to land first) and migration from the old credential store (apps will be able to safely migrate devices in the field to use this).
Currently we use Hardware-Backed Android KeyStore for
CredentialKey
andDeviceKey
which means that the private part of those keys never leave Secure Hardware. Concretely the Secure Hardware is where KeyMint (KeyMaster in older Android versions) is running and this is typically the Trusted Execution Environment but could also be something else such as a Secure Element. This approach provides a number of security guarantees and is consistent with NOTE 1 of ISO/IEC 18013-5:2021. Crucially this feature is available on almost all Android phones today.In some cases however it is desirable to use another Secure Area for managing keys so it would be useful to have a small abstraction for how we use EC keys, for example
It's possible that each implementation needs user interaction for unlocking a key, this can be done by concrete implementations. For example the implementation for Android KeyStore would be
The application would then construct an
IdentityCredentialStore
by passing in aKeystoreImplementation
object. Our reference apps would useAndroidKeystoreKeystoreImplementation
and set up a listener for unlocking keys.You could also have
SoftwareBackedKeystoreImplementation
which would allow to backup/restore keys or it could run in a non-Android environment (useful for testing etc.)Or you could have
MyOwnTrustedAppKeystoreImplementation
which implements the interface by communicating with e.g. a JavaCard applet on a Secure Element using OMAPI. Such an implementation could have its own listener that could be used to ask the use for a PIN for unlocking which could then be sent to the Secure Environment.We'd need to change the core
IdentityCredential
API a little bit (today it exposesCryptoObject
directly, we'd have to change that) to make this work but I don't think it would be a very big change and we've been wanting to do that anyway.