Slashdot Mirror
Edward Snowden Calls For Google To Side With Apple On Encryption Debate (techinsider.io)
An anonymous reader writes: Edward Snowden, the most famous whistle blower in the world, is calling for Google to side with Apple and against the FBI in the "most important tech case in a decade." On Tuesday, the FBI asked Apple to help it crack the password on an iPhone belonging to a shooter in the high profile San Bernardino case. Apple CEO Tim Cook quickly responded with a public letter denying the request, calling it "an unprecedented step which threatens the security of our customers." Google creates Android, the most-used mobile operating system for smartphones in the world. Google has been nowhere near as firm as Apple about its stance on un-compromised encryption - Android is famously an open sourced platform that anyone can modify. Snowden issued his message in a tweet.
I don't have a problem with the specific thing that Apple is being asked to do. They aren't being asked to break the encryption they are being asked to change the firmware on the device to one that doesn't have an artificial throttle on the number of brute force attempts per second; and to disable the wipe command that is engaged with 10 wrong guesses.
My question is a side one. Apple has described that for every secure enclave in its iPhones (region of the core processing chips), they inscribe a unique ID -- completely unknown and irretrievable by Apple or its suppliers -- that serves as a private key during encryption operations. This way you cannot unlock an iPhone's contents without the correct passphrase/passkey and the phone's unique ID in your possession.
How does a chip manufacturer inscribe a unique code into every chip? As I understand it, chips are produced by successive masks (film) with the circuit pattern layered on each mask.
Is one of the masks getting printed with the unique set of codes? Are the masks printed and changed with every wafer, after the unique codes are changed and discarded? Seems like a very intense way of having to put a unique code on each chip.
Or, if you remember film cameras from like the 80s/90s, where they could burn a date into the corner of the negative, do IC making masks have the ability to dynamically burn a changing code during exposure of the wafer??
Thanks for any knowledge you can offer on this point!
It seems more that Apple cannot cooperate, which is what will keep the FBI from storming their facilities in the long run; their "unwillingness" to cooperate is simply cheap PR riding on the back of their inability to do so.
Don't get me wrong, their inability to cooperate is a good thing, it means they don't have a backdoor, nor do they mirror keys without user knowledge. Spinning it as them standing up to the FBI, rather than facts and science doing the same, is just hilarious, though.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Just to reiterate a point - the phone in question is an iPhone 5C which doesn't have a secure enclave. A7 SoCs and above with the secure enclave do all the PIN verification in hardware, enforcing the timeouts and the 10 incorrect guess wipes. But since the iPhone 5C doesn't have this, it's a software check that does it. (However, it doesn't mean Apple can just load on a new firmware update to a locked phone - doing so could wipe the phone as well).
So it is theoretically possible to write code that allows unlimited guesses. Whether or not you can load it on a phone is another question altogether (and I wouldn't be surprised if you couldn't without wiping the phone).
As for the SoC part - no, they don't pattern the masks with the ID. What happens is in practically every SoC in existence, there is a bit of memory that is one-time programmable. Effectively, it's an array of fuses (we call them fuses, but in reality, they're antifuses). You can blow the fuses which often sets various configuration options (e.g., blow one fuse, and the JTAG interface is disabled, blow another fuse, and you disable some block, or half the cache or whatever). You can also blow fuses that have special properties - e.g., a memory area that cannot be read by software, but hardware can access it. This is often done by initial programming software - you program in a serial number and the software blows the right fuses for that serial number. That software can also generate the hardware keys for encryption - by generating a random key using the key generator block (usually a random number generator) of the cryptographic engine, then using that to blow the key fuses. If the software doesn't report the key to the manufacturing hardware, then no one knows the key, not even Apple.
OTP fuses can be blown during the hardware test phase of chip production as well. Special pads on the die that aren't brought out of the package can be used to access and blow the OTP fuses. This is typically done for the unique identifier portion
For small lots, it's often easier to do it in software during production - customers will buy chips with areas of the OTP unblown to which they can use vendor-provided tools to blow them. Larger runs can be blown at the factory.
The OTP array is not strictly a 2D array of fuses - there's metadata like a valid bit (the row of memory is programmed - used by boot firmware to determine if it needs to engage the encryption unit), a lock bit (to prevent bits from being written - stuff like serial numbers and unique IDs will have the lock bit blown to prevent people from blowing fuses in that row and changing the ID), the bits themselves and special wiring that connects each bit with the appropriate piece of hardware.
I believe that this is possible. Further, before you mount the die, during the automated testing phase you could easily allow the test unit to make connections to the die in order to allow programming of the nonvolatile areas, then "blow the fuses" by application of specific voltages/currents so the device cannot be modified using the same process ever again. If you use a random enough data source for setting the key, it will be logically impossible to do anything but brute force the key.
Of course, it is all academic. If you have access to the physical device, it should be possible, though likely very difficult, to determine what you need to know to access the data on the phone, even without the pin. At the very least, one should be able to attach to the device, dump the encrypted content, duplicate it onto a emulated device and brute force the pin without having to worry about busting the original phone. Apple could do this if they wanted but it's going to take internal knowledge of the device's design and the software that runs it. I don't see this being dangerous to privacy as it's really just an attack that is going to require extended physical access to the phone by an army of people who are equipped with the necessary hardware, software and tools along with the necessary technical data. Surely Apple can do this for ONE phone.
My guess here is that if the FBI really wants to do this, they can easily force Apple to release the necessary technical data with appropriate NDA's and hire it done. My guess is they don't want it that badly but they will do what they can to hold Apple's feet to the fire by asking the judge for sanctions given his orders are not being followed. Apple may eventually find themselves in some seriously uncomfortable situations if they truly mean to press this.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Just the fact that Apple is being asked to DECRYPT a phone tells you it can be done.
Your shit is not secure, and never was on OSX/iOS.
"If any question why we died, Tell them because our fathers lied."