The encryption is not broken, it's bypassed. The data go to an unintended third party, even when the encryption is legit, rendering the encryption useless.

So the word "bypass" is correct.

They have similar end result for the phone in question, but headlines like this can lead to people being less secure on the whole.

Arguing this point at all is silly when many people, even many IT professionals don't know and don't care about the difference between bypassed and broken. This arguing detracts from the important news...

The CIA sees fit to ignore the security of Americans by not alerting the companies that make the software the CIA exploits. They do this to insure they can hack whoever they want, and there is no meaningful oversight and no ethical, economic or constitutional consideration.

If group with the massive funding and pervasive reach like the CIA can operate with impunity it does not matter what app or what security you think you have.

The fine distinction of one app being singled out sucks, but it really is small potatoes here. The owner of the app should write the NYT and complain that their app was used inappropriately or perhaps write an editorial to get even more free advertising. The real news is that the CIA lied to Americans and the President so they could continue damaging American businesses, in the name of protecting America.

It sounds like we are not too far off from the CIA being able to write self spreading malware that allows monitoring they just haven't because... maybe it would be too easy to spot. Oh wait groups like the CIA did this already and rigged it to delete itself when not on one of their intended target's machines, stuxnet.

Pending that, here is evidence of a counter claim. I'd repeat what tptacek said, but he's whittled it down better than I could: https://news.ycombinator.com/item?id=13811541

To cite Tony Arcieri, the only elite cryptanalysis trick in play here is "Android is a tire fire". Cue surprised gasp from security researchers.

Furthermore, you did not refute my central claim. Popping a Cisco 12k: read a bunch of unencrypted comms until detection. Target a specific person to get bit by a specific iOS exploit: maybe read some of the data until it gets patched. Surely you'll agree that one is drastically more expensive than the other?

> dozens of "zero day" weaponized exploits against a wide range of U.S. and European company products, include Apple's iPhone, Google's Android and Microsoft's Windows

The only presumption on my part is that they are remotely exploitable, which is practically a requirement for mobile device exploits to be useful because physical access is hard to obtain. I do plan on going further through these, they look fun.

Of course encrypted communication is better for the user than unencrypted, but this is not the place for that, which is why I ignored it. This was supposed to be a discussion about massive government overreach, not petty squabbles between apps. With unfettered access to these phones there are all manner of hypothetical attacks that could go after any of these app providers and not just snoop on the communications of the users. With root access to a large number of phones and little oversight their capacity for harm is frightening, this seems more worthy of discussion.

I wonder what this administration will do with this knowledge. It will be interesting to see trump respond too, rather than manufacture news.

It does mean Signal is pointless to use however. Why encrypt if your communications are picked up prior to encryption? Akin to putting your seat belt on after the car has crashed.

Defense in depth! Do you stop using TLS on your banking website every time a Windows 0day comes out?

So in that case switching to something less secure will instantly make your problems worse.

Yes, catastrophic compromise is possible, but that does not render all security measures moot. A precious few attackers have the capability for such attacks, they are very costly to develop and therefore very precious and well kept secrets, to be used on high profile targets.

Unless you are a spy, a terrorist, a state official with significant power or a dissident against the likes of Russia or China, end-to-end encryption like Signal will keep your communication private.

Maybe, if one person can do it so can others. It would be foolish to assume you are safe just because the US government doesn't deem you a person of interest. It might be far fetched, but now that the world knows it's possible to bypass encryption you cannot ignore the fact that Signal may not work at all.

This is the point of the majority of propaganda, really: it's not to convince the people who know anything about the issue; it's to prejudice the people who don't, so that it'll be harder for the people in the know to communicate the facts to them.

Also, if you these people read only the title, then the problem is not any sort of text, you should fix those people first. No matter what words were chosen they will most likely make the wrong judgment.

| WikiLeaks: CIA managed to bypass encryption on popular messaging services on Android phone (nytimes.com)

While Signal and WhatsApp have not been broken (apparently), pretty much every platform they are hosted on has been.

The main point is that the CIA can read your encrypted messages before they become encrypted, if they really want to. So while your encryption works, you can still be pwned.

Of course this source is part of the same media that continually calls the election "hacked" despite there being no known technical irregularities with voting machines or vote recording or the actual election itself [^1] (that I'm aware of, at least). (Yes, computer systems were compromised, and data was exfiltrated from the DNC/related parties and released by foreign state actors. Unfortunately that is not "hacking an election." It's just plain and traditional information ops.)

So it's pretty par.

Mainstream news sources seem to continually get worse at reporting tech related stories, and I think there must be an even greater level of confusion when it comes to typical non-techinical individual citizens.

[^1]: Whether anybody is actually interested in actual elections running in auditable, effective, and functional way is apparently another question entirely, and the answer from most seems to be "nope."

If the problem was with Signal or Whatsapp, as the headline suggested to me, switching to another messaging service is the natural reaction. If people understand that the problem is with the platform, and that all platforms are compromised that solution doesn't work, and using signal is still better than SMS because it still protects against other forms of surveillance.

Luckily, they've realized the mistake and apparently changed the headline.

If I as a user, believe that a sequence of actions, from my keystrokes to voice input, which I perceive to be a direct interaction with a secure app are in fact insecure, then is the app really secure?

I guess that's the question being posed here

Furthermore, from the point of view of the end-user, the important point is that WhatsApp and Signal are not necessarily secure to use. The exact nature of the security hole is not as important for the vast majority of users.

Fear that using a "secure" messaging app on your rooted phone will expose you to consequences.

Uncertainty that your communications are secure when using your phone with the "secure" messaging app.

Doubt that using the "secure" messaging app is secure.

yes, it's FUD.

"Among other disclosures that, if confirmed, would rock the technology world, the WikiLeaks release said that the C.I.A. and allied intelligence services had managed to bypass encryption on popular phone and messaging services such as Signal, WhatsApp and Telegram. According to the statement from WikiLeaks, government hackers can penetrate Android phones and collect 'audio and message traffic before encryption is applied.'"

They have changed the title. Currently: "WikiLeaks Releases Trove of Alleged C.I.A. Hacking Documents"

It's not hard for them. I'm not making this up: NYT has a huge list of experts to reach out to for stories. They just chose not to.

I wasn't disagreeing with you. I was just saying that their tactic is to publish first and update. This is pretty common, especially in bigger stories. They get paid by getting eyeballs on their site. If someone publishes 20 mins before them they lose money, even if they are more accurate.

So just always take a breaking story as a draft. The story isn't finished and I bet will get updated several times.

https://www.nytimes.com/2017/01/04/us/politics/julian-assang...

https://www.nytimes.com/2017/01/08/business/media/assange-wi...

The current title [0] is wrong, but NYTimes is relatively clear:

> Among other disclosures that, if confirmed, would rock the technology world, the WikiLeaks release said that the C.I.A. and allied intelligence services had managed to bypass encryption on popular phone and messaging services such as Signal, WhatsApp and Telegram. According to the statement from WikiLeaks, government hackers can penetrate Android phones and collect “audio and message traffic before encryption is applied.”

It depends on how you define "bypass". In my opinion, accessing data before encryption is a form of bypassing... but it doesn't necessarily mean they can decrypt an already encrypted signal.

[0] "WikiLeaks: CIA managed to bypass encryption on popular services Signal, WhatsApp " as of this writing

edit: A new tweet referencing the article: "WikiLeaks release said CIA managed to bypass encryption in mobile apps by compromising the entire phone"

I think a lot of people in this thread are hating on NYTimes today for this headline because of the inaccurate WhatsApp encryption news stories of recent.

I could see myself being bothered if they had written that the encryption was "broken" or "cracked" as if you destroyed the boulder in your path. Bypass seems fine. Hacker News doesn't normally use bypass as a synonym for break, but for some reason today it i to the commentators

More because we're all getting blown up with "Signal is broken" messages and have to answer them one by one because of misleading/disingenuous headlines. Yes, 'bypass' is technically correct but the implication of the headline is that the problem lies with the named apps. This is not true and actively problematic.

Exactly, and some people including me thought about this possibility years ago. The most secure system in the universe can still be hacked very easily by a malicious closed driver because device drivers have the highest access level to the underlying hardware. Every information being produced: (virtual) keyboard writings, data, contacts, sensors data, GPS, audio, files, etc. I mean everything can be accessed a lot before it reaches the encryption code and be relayed to a 3rd party without the user even noticing.

This plague won't go away, not until enough people with enough influence will require hardware manufacturers to document their hardware in order to create OSS and trustworthy device drivers.

The reality is that no matter how good the software engineers are; no matter how sound the algorithms; no matter how well funded the startup or open source project; it's completely outnumbered and completely out gunned. Nation states operate at a different scale and easily deployable encryption systems for novice users are white horse led brightly dressed musketeers drum marching to their general's firing line in the midst of a modern free fire zone.

To me, any secure communications systems that provides the convenience of app store downloads and over the air updates should be considered compromised. On the other hand, if someone thinks that a three letter agency might be interested in their communications and that person does not work for another three letter agency, they should probably assume that their signals are compromised if they are detected.

Step the fuck up Google. Android security is an embarrassment.

For regular people, the effort of encrypting things is simply not worth it because they're powerless against a really determined attacker. It's rational to protect against casual attacks from spammers and scammers, but protecting oneself against state-level attackers is futile unless you make a full-time job out of it.

Someone usually pipes up at this point saying 'we need to limit the powers of the state', like some sternly-worded law is going to undo the existence of the technology or take away the vast economic and political incentives to deploy it. Get real folks, technology doesn't get un-invented, and powerful organizations are just like powerful organisms; they're opportunist, they maximize their own chances of survival, and when they do collapse the resulting power vacuum is filled as rapidly as any other vacuum would be. One can certainly seek to govern the behavior of a state or state organ, but attempting to limit its technical ability is naive, for the same reason that you'd be naive to try to fix police brutality by legislating about the design parameters of police batons.

Nice passive voice there, NYT.

This a perfectly useless bit of information in that it says nothing about how this penetration could occur. Pretty much anything can be cracked with a trojan. Something like a currently valid remove exploit would be a much bigger deal.

I could say that all the secure apps are broken because I can stand behind you and look over your shoulder while listening to anything you might say.

> As of October 2014 the CIA was also looking at infecting the vehicle control systems used by modern cars and trucks. The purpose of such control is not specified, but it would permit the CIA to engage in nearly undetectable assassinations.

https://wikileaks.org/ciav7p1/

Given the fact that car makers don't even have "PC age" security in their cars, things are looking pretty bad for self-driving cars in general.

Former U.S. National Coordinator for Security, Infrastructure Protection, and Counter-terrorism Richard A. Clarke said that what is known about the crash is "consistent with a car cyber attack". He was quoted as saying "There is reason to believe that intelligence agencies for major powers — including the United States — know how to remotely seize control of a car. So if there were a cyber attack on [Hastings'] car — and I'm not saying there was, I think whoever did it would probably get away with it."[68]

Cenk Uygur, friend of Hastings' and host of The Young Turks, told KTLA that many of Michael's friends were concerned that he was "in a very agitated state", saying he was "incredibly tense" and worried that his material was being surveilled by the government. Friends believed that Michael's line of work led to a "paranoid state".[80] USA Today reported that in the days before his death, Hastings believed his car was being "tampered with" and that he was scared and wanted to leave town.[81]

[1] https://en.wikipedia.org/wiki/Michael_Hastings_(journalist)

Not really. The possibility of taking over unmodified cars remotely was not very widely known at the time. An organization that knew about that and had the technology to actually do so would not want to use it except on high value targets that they could not reach by more conventional means, because they would want to keep this capability under the radar of potential targets for as long as possible.

Due to the nature of his work Hastings would have been easy to take out by conventional means. He was an investigative reporter. It would be easy to feed him a lead on some story, like some important political person having a connection to a drug gang, and set up a meeting in a sketchy part of town with someone who says they want to give him confidential information about that. There would be nothing suspicious about that, and it would be easy to arrange for this fake meeting to go bad and end up with Hastings dead.

This would look like a sad but not totally unexpected way for a bold, risk taking, investigative reporter to die, and there would be not even a hint of a connection to any government agency.

If his car did not have remote vulnerabilities, and so any takeover involved modifying the car, then killing him by car takeover is even more absurd. It runs the risk of the modifications being discovered between the time they are installed and the time they are used (what if he takes his car in for service and the mechanic finds them?), and if used in a place where the agency doing the assassination does not have control of the scene afterwards risks the mods being discovered in the wreckage.

Ultimately though, we don't know what he uncovered and intended to publish, and how long the CIA had to react to it. An extraordinary revelation may have necessitated an extraordinary reaction. The point is that the new information takes the concept of malicious car hacking from speculation to reality.

Also in the police report, I believe his brother said he had been using DMT and he tested positive for what was likely Adderall. He was in a unique state to truly be paranoid and throwing psychedelics in the mix could cause one to try to cope in ways that challenge reality.

Of course, this also would be the perfect time to stage a murder and it's not improbable that someone did discuss killing him. Also DMT only last 5-10 minutes, he certainly wasn't driving while doing it and if anything, it can give you a sense of peace and acceptance to the craziness of life.

I never thought they seemed implausible.

Potential assassination?

  According to the statement from WikiLeaks, government 
  hackers can penetrate Android phones and collect
  “audio and message traffic before encryption is applied.”

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.

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

> ChromeOS and Android both implement FDE

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

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?

0_o

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.

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

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

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

"Apple says most vulnerabilities in Wikileaks docs are already patched"

https://techcrunch.com/2017/03/07/apple-says-most-vulnerabil...

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.

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

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.

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.

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.

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.

This is also why every single reputable source on security is condemning the NYT for running such an irresponsible headline, since it was not about flaws in the secure messaging apps or their encryption in any way.

And in my opinion, if you require security that the CIA can't bypass, you won't find it in any mainstream consumer hardware or software.

I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0]

A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app

It is trivial to find the plaintext in these situations.

Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page.

To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered.

[0] https://www.gibberit.com/

[1] http://i.imgur.com/CsgOkZ2.png

[2] http://i.imgur.com/uZg0E4l.png

[3] http://i.imgur.com/eq19mET.png

[4] http://i.imgur.com/lOsibBP.png

Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably.

That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited.

And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.

if you're doing

aes(plaintext, sha2(password)) = cyphertext

given cyphertext I can get to plaintext with sha2(8-char dictionary)

well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm

this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space

So what about mailvelope?

I want you to know, very sincerely, I appreciate your feedback over the past two days.

Some lessons (re-)learned:

* Security is a conclusion, not an assertion - it is improper to present a system as secure without evidence. * I am not, nor will I ever be, qualified to provide a conclusion regarding security. * The language on the homepage needs to be clear in this regard without being 'cute.' * If I ever post on HN regarding security, either use evidentiary sources to back my points on provide code.

Thanks for the reality check.

the design of the app is that it injects content scripts with global variable names everywhere.

any site can overwrite the encryption functions, or redefine some of the global vars that are used for images, etc.

As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki:

https://www.chromium.org/Home/chromium-security

it is also being marketed as such by you here

Would you consider heavily caveating statements you make about information security? A lot of what you say here is basically wrong.

A national security lawyer could provide interesting insight into how the CIA is allowed to use these tools vs NSA.

That is appreciated, and you are in the minority.

I'm taking this advice, btw, and being more circumspect when I post in the future.

Cheers.

The whole "why not encrypt local resources" thing is an odd red herring that a lot of (even fairly experienced) people trip over. There was a massive public furor over Chrome's chrome://settings/passwords (i.e. lack of a master password) design choice a couple of years ago that was a specific such case in point.

Chrome: =======

Someone who can access chrome://settings/password is presumed to have physical access to your powered-on, unlocked machine. E.g. someone who sits at your keyboard when you get up for coffee.

And that person can just as easily install a Chrome extension that sniffs your passwords or steal your raw auth cookies directly from the developer console. (He could even paste some JS into the developer console to intercept the password as-typed by autocomplete!)

(Note that an attacker with access to a locked/powered-off machine or with no local access is not part of the threat model, since they are presumed to be addressed by FDE, screen locks, remote access controls, etc.)

Now, the major counterargument is essentially that a lot of unsophisticated attackers (like spouses) may not know about cookie jars or JavaScript, but they know about "view saved passwords." I find this argument somewhat reasonable, but from some vantage point it's security theater--not knowing about ctrl+j isn't a strong security guarantee, after all. So I view the Chrome team's stance as being a very principled one, namely: don't invest in "security" features where a bypass would not be a bug.

(In some literature this is referred to as a "security boundary", typically defined as "a control which, if bypassed, has a bug." Note the contrast with, for example, spam filters and antivirus, which may be sometimes bypassed while working as intended.)

More generally: ===============

I think what was lacking in this conversation in general was a firmly defined threat model and a firmly defined security boundary. My contention about per-application encryption is that it doesn't represent a security boundary because any attacker who can execute code that can read application-ACL'ed data on disk is by definition either running code at a higher security level (e.g. has root) or is running code at the same security level (and can thus inject code into the browser process itself).

This conversation gets a little more complex when talking about mobile OSes that have per-application sandboxing, but the same observation effectively holds.

Anyway, I'm tired of typing, but hopefully that makes a bit of sense. Let me know if I'm being confusing.

* On OSX, OS passwords are stored in the keychain. * However, Chrome stores passwords in a local SQLite database https://www.howtogeek.com/70146/how-secure-are-your-saved-ch..., which, on osx, I believe is in your Application Support Folder ("ChromeDB") * The user, who is not root, has read/write access to the ChromeDB * Is it not the case, then, that any script that has user-level permissions can access the Chrome passwords? Because Chrome is not available through the app store, it does not store passwords on the OSX keychain, which, again, correct me if I'm mistaken, requires higher permissions to read? So that, for instance, a malicious script that only had user-level permissions could not access the contents of databases encrypted with credentials stored in the keychain?

Would local encryption of these password stores be a (potentially) effective protection against this?

A malicious script that runs as user X can typically (on desktop OSes) inject code into any other process running as user X at the same security level. The details vary by OS--in Windows there's a system call called NTCreateThread that lets you inject code from a loaded DLL in your process into any other process at the same or lower security level; in OSX, at a quick Google, it looks to me like http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_c... may do the same.

So the attack that this opens up is to basically wait until Safari is running and loads the credentials into its memory--which it has to do to prefill the password field in a page--and then just read that memory from your code running in the same process in a different thread (which shares the address space). And if you don't want to wait, you can simply request the credentials directly from the Keychain API; Keychain doesn't know you're not "Safari" (since you're running in the same process) and will happily give you the credentials!

Now, there's still a small advantage to the DPAPI/Keychain approach, namely that it allows the OS to show approvals to the user ("Unlock the keychain?" dialogs or whatever), ensuring that the malware can only steal credentials while the user is present. There are some circumstances where a credential API is nonetheless useful. Offhand:

1. Cases where there's a test-of-presence ("Do you want to unlock the Keychain?") conducted by the higher-privilege process, and where approval is not routine (so that the user is not going to just click "OK"). Browser password autofill is not such a case, however.

2. Cases where there's a test-of-presence and the user assent is transactional (i.e. they see what they're approving and the approval is only good for that one action--as with Windows UAC).

3. Cases where the credential granted is a signature and not a bearer-token, and we find some advantage in the token itself being bound to the device. (IOW, the down-level process can steal a signature, but it can only use the signature for some limited use, and cannot steal the signing secrets, which never leave the privileged domain.)

So to get this right requires a lot of thought about things like broker processes, transactional approval, etc. I'm far from an expert in this, but hopefully the above makes some sense.

However, in my experience (disclaimer: the plural of anecdote is not data, I am very well aware of this), the frequency of worms and viruses that are released by script kiddies using commercially available malware is on the rise, and these are malicious and effective but not terribly sophisticated. Check my other thread for more on this.

In other words, what I am saying is that you are describing a very nasty theoretical worm - I am, however, describing to you a family of worms that is currently out in the wild and causing a hell of a lot of damage, and, as far as I know, actually does function in the way I describe. Filecryptor viruses can be made / purchased by any script kiddy jerk these days, and it seems to me that they do not function in this very sophisticated way you describe, but instead may actually be stymied by local encryption of files with passwords in them. (Or, rather, the distribution of your passwords to the virus owner would be stymied.)

I would very much like to know if is accurate or not. I understand that the devil is in the details, but if it is true, then I stand by my point that it seems unwise (borderline indefensible) not to encrypt local password stores - as there is a known valid threat. If it is not true, then I stand corrected - which happens all the time.

Either way, I am deeply interested to know.

You're right that unsophisticated malware may be thwarted by per-app disk encryption or credential stores like Keychain, but it doesn't represent a security boundary. That's why I would describe the Chrome team's approach as being "principled"--they're refusing to implement an ambiguously useful security feature because its bypass would not represent a bug.

Whether such a feature is nonetheless valuable for the user is unanswered by that discussion, however; as you say, it may have value in some circumstances.

However, remember that by volume most exploitation is (as best as I can tell) economic--people who do it for business. And people doing it for business can buy whatever malware is on the market. If stealing in-memory secrets is reliably accomplished (which it is), malware vendors have a strong incentive to implement this and sell it as well.

So I think you have the right idea, but answering the question is nontrivial. If Chrome implemented file encryption (or, more likely, used the platform APIs where available), would the engineering cost (and complexity--e.g. different behavior on different platforms) be counterbalanced by the increased cost imposed on malware authors? Or would one or two malware authors quickly adapt and malware prices/effectiveness would remain fairly static?

You get the point.

Check it out and let me know what you think.

Edit: from the top google result on Dynacrypt:

>While the ransomware portion of DynA-Crypt, as described in the next section, is a pain, the real problem is the amount of data and information this program steals from a computer. While running, DynA-Crypt will take screenshots of your active desktop, record system sounds from your computer, log commands you type on the keyboard, and steal data from numerous installed programs.

>The programs and data that DynACrypt steals includes:

>Screenshots

>Skype

>Steam

>Chrome

>Thunderbird

>Minecraft

>TeamSpeak

>Firefox

>Recordings of system audio

To what are you referring to here, precisely?

Since AOSP is open source, is there a specific line of code that you can point to that contains (or is emblematic of) this insecurity?

Your article doesn't seem to say.

as a "(slightly-higher than script-kiddy-level) web developer" I'm going to guess that he doesn't actually know very much about AOSP, the Linux kernel, or indeed GNU/Linux security in general. So his emphatic statement "Compare the security of Android - which we now know to be 'owned' by the US Government" is pretty much worthless as he's very clearly speculating about things that he doesn't understand.

I know a fair amount for a 'layperson', which you can (probably rightly) argue means I am unqualified for comment in these circles, and you are right that I am including too much speculation. I absolutely, inarguably overstepped. My bad.

However, with regard to Android being owned - this article is literally about the CIA tools that are used to compromise Android. The trove has been released. It is incontrovertible at this point: https://www.washingtonpost.com/world/national-security/wikil...

The issue is to what extent other fundamental assumptions are now called into question. Is it only android, or is Chrome now suspect as well? What protocols are compromised?

I suspect we will find out more in the coming days, and I should have been more circumspect in my own post. It was unbecoming.

In any event, thanks for your feedback.

Back to the question at hand - there seems to be extremely strong evidence that android - and iOS, apparently - are compromised pretty thoroughly. https://betanews.com/2017/03/07/wikileaks-vault-7-cia-year-z...

If this is not the case, then what is your conclusion? Because the claim that is being made far and wide, right now, is that android, ios and samsung smart TVs appear to be fundamentally compromised.

You want to distinguish between:

- remote takeover (like stagefright vuln)

- ability to take control of the device from within an app sandbox

- ability to unlock a device in your physical possession (FBI was able to do this on prev V of ios)

The background video on gibber is awful, makes it very hard to read the page. I've just opened it in another browser with all the JS on and again your page totally doesn't work with the google ajax switched on. Worth fixing.

So your comparing the current security of the iPhone with old CIA Android and Chrome exploits from circa 2011-2013?

But this is just as secure as full disk encryption of the device right?

Android applications are also sandboxed from each other. You would have hard time getting from one app to another's files, unless the original app published them - or you've got root.

Just hacking the device while it is being used is what every iOS jailbreak does. And there seem to be quite a number of them.

Not sure why you mention "secure local storage"; none of that local storage is secure if the device is compromised! That can then be bypassed in the same way that you bypass WhatsApp or manipulate any other app on the device.

If you are running something based off of AOSP, you're running code that was touched by Google employees. Is your fear that Google is installing backdoors to help the CIA? If so, why are you afraid of that?

Doesn't matter who touches code when that code is publicly visible and available to the scrutiny of everyone. AOSP can be checked out and audited independently, just like any open source project.

Open vs closed source is a distinction I don't see a lot of folks in the security community take seriously, and for good reason: it's a response to a very specific threat model, where your concern is not primarily accidental 0days but intentional backdoors.

I would posit that the cost of a backdoor is probably higher than the cost of an 0day: the reputational risk to Google or Apple if they were discovered to have planted one is worth potentially billions of dollars in sales, so they will spend a lot of money fighting any such court order (and, as far as we know, such an order has never been successfully made).

The counterargument here is that if the government did win such an order, the backdoor is the gift that keeps on giving, whereas 0days eventually get patched and fixed.

But that's a long digression. For most users, this is simply the wrong threat model.

Is that your concern? And if so, why are you concerned specifically about Google apps? Any malicious app can exploit a local EOP.

Also, if I remember right (and I'm not an Android expert, so grain of salt here), Android OS itself enforces sandboxing based on app signing keys; even the Play app can't overwrite the Signal binary without a binary signed by the same key (though conceivably it could install some other fake-Signal app that looks just like Signal and has a similar icon--but that app would not have access to your private key!).

Personally I trust Android as much as I'd trust iOS... Which is to say I expect the government can get at either with physical access but only at the highest levels of government (CIA/NSA/FBI).

As you say, in both cases (iOS and Play Services) it's a commercial closed-source bundle. shrug

I don't personally spend time worrying about that, given that Google and Apple's code is probably better reviewed than some random open source app, but some people like to nerd out about such things.

As you say, the FBI was eventually able to get access to the San Bernardino shooter's phone. But this isn't exclusive to the highest levels of government; it just depends on your budget: http://www.reuters.com/article/us-apple-encryption-fbi-idUSK.... It's not surprising the CIA would have a stockpile of unpatched 0days, found or bought.

I don't believe I'm worth $1m to anyone, so I feel pretty safe using both iOS and a recent, patched Android.

And it's kinda an unspoken goal of mine to, ya know, not end up on a CIA watch list. Now I know some of the concern goes around controlling so the Government doesn't get out of control but I think that we would expect a government's worth of resources able to do something as trivial as cracking a commercial phone.

First rule of not being on the watch list is not to admit you don't want to be on the watch list.

What, do you have something to hide? Huh?

Maybe he was referring to these privileged permissions: http://android.stackexchange.com/a/17874/104563

To expand, this would be some vulnerability which allows a non-privileged local app (like Gmail) to execute code at a higher security level.

The focus on Google apps specifically here is misleading. In the Android (and iOS) security model, apps are sandboxed, and cannot generally inject code into other apps (in contrast to most desktop OSes, where all processes running as "you" can sort of do what they want to each other).

The threats that apply on Android or iOS are, roughly speaking:

1. You grant an app more permission than it should have (e.g. microphone or keyboard input)

2. Local EOP plus installing a malicious nonprivileged app (or a remote code execution vuln) such that someone can get root on the device and inject code into Signal (or whatever)

3. A backdoor in the OS or app you are using

Android and iOS both have vulnerabilities in the wild. Older Androids are riddled with them, and the Android ecosystem is shit for getting updates out. If you're not using a Nexus or Pixel or a device from a reputable OEM (supposedly Samsung takes patches seriously, but I don't pay attention to this), you're probably easily exploited.

That's all the news that's here, AFAICT. The focus on encrypted messaging apps is on the one hand silly and on the othe rprobably necessary. Everyone in the security world knows that the easiest way to beat end-to-end encryption is to compromise the endpoint. But everyone in the wider world thinks that if they use Telegram they're secure, even if they're using an unpatched Samsung from 2011.

There was some huge political problem and the Cyanogen company did something the open source guys didn't like, so they left.

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

As you can see they pretty much all reference very old versions of Android (v4) and Chrome.

Tox on the other hand seems much more secure... though I guess if you're phone is compromised you're pretty much screwed to start with (which is not too hard with all the bloatware one needs these days).

Long story short: if someone obtains your Tox private key, they are able to impersonate you in the conversations with other people without you realizing it.

Tox developers admitted this was an issue. Fixing this means changing the protocol itself (which will affect everyone).

Tox is still experimental (which they admit here: https://github.com/TokTok/c-toxcore/issues/426) and it is not advisable to use it.

disclosure: working on an open source alternative for messaging