[libertymcateer]

The kernel is owned (or some part of the phone below the application level). The encryption only gets applied at the application level before the messages are sent down the wire.

The interception happens prior to the encryption being applied. Think of it as a dongle on the wire between your keyboard and the computer. It doens't matter if the computer is secure - the message is intercepted prior to any encryption.

This is, what I am assuming, has happened here.

Edit: lots of stuff deleted for very valid criticism, as below.

[md_]

> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising. I have long been saying that Android is insecure and that storing passwords in Chrome is dangerous.

ChromeOS and Android both implement FDE. There are some legitimate criticisms of (especially) the latter, voiced by e.g. Matthew Green, but you're just speaking nonsense here.

There's very little value in per-app encryption on desktop OSes; it's security theater.

I shudder to think of what your "secure communications" app does. I hope you're a good lawyer. ;)

[libertymcateer]

I am not talking about ChromeOS - I am talking about the Chrome browser. Localstorage, last I checked, which was recently, is plaintext.

> ChromeOS and Android both implement FDE

Which is irrelevant if the runtime is compromised, which appears to be the case.

[md_]

Let's be all Socratic here:

Given a desktop OS like Windows that implements FDE like Bitlocker and runs a browser like Chrome, can you describe a hypothetical threat in which Chrome encrypting localstorage would prevent exploitation?

[libertymcateer]

Yes - worms or browsers that scan local data files without accessing the runtime of the parent application.

[md_]

So your threat model is "malware which has access to memory containing plaintext but is written by idiots"?

0_o

[libertymcateer]

Dunno if you are still checking this thread, but I had a followup to this question.

It seems to me that certain cryptoviruses function in the following way (e.g. certain variants of ransom_vxlock - I will see if I can find a specific example):

* The virus functions like other cryptoviruses, encrypting local data and holding it for ransom

* However, in addition to holding your local data ransom, it archives certain files that are likely to hold passwords (e.g., the chrome password store), and then emails them to the C&C server

If this is the case, would local encryption of the chrome password store be a protection, or would the decryption of this store be trivial the the virus author? Again, assuming that the virus author is a script kiddy.

So, basically, I am asking that if the characterization of the virus described is accurate, doesn't that mean that the threat model I describe also actually occurs in the wild? I'm not trying to be facetious here - I am trying to get to the bottom of this.

I will try to find links to support the above.

[vetinari]

And it does not matter - it is in Chrome's homedir, no other app can access it. Wrt. physical store, it is on FDE anyway.

[libertymcateer]

Good sn.

[bitmapbrother]

>Which is irrelevant if the runtime is compromised, which appears to be the case.

You're under the false assumption that these exploits are current - they're not. In fact, they're very old.

[libertymcateer]

These ones?

https://www.washingtonpost.com/world/national-security/wikil...

[bitmapbrother]

Why not point to the actual ancient exploits from circa 2011-2013 for Android versions below 5 and Chrome versions below 40?

https://wikileaks.org/ciav7p1/cms/page_11629096.html

[libertymcateer]

Thanks for the link. So then is the assertion that the relevant hacks are all for older versions of Android? How does that comport with the current batch of hacks?

[GauntletWizard]

You're very much misrepresenting the facts. Android very much encrypts data (or gives users the option to, I'm not certain if it's the default). Chrome, the desktop application, does not. Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data. This is not real protection. It is up to the user to not run malicious apps under the same security context as Chrome, and to encrypt their hard drive to protect their data at rest. Nothing that chrome can do in its security context is anything more than placebo - as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database.

[libertymcateer]

> Why? Because that's a false sense of security. Chrome would have to also store the encryption key, and store it in the same place and under the same access controls as the encrypted data.

I hear you, but this is not the case with Safari. It offers secure local storage. It's the securesettings API. It uses the OS level encryption, and, based on the current state of play, this does not appear to be compromised.

> as shown by the fact that malware (and legitimate programs!) can read the Firefox local password database.

Is this also the case for Safari? I have not read anything to this effect.

[GauntletWizard]

I'll admit that the OSX Keychain has advantages - Offering OS-managed secure storage, with the possibility of the OS authenticating requests for credentials with the user is pretty cool. But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.

[libertymcateer]

> But as Chrome is cross-platform, and there's not standardized and similar APIs on Linux and Windows, I don't think it's the right move to have an OSX exclusive implementation that uses that api.

That is a very fair point, which I will take into consideration.

[mschuster91]

> It uses the OS level encryption

So all the NSA/CIA needs is a XNU kernel exploit which they need anyway for iPhone root exploits. Then, intercept the securesettings API or just do a raw memory dump of the browser process.

And the NSA has another card they can play, and that way easier on Apple than on the fragmented Windows ecosystem: all the tiny chips on your motherboard (EC, or any chip on the PCI bus which has DMA) can read and parse the RAM. Given that there is a highly limited number of different Mac EC chips and even then Apple likely uses the same firmware across them, it's easier for CIA/NSA to develop an exploit for these and don't care about kernel at all.

[dleslie]

I don't trust Google, Facebook, or anyone else who provides freemium services and has ties to the American Government. I don't understand why anyone does.

[Synaesthesia]

It's funny, I trust Apple because they're not "freemium" as in, they make their profit elsewhere. But I'm not sure I should really! After all they did participate in PRISM AFAIK

[daenney]

> Given Google's stance of not encrypting local storage in any way that I am aware of, this is fundamentally unsurprising

How does not encrypting local storage relate to this story? You're just pulling that one out of thin air to somehow prove your point. Besides the fact that there is no correlation between encrypting local storage and intercepting keystrokes or more broadly owning the kernel, it's also false. Though there are concerns with how disk encryption is implemented in Android and there are ways around it, it's come with FDE since version 5.0.

Encrypting local storage wouldn't have saved you one bit from this kind of thing where they just intercept the keystrokes. And your app wouldn't be safe from it either.

[libertymcateer]

I agree. Wholeheartedly. The point, however, is that it belies Google's larger approach, including that they turned a browser into an operating system.

Encrypting local storage would not have saved you. Absolutely. Maybe I am reading tea leaves, but it seems to me that this is indicative of the sort of security-lax mindset that allowed android to be owned.

> And your app wouldn't be safe from it either.

Yup. I know. It is a concern.

[georgemcbay]

You don't even need to necessarily own the phone at the kernel level. Things like the Android AccessibilityService APIs are kind of a huge gaping issue if the app uses standard text controls without overriding the View.AccessibilityDelegate event handlers.

Of course, this is a bit of a balancing act, because many disabled people legitimately benefit from the accessibility services, but they are like a huge vacuum from which displayed and entered textual data from your application can be sucked out.