Please cite the portion of CALEA that requires commercial enterprises to subvert encryption in any way, key escrow or otherwise.
I for one would be shocked.
It may, however, still be the case that PATRIOT creates a legal authority from which multiples agencies might ask companies to undermine some of the goals of cryptography--depending on your politics and your vantage point--to be able to profile lawful intercept capabilities, e.g. by offering unmonitored access through something like Google's eDiscovery portal or just by complying with legal requests.
What I'm interested in is, what's an example of some authority of PATRIOT compelling a commercial enterprise to weaken or subvert their cryptography or, as you put it, the goals of their cryptography? Be specific, please. This thread lead off with a truly wacky and false claim about compulsory key escrow. I'd prefer not to see it rehabilitated by a flight to abstraction and appeals to our shared dislike of NSA.
My understanding was that the government--typically the FBI--could send NSLs to tech companies to secretly demand a broad range of user information, and short of being Tahoe-LAFS and it being impossible to fulfill such a request or being Lavabit and asking for money to build in a backdoor to fulfill such a request, companies had to find a way to comply.
In other words, my understanding was more that PATRIOT created a legal authority that allowed the government to secretly demand user information in ways that made requests difficult to challenge in court or disclose to affected users, and that the technical and other specifics of how to satisfy those requests was typically up to the companies.
I'm not aware of compelled key escrow (but also wouldn't necessarily expect to be given the role of gag orders), but Lavabit might be considered an example of compelled key disclosure. At least technically, that's a very different beast.
I would say that they haven't.
_RSA_, whose only product is sturdy crypto, subverted their products.
I would say that this sentence amounts to an unverified assumption. I can't actually think of an example - can you?
If the closest you can come to arguing that all commercial tech enterprises are "voluntold" to build key escrow is a crypto library used by virtually no end-user encrypted communications systems, I'm suddenly a lot less interested in this discussion.
I think Dual-EC probably was a backdoor. I think any commercial product that adopted Dual-EC is worthy of suspicion. Fortunately, so far as I can tell, virtually nothing that matters ever used Dual-EC.
If the financial kickback to RSA was 'small' (care to post an analysis) then they added the backdoor to BSAFE for other reasons. Therefore I don't think that argument addresses the thesis.
Here are a list of suites NIST validated with DUAL_EC.
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval....
Plenty of products relied on BSAFE including enterprise security products like McAfee.
https://lwn.net/Articles/566329/
But practical impact aside, you haven't addressed the primary thesis.
Indeed, many random enterprise security products did use BSAFE. Most of them did so because during the mid/late '90s, a BSAFE license was how you shipped certificate-based public key features, because RSA was enforcing their patent. Many of those products include BSAFE on their manifest but use OpenSSL and Microsoft SChannel instead. And the features we're talking about are things like login pages or agent/server communications for things running on 10-net addresses.
How many of those enterprise security products did end users rely on to protect their secrets from the USG? I'm going to go out on a limb and suggest that number is zero.
"(3) Encryption
A telecommunications carrier shall not be responsible for decrypting, or ensuring the government’s ability to decrypt, any communication encrypted by a subscriber or customer, unless the encryption was provided by the carrier and the carrier possesses the information necessary to decrypt the communication."
http://www.law.cornell.edu/uscode/text/47/1002
Here's the Wikipedia article:
"The Communications Assistance for Law Enforcement Act (CALEA) is a United States wiretapping law passed in 1994, during the presidency of Bill Clinton (Pub. L. No. 103-414, 108 Stat. 4279, codified at 47 USC 1001-1010). CALEA's purpose is to enhance the ability of law enforcement agencies to conduct electronic surveillance by requiring that telecommunications carriers and manufacturers of telecommunications equipment modify and design their equipment, facilities, and services to ensure that they have built-in surveillance capabilities, allowing federal agencies to monitor all telephone, broadband internet, and VoIP traffic."
https://en.wikipedia.org/wiki/Communications_Assistance_for_...
Here's a checklist for CALEA:
http://transition.fcc.gov/bureaus/pshs/services/calea/CALEA%...
That is, if a company is running a key escrow, then it is required to decrypt information for the government. But it's not already running a key escrow, there's nothing in the section you cited that requires it to.
The law simply does not require Google, Microsoft, &c to implement key escrow, and so far as I can tell, those companies don't.
CALEA relies on voluntary key escrow which essentially all major information providers have been willing to provide (see Snowden leaks).
Voluntary only exists where incentives allow a full reasoned decision to be made by corporations.
Look at the fines that Yahoo was forced to face on a daily basis for not providing the information requested by the government. Look at how QWest was unraveled.
Soft power, financial leverage, standards manipulation, other laws and legal requirements (law praxis) - including those mentioned in the parent comments (ignored thus far by downvote brigade), executive orders and others effectively require key escrow. All major telecommunications carriers have been onboarded to 'voluntary escrow' in this regard.
The presumed 'big news' being that Apple and Google providing escrow-less cryptography directly implies that there was key escrow before (there was encryption present before, but no law enforcement condemnation).
I encourage readers of these comments to chase the provided links and information, as well as the fully body of knowledge leaked by Binney, Snowden and others, to bear on the 'truthiness' of this comment thread.
"For all devices running iOS 8.0 and later versions, Apple will no longer be performing iOS data extractions as the data sought will be encrypted and Apple will not possess the encryption key.
For iOS devices running iOS versions earlier than iOS 8.0, upon receipt of a valid search warrant issued upon a showing of probable cause, Apple can extract certain categories of active data from passcode locked iOS devices. Specifically, the user generated active files on an iOS device that are contained in Apple’s native apps and for which the data is not encrypted using the passcode (“user generated active files”), can be extracted and provided to law enforcement on external media.
Apple can perform this data extraction process on iOS devices running iOS 4 through iOS 7. Please note the only categories of user generated active files that can be provided to law enforcement, pursuant to a valid search warrant, are: SMS, iMessage, MMS, photos, videos, contacts, audio recording, and call history. Apple cannot provide: email, calendar entries, or any third-party app data."
I can see how you read this. I read it another way. There was encryption on the device, but it was circumvented in iOS4 through iOS7 (so called "active data") so that law enforcement could access it (over snailmail). The implication is that 'active data' persists longer than the alivetime of the device.
"It is further ordered that, to the extent that data on the Device is encrypted, Apple may provide a copy of the encrypted data to law enforcement but Apple is not required to attempt to decrypt, or otherwise enable law enforcement's attempts to access any encrypted data."
I can see how you read this. I read it another way. Many of the CALEA programs allow businesses to 'volunteer' data or to volunteer to decrypt information. They've been bullied into doing this. Apple says that it will take a stand, but I don't have very much trust in them because them ultimately is a board of directors chasing profits.
"iCloud only stores content for the services that the subscriber has elected to maintain in the account while the subscriber’s account remains active. Apple does not retain deleted content once it is cleared from Apple’s servers. iCloud content may include stored photos, documents, contacts, calendars, bookmarks and iOS device backups. iOS device backups may include photos and videos in the users’ camera roll, device settings, app data, iMessage, SMS, and MMS messages and voicemail. iCloud content may be provided in response to a search warrant issued upon a showing of probable cause."
iCloud data syncs by default. That is, they've added data encryption to singular devices but placed the data by default into their cloud, where they offer decryption for law enforcement.
CALEA does not apply.
Now that Apple does not have access to the UIDs built into the "secure enclave" they can not provide decrypted content directly. However they will still hand over encrypted data and manufacturers do have these UIDs. The user can still provide ~12 bits of key entropy.
Apple currently makes it extremely difficult not to store most information on iCloud, sets the default to store data on iCloud, and this data is provided to law enforcement. This data is encrypted but Apple will decrypt it for law enforcement.
CALEA (and others, as discussed in the thread) _do__ apply. It's why Apple needs to claim that they don't have the keys "unless ... the carrier possesses the information necessary to decrypt the communication."
The big news was in fact that they would be providing end-to-end encryption with the claim that they 'do not have a key and so can not comply with key requests.' Find me some articles that don't center around the issue of law enforcement getting keys.
Encryption, including by default and including FDE existed before this year. That's not the news.
Any HN reader reading this can confirm this is the case with a few quick searches around the use of full disk encryption and encryption in general in Google and Apple.
I see I've interacted with you before with the same result. I'll give you the same ultimatum I gave you then. Provide a source now, or stop repeating this nonsense.
Apple's announcement itself:
"Unlike our competitors, Apple cannot bypass your passcode and therefore cannot access this data. So it's not technically feasible for us to respond to government warrants for the extraction of this data from devices in their possession running iOS 8."
https://www.apple.com/privacy/government-information-request...
"Specifically, Apple has radically improved the way that data on those devices is encrypted. Once users set a passcode, Apple will no longer be able to unlock your device—even if ordered to do so by a court."
http://www.slate.com/articles/technology/future_tense/2014/0...
"To get started, it's worth pointing out that disk encryption is hardly new with iOS 8. In fact, Apple's operating system has enabled some form of encryption since before iOS 7. What's happened in the latest update is that Apple has decided to protect much more of the interesting data on the device under the user's passcode.
...
So to a large extent the 'new' feature Apple is touting in iOS 8 is simply that they're encrypting more data. But it's also worth pointing out that newer iOS devices ... also add substantial hardware protections to thwart device cracking.
In the rest of this post I'm going to talk about how these protections may work and how Apple can realistically claim not to possess a back door."
http://blog.cryptographyengineering.com/2014/10/why-cant-app...
http://www.cnet.com/news/apple-deluged-by-police-demands-to-...
http://www.cnet.com/news/how-apple-and-google-help-police-by...
http://boingboing.net/2013/05/12/apple-can-decrypt-iphones-f...
http://www.theguardian.com/world/2013/jun/06/us-tech-giants-...
http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl...
"Give me links as proof"
[Downvote them and not reply]
It's okay. Other HN readers know what's up.
If I had to guess why you've been downvoted, I'd guess it was because you keep posting links that don't support your claim, wasting everyone's time.
Also, this is much different from last time. Last time, you didn't bother to post any links at all, even links irrelevant to your claim.
You aren't going to get a nice first party source, although Apple has essentially admitted to it.
Apple says that "For all devices running iOS 8.0 and later versions, Apple will no longer be performing iOS data extractions as the data sought will be encrypted and Apple will not possess the encryption key."
You're going to interpret that as "oh hah, well some of the data wasn't encrypted before". But I included links earlier showing how Apple's (and Google's) announcement centered around the use of new technology that would not allow Apple to have a copy of the key. And if you look at the data they were pulling off, there was data that was 'encrypted' before but had engineered circumvention - 'active data' being one.
Apple will (currently) decrypt data it has in iCloud for a device. It is engineered to be very difficult to not store data in iCloud [1]. Apple's own list of information that may be in iCloud include "stored photos, documents, contacts, calendars, bookmarks and iOS device backups. iOS device backups may include photos and videos in the users’ camera roll, device settings, app data, iMessage, SMS, and MMS messages and voicemail."
https://news.ycombinator.com/item?id=8522316 for more.
Re: last time. I pointed to other areas of the thread, where plenty of sources were given.
[1] http://mjtsai.com/blog/2014/10/26/yosemite-uploads-unsaved-d...
The passcode of 12 bits...
Apple can and will provide ciphertexts, will hand over copies of the large amounts of data customers are encouraged and sometimes forced to upload.
> This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't.
From the top of the post: "CALEA, the Stored Communications Act and Section 215 of the Patriot Act all compel corporations (via the Department of Commerce) to build DATA AND key escrow services into their products."
What you're saying is that they don't provide key escrow specifically (while wholly ignoring data escrow). What I'm saying is that by design the crypto doesn't matter in practice and the system had been (still is) architected to allow for data intercept.
When you argue the 'no key escrow!' case you are implicitly condoning 'they won't hand over your data!'.
Not true. It was the case and _still is_ the case that Apple and its manufacturers will give access to your private communications, metadata and data.
We've focused on Apple but Google is not different.
> The passcode of 12 bits...
Even the weakest passcode option is more than 13 bits, but neither Apple nor Google restricts you to such short passcodes.
> [CALEA nonsense]
How many times do people have to tell you that CALEA doesn't apply in this case? Don't you find it suspicious that Apple and Google are essentially claiming to be flouting your imaginary version of CALEA, and nobody has called them on it except you?
> Google is no different.
Exactly. They don't provide the government with decryption keys either.
It's been fun, but you'll have to argue about imaginary laws, black helicopters, chemtrails, and ice bullets with your fellow conspiracy theorists. If you won't trust primary sources and common sense, there's nothing more I can do.
Whoops typo. Care to respond to the spirit of the argument, rather than its letter?
> Even the weakest passcode option is more than 13 bits, but neither Apple nor Google restricts you to such short passcodes.
Care to break down the entropy of user supplied passcodes? Does it surpass 80 bits? No. 12, 13, 14, 24, 50? At that complexity it's all the same to law enforcement.
> > [CALEA nonsense]
Nah, I was quoting the top of the thread and capitalizing "DATA AND key escrow" in response to "This whole thread has been about whether they have the keys to decrypt encrypted data on the device. They don't." It hasn't been wholly about whether they have the keys, but whether they can get the data. Keys are one way to do this. Brute forceable keys are another. Data backups are another. Broken crypto is another. Etc.
The thread has not been about whether they have the keys - but whether they work with law enforcement to create systems can be subverted, either by creating ineffective crypto, crypto with low entropy or controlled keys, key escrow or direct data escrow.
The other point was to remind you that the topic is about more than CALEA, but in fact other laws (and interpretations thereof). You're the one who has tried to make the focus about CALEA in isolation.
> > Google is no different.
> Exactly. They don't provide the government with decryption keys either.
Right, but they do provide _data escrow_ and mechanisms to defeat in place on-device crypto (such as access to data backups stored in the cloud).
> It's been fun, but you'll have to argue about imaginary laws, black helicopters, chemtrails, and ice bullets with your fellow conspiracy theorists. If you won't trust primary sources and common sense, there's nothing more I can do.
Straw men. All of it.
I directly quoted (this is just one example) from primary sources the policies in place today that provide data escrow. I also discussed the backdoorable design of the Secure Enclave using primary documents.
Common sense is something every man thinks he has a monopoly on. It is for neither of us to decide if the other has it (for I would be prone to say the same).
I'm sorry to hear that you are done contributing - there's so much left in the thread that was never challenged. I found the conversation very valuable as it has provided (at least me) a good opportunity to dig up additional sources and has provided a stage for dissemination of information to broader eyes.
I'm very glad that the discussion is in public record, and that other HN readers can access this information, do their own research, and decide for themselves.
See you around the next Snowden thread! ;)
Your claim at the top of this thread was that companies like Microsoft (presumably also Google, Dropbox, Apple, Stripe, Mozilla, Facebook, LinkedIn, Samsung, &c) were legally compelled to implement --- your words --- key escrow. Even if we charitably defocus that argument to cover not just literally key escrow but any cryptographic or security UX property meant to reduce security or provide lawful intercept capabilities, I know that claim to be false.
I'm eagerly awaiting actual evidence from you to back your claim up, because if you're right, I'm profoundly wrong about something. I doubt you're right, but the risk/reward on wasting my time versus a life-changing revelation work out for me to keep participating in this discussion.
Bollocks. But let me ask you this: have other incentives - non-legal ones, even personal whim - enticed any of these companies to provide key escrow for the US government? What is the current policy climate with this regard? Is there a voluntary key escrow program? How many companies are on board it? Is there a single telecommunications provider that -isn't- providing key escrow?
I can't find a testable claim anywhere in your comment. That's not a ding, it's merely the usual nature of HN comments. It is a sort of foul play to selectively apply criteria.
Here's a testable claim. If a HN participant does independent research on the Apple and Google encryption news recently (not you or me or lern_too_spel), that participant will find that encryption is not new nor the thing that law enforcement are critical about. They will find that there is a long history of FDE on Android and on Apple and on other products. They will find that both Apple and Google declared that they would provide encryption mechanisms that they would not have access to decryption keys for. They will find that this causes a ruckus at the FBI and other law enforcement.
This is a testable claim. Not testable by you or by me. But it is testable by other readers. They should do it for themselves.
The quality of my posts are not in question. I highly encourage readers to wade through my comment history (and that of 'xnull' as well) to links interesting and relevant to the current state of cybercontrol.
The facts stand on their own.
I encourage anyone who makes it to this comment-leaf to investigate the facts for yourselves. Neither I nor Tptacek are pseudonyms you can trust.
But it makes it all the more surprising that none of these companies supports user-controlled keys, convenient and trustworthy key exchange, and end-to-end encryption for their storage and communications products.
But you could also say that ephemeral keys are user controlled to the extent they are exchanged end-to-end and the conversation can't be evesdropped.
Your objection amounts to saying "We don't have easy, trustworthy key exchange backed by a web of trust."
* Key continuity (a la SSH)
* Web of trust (a la PGP Keyservers)
* PKI (a la SSL CAs)
Of these three, only key continuity appears to work in practice.
I'm eagerly awaiting the UX invention that somehow merges continuity and web-of-trust to make the latter tractable.
I'm definitely not complaining that there's no web-of-trust, since I don't believe in it as a workable UX solution for normal people.
I believe the mainstream Web services hold the key (no pun intended) to UX for web-of-trust key exchange. Their users have access to real time communication which would make subverting key exchange and key signing hard, and building a Web of trust convenient, including key replacement, etc. The secure specialty services don't have that capability, and so they remain privacy-for-wonks.
I'm certainly willing to consider that I could be wrong about that. But with trust in short supply, someone should be tempted to build products that say "Trust no central authority, trust this math and the open code that implements it."