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:Qualcomm

[wbr1]

swilden, thank you.

This friends is the slashdot of old, where you you could get intelligent, in depth information from an engineer close to the source, or an astronomer talking about mods to their statistical analysis packages.

There was always a political echo chamber and a certain level of douchbaggery, but this is what made the site shine. I have been here in various guises since 97 or so.

Thanks again for helping keep this place great.

Re:Qualcomm

[swillden]

The uncovered flaw is entirely an Android software issue, wherein an attacker with malware or a 0-day priviledged exploit can silently [...]

So... to gain access, they need to already get root access to the device? Sorry to break it to you, but once they got root, it's game over.

For keys managed by the Android/Linux system, that's true, which is why the encryption in question is deprecated and slated for removal. Keys managed in the trusted execution environment are not compromised by rooting, in the sense that the attacker cannot extract the raw key material, and can't direct the TEE to perform any operations with the key that aren't permitted by whatever access controls are enforced in the TEE.

In simpler terms, please?

[H3lldr0p]

Would it kill the editors to cut through the BS and give us a blurb under the article that explains this in simpler terms?

It'd be nice to understand what the actual problem is without having to spend an hour looking up the TLAs.

Re:In simpler terms, please?

[LichtSpektren]

The keys to your cars are on a rack in your house. You have a security camera in your house that makes ensure against a malicious person who walks in your house, takes your keys, clones them, then puts the originals back on the rack. It turns out the security camera's susceptible to that trick from The A-Team where you take a photo of the room from the perspective of the security camera, then tape the photo onto the security camera's lens so it looks like there's no activity in the room. Because of that, there's no way of checking to make sure nobody sneaks in your house to clone your car keys.

Re: BULLSHIT

[saloomy]

Get the fuck out of here, you with your stupid.... facts, and stuff.

Re:Huh

[mcl630]

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

Re:Non clear language

[Tourney3p0]

It seems to prove the exact opposite of your point. The phrase "non-provably secure" was chosen because that's what it is. "The system is not secure" is not the same as "The system should be treated as not secure". In one case, something has been proven. In the other, it has not. That is a huge, huge difference in terms of why we use different words to mean different things. Or you can just admit that you didn't understand what was originally written and got called out on calling *someone else* bad at English.