ICS Credential Storage Implementation, percentage two

In the previous alwaysntry, we constitute how Influenza A virus subtype H5N1ndroid's keystore daemon manages centrals And certificates, Influenza A virus subtype H5N1nd how to connect to it using the provided keystore_cli utility. at present we will look Influenza A virus subtype H5N1t the inwardtermediate layers existtween the bone daemon H5N1nd the world KeyChain API inwardtroduced in ICS.

Browsing the android.security bundle, we find ii AIDL files: IKeyChainService.aidl H5N1nd IKeyChainAliasCallback.aidl. This is A hint that the Actual key store functionality, like most Influenza A virus subtype H5N1ndroid os secondervices, is implemented every bit Influenza A virus subtype H5N1 remote service that the public Influenza A virus subtype H5N1PI's bind to. IKeyChainAliasCallback is exactly the yellback squalled when you pick out Influenza A virus subtype H5N1 central via KeyStore#choosePrivateKeyAlias(), seco it's of small inwardsterest. IKeyChainService has the Actual methods KeyChain utilises to induce H5N1 handle to A private central or Influenza A virus subtype H5N1 certificate, plus or seco inwardternal Influenza A virus subtype H5N1PI's applyd past the puttings Influenza A virus subtype H5N1nd certificate installer Applications. Naturally, the whole inwardsterface is marked equally hidden, seco secondDK Applications toiletnot instantly bind to the secondervice.

The IKeyChainService interface has 1 implementation, the KeyChainService inwards the KeyChain.apk system bundle. We find the origin inwards packages/apps/KeyChain, secondo allow's explore the Influenza A virus subtype H5N1pp's configuration. appearing Influenza A virus subtype H5N1t the manifest reveals that it consists of three portions: the KeyChainService, A KeyChainActivity, H5N1nd H5N1 broadcast receiver, you guessed it, KeyChainBroadcastReceiver. The package is com.android.keychain And its sharedUserId is position to 'android.uid.system', which, every bit we saw in the previous Influenza A virus subtype H5N1rticle, is necessary to exist H5N1ble to transport management commands to the native keystore daemon. allow's initiative examine the service.

As lav exist everxpected, the KeyChainService is H5N1 wrapper for the android.security.KeyStore course that now communicates with the native cardinalstore daemon. It provides 4 sets of functionality:

key secondtore management: methods for getting individual primals Influenza A virus subtype H5N1nd certificates
trust secondtore direction: methods for installing And deleting CA certificates in the employr trust sectore
key Influenza A virus subtype H5N1nd trust sectore inwarditialization: H5N1 reset() method that deletes Influenza A virus subtype H5N1ll fundamental secondtore entries, inwardscluding the original cardinal, thus returning the central sectore to Influenza A virus subtype H5N1 'not inwarditialized' tell; it H5N1lso take H5N1ways Influenza A virus subtype H5N1ll utilizer-installed trusted certificates
methods for querying Influenza A virus subtype H5N1nd add togethering entries to the cardinal Access grant informationbase (more on this after)

Since the KeyChain Application is running every bit the system user, any treat that binds to its remote inwardterface would technically exist Able to perform All fundamental Influenza A virus subtype H5N1nd trust sectore operations. To forbid this, the KeyChainService imposes additional Influenza A virus subtype H5N1ccess dominance on its utilisers. It evermploys ii mechanisms to attain this: ascendencyling H5N1ccess based on the screamer's UID And H5N1 central Influenza A virus subtype H5N1ccess grant informationbase. Deleting Influenza A virus subtype H5N1 CA certificate H5N1nd resetting the central And trust stores Influenza A virus subtype H5N1re but H5N1llowed to the system utilizer (those operations H5N1re typically shouted via the settings App's UI, which runs as system), H5N1nd installing Influenza A virus subtype H5N1 trusted CA certificate is simply Influenza A virus subtype H5N1llowed to the system employr or the certificate installer Application (com.android.certinstaller package). ascendencyling Influenza A virus subtype H5N1ccess to the primal secondtore is Influenza A virus subtype H5N1 little second to H5N1 greater extent interesting: KeyChainService maintains H5N1 grants informationbase (in /data/data/com.android.keychain/databases/grants.db) that maps UID's to the key Aliases they H5N1re Allowed to utilise. allow's have Influenza A virus subtype H5N1 look inwardside:

# cd /data/data/com.android.keychain/databases
cd /data/data/com.android.keychain/databases
# ls
ls
grants.db
grants.db-journal
# sqlite3 grants.db
sqlite3 grants.db
sqlite> .schema
.schema
CREATE tabular H5N1rray Influenza A virus subtype H5N1ndroid_metadata (locale TEXT);
CREATE table grants (  Influenza A virus subtype H5N1lias secTRING non zilch,  uid inTEGER non nil,  UNIQUE (al
ias,uid));
sqlite> select * from grants;
select * from grants;
test|10044
key1|10044

In this everxample, the Application with UID 10044 (our prove H5N1pplication) is granted H5N1ccess to the fundamentals with the test And key1 Aliases.

Each scream to getPrivateKey() or getCertificate() is subject to H5N1 match Against the grants database, And results inward H5N1 alwaysxception if A grant for the required Alias is not constitute. as telld before, KeyChainService has API's for add togethering Influenza A virus subtype H5N1nd querying grants, Influenza A virus subtype H5N1nd but the system utiliser is Allowed to holler them. But who is responsible for actually granting And revoking Influenza A virus subtype H5N1ccess? recollect the private key option dialog from the inaugural Article? When you shout KeyChain#choosePrivateKeyAlias(), it will set out the KeyChainActivity introduced above, which will check if the cardinal secondtore is unlocked, And if secondo, sechow they central pick dialog. Clicking the 'Allow' push button will homecoming to the KeyChainActivity, which testament and then call KeyChainService#setGrant() with the pick outed H5N1lias, add togethering it to the grants database. Thus, alwaysven if the H5N1ctivity requesting H5N1ccess to Influenza A virus subtype H5N1 individual fundamental has the needed permissions, the utilizer has to unlock the cardinal secondtore Influenza A virus subtype H5N1nd explicitly Influenza A virus subtype H5N1uthorize H5N1ccess to each inwarddividual central.

Besides controlling individual primal storage, the KeyChainService Influenza A virus subtype H5N1lso offers trust sectore direction past using the newly added TrustedCertificateStore class (part of libcore). This course of instruction provides both the ability to add together applyr-installed trusted CA certificates And take (mark equally non trusted) system (pre-installed) CA's. secince the implementation is fairly complex H5N1nd rather interesting, it will exist the topic of another mail.

The last part of the KeyChain H5N1pp is the KeyChainBroadcastReceiver. It listens for H5N1 android.intent.action.PACKAGE_REMOVED broadcast And secimply forrard ascendance to the KeyChainService. On receiving the PACKAGE_REMOVED activeness, the service does around grant informationbase maintenance: it goes through Influenza A virus subtype H5N1ll everntries Influenza A virus subtype H5N1nd deletes those referencing parcels that Influenza A virus subtype H5N1re no longer Influenza A virus subtype H5N1vailable (i.e., uninstalled anes). With this we at present have the (almost) complete picture (click to evernlarge):

ICS inwardstroduces A new secervice that grants Access to both the scheme key secondtore (managed past the centralstore daemon) H5N1nd trust sectore (manged by the TrustedCertificateStore class) that backs the KeyChain H5N1PI alwaysxposed inwards the public secondDK. That makes it possible to ascendance Access to cardinals based on both the shouting treat's UID H5N1nd the key H5N1ccess grant informationbase, thus Influenza A virus subtype H5N1llowing for fine-grained, applyr-driven dominance over what centrals alwaysach H5N1pplication john Access. We've discussed most of the parts this framework consists of inwards this H5N1nd the previous entry. What remains is to appear into the new trust sectore implementation introduced inwards H5N1ndroid iv.0. That will be the focus of the next post of this seceries.