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

[Anonymous Coward]

I think you are talking about the FDE article submitted some days ago. This one deals with the default KeyStore implementation in Android.

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

[Anonymous Coward]

Maybe. Who knows what security holes he introduced into Marshmallow? He's too busy acting as the local PR rep of Google to actually do his job.

Re:Qualcomm

[Anonymous Coward]

Nexus devices are patched.

I think you meant to say Nexus devices are patched for 18 months (unless you bought it on launch day)...
If only my Nexus 7 (2012) continued to receive patches ;^)

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

[Anonymous Coward]

Patched? How? Buy phone. Use phone.

Patching?

Re:Qualcomm

[Anonymous Coward]

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.

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

[Anonymous Coward]

Said without the slightest hint of irony...

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

[Anonymous Coward]

This is my job, you insensitive clod.

Plus, my sloppy work hasn't ended up in the news, yet!

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.

OpenSSL Strikes Again!

[Anonymous Coward]

Sigh....

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.

Non clear language

[Anonymous Coward]

"the system is non-provably secure," would be better stated as "The system is not secure."

It is hard to trust the integrity of a complex system and the understanding of the researchers when they cannot handle a simple statement in simple English.

They would do better to hire an editor. Trying to make it sound more complex than it is by phrasing things like "Non provably secure" is more rhetoric than demonstrating any sort of knowledge or technical proficiency. This is coming from someone with 3 degrees and 20 years experience in the field.

Re:Non clear language

[Anonymous Coward]

No, they are not the same at all. "Non-provably secure" means that it may or may not be secure, but it can't be proven. "Not secure" means not secure. Speaking of not being able to handle a simple statement in simple English.. throwing out the degrees and experience was a nice touch as well.

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 .

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.

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.

Re:Non clear language

[Anonymous Coward]

What is theoretical today can become practical tomorrow and what is at CIA/MI5 level could become cyber mafia level. Given the fact that Android updates are hard to get on many devices, this needs to be fixed soon.

Re:Non clear language

[Anonymous Coward]

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.

This is just my point, they may as well say that the system is non-not-non-not-non-secure.. what a disaster of English! Real engineers who are successful in this field have a gift for being able to render complex topics simple to the non-expert and the engineers in the article have done just the opposite. I say this looking at the first AC who answered my statement above on clear english.. they tried to throw back the phrase "Not secure" like it is not clear, when it is nothing but.. It is clear why that idiot is not involved in IT security and is pissed he can't get hired.

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.

Re:Non clear language

[Anonymous Coward]

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.

First off you are a moron.

Ill put it into other words that you might more likely see the problem so you can shut up and stop trolling.

Non-provably secure, is not the concept expressed in the simplest terms, just like sometimes a page full of algebra equations can be stated in one line by simplifying the equation. The phrase "Non-Provably Secure" is meant to point out a system that has a possible exploit and (sing along now kids!) a system with a possible exploit is insecure!

I understood perfectly what they fucking meant so stop your trolling asshole!

Seriously you are just restating the points of the idiot that got shot down 5 minutes after I initially posted so shut up, you are an idiot and I know what the fuck "They meant" but not everyone else does and here is the kicker...
IT IS FUCKING IRRELEVANT, the term is unnecescarially complicated, and can be stated more precisely in fewer words , and in such a way that meaning of your "Different words meaning different things" are communicated more simply and efficiently using less words..

Seriously man you might just be the smartest kid with down syndrome!

Re:Non clear language

[Anonymous Coward]

wow! Tourney3p0 got schooled!

I am wondering here Tourney, how exactly is that you figure this proves the "opposite" of the point the AC is made, that being the wording is confusing and unnecessarily complicated thereby obscuring the intended meaning of insecure or not able to be proved secure?

I don't see it and neither does about 5 people in my office I have shown this to today.

It seems they are using an award, non standard, made up term that seems to mean whatever the reader wants it to mean. It seems by you saying it means the opposite of this does not make a lot of sense in your argument, So you are saying "non-provably secure" is not simpler than saying "Insecure" or "Potentially insecure" or "Potentially exploitable"? The term "Non-provably secure" is like throwing a maybe after a direct statement of confidence in the system thereby casting uncertainty or doubt on what you just said and since it is not a regularly used term, it is not reasonably clear what is meant as there are several different interpretations that can be made.. personally sounds more like a clickbait strategy than something I would use to explain a potential system vulnerability to my supervisor or my software development team that would ensure in a few words that we ALL are on the same page.

How exactly does this prove the "opposite" of the above? tell us!

Enlighten us please...

Re: Non clear language

[Anonymous Coward]

Yeah, the trusted chip of any phone could have a bug in it, especially the closed source ones - you have to take the word of the manufacturer that they implemented it correctly.

All devices are therefore non-probably secure.

Those words mean nothing. You can't prove they're secure also means you can't prove they're insecure. A theoretical flaw is just a theoretical flaw. Unless you either prove mathematically or just straight up do it, you can presume industry standard implementations are pretty secure.

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.

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

[Anonymous Coward]

You seem to be using Android and work for google and don't like the "facts". But we do. So you need to get out of here and bury your head in sand.

Re: BULLSHIT

[Anonymous Coward]

*whoosh*

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?

[Anonymous Coward]

There is always [New] Hope.

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?

[Anonymous Coward]

In simpler terms: All Your Base Are Belong To Us.

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...

Re:In simpler terms, please?

[Anonymous Coward]

Can you do sports analogy? I don't understand cars.

Fingerprints

[Anonymous Coward]

Doesn't that allow hacking of the stored fingerprint, oops.

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

[Anonymous Coward]

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

Somebody got you car keys! You car has been stolen!

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.

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:Not clear

[Anonymous Coward]

Actually, it has nothing to do with mac-then-encrypt. The attack works by removing the mac block. It is MD5, 16 bytes, and so takes up the entire first block. Once the mac is removed, there are apparently no further validity checks when a symmetric key is used. So the attacker forges a block of garbage data that the keystore then decrypts as a short symmetric key. Because it is just a key, there is no way to verify that it is valid, so it gets used, and so the attacker can crack messages using it.

Furthermore, the paper explicitly states that the attacker must already have root access to your phone, or be able to run as the keystore user. This privilege escalation is required in order to write keystore data files.

So, to summarize: the attack works because keystore can read in a key without a mac, and because the attacker already has rooted your phone. Therefore, it almost certainly does not affect you.

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..

"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...