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

[surfdaddy]

OK, thanks for the clarification. So I was confusing this issue with the Qualcomm one, which is also relevant.
The good news is that the Android flaw will likely be patched quickly (for those of us with Nexus phones at least). The hardware flaw from Qualcomm will probably take a bit more time and of course current HW isn't going to get fixed.

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

[Curunir_wolf]

Good news, Thanks!

I recently got the Marshmallow update on my Alcatel phone, so I should be all good.

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]

Good news, Thanks!

I recently got the Marshmallow update on my Alcatel phone, so I should be all good.

Marshmallow doesn't fix this broken encryption; we just decided in Marshmallow that since this is not useful we should deprecate it.

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.

Re:Qualcomm

[Lothsahn]

Thank you for a clear and descriptive explanation of the actual bug. This is why I've loved Slashdot all of these years.

Re:Qualcomm

[acrimonious howard]

Slashdot is back, it's the Year of the Slashdot!

J/K. Seriously, thanks swilden.

Re:Qualcomm

[swillden]

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.

Thanks. That is exactly what always made me love slashdot, and it's mostly those memories that keep me around, I think. I'm glad I could contribute in this case.

Re:Non clear language

[AmiMoJo]

The article says they think there is a theoretical flaw, but they don't have a working exploit. It needs fixing, but should be more than strong enough to keep most adversaries below CIA/MI5 level out .

BULLSHIT

[Anonymous Coward]

Qualcomm isn't mentioned at all in the fucking paper itself

Re: BULLSHIT

[saloomy]

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

Re:Non clear language

[sexconker]

They are the same. If you can't prove it's secure, it must be treated as if it were not secure.

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:In simpler terms, please?

[slew]

A not so perfect car analogy...

You have a car that accepts a valet key (short key) and a owner key (long key). Both keys open the door and start the engine, but only the owner key opens the glove box. The flaw in this system is that allows for the possibility for some hacker to "forge" a long key that opens the glove box with a different "key" (that is known to the hacker) which has the short key attributes you check all the time (e.g., opens the door and starts the engine), but doesn't actually open the glove box (which you don't do very often), yet still superficially appears to be a long key that *might* open a glove box (even though the "key" won't actually open your glove box if you tried it).

It isn't the end of the world, since a valet can't do this swap (because you only give them the short valet key, but you generally don't give the long owner key to anyone), but if somehow someone gets access to your keystore and swaps your owner key for this long "key" forgery, there might be a problem (maybe you occasionally get drunk and install malicious apps)...

Since you haven't recently attempted to use your "key" to open the glove box recently, when you decide to have a locking gun rack installed which you want to work on the same long owner "key" you have. You get the person that makes the lock for the gun rack to key to lock with the "key" from your keystore. Now, you aren't aware of it yet, but the hacker will now have the ability to steal the gun because they have a copy of the "key" that opens your gun rack even if though don't have a copy of the original long key that can open your glove box. You eventually figure it all out when a cop stops on suspicion that your gun has been used in a crime and you look back and see your gun rack locked, empty, but undamaged, and your "key" works on the gun rack, but won't open your glove compartment to get your car registration papers. Circumstantially speaking, it then sucks to be you ;^)

Of course the real hash-then-encrypt isn't really the same as the short-key/long-key car analogy given above, but it's the best car analogy I could come up with...

Huh

[watermark]

I'm unsure how scared I should be. Could someone put this in a car analogy?

Re:Huh

[LichtSpektren]

https://tech.slashdot.org/comm...

Re:Huh

[p0p0]

The doors are unlocked.

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

[sbrown7792]

If you can't prove it's secure, it must be treated as if it were not secure.

Emphasis mine. Just because you treat something as if it was non-secure, does not make it non-secure.
Non-provably secure != Provably non-secure.

Re:Non clear language

[bjamesv]

they don't have a working exploit.

Yes they do. The abstract of the linked paper states clearly: "we exploit this flaw to define a forgery attack"

Their demo exploit is an app, malware, and could be used by any other user, criminal, three-letter agency capable of such advanced techniques as *getting malware* onto target device. The linked article further expands on this to point with comments from the author, highlighting that anyone with a 0-day or known exploit would be able to degrade KeyStore encryption to crackable levels, without first having to trick a user into installing their app.

Re:Non clear language

[mlts]

If some adversary, even a well-heeled one can find it now, it only will get worse. Once the exploit is out, it can be made into something usable by virtually anyone. Stuff like this needs fixed, theory or no, because the Android keystore or iOS's KeyChain guards a lot of sensitive, high-value content.

OpenSSL?

[QuietLagoon]

...KeyStore, which performs key-specific actions through the OpenSSL library...

Or BoringSSL ?

Not clear

[TheRealMindChild]

So... if I understand this correctly, the vulnerability is in the fact that since they mac-then-encrypt, the data must be decrypted before the HMAC can be validated. SO, in theory, it opens up the possibility of a side-channel attack, but I don't see how the encryption is actually "broken"

Re:OpenSSL Strikes Again!

[bluefoxlucid]

It's not a flaw in OpenSSL's implementation; it's a flaw in the order of encrypted operations selected by a client library.

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.

Thank you!

[H3lldr0p]

Thank you! You even managed to make the analogy not hyperbolic. You are the hero we deserve today.

No,never.

[Anonymous Coward]

Suprise,suprise,another hole in Google's crud os,and people complain about ms ?
But then Google have to ale sure every device is readable by nsa etc etc,whatever the user has done to try and lock down device...
Do no evil,what a joke.
They should have said,
Never get caught lieing instead.
Why people ever trusted or still do is beyond me.
Like every other firm that came out of that area,their just a bunch of greedy crooks..

Re:Non clear language

[K. S. Kyosuke]

It is a MOOt point if it is secure or not. The problem with the statement of ''"the system is non-provably secure," would be better stated as "The system is not secure."' is that the latter contains strictly more information so it can't be equivalent to the former.

"What about my little keister?"

[Vidar Leathershod]

Can't read this without thinking of this - doesn't get more applicable:

http://www.dailymotion.com/vid...

07:26 for the direct reference, but the whole episode was a truly fantastic piece of comedy...