If a court can force a company to create new technology that didn't exist before, what other tools might they be forced to build?
1) Stream keystrokes, audio, video, location to law enforcement prior to encryption
2) Replace actual search results with government-approved results
3) Force Apple to create target lists of suspects based on their location, apps installed, sites visited, keywords typed
Bad things happen when the government can force private companies and individuals to create new tools for law enforcement.
There is no technology that prevents Apple from subverting Apple's security. If Apple loses, the new precedent could open Pandora's box.
That's just in this universe. If users truly owned their devices, with full knowledge of the hardware and control of the software + data, we would never have this discussion.
In this world, you have to jump through flaming hoops just to prevent Apple from automatically swapping out your OS!
Then we're getting into compromised hardware, you verified that the chips actually are the same as the circuit diagrams after all.
There is only so much tinfoil you can deploy. If an advanced nation state truly has you in its sights there isn't much you can do about it, and to be honest that's the way it should be. We sacrifice individual liberties for the advantages of being part of an organised society, and the limitation of coercive power to the state is a key part of that.
A well regulated state in which the right people get targeted, with an acceptably low false positive rate that scales based on the degree of privacy violation of the targeting seems to be a perfectly sensible state of affairs. Apple's argument that they are being asked to do something that isn't justified fits just fine into that.
* Certificate Transparency-style public ledger for all firmwares that Apple has signed. Refuse an update if the firmware version has not been published to the ledger. This would make these backdooring attempts public, since we can assume people would watch the ledger and ask questions in case of an unknown version being published.
* For open source firmwares, reproducible builds are a great tool to make sure the distributed binaries actually match the publicly reviewable source code. Third parties could recompile the firmware and attest (through signing) that they get the same result.
I don't know any implementation of either of these two systems, at least publicly available (hint: Bazel does reproducible builds, and you can guess what is driving this requierment). Debian and Mozilla are experimenting with reproducible builds but I don't know that it ever reached any useful conclusion.
That's seems like a fantastic idea but without open source firmware I don't see how it could be enforced.
But it's pretty easy to imagine a feature where, similar to cert-pinning, many clients report the hashes that they see on the website and if you see something different from what everyone else does, you know something is wrong. It wouldn't need to be a "techie" feature - it would simply show a package as broken and refuse to install if it wasn't verifying, etc.
And the goal isn't some impossible 100% security, the goal is enough security to end mass interception and make the government rely on warrants and targeted tactics again.
This is why as well as serving those hashes over HTTPS, you sign the hashes with a key, the public part of which is distributed/retrievable/verifiable via some other means.
I think there's value in the purely user-based solution though. If two people go to a site at the same time and aren't served the same binary they should be curious why, even if the company securely and auditably signed both images.
And, it helps in all the cases when companies don't implement great release-security.
And how do I verify that the code I've just read is what shipped on my computer? If I install it myself, how do I verify the CD or ISO I have is what I read? If I compiled it myself, how do I verify the compiler didn't change anything? What about the system that compiled the code, do I trust that? How far back do I have to go before I have trusted everything?
And then what about hardware? Is there a chip that changes some of the code that's running? Can I verify every piece of hardware in my system, a 16-core CPU with 64GB of RAM and a high-end video card? How do I even do that? And what are the odds I am a world class C coder and a world-class hardware expert?
And then what about client code? Am I a world-class Javascript expert too, with full source access to the Django backend? And the system that is running that server code, do I have access to that hardware to make sure it's not going to compromise my security?
No. Fully trusting a computer is impossible. It doesn't mean we shouldn't try, we should at least make it as hard as possible for the bad guys to trick us. But what's better, IMO, is to create an environment where it's detrimental to companies to trick their users like that. Apple seems to have gotten a lot of great press for standing up in this situation. There's a market for it.
Can you trust Apple tech? Maybe not. But can you trust it more than Google or Microsoft or Samsung or Facebook or Amazon etc etc? It does seem that way. Without being a world-class expert in everything, eventually you have to trust someone.
I completely agree. I liken it to something like world-peace: It's an ideal, and we'll probably never get there. Doesn't mean we shouldn't try to get there though.
We should have a series of standardized trusted execution modules which are open source hardware and open source software. There should be a public process by which these are vetted. Watchdog groups could disassemble samples of the chips and place them under electron microscopes and otherwise examine them for tampering.
The effect of this would be to place individuals and grassroots organizations on an even playing field with corporations and governments with regards to such tools. It's a disaster for large organizations to have access to individual private information, yet it's a societal boon for such organizations to be open and for individuals to know what they are doing. The same asymmetry applies to trusted execution. It's a disaster when big organizations use it against individuals, but it would be a societal good if individuals could revoke access to their information from corporations when they break goodwill.
It's just the old versions, before Apple started making privacy a political tentpole, that they could ever manage to backdoor in this particular way. That's still bad—but what Apple are mainly worrying about is that this precedent would force them to aid the FBI in other act-of-creation ways, not just in ways involving introducing backdoors.
The FBI might compel Apple to, for example, build a monitoring and clustering service into iTunes Genius/Apple Music to de-anonymize people through their music preferences; or they might request Apple build a facility to censor all messages travelling through APNS that mention the names of informants in active sting operations. Or they might compel Apple to build a secret CPU ring-0 elevation handshake into the A10 chip.
Even if the new generation of iOS devices was completely un-backdoor-able, and the usage of the old generation was effectively nil, that still wouldn't minimize the FBI's request. The FBI are likely much more concerned about all the orders they could give to, effectively, turn Apple's engineering talent into a domestic-surveillance consultancy.
The problem for Apple, or any other tech company, is that once you say "okay" once, you can't swat away the next one by saying "Impossible" and being done with it. You have to lawyer up. That takes time and costs money.
So Apple's real issue is that they don't want to spend many millions of dollars (billions?) on lawyers to get the FBI and other alphabet agencies to behave properly. That's a very legitimate business position. It's just a little more nuanced than what we were told on day one.
For example, the government could require Apple to build future iPhone software to permit backdoor access. The question today is whether the government can do so with a court-issued warrant, or whether it will require legislation, as it did with CALEA.
Apple can hopefully win this case based on the forced creation aspect. But they'd likely lose the next iteration where the FBI subpoenas technical documentation about the key derivation function, and builds their own hardware to talk to the hardened chip. Of course the FBI has little interest in doing this, because the whole affair is a psyop.
If you want to fully protect your customers, don't design backdoors into your products in the first place!
And Apple has done that: the type of hack the FBI is asking for cannot work on newer iPhones.
Do you have the source for that, too? I was still under the impression that the Secure Enclave would erase the keys if it's updated.
It's a pretty huge flaw if the firmware can be updated and the keys preserved without first validating with the passcode.
I also don't understand why they couldn't provide the FBI with an OS that refuses to run on anything other than the specific device in question. Isn't that the whole point of code signing?
Tim Cook today doesn't create it. Cook Tim tomorrow will.
If you think (and it's not crazy) that sometimes small, elite populations know better than the public at large, great, but please don't call that democracy.
https://en.wikipedia.org/wiki/Representative_democracy
This is what we mean when we use the word "democracy" today, unless you live in ancient Greece or some small village.
So having experts on technology,security and privacy being overruled by an uneducated mob is madness, not democracy.
If you're doing something that will attract negative political attention, mail a letter.
Even that might not help:
http://arstechnica.com/security/2015/10/how-soviets-used-ibm...
It's pretty trivial to obscure that metadata, and frankly the content of your correspondence is more important than the metadata.
Your mail has fairly robust legal protection, and you can spend more money (i.e. Registered mail) to provide a higher level of tamper evidence and accountability in transit.
Is that true? I mean, wouldn't those employees need the root signing certificate... something I suspect is very tightly protected even within apple.
By, say, breaking up its custodianship among a … finite group of human beings.
But that said I'm definitely for the stance that technology be designed in such a way to be unbreakable to Apple or anyone else once the device is sold.
> > The only way to guarantee that such a powerful tool isn’t abused and doesn’t fall into the wrong hands is to never create it.
And of course, that's also wrong. The only way to guarantee that such a powerful tool isn't abused it and doesn't fall into the wrong hands is to make it impossible for such a tool to exist, not to refuse to create it.
Right now, today, Apple has the ability to create such a tool. Some finite number of human beings at Apple have the ability to create such a tool on their own initiative, e.g. were they disgruntled.
It should be impossible for Apple, or disgruntled Apple employees, or any nation state, to create such a tool.
Otherwise, it will eventually be created, because if something is possible then is eventually probable.