Slashdot Mirror
Apple Court Testimony Reveals Why It Refuses To Unlock iPhones For Police (dailydot.com)
blottsie writes: Newly unsealed court transcripts from the U.S. District Court for the Eastern District of New York show that Apple now refuses to unlock iPhones for law enforcement, saying "In most cases now and in the future, the government’s requested order would be substantially burdensome, as it would be impossible to perform." “Right now Apple is aware that customer data is under siege from a variety of different directions. Never has the privacy and security of customer data been as important as it is now,” Apple lawyer Marc Zwillinger said at the hearing. “A hypothetical consumer could think if Apple is not in the business of accessing my data and if Apple has built a system to prevent itself from accessing my data, why is it continuing to comply with orders that don’t have a clear lawful basis in doing so?”
One U.S. attorney argued that it was "more concerned with public perception" than helping catch criminals.
Duh? No shit? That's not Apple's job, dipshit. They're not here to make your job easier, stop being a bunch of lazy jackasses.
For one, I love the fact that Apple is saying "fuck you" to the cops.
On the other hand, it shows the power of multinational corps - they're above the law. Meaning one day, they may do me or others some serious harm and get away free - like Wall Street did.
And as far as my personal privacy is concerned, neither can be trusted.
People and companies will stand up to the government all the time, if there is profit in doing so.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
spend a week cracking the data
How do you propose to do that?
If you assume:
Every person on the planet owns 10 computers.
There are 7 billion people on the planet.
Each of these computers can test 1 billion key combinations per second.
On average, you can crack the key after testing 50% of the possibilities.
Then the earth's population can crack one encryption key in 77,000,000,000,000,000,000,000,000 years
http://www.eetimes.com/documen...
Anyone who thinks AES 256 (what iPhones are encrypted with) can be cracked by any computer doesn't understand the math.
That's not to say there aren't potential successful ways to get the information besides brute forcing. I just get a little chuckle out of every time somebody suggests governments have magic computers. Yes, I'm aware of quantum computing and exactly how far along the tech has come and no, it isn't something that anybody has yet. The magic quantum encryption cracking system is still *at least* a decade away. (It may never happen, and if I were guessing, I'd put it at closer to a couple centuries away, but even assuming impossible breakthroughs have already been made, a decade is unreasonably optimistic.)
I've worked in a few corporate environments where they were extremely paranoid about e-discovery (back when this was a new thing.) Almost always, the answer was to set the retention policy to 30 days, as in, no email backups older than 30 days, no (sanctioned) way to archive email, and everything older than 30 days was purged from mailboxes. This allowed the company to say with a straight face, "I'd love to give you the messages relevant to such-and-such business deal gone bad 5 years ago, but I simply cannot."
It sounds a lot like what Apple's doing -- they purposely built the encryption system with no way to bypass it so they can push it right back on the police and courts -- "Sorry, can't help you!" That gets them tons of great customer PR, as opposed to Google/Android, so it makes sense.
I think the statement reads oddly out of context because the case is about an iOS7 phone, where it's not 'impossible' (only burdensome) yet warning them that it will be impossible in the future. They're afraid that un-encrypting it now, just because it's not 'impossible' will mean that in the future they might be forced (by law) to make it possible, so they're arguing that they shouldn't have to do it, even now that it's only 'burdensome'.
It's long, but that transcript is really worth a read. First the judge thoughtfully skewers every argument the government presents, and tries to get to the fundamental principles involved. Then he thoughtfully skewers every argument Apple presents and tries to get them to throw away all of the marketing nonsense and just say what they think the actual issues are. Then he takes it all into consideration and says he'll go try to find the proper balance in his ruling.
No matter how that case comes out, that's one judge who is doing his job.
Correct, you do not know much about how iPhones work but it didn't seem to stop you from speculating.
If you want to learn how the encryption works, see this explanation.
Yes, it does use dedicated cryptography hardware. Yes, the key is protected from the rest of the OS.
ah, putting words into Apple's mouth is so much fun. Of course, they never said any such thing. Instead, as you could read from the quotes above, they say that they believe in the customer's privacy. You aren't playing devil's advocate, you are willfully misrepresenting Apple's position.
Nice strawman, btw
Maybe, just maybe, because that backdoor provides a vulnerability that can be hacked. One less complication in the system means at least one less vulnerability to be exploited.
You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave.
Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers.
The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.
The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.
The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.
Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored on the flash itself, it's only stored within the secure enclave itself which you can't remove the storage from.
Each boot, the secure enclave creates it's own temporary encryption key, based on it's own UID and random number generator with proper entropy, that it uses to store the full device encryption key in ram. Since the encryptio