Android KeyStore Encryption Scheme Broken (threatpost.com)

Reader msm1267 writes: The default implementation for KeyStore, the system in Android designed to store user credentials and cryptographic keys, is broken, researchers say.>In an academic paper published this week, researchers argue that the particular encryption scheme that KeyStore uses fails to protect the integrity of keys and could be exploited to allow an attacker to modify stored keys through a forgery attack.
KeyStore, which performs key-specific actions through the OpenSSL library, allows Android apps to store and generate their own cryptographic keys. By storing keys in a container, KeyStore makes it more difficult to remove them from the device. Mohamed Sabt and Jacques Traore, two researchers with the French telecom Orange Labs, claim the scheme associated with the system is "non-provably secure," and could have "severe consequences." The two point out in their paper "Breaking Into the KeyStore: A Practical Forgery Attack Against Android KeyStore," that it's the hash-then-encrypt (HtE) authenticated encryption (AE) scheme in cipher block chaining mode (CBC) in KeyStore that fails to guarantee the integrity of keys.

Comments

Qualcomm

[surfdaddy]

To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself, although the effect is the same. Samsung has some non-Qualcomm chipsets (Exonos) used on some of their phones and those are apparently not affected.

Re:Qualcomm

[bjamesv]

To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself

Incorrect. The threatpost author just threw in the comment regarding Qualcomm at the very end of his writeup, it has entirely nothing to do with the cryptographic weakness the researchers from Orange uncovered.

The uncovered flaw is entirely an Android software issue, wherein an attacker with malware or a 0-day priviledged exploit can silently downgrade the strength of certain symmetric keys apps use to store private/encrypted data to cloud storage services. (Thereby allowing the attacker to swiftly break the encryption of data which previously could be efficiently decrypted only via the unmodified secret key located on the users handset)

Re:Qualcomm

[swillden]

To be clear, the issue is a hardware issue in Qualcomm chipsets rather than with Android itself, although the effect is the same. Samsung has some non-Qualcomm chipsets (Exonos) used on some of their phones and those are apparently not affected.

I'm the Google engineer responsible for Keystore.

What you're talking about is a different (and more serious) issue, related to "hardware-backed" keys. The just-published paper is about a weakness in a software-only legacy method that was put in place to provide minimal protection of keys on devices that lacked any reasonable option for device encryption. It's something that I've been meaning to remove completely. It is applied only when apps specifically request it with KeyPairGeneratorSpec.setEncryptionRequired. Based on a scan of the Google Play store, almost no apps request it, and it was formally deprecated in Android Marshmallow. Even if it didn't contain an error in its cryptographic construction, it provides very little security, because you have to root the device to get at the encrypted keys, and once you've done that you have all sorts of options to get at the plaintext.

The primary value in the Android Keystore is in hardware-backed keys: Keys that are generated and used only in the Trusted Execution Environment. Because those keys are (barring issues like the aforementioned Qualcomm TEE bug) never available to the Linux kernel or Android system, no break of the system security can enable extraction of the key material, which keeps the keys bound to the device. Moreover, in a major overhaul of Keystore in Marshmallow, Android Keystore gained the ability to enforce various other access controls to the keys; most of this enforcement is also done in the TEE, reducing the ability of an attacker who roots the device to use Keystore as a key oracle.

There is also some value in Android Keystore on devices without a TEE. Specifically, using Keystore keys rather than keys managed directly by the app moves the key material out of the app's process space, which means that any attack which manages to exploit some security defect in the app and gain access to the app's data can't get a copy of the key material. To do that, the attacker has to get root -- and, assuming "setEncryptionRequired" was used, also break this weak and (in the opinion of the Android security team) unnecessary encryption.

So, yeah. This encryption is broken. But it's unnecessary, deprecated and slated for removal anyway, so it doesn't matter. Which is exactly what I told the researcher when he reported the bug.

The Qualcomm TEE bug, on the other hand, is an issue. It's a fixed issue, but there's this old and very hard-to-fix problem that Android devices don't get security patches the way they should. Nexus devices are patched.

Re:Huh

[mcl630]

Somebody can replace the locks in your car with new locks that both your keys and their keys will unlock.