The Continuing Public/Private Surveillance Partnership

If you’ve been reading the news recently, you might think that corporate America is doing its best to thwart NSA surveillance.

Google just announced that it is encrypting Gmail when you access it from your computer or phone, and between data centers. Last week, Mark Zuckerberg personally called President Obama to complain about the NSA using Facebook as a means to hack computers, and Facebook’s Chief Security Officer explained to reporters that the attack technique has not worked since last summer. Yahoo, Google, Microsoft, and others are now regularly publishing “transparency reports,” listing approximately how many government data requests the companies have received and complied with.

On the government side, last week the NSA’s General Counsel Rajesh De seemed to have thrown those companies under a bus by stating that—despite their denials—they knew all about the NSA’s collection of data under both the PRISM program and some unnamed “upstream” collections on the communications links.

Yes, it may seem like the public/private surveillance partnership has frayed—but, unfortunately, it is alive and well. The main focus of massive Internet companies and government agencies both still largely align: to keep us all under constant surveillance. When they bicker, it’s mostly role-playing designed to keep us blasé about what’s really going on.

The U.S. intelligence community is still playing word games with us. The NSA collects our data based on four different legal authorities: the Foreign Intelligence Surveillance Act (FISA) of 1978, Executive Order 12333 of 1981 and modified in 2004 and 2008, Section 215 of the Patriot Act of 2001, and Section 702 of the FISA Amendments Act (FAA) of 2008. Be careful when someone from the intelligence community uses the caveat “not under this program” or “not under this authority”; almost certainly it means that whatever it is they’re denying is done under some other program or authority. So when De said that companies knew about NSA collection under Section 702, it doesn’t mean they knew about the other collection programs.

The big Internet companies know of PRISM—although not under that code name—because that’s how the program works; the NSA serves them with FISA orders. Those same companies did not know about any of the other surveillance against their users conducted on the far more permissive EO 12333. Google and Yahoo did not know about MUSCULAR, the NSA’s secret program to eavesdrop on their trunk connections between data centers. Facebook did not know about QUANTUMHAND, the NSA’s secret program to attack Facebook users. And none of the target companies knew that the NSA was harvesting their users’ address books and buddy lists.

These companies are certainly pissed that the publicity surrounding the NSA’s actions is undermining their users’ trust in their services, and they’re losing money because of it. Cisco, IBM, cloud service providers, and others have announced that they’re losing billions, mostly in foreign sales.

These companies are doing their best to convince users that their data is secure. But they’re relying on their users not understanding what real security looks like. IBM’s letter to its clients last week is an excellent example. The letter lists five "simple facts" that it hopes will mollify its customers, but the items are so qualified with caveats that they do the exact opposite to anyone who understands the full extent of NSA surveillance. And IBM’s spending $1.2B on data centers outside the U.S. will only reassure customers who don’t realize that National Security Letters require a company to turn over data, regardless of where in the world it is stored.

Google’s recent actions, and similar actions of many Internet companies, will definitely improve its users’ security against surreptitious government collection programs—both the NSA’s and other governments’—but their assurances deliberately ignores the massive security vulnerability built into its services by design. Google, and by extension, the U.S. government, still has access to your communications on Google’s servers.

Google could change that. It could encrypt your e-mail so only you could decrypt and read it. It could provide for secure voice and video so no one outside the conversations could eavesdrop.

It doesn’t. And neither does Microsoft, Facebook, Yahoo, Apple, or any of the others.

Why not? They don’t partly because they want to keep the ability to eavesdrop on your conversations. Surveillance is still the business model of the Internet, and every one of those companies wants access to your communications and your metadata. Your private thoughts and conversations are the product they sell to their customers. We also have learned that they read your e-mail for their own internal investigations.

But even if this were not true, even if—for example—Google were willing to forgo data mining your e-mail and video conversations in exchange for the marketing advantage it would give it over Microsoft, it still won’t offer you real security. It can’t.

The biggest Internet companies don’t offer real security because the U.S. government won’t permit it.

This isn’t paranoia. We know that the U.S. government ordered the secure e-mail provider Lavabit to turn over its master keys and compromise every one of its users. We know that the U.S. government convinced Microsoft—either through bribery, coercion, threat, or legal compulsion—to make changes in how Skype operates, to make eavesdropping easier.

We don’t know what sort of pressure the U.S. government has put on Google and the others. We don’t know what secret agreements those companies have reached with the NSA. We do know the NSA’s BULLRUN program to subvert Internet cryptography was successful against many common protocols. Did the NSA demand Google’s keys, as it did with Lavabit? Did its Tailored Access Operations group break into to Google’s servers and steal the keys?

We just don’t know.

The best we have are caveat-laden pseudo-assurances. At SXSW earlier this month, CEO Eric Schmidt tried to reassure the audience by saying that he was “pretty sure that information within Google is now safe from any government’s prying eyes.” A more accurate statement might be, “Your data is safe from governments, except for the ways we don’t know about and the ways we cannot tell you about. And, of course, we still have complete access to it all, and can sell it at will to whomever we want.” That’s a lousy marketing pitch, but as long as the NSA is allowed to operate using secret court orders based on secret interpretations of secret law, it’ll never be any different.

Google, Facebook, Microsoft, and the others are already on the record as supporting these legislative changes. It would be better if they openly acknowledged their users’ insecurity and increased their pressure on the government to change, rather than trying to fool their users and customers.

This essay previously appeared on TheAtlantic.com.

Posted on March 31, 2014 at 9:18 AM57 Comments

Comments

xx March 31, 2014 10:03 AM


Google could change that. It could encrypt your e-mail so only you could decrypt and read it. It could provide for secure voice and video so no one outside the conversations could eavesdrop. It doesn’t. And neither does Microsoft, Facebook, Yahoo, Apple, or any of the others.

Actually, Apple does do exactly that – being in the business of selling hardware, they don’t want the hassle of dealing with user data when they can avoid it. Most recently, the iMessage protocol’s security, designed to avoid cleartext or storage of texts outside of the communicating devices, made the rounds: http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is/ (paper linked from that article). The Keychain protocol is similarly designed: even if you sync the keychain over iCloud, it is never stored outside of your devices.

Natanael L March 31, 2014 10:32 AM

@xx: The problem with that is that Apple is still the man in the middle. They run the whole key distribution and everything. They can silently tell your devices to encrypt the data with one of their keys as well, and they’ll have access without your knowledge. And so can any Certificate Authority!

John Macdonald March 31, 2014 10:46 AM

Reading this discussion, I scrolled to the bottom of the page and saw the checkbox labelled “Remember personal info?” and initially was thinking it was still part of the discussion – as an ironic “Do you remember the days when there was such a thing as info that was kept personal?”.

Anura March 31, 2014 12:07 PM

@kashmarek

As far as I’m concerned, cloud storage should only be used for stuff you want public, or TrueCrypt containers.

dhasenan March 31, 2014 12:38 PM

What is the email encrypted with? You need asymmetric encryption (otherwise you’re back to storing the person’s incoming email in something you can read), which implies an RSA or DSA key pair as the obvious means. But your user isn’t going to send you their private key. You store that server-side. And you encrypt it with the user’s password, right?

And then I forget my password and lose all the email I’ve ever received.

And even then, the government could require that you provide the user’s credentials as soon as you are able — which is to say, you need a system for specifying that a particular user’s credentials should be preserved and sent to a government association when they log in.

You can do better in terms of security. That requires you to sacrifice features, though. Specifically, you encrypt incoming messages with the user’s public key, indexing them probably by date received and a unique identifier. The client can query for a list of messages in a date range and can get the encrypted data for each. It handles decryption, having the user’s private key. You only get full text search for anything the client has downloaded at best.

Lose your private key? You’re hosed. But at least no government can access your data. Unless they force your email provider to log your incoming and outgoing messages before they’re encrypted. To avoid that, you’d have to design a new protocol — one that has the same issue of losing your private key.

Rufo guerreschi March 31, 2014 1:08 PM

You say:”But they’re relying on their users not understanding what real security looks like”
And you also encourage them (big cloud companies) to be sincere to their users about the insecurity of their services.

They are relying not on users not understanding, but on mainstream media and tech blogs to keep users ignorant.
Those same media should be the ones detailing why their services are insecure.

I believe good old Chomsky propaganda model is at work here to explain why media is so far from doing their job.
It is incredible how over 90% of tech blogs still believe users can get ANY privacy by installing a specific app or buying a Blackphone…

Bruce, you should set the record straight to tell the world that everything that is being sold out their as private is not, and/or we have not nearly sufficient information to ascertain if it is our not.

DB March 31, 2014 2:00 PM

@ dhasenan I theorize that it could be possible to have the client do “full text search indexing,” encrypt it, then incrementally upload index containers to the cloud… the actual searches would have to be done on the client, yes, but a good compressed-and-then-encrypted index still should be orders of magnitude faster than downloading/decrypting full content before performing a search…

Anura March 31, 2014 3:09 PM

@dhasenan

If you had two public keys, one for the recipients MX server, and one for the recipient, and the MX server’s key encrypted the recipient’s email, but the sender’s information and body were encrypted by the recipient’s public key, then this would be a significant improvement.

If you want to use an email client with the knowledge that if you lose your private key, you are hosed, great, you have more security. If, on the other hand, you care about being able to access your email from anywhere, then you have to be willing to trust the mail server to store your private key, but your email is encrypted in transit and you still have more security than the existing system (in which you don’t know if your email is encrypted in transit, but it probably isn’t).

dany555 March 31, 2014 3:25 PM

Only real secure way :
Classify your personal data, really private data should be kept off of any electronic device and not on the internet. The rest of your semi public life, try to know where you send it.

Consider any data stored on an electronic device to potentially be read some day,even after many years, by private companies,government, so called friends over social network…

This is what became privacy in the information age, so be aware of what is less private and what has more value.

Beemo March 31, 2014 5:22 PM

I’d be willing to pay Google to provide end to end encryption for my account with the stipulation that i accept the risk of losing all access to my email if i lose the key.

That said, that method still keeps the door open on law enforcement forcing Google to change their authentication system to record what password you put in, thereby invalidating the protection of data against the standard voyeuristic spook.

The solution on a technical level alone is akin to Sisyphus and a political change seems to be the best way forward without redesigning our entire infrastructure from scratch.

Bruce, I asked you a while back if you expected meaningful reform of the nsa to happen as a result of the disclosure and you said that you did. Do you still believe this to be the case?

Anura March 31, 2014 5:32 PM

@Beemo

If the service provider has the ability to decrypt your emails, then I wouldn’t call that end-to-end encryption. To me, end-to-end encryption means that it is encrypted on the sender’s device, and decrypted on your device. If the content provider can decrypt what it’s storing, then that’s barely a step above plaintext storage. If you basically use the existing email protocol+encrypted storage, then you can’t even guarantee your email is encrypted in transit.

yesme March 31, 2014 5:34 PM

@Beemo

There is a practical solution. See this link. In short, use gmails smtp/pop3 with Thunderbird and PGP. A portable solution is with an USB stick with truecrypt and on that Thunderbird and PGP (be sure to back it up regularly).

DaveN March 31, 2014 5:36 PM

I believe that if one of these companies refused to honor a government request they consider illegal, the government would have to cave. With the amount of attention to the warrantless surveillance issue, and the fact that it hasn’t died down in almost a year, I don’t think they’d risk having someone like the CEO of a major tech company go on TV and say we refused to comply with an illegal order. What would they do then, jail him? I don’t think the administration could survive the public’s outrage if they believed someone were prosecuted for defending citizens’ rights.

It’s disgusting that these people take our money and claim to have our interests at heart, and then take the path of least resistance and hand everything over without judicial process.

yesme March 31, 2014 5:55 PM

@Beemo

It doesn’t solve the problem of metadata however. And Google still has the contact list. If you want to solve that you probably have to set up your own mail server (OpenSMTPD).

Anura March 31, 2014 6:10 PM

@yesme

Also, keep in mind that even if the data is protected at your end, if the people you are communicating with use GMail or another major service provider, then the bulk of your emails and/or their metadata can still be collected at the other end.

TimL March 31, 2014 6:11 PM

@DaveN “What would they do then, jail him?”

The NSA can exert pressure in any number of ways.

They know everyone’s weak points and are not afraid to use that information.

If you haven’t seen the movie “The Lives of Others”, it will help to explain what we’re dealing with here.

Anura March 31, 2014 6:22 PM

@anon

I’d be skeptical about that particular case, although I wouldn’t deny it’s a possiblity. The fact that I can’t dismiss it outright is a scary sign of the state of affairs in this country. It’s no secret that justice tends to be very selective.

The Truth March 31, 2014 6:27 PM

“We don’t know what sort of pressure the U.S. government has put on Google and the others.”

They don’t need “pressure”, they only need taxpayers’ money. These companies are in business to make money, that’s it.

The only reason all of these US companies are complaining publicly about the spying IS BECAUSE EDWARD SNOWDEN REVEALED THEY WERE SELLING ACCESS TO ALL OF THEIR DATA!

The ultimate irony of this spying is that the taxpayers pay for every cent of it.

EDWARD SNOWDEN – the bravest hero of the 21st century – and beyond!

Buck March 31, 2014 7:09 PM

@DaveN

“It’s disgusting that these people take our money and claim to have our interests at heart”…

Not only is it disgusting, but as publicly traded corporations, it is probably even part of their ‘fiduciary duty’. !? (IANAL) How could one possible justify to their shareholders… the passing on an opportunity to demand payment from customers, not only once for services provided, but twice (including mandatory law enforcement intercepts; of course with a bill footed to all American taxpayers)!

tz March 31, 2014 9:46 PM

There should be.cryptographically secure ways of getting keywords. Google could do this. Or someone else.

Rahul Chhangani March 31, 2014 11:12 PM

It means in Internet market, there is nothing like “personal”,
AAAHH!! the companies, who gave them right to do read and monitor??….if they are giving free service that dosen’t mean they do sale of our privacy.

TS April 1, 2014 1:40 AM

An end-to-end encryption approach replaces an eavesdropping problem with a key management problem.
There are probably a million people a day who forget their email password (or it gets compromised). If your mail server can’t decrypt your email then the government might not be able to access it, but neither will you if you lose your key. The number of users who lose access to their accounts probably far exceeds the number of users whose data is handed over to the government.

If you think the NSA has compromised the SSL keys of all the major web companies, why wouldn’t you assume they can subvert the web browsers that decrypt your mail? How would you know the code in the page won’t read your decrypted email and send it somewhere in the clear? How do you verify that the transfer of your private key from your old smartphone to your new smartphone was safe? If you can search your mail, why wouldn’t the government be able to subpoena the index? And if they’ve got a wiretap in place, client-server email encryption isn’t much help when the server-to-server traffic is in plain text.

On the continuum of security/usability tradeoffs, encrypted email swings far from the positive usability side, in large part because key management is such a pain. Even people who write cryptography software seem to rarely encrypt their email.

Full disclosure: I work for a large consumer-focused Internet company. I think we can increase the worldwide level of Internet security more by implementing measures that hundreds of millions of non-tech-savvy people can take advantage of than by creating products with crypto turned up to 11 that most people have trouble using. When security is a burden, people tend to fall back to less-secure practices, like propping open a door with a complicated high-tech lock.

DB April 1, 2014 2:15 AM

@TS

If you won’t remember your password, then the data can’t be that important to you, can it. Saying “but we need full access to all your information so we can protect you from yourself” doesn’t cut it, when some of us want to be protected FROM YOU, thank you very much! Obviously, it’s not for everyone, some people would rather be hand-held with their passwords. I have an idea, why not offer both options, and see what the market decides all by itself, instead of you deciding for us?

Yes, the government can subpoena me, and collect my records from me directly… this is the way it’s been for many decades before mass surveillance. I get to inspect the warrant, and see that they’re following it, and I also get to contest it in court if I so desire (like, for example, if I’m accused in error or unjustly). Secrecy instead of openness is just your way of trying to stay away from embarrassment.

Key management is not that hard, I’ve been doing it for years… though the user experience could be improved a lot, to make it more accessible to the common man.

yesme April 1, 2014 2:22 AM

@TS

“On the continuum of security/usability tradeoffs, encrypted email swings far from the positive usability side, in large part because key management is such a pain. Even people who write cryptography software seem to rarely encrypt their email.”

Sorry, I think you are wrong about that. The problem is that the major OS vendors didn’t play this game, with the exception of Blackberry (Canadian company). If they wanted to, it could be a system configuration functionality. No keys, no e-mail. It could be roughly the same as with password login. But they didn’t.

Also IETF has some problems to solve regarding e-mail. Can someone tell me if they are working on this? The IETF site is kinda hard to search through.

Anura April 1, 2014 3:06 AM

For the vast majority of people, losing a few days worth of email will be just a minor inconvenience anyway. The protocol should be designed for maximum security; if you want to store the keys with the email provider so you don’t have to worry about losing your password, that is always a choice. The only problem is that if one end is not secured, then the whole system falls apart. It’s still better than having everything in the clear.

Clive Robinson April 1, 2014 5:13 AM

The problem with EMail security is in the main due to user expectations of “ease of use”.

If people can remember back to the days of “postal mail” being the major means of communications between private individuals and compare the features of then and Email today it’s easy to see how we have paid several major prices for our “easy life”.

The only way to get back to some semblance of privacy/security is as a first step to have “personal secretary devices” where all the mail we send and receive goes into these end point devices, all plain text activities we use should be on these devices not on some webmail server where the plain text is visable to anyone with access to the server.

The problem with this necessary first step is it becomes a “single point of failure” unless quite a few issues are addressed in terms of reliability and security. Sadly we’ve not realy thought about them properly as an industry and even though we should based on the history to date do we realy think we will?

I for one am not going to hold my breath…

Clive Robinson April 1, 2014 5:41 AM

@ DaveN,

    What would they do then, jail him?

That depends on what they think they can get away with, for instance how about this “hicksville aproach” by the New York DA,

http://www.wired.com/2013/01/coder-charged-for-gambling-software/

Oh and you need to remember that NY has major revenues from it’s state licenced gambaling which have be “threatend by off shore online gambaling” so you might want to consider the Protection/Racketering angle in effect being carried out by the NY DA when considering his behaviour.

As has been pointed out by others you have to ask how many other people have been preasured in this way and have silently buckled and done what is immoral/criminal for various US TLAs. Especialy when it’s clear to all who care to look that the TLA’s know thay can get away with it because the DoJ and executive will fully protect/support them in such actions…

Bob S. April 1, 2014 6:08 AM

It seems corporations are only interested in security or privacy to the extent it impacts the bottom line.

Indeed some of the companies whining the loudest profit from re-selling personal data to the government.

Regardless, the world market is huge and I would not be surprised to see some major corporations go bankrupt due to NSA conduct and corporate complicity. But, like the banks, possibly NSA and their counterparts are too big to fail, it seems.

The more visible pending bills in Congress are the usual sophist garbage which will INCREASE NSA power and give the players retroactive immunity forever.

We cannot count on power freak government or greedy corporations to do the right thing. Quite simply, they won’t.

It’s up to us as individuals to spread the word of betrayed privacy and security and the technical people who can and will build new armor to protect us from the onslaught.

This is an awful mess that seems to be permanent.

Benni April 1, 2014 6:22 AM

By the way, it seems that this new SPIEGEL book is available in english too:

http://www.randomhouse.de/book/The-NSA-Complex-Edward-Snowden-and-the-road-to-total-surveillance/Marcel-Rosenbach/e460131.rhd?pub=36000&frm=true

The good news:
The websites siemens.com and mercedes-benz.com are not being spyed on from Bad Aibling. For other sites, this warrant does not hold.

dozens of examples of industrial espionage. and other things.

Most funny is the nsa project Cajablossom. Its goal is an automated evaluation of your internet browsing history, in order to transform it into a complete personality profile.

Also interesting: new technologies coming from germany are surveillance priority 4. german politics and economy is priority 3.

International financial infrastructures have priority 2. non-us and intertinational groups involved in research and development, and international companies are 3.

The international court in Den Haag also has priority 3.

Graham April 1, 2014 6:44 AM

My first concern is to prevent mass-surveillance and fishing expeditions. Attacks which require targetting an individual are of secondary concern, to me. My other goal is to make sure all interception requires as much cost as possible (resources like time, money and processing power, but also high risks, larger number of people knowing what is happening, etc): we have learnt that laws don’t constrain these agencies — costs are the most effective controls.

In my view, the first, most important, quickest and easiest thing to do is to make sure that all SMTP communication happens over TLS. That raises the bar for mass surveillance way above the level today. Of course it isn’t perfect but it is a great first step. Personally, my mail client looks at the headers and warns me if an email I receive didn’t use TLS — many do but a lot still don’t. We need that to change.

As a second focus, a scheme where the server only stores encrypted text, and the client decrypts, also increases the cost of interception. Even if the server offers to store keys, the problem then becomes targetted surveillance instead of mass-surveillance — as long as we can (somehow) be sure that the server isn’t storing another copy for the government. So, I think that would be a problem worth trying to solve.

We shouldn’t let the truth that we can never be completely protected stop us from doing everything we can to incrementally increase the costs of the attacks.

Clive Robinson April 1, 2014 7:52 AM

@ Graham,

    As a second focus, a scheme where the server only stores encrypted text, and the client decrypts, also increases the cost of interception

In other words make the server a “post box” not a middleware “user agent”, which is what I was talking about. In the early days of EMail –appart from encryption– thats pretty much the way things were.

However I had a reason for having the device store all the messages.

Think not of one “post box” for a user but “one per message”. That is when I send you an email the encrypted message ends up in some random place inside a mix network that I as the originator never know. You as the recipient pull the message from the random point via the mix network and store it on your device.

This decouples not just the message from it’s routing data but also decouples the sender and recipient as the mix net work issolates them.

This leaves the issue of how the recipient gets notified of the availability of a message and where it is. I’ve mentioned one way to do this previously on this blog, I was kinf of hoping others would have a think along those lines and come up with alternatives… sofar nix 🙁

Winter April 1, 2014 8:26 AM

The problem of lost email passwords is a red herring.

If we would install end-to-end email encryption, we can tell users to write down their email password, frame it, and hang it on their bedroom wall They would still be more secure than they are now.

Currently, everyone outside of their home with access to the network or servers can read their email.

This sounds suspiciously like the arguments against “TLS everywhere”, which would have made everyone more secure.

Saul Tannenbaum April 1, 2014 8:39 AM

One more aspect to the word games.

Bruce writes:

The big Internet companies know of PRISM — although not under that code name — because that’s how the program works; the NSA serves them with FISA orders.

It’s the FBI that serves PRISM FISA orders, acting on behalf of the FBI. So, any denial in the form “we’ve never cooperated with the NSA” can be literally true and totally meaningless.

BadApple April 1, 2014 9:09 AM

@xx “Actually, Apple does do exactly that – being in the business of selling hardware, they don’t want the hassle of dealing with user data when they can avoid it. Most recently, the iMessage protocol’s security, designed to avoid cleartext or storage of texts outside of the communicating devices, made the rounds: http://techcrunch.com/2014/02/27/apple-explains-exactly-how-secure-imessage-really-is/ (paper linked from that article). The Keychain protocol is similarly designed: even if you sync the keychain over iCloud, it is never stored outside of your devices.”

You are wrong: Apple maintains copies of your key despite what they say, see http://arstechnica.com/apple/news/2012/04/apple-holds-the-master-key-when-it-comes-to-icloud-security-privacy.ars

Sancho_P April 1, 2014 11:47 AM

@ Clive Robinson:

“This leaves the issue of how the recipient gets notified of the availability of a message and where it is.”

What about this extension:

Sender’s email client encrypts email and “dends” (deposit sends) it using provider A, but directly sends the key to the recipient using provider B.
Sending the key may happen at random (ms) time before or after “dending”.

The recipient’s email client receives the key with info who is B and how to retrieve the message, pulls in the message and encrypts it automatically.
Using POP with “delete from server” or similar would be best …

The end user would not be involved, the short “notification” doesn’t really increase network load.

Saul Tannenbaum April 1, 2014 1:28 PM

@myself: When I wrote “It’s the FBI that serves PRISM FISA orders, acting on behalf of the FBI” I meant to write “It’s the FBI that serves PRISM FISA orders, acting on behalf of the NSA.” Ooops.

brooks April 1, 2014 7:58 PM

That is why NSa promoted shyster Bill Gates. They had him monopolized the market with his garbage, starting with backdoors in Windows 95, which he himself refused to use at Redmond.

That, turns out, to be a two way street. How many Snowdens are there, who never got detected? What is the level of reverse penetration from Russia and China using weakness promoted by NSA itself?

We are yet to hear NSA explanation of the epic failure to foresee and detect quick Crimea takeover.

Mike the goat April 2, 2014 5:10 AM

What surprises me is that even rather technically competent users have shunned email encryption despite the ready availability of tools using both OpenPGP and SMIME (yes, both have their shortcomings); usually the excuse is that their correspondence isn’t important enough. I believe Phil Zimmerman himself said that those same people don’t write all their mail on postcards – they use envelopes.

Even if you used TLS in communicating your outgoing email to your ISP’s server, and the entire path and all relays used TLS, you would still have the issue that all intermediate hosts involved still have access to the cleartext, and even if the recipient picks up their mail using TLS enabled POP or IMAP the message still sits in their mailbox at their provider in the clear. So basically even in an ideal situation you need to trust both your ISP, the recipient’s ISP and potentially any relays in between. So those pushing for TLS everywhere are absolutely right that it will prevent blind wiretapping but we know from the NSA saga that ISPs etc are complicit and thus /nothing/ short of end to end encryption is satisfactory.

kashmarek April 2, 2014 5:24 AM

The spy agencies are good at monitoring weak targets, such as people & companies within our borders.

The spy agencies tend to be poor at monitoring things outside our borders, as most of those institutions behave accordingly and put up defenses or use smarter offenses to avoid detection of their intentions.

If the spy agencies would shift their resouces to doing a better job of monitoring outside our borders, they might stand a chance of detecting something they are being paid look out for. However, that would mean working harder and that certainly won’t happen. This is not to disparage all spy agency personnel, but to point out that those leading the charge are also the ones responsible for the failures.

I had not thought about the reverse penetration issue (due to weaknesses implemented by the spy agencies themselves.) That in and of itself is a classic failure for which those responsible should be held accountable. Of course, that kind of failure shows up with things like the Snowden leaks. Everybody above Snowden needs to be held accountable for that (and there are likely more of these events to come; speculation).

Bill Franklin April 2, 2014 9:07 AM

Seems like US policy is at the heart of the issue. That’s why we founded Lavaboom, Lavabit’s successor, outside US jurisdiction. HQ in Germany, servers in New Zealand, and a zero-knowledge policy: the aim of http://www.lavaboom.com is to supply secure email for everyone.

Clive Robinson April 6, 2014 2:43 AM

@ Sancho_P,

Sorry for the non reply I’ve been a bit busy attending to the busines of living for the past few days.

What you describe is a method of decoupling the message from the control/routing meta-data but does not say how you decouple the meta-data from the sender and recipient, thus does not stop traffic analysis.

What I was looking at was an improved version of TOR and a mix network with internal multiple stores and directories.

In essence you do a directory lookup at any one of many entrypoints into the distributed directory in a way that does not –easily– identify who you are looking up. This returns one or more public keys records one or some of which relate to the user you wish to communicate with and a “virtual address” to send it to.

You then encrypt the message body under a random symetric key and preapend a random identity string and hash encrypted under the recipients public key that has been then encrypted under your private key. The resulting file you send via anonymous routing to a randomly selected file storage location within the mix network along with a “time to live” field.

You then encrypt the file name and storage location and a second identity string with your private key append your virtuall ID and encrypt with the recipiets public key and send via anonymous routing to their “virtual address”. Importantly you have not sent the symetric key yet.

The virtual addresses are “post boxes” hidden inside the mix network that you access indirectly via anonymous routing.

The recipient on receiving the location message decrypts it under their private key to get your virtual ID which they use to get your public key which they then use to decrypt the location information of the file and the second identity string. They get the file and decrypt the first identity string.

The recipient then contacts you anonymously with the second identity string and via various protocols prove they have the first identiy string and you transfer the symetric key.

The problem with this system is that of most public key systems and that is verifying the contact details in the directories are current, genuine and not subverted in some way or acting as a masquerade. As a rule of thumb this requires a properly authenticated side channel such as a personal meeting which in many cases is not practicle and it’s this problem area we need to be addressing in some way. Theory sugests we are only at “six degrees of seperation” from each other so it should be possible to build a web of trust provided “all participents are diligent and honest” which is very unlikely to be the case.

Mike Dimmick April 7, 2014 12:27 PM

@Natanael L: No, Certificate Authorities cannot read any part of traffic encrypted with certificates that they issued. That’s not how PKI works. PKI is limited to authenticating that the parties are who they say they are – or at least that they were able to convince the CA that that is who they are.

The only keys that the CA has are those that they used to sign the certificate – a hash of the certificate is encrypted with the CA’s private key and attached to the certificate. That allows you to decrypt their signature blob using their public key, hash the certificate, and compare the decrypted hash with the one you just computed. If they match, you know that someone holding the corresponding private key signed that certificate, and that it hasn’t been tampered with afterwards. Assuming that the CA have properly protected their private key, and that they did reasonable diligence on who requested the certificate, you know that the person presenting the certificate are who they say they are.

When generating a certificate, the user or server operator keeps the private key private. The CA never sees the private key. Only the public key is included in the certificate presented to the CA to sign. The private and public keys are randomly generated and have no relationship to the keys used by the CA. Normally the private and public key pair are generated before selecting the CA to send the certificate request to.

As for iMessage: Apple’s description seems to be missing a step – they mention encrypting the message with AES-128 but do not mention how that key is derived, nor how it relates to the devices’ public keys. AES is a symmetric algorithm: you use the same key to encrypt and decrypt. If they are genuinely only encrypting the messages with a symmetric key, then Apple would presumably be able to decrypt the message. However, that would leave the public key redundant. They could be using a system similar to DVD encryption or an encrypted file system, where the message itself is encrypted with a new randomly-generated key. That key is encrypted with each of the public keys for the recipients and the result of each encryption attached to the message. The usual reason for doing this is that it reduces the amount of data encrypted with different keys, which reduces data storage requirements.

If the sending device generates the symmetric key, that key is only encrypted with the recipients’ public keys, and the symmetric key isn’t sent to Apple in the clear, then there is no way for Apple to read the message either.

Sancho_P April 8, 2014 6:04 PM

@ Clive Robinson:

From your “how the recipient gets notified of the availability of a message and where it is” I assumed you think about kinda offline communication, like e.g. email, there is the focus of my comment.

First, I have to say that I’m not happy with the term “metadata” in this (or any conversation) context. It is newspeak, often deliberately used to deceive the masses.

On the contrary, the connection detail (the routing and timing information) is probably the only true [1] and trustworthy data of the message / conversation.
I’d prefer to call that the “header” in respect to the email example.

The raw content, the “body” of the message, could be completely misleading, intentionally or not. We could agree to say “yes” for “no” or any other cleartext obfuscation, write the truth or lie / fantasize, who would ever know?
And the language itself … There are transcripts of ancient texts where experts, after years, are not sure what was meant exactly.
Also in our native language there are too many misunderstandings, see our politicians
Only when using strong encryption everyone will recognize that immediately … and automatically.

Second, I think we agree that if someone is already targeted by his local “NSA” in cooperation with his local ISP, then he is screwed anyway. They’d copy every byte of the particular Internet (and phone) connection to their HQ and analyze it.
So here I’m fantasizing about “not wittingly” mass collection only.


“… but does not say how you decouple the meta-data [header] from the sender and recipient …”

But a scheme like mailinator will do it, although not perfect.
In fact, the email (SMTP) header contains the sending server, and your email provider may include your own public IP.
Yes, clearly you are the sender, but the recipient remains unknown, it is a fictional address, no one could verify whether it’s valid or not.
The access (if any) to that receiving mailbox could be seen at mailinator’s servers only.
The message’s body is completely public, therefore it must not contain the plain text info. What about splitting the message over three “mailinators”?

Now let’s assume several service providers in different jurisdiction have something like mailinator (I’d like to see news agencies, like NYT, El Pais, The Voice Of Russia, The Intercept, …, would run it).
The post boxes are completely public but anonym.
Any (https) access to these boxes (also per API function) is only know to that single provider.

Only by access to these providers one could assume who is interested in the recipient’s address.

However, the one and only basic question remains: Authentication (= trust).
And: Who really runs the service?

That’s the same with TOR or any VPN solution, there is not trust without law.

[1] However, we can not really trust that information.
We never could: We never had the system, OS, application SW and methods to be “guaranteed free of failure” from the vendor for any single piece, let alone for the combination of all pieces that may be involved (see EULAs).
But now, post Snowden, every sensible human (not only technician, e.g. a judge) should know that any “evidence” taken from the IT must be dismissed in court.

BTW:
This is the only chance to end that mess in general:
We need a law to reject any “information” taken from the Internet to be accepted as “evidence” in court. It may be used as a hint into further investigations but can not be accepted as evidence to convict someone of any wrongdoing.
Such kind of “information” can
a) neither be proven right or wrong because of complexity
b) easily be faked without a trace.

(E.g.: From my home computer I have admin access to hundreds of private Internet routers, to read / change admin and wifi passwords, change their DNS server forth and back, whatsoever, because of deliberately (vendor+ISP) placed backdoors to recover that device in case the customer got in trouble. There are dozens of bot-nets with hundreds of routers in the Net, no one can stop that …)

Buck April 8, 2014 7:48 PM

@Sancho_P

We need a law to reject any “information” taken from the Internet to be accepted as “evidence” in court. It may be used as a hint into further investigations but can not be accepted as evidence to convict someone of any wrongdoing.
Such kind of “information” can
a) neither be proven right or wrong because of complexity
b) easily be faked without a trace.

A very valid point! One that has thus far managed to somehow escape the grasp of all legal ‘professionals’, and seemingly almost all IT ‘experts’ as well…

Julian Assange April 10, 2014 5:20 AM

@Buck

For example the trap that was running with the unknown user/users posing as Julian Assange and trying to convince people to supply them information or do things like set up a VPN with remote access to their system.

William Franklin McCoy, M.D. May 27, 2014 11:53 AM

Dear Bruce,

What is your impression of Blackphone?

All the Best,

W. F. McCoy, M.D.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.