Pointless posing ,, the NSA will simply have Taiwan Semi do it for them.
Maybe just a cheap movie plot...but with bammy and his cohorts in crime? I don't think there is anything they would not do.
But I thought Cook liked the back door?
Apple, and he, succeed and make humongous profits on the freedoms that we are afforded here.
The San Bernardino killers and their ilk are enemies of the US....they are bent on destroying our freedoms and everything we stand for.
It is an atrocity that Apple would allow these killers to continue their destruction of America.
I hope Cook holds steady to his position that compromising one phone compromises every phone, and that even the heinous nature of the San Bernadino terror attack does not justify compromising every law-abiding citizen’s privacy. And that applies to every other device out there.
Odd that the folks that let the media circus rampage through the killers home are now worried about evidence. If you want to catch jihadists, look at the mosques, bastions of enemy combatants hiding in plain sight. Whatever happened to the jihadi’s momma ? I bet if you waterboarded that hag she’d remember a thing or two.
Keep up the fight for terrorists’ privacy rights. Tell us how you you like jail Timmy!
Is Cook claiming. there is no way to break into this one phone without unleashing the hounds of hell and compromising the privacy of every iphone owner?
Sounds pretty far fetched.
Hey Mr. Apple, you’d do it, if I were in charge, or, your company would cease to exist and the land where your building once stood will be bare ground sown with a 6 inch bed of salt so nothing would ever grow there again for generations. Have I expressed myself sufficiently?
Take it to the Supreme Court so those schmucks can set precedent and create new law now that Alito is gone. We are so screwed.
Why not just give the Feds. the unencrypted data, and not the method for unlocking the “backdoor”? It’s a fricking dead Terrorist for heavens sake.
One would think that a faggot CEO would approve of a "backdoor" entry into one of their products.
I don’t see the problem in this case, aren’t the Perps already dead?
Cook is correct.
Anyone who thinks that the Feds would only use it on one phone is delusional
Apple should have quietly offered to help (or complied with a subpoena), put a few pointy heads on this, hopefully provided information, and then have been done with it.
I get Apple’s concern of enabling a backdoor to the device, and if I were an iPhone user would appreciate the knowing apps such as banking were as secure as possible. Apple however is failing to acknowledge that a terrorist organization declared war on America and we’re taking casualties. Lives lost just a few hours downstate - you would think that would resonate in some meaningful way with Apple.
IMO, Apple’s failure to cooperate is a concise declaration of their unwillingness to stand with America against terrorism.
Interesting to me that Cook opposes the violation of privacy here, but will at the same time heartily endorse the violation of beliefs for religious business owners who do not want to engage or work for the advancement of relationships that violate Scripture.
I wonder how different this thread would have been if Cook wasn’t gay?
Is it 1776 yet?
-—Borrowed from another thread ——
Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.
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. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can’t separate the secure enclave from it’s paired processor.
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, effectively erasing all the data on the device. 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 in the flash itself, it’s only stored within the secure enclave itself which you can’t remove the storage from or image it.
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 encryption key is also stored in ram encrypted, it can’t simply be read out of the system memory by reading the RAM bus.
The only way I can possibly see to potentially unlock the phone without the unlock code is to use an electron microscope to read the encryption key from the secure enclave’s own storage. This would take considerable time and expense (likely millions of dollars and several months) to accomplish. This also assumes that the secure enclave chip itself isn’t built to be resistant to this kind of attack. The chip could be physically designed such that the very act of exposing the silicon to read it with an electron microscope could itself be destructive.