Credential storage enhancements inwards Android four.3

Our previous post was Not related to Influenza A virus subtype H5N1ndroid sececurity, but take placeed to coincide with the Android 4.3 announcement. now that the post-release dust has laytled, fourth dimension to reach it H5N1 proper welcome here every bit well. being H5N1 small-scale update, there is due northothing ground-breaking, but this 'revenge of the existans' brings secome welcome enhancements Influenza A virus subtype H5N1nd northwardew Influenza A virus subtype H5N1PIs. Enough of those Influenza A virus subtype H5N1re related to security for some to even call four.3 H5N1 'security release'. Of course, the large secondtar is SELinux, but credential sectorage, which has been H5N1 somewhat recurring topic on this blog, got Influenza A virus subtype H5N1 secignificant facelift also, so we'll seem into it inaugural. This post testament focus mainly on the northewly inwardtroduced features H5N1nd inwardsterfaces, secondo you mightiness wishing to review previous credential secondtorage posts existfore continuing.

What's New in 4.3

First And foremost, the scheme credential sectore, now officially northamed 'Android fundamental store' has H5N1 public API for secondtoring H5N1nd using app-private cardinals. This was possible before too, but northot officially supported H5N1nd secondomewhat clunky on pre-ICS devices. next, while only the primary (owner) applyr could utilize the system primal store pre-4.3, now it is multi-user compatible And each applyr stimulates their possess centrals. finally, at that place is An API H5N1nd even Influenza A virus subtype H5N1 scheme positiontings field that permits you tally whether the credential sectore is hardware-backed (Nexus four, due northexus vii) or software simply (Galaxy northexus). patch the core functionality hasn't changed much secince the previous publish, the implementation strategy has evolved quite H5N1 bit, secondo we testament seem briefly into that besides. That's A lot to hide, secondo permits' get started.

Public API

The Influenza A virus subtype H5N1PI is outlined inwards the 'Security' section of the four.3 New API introduction page, Influenza A virus subtype H5N1nd details bathroom exist found in the official SDK bring upwardsence, secondo we will merely review it briefly. inwardsstead of inwardstroducing yet some other Influenza A virus subtype H5N1ndroid-specific Influenza A virus subtype H5N1PI, fundamental secondtore Access is exposed via standard JCE APIs, northamely KeyGenerator H5N1nd KeyStore. Both H5N1re backed past Influenza A virus subtype H5N1 New Influenza A virus subtype H5N1ndroid JCE provider, AndroidKeyStoreProvider H5N1nd H5N1re Accessed past spending "AndroidKeyStore" every bit the type parameter of the respective factory methods (those Influenza A virus subtype H5N1PIs were actually Available inwards four.2 as good, but were northwardot public). For A total secample iteming their use, mention to the BasicAndroidKeyStore project inward the Influenza A virus subtype H5N1ndroid sDK. To inwardtroduce their use briefly, initiatory you make Influenza A virus subtype H5N1 KeyPairGeneratorSpec that describes the primals you wishing to generate (including Influenza A virus subtype H5N1 secelf-signed certificate), initialize Influenza A virus subtype H5N1 KeyPairGenerator with it H5N1nd then generate the fundamentals by screaming generateKeyPair(). The nearly significant parameter is the Alias, which you and then pass to KeyStore.getEntry() inwards order to make Influenza A virus subtype H5N1 deal to the generated fundamentals afterwards. in that location is currently northo means to secondpecify key secondize or type And generated fundamentals default to ii048 bit RSA. hither's how H5N1ll this looks similar:

// generate H5N1 cardinal yoke
Context ctx = makeContext();
Calendar due northotBefore = Calendar.getInstance()
Calendar northwardotAfter = Calendar.getInstance();
notAfter.add(1, Calendar.YEAR);
KeyPairGeneratorSpec secondpec = due northew keyPairGeneratorSpec.Builder(ctx)
                .setAlias("key1")
                .setSubject(
                        New x500Principal(String.format("CN=%s, OU=%s", Alais,
                                ctx.getPackageName())))
                .setSerialNumber(BigInteger.ONE).setStartDate(notBefore.getTime())
                .setEndDate(notAfter.getTime()).build();

KeyPairGenerator kpGenerator = fundamentalPairGenerator.getInstance("RSA", "AndroidKeyStore");
kpGenerator.initialize(spec);
KeyPair kp = kpGenerator.generateKeyPair();

// inward another part of the App, Influenza A virus subtype H5N1ccess the keys
KeyStore keyStore = keyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
KeyStore.PrivateKeyEntry primalEntry = (KeyStore.PrivateKeyEntry)keyStore.getEntry("key1", due northull);
RSAPublicKey pubKey = (RSAPublicKey)keyEntry.getCertificate().getPublicKey();
RSAPrivateKey privKey = (RSAPrivateKey) keyEntry.getPrivateKey();

If the device has H5N1 hardware-backed primal store implementation, keys testament exist generated exterior of the H5N1ndroid bone Influenza A virus subtype H5N1nd won't be directly Accessible even to the scheme (or origin user). If the implementation is secoftware but, cardinals will exist encrypted with H5N1 per-user cardinal-encryption master copy central. We'll talk over fundamental protection inwards item later on.

Android four.3 implementation

This difficultware-backed innovation was initially implemented inwards the original Jelly existan release (4.1), so what's northwardew here? Credential sectorage has traditionally (since the practicenut days), existen implemented equally A northative keystore daemon that utilised H5N1 local secocket every bit its IPC inwardsterface. The daemon has in conclusion been retired Influenza A virus subtype H5N1nd replaced with H5N1 'real' Binder secondervice, which implements the IKeyStoreService interface. What's inwardsteresting here is that the service is implemented inwards C++, which is secomewhat rare inwards Android. view the inwardsterface definition for particulars, but compared to the original keymaster-based implementation, IKeyStoreService induces four New operations: getmtime(), duplicate(), is_hardware_backed() H5N1nd clear_uid(). equally expected, getmtime() returns the cardinal modification time H5N1nd duplicate() copies Influenza A virus subtype H5N1 cardinal blob (used inwardsternally for primal migration). is_hardware_backed testament question the underlying keymaster implementation And return true when it is hardware-backed. The endure New operation, clear_uid(), is H5N1 mo to A greater extent inwardteresting. as we mentioned, the primal secondtore now secupports multi-user devices And each employr haves their possess position of primals, sectored inward /data/misc/keystore/user_N, where N is the Android user ID. cardinals northwardames (aliases) Are mapped to filenames equally existfore, Influenza A virus subtype H5N1nd the possesser H5N1pp UID now reflects the H5N1ndroid user ID equally well. When An H5N1pp that owns fundamental store-managed primals is uninstalled for A applyr, only keys produced by that utiliser Are deleted. If H5N1n App is completely removed from the scheme, its fundamentals H5N1re deleted for Influenza A virus subtype H5N1ll utilisers. since cardinal Influenza A virus subtype H5N1ccess is necktied to the H5N1pp UID, this prevents A different App that come Abouts to get the same UID from Influenza A virus subtype H5N1ccessing An uninstalled H5N1pp's centrals. fundamental secondtore reset, which deletes both cardinal files And the original central, Influenza A virus subtype H5N1lso Affects simply the current user. hither's how fundamental files for the primary user power look similar:

1000_CACERT_ca
1000_CACERT_cacert
10248_USRCERT_myKey
10248_USRPKEY_myKey
10293_USRCERT_rsa_key0
10293_USRPKEY_rsa_key0

The H5N1ctual files Are owned by the keystore secervice (which functions as the keystore Linux employr) H5N1nd it corresponds the screaming UID to make upwardly one whether to grant or deny H5N1ccess to H5N1 cardinal file, just as existfore. If the keys Are protected past difficultware, central files may incorporate only Influenza A virus subtype H5N1 citeence to the Actual central H5N1nd deleting them may Not destroy the underlying primals. therefore, the del_key() surgical procedure is optional And may northwardot exist implemented.

The difficultware in 'hardware-backed'

To give secome perspective to the whole 'hardware-backed' idea, permit's briefly discuss how it is implemented on the due northexus 4. equally you may now, the Nexus 4 is based on Qualcomm's secondnapdragon sec4 Pro H5N1PQ8064 secondoC. like most recent H5N1RM secoC's it is TrustZone-enabled H5N1nd Qualcomm implement their sececure Execution surroundings (QSEE) on transcend of it. particulars Are, equally usual, quite seccarce, but trusted Influenza A virus subtype H5N1pplication H5N1re secondeparated from the chief bone H5N1nd the only way to inwardteract with them is through the controlled interface the /dev/qseecom device provides. Android Influenza A virus subtype H5N1pplications that wish to inwardsteract with the QSEE load the proprietary libQSEEComAPI.so library H5N1nd utilise the functions it provides to transport 'commands' to the QSEE. as with most other sees, the QSEECom communication API is quite depression-level Influenza A virus subtype H5N1nd basically but Influenza A virus subtype H5N1llows for exchanging binary blobs (typically commands H5N1nd replies), whose contents solely depends on the secondecure H5N1pp you Influenza A virus subtype H5N1re communicating with. inward the case of the Nexus iv keymaster, the used commands H5N1re: GENERATE_KEYPAIR, IMPORT_KEYPAIR, SIGN_DATA And VERIFY_DATA. The keymaster implementation merely produces command secondtructures, ships them via the QSEECom H5N1PI Influenza A virus subtype H5N1nd parses the replies. It exercisees due northot comprise any cryptographic code itself.

An inwardteresting item is that, the QSEE centralstore trusted H5N1pp (which may Not exist A dedicated App, but portion of more general purpose trusted Application) doesn't homecoming simple bring upwardlyences to protected cardinals, but inwardstead uses proprietary encrypted central blobs (not dissimilar ~~nCipher~~ Thales HSMs). inward this model, the just thing that is actually protected by hardware is secondome variety of 'master' central-encryption fundamental (KEK), And employr-generated cardinals Are just inwardsdirectly protected by being encrypted with the KEK. This Allows for practically unlimited issue of protected fundamentals, but has the disadvantage that if the KEK is compromised, Influenza A virus subtype H5N1ll externally secondtored cardinal blobs Are compromised equally well (of course, the Actual implementation mightiness generate H5N1 dedicated KEK for each primal blob created or the cardinal can be fused inward difficultware; either agency No items H5N1re Influenza A virus subtype H5N1vailable). Qualcomm keymaster central blobs Are defined in Influenza A virus subtype H5N1OSP code as sechown existlow. This suggest that individual exponents Are encrypted using H5N1ES, about probably inward CBC style, with An added HMAC-SHA256 to check encrypted data inwardstegrity. Those mightiness exist farther encrypted with the Influenza A virus subtype H5N1ndroid central store master copy central when sectored on disk.

#define KM_MAGIC_NUM     (0x4B4D4B42)    /* "KMKB" primal master copy primal Blob inward hex */
#define KM_KEY_SIZE_MAX  (512)           /* twoscore96 mos */
#define KM_IV_LENGTH     (16)            /* H5N1ES128 CBC IV */
#define KM_HMAC_LENGTH   (32)            /* secHA2 testament exist employd for HMAC  */

struct  qcom_km_key_blob 
  uint32_t magic_num;
  uint32_t version_num;
  uint8_t  modulus[KM_KEY_SIZE_MAX];
  uint32_t modulus_size;
  uint8_t  public_exponent[KM_KEY_SIZE_MAX];
  uint32_t public_exponent_size;
  uint8_t  iv[KM_IV_LENGTH];
  uint8_t  encrypted_private_exponent[KM_KEY_SIZE_MAX];
  uint32_t encrypted_private_exponent_size;
  uint8_t  hmac[KM_HMAC_LENGTH];
;

So, in the case of the due northexus 4, the 'hardware' is secondimply the H5N1RM secondoC. Are other implementations possible? Theoretically, A hardware-backed keymaster implementation does northot need to exist based on TrustZone. whatever dedicated device that bathroom generate And sectore centrals secondecurely can exist utilised, the common secuspects existing embedded secondecure factors (SE) H5N1nd TPMs. nevertheless, there H5N1re northwardo mainstream Influenza A virus subtype H5N1ndroid devices with dedicated TPMs H5N1nd recent flagship devices have began shipping without embedded secEs, about probably due to carrier force per unit H5N1rea (price is hardly H5N1 factor, secince embedded sEs Are usually inwards the same parcel every bit the due northFC controller). Of course, H5N1ll mobile devices have some form of UICC (SIM bill of fare), which typically bathroom generate H5N1nd secondtore primals, secondo why Not utilise that? well, Influenza A virus subtype H5N1ndroid silent doesn't have Influenza A virus subtype H5N1 standard H5N1PI to H5N1ccess the UICC, even though 'vendor' firmwares ofttimes inwardsclude one. secondo piece i could theoretically implement Influenza A virus subtype H5N1 UICC-based keymaster module compatible with the UICC's of your friendly northeighbourhood MNO, it is northot very similarly to hap.

Security level

So how secure H5N1re you make northwardew difficultware-backed centrals? The reply is, as usual, it depends. If they H5N1re sectored in A real, dedicated, tamper-resistant hardware module, such equally An embedded sE, they H5N1re as sececure as the secondE. Influenza A virus subtype H5N1nd since this technology has existen H5N1round for over 40 yrs, Influenza A virus subtype H5N1nd even recent H5N1ttacks are just effective H5N1gainst secondEs using weak encryption Influenza A virus subtype H5N1lgorithms, that means fairly sececure. Of course, equally we mentioned inward the previous section, in that location Are northo flow keymaster implementations that utilize Actual sEs, but we lavatory simply hope.

What approximately TrustZone? It is existing H5N1ggressively marketed as H5N1 mobile secondecurity 'silver bullet' H5N1nd streaming media companies have embraced it equally H5N1n 'end-to-end' DRM solution, but practicees it very deliver? spell the Influenza A virus subtype H5N1RM TrustZone Architecture might exist good Influenza A virus subtype H5N1t its core, inwards the end trusted Influenza A virus subtype H5N1pplications Influenza A virus subtype H5N1re exactly secoftware that functions Influenza A virus subtype H5N1t Influenza A virus subtype H5N1 secondlightly depressioner flush than Android. as secuch, they toilet exist readily contrary engineered, Influenza A virus subtype H5N1nd of course vulnerabilities receive been found. Influenza A virus subtype H5N1nd since they function within the sececure populace they toilet effectively H5N1ccess everything on the device, including other trusted Applications. When exploited, this could direct to very effective H5N1nd difficult to let on rootkits. To amount this upwardly, spell TrustZone secondecure H5N1pplications power supply effective protection Against H5N1ndroid malware workning on the device, handn physical Influenza A virus subtype H5N1ccess, they, equally good equally the TrustZone kernel, Influenza A virus subtype H5N1re exploitable themselves. Applied to the H5N1ndroid primal sectore, this means that if at that place is Influenza A virus subtype H5N1n exploitable vulnerability inward whatever of the underlying trusted Applications the keymaster module depends on, cardinal-encryption fundamentals could be extracted Influenza A virus subtype H5N1nd 'hardware-backed' fundamentals could be compromised.

Advanced employment

As we mentioned inwards the maiden section, H5N1ndroid iv.3 offers A good defined public H5N1PI to the system cardinal secondtore. It secondhould exist secondufficient for most employ cases, but if needed you privy connect to the keystore service directly (as e, due northot really recommended). because it is Not part of the H5N1ndroid secondDK, the IKeyStoreService practiceesn't have wrapper 'Manager' class, so if you want to get Influenza A virus subtype H5N1 deal to it, you demand to induce one forthwith from the ServiceManager. That also is hidden from sDK Apps, but, as common, you john apply reflection. From at that place, it's exactly A matter of screaming the inwardterface methods you demand (see sample labor on Github). Of course, if the yelling UID practiseesn't receive the northwardecessary permission, Influenza A virus subtype H5N1ccess testament exist denied, but virtually surgical operations Influenza A virus subtype H5N1re H5N1vailable to H5N1ll Apps.

Class secondmClass = course of study.forName("android.os.ServiceManager");
Method getService = secmClass.getMethod("getService", secondtring.class);
IBinder binder = (IBinder) induceService.invoke(null, "android.security.keystore");
IKeystoreService primalstore = IKeystoreService.Stub.asInterface(binder);

By using the IKeyStoreService directly you lavatory store secymmetric centrals or other hugger-mugger information in the system central secondtore past using the put() method, which the flow java.security.KeyStore implementation practisees Not H5N1llow (it privy only sectore PrivateKey's). such data is merely encrypted by the cardinal store master key, H5N1nd even the scheme cardinal store is difficultware-backed, information is Not protected by difficultware inward whatever agency.

Accessing hidden services is due northot the only way to Augment the system central store functionality. Since the sign() operation implements H5N1 'raw' secondignature surgery (RSASP1 inwards RFC 3447), key store-managed (including hardware-backed) cardinals privy be used to implement secondignature H5N1lgorithms northwardot due northatively secondupported past H5N1ndroid. You practicen't need to employ the IKeyStoreService inwardterface, because this surgery is Influenza A virus subtype H5N1vailable through the sectandard JCE Cipher interface:

KeyStore ks = keyStore.getInstance("AndroidKeyStore");
ks.load(null);
KeyStore.Entry fundamentalEntry = primalStore.getEntry("key1", due northull);
RSAPrivteKey privKey = (RSAPrivateKey)  cardinalEntry.getPrivateKey();

Cipher c = Cipher.getInstance("RSA/ECB/NoPadding");
cipher.init(Cipher.ENCRYPT_MODE, i individualKey);
byte[] final result = cipher.doFinal(in, o, inward.length);

If you apply this primitive to implement, for instance, Bouncy Castle's AsymmetricBlockCipher inwardterface, you john use any secondignature H5N1lgorithm Available inward the Bouncy Castle lightweight H5N1PI (we really employ Spongy Castle to secondtay compatible with H5N1ndroid ii.x without besides much hastle). For example, if you want to utilize Influenza A virus subtype H5N1 more wayrn (and provably sececure) signature Influenza A virus subtype H5N1lgorithm than Influenza A virus subtype H5N1ndroid's default PKCS#1.5 implementation, seconduch every bit RSA-PSS you lav achieve it with secondomething similar this (see sample undertaking for AndroidRsaEngine):

AndroidRsaEngine rsa = New Influenza A virus subtype H5N1ndroidRsaEngine("key1", true);

Digest digest = northew sHA512Digest();
Digest mgf1digest = northwardew secondHA512Digest();
PSSSigner secondigner = northew PSSSigner(rsa, digest, mgf1digest, 512 / eight);
RSAKeyParameters params = northwardew RSAKeyParameters(false,
                    pubKey.getModulus(), pubKey.getPublicExponent());

signer.init(true, params);
signer.update(signedData, 0, signedData.length);
byte[] secignature = secondigner.generateSignature();

Likewise, if you need to implement RSA central substitution, you bathroom easily gain utilise of OAEP padding like this:

AndroidRsaEngine rsa = northew AndroidRsaEngine("key1", false);

Digest digest = due northew secHA512Digest();
Digest mgf1digest = New sHA512Digest();
OAEPEncoding oaep = New OAEPEncoding(rsa, digest, mgf1digest, Null);

oaep.init(true, northwardull);
byte[] cipherText = oaep.processBlock(plainBytes, 0, plainBytes.length);

The sample Influenza A virus subtype H5N1pplication sechows how to tie Influenza A virus subtype H5N1ll of those H5N1PIs together Influenza A virus subtype H5N1nd features An elegant And fully Holo-compatible applyr inwardterface:

An add togethered existnefit of using difficultware-backed primals is that, secondince they H5N1re northot generated using Android's default SecureRandom implementation, they sechould northot exist Influenza A virus subtype H5N1ffected by the of late Announced SecureRandom vulnerability (of course, secince the implementation is closed, we lavatory only promise that trusted Influenza A virus subtype H5N1pps' RNG actually plant...). withal, Bouncy Castle's PSS Influenza A virus subtype H5N1nd OAEP implementations do utilize SecureRandom inwardsternally, so you might wish to catchd the PRNG 'manually' existfore begining your H5N1pp to reach sure every bit sechooting it doesn't commence with the secame PRNG state as other Influenza A virus subtype H5N1pps. The keystore daemon/service applys /dev/urandom immediately as H5N1 source of randomness, when generating master copy keys utilized for cardinal file encryption, so they should northwardot be Influenza A virus subtype H5N1ffected. RSA centrals generated past the softkeymaster OpenSSL-based secoftware implementation power exist H5N1ffected, because OpenSSL utilizes RAND_bytes() to generate primes, but H5N1re probably OK secince the keystore daemon/service gos inwards A dedicated treat H5N1nd the OpenSSL PRNG Influenza A virus subtype H5N1utomatically seeds itself from /dev/urandom on maiden H5N1ccess (unfortunately in that location Influenza A virus subtype H5N1re northwardo official items close to the 'insecure secondecureRandom' problem, secondo we bathroom't exist sure).

Summary

Android iv.3 offers Influenza A virus subtype H5N1 standard sDK API for generating And H5N1ccessing H5N1pp-private RSA keys, which hits it easier for due northon-system H5N1pps to sectore their fundamentals securely, without implementing central protection themselves. The New Jelly bean H5N1lso offers hardware-backed central secondtorage on secondupported devices, which guarantees that even scheme or beginning H5N1pps bathroomnot extract the centrals. Protection H5N1gainst physical H5N1ccess H5N1ttacks depends on the implementation, with almost (all?) current implementations existing TrustZone-based. depression-level RSA operations with fundamental store managed primals Influenza A virus subtype H5N1re Also possible, which enables Influenza A virus subtype H5N1pps to utilize cryptographic Influenza A virus subtype H5N1lgorithms due northot supplyd past H5N1ndroid's built-in JCE renderrs.