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.
You don't think that the second it's been done, that the government won't attempt to reverse engineer the "firmware update" thus enabling them to do it to anyone? Regardless of whether or not it is POSSIBLE to reverse engineer it, the government will try to.
Which has more power: the hammer, or the anvil?
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.
I'm glad you're not the only one judging this then, because I have a problem with this. It would essentially mean that security could be defeated, which means it could be done by corrupt officials or corrupt Apple employees.
Sorry, maybe if Feds wanted info from the San Bernardino "terrorists" they shouldn't have shot them up and arrested them instead for questioning later using the guaranteed $5 exploit: https://xkcd.com/538/
I guess when you just gun down everyone you might lose key data!
Make sure everyone's vote counts: Verified Voting
Apple hasn't said they couldn't cooperate, they said that they wouldn't. It seems likely there is at least something they could do if they were willing to cooperate.
We hope your rules and wisdom choke you / Now we are one in everlasting peace
The problem is this is how the slippery slope is entered. Today it's a terrorist's phone, tomorrow a drug dealer's, the day after that, a shoplifter's. The day after that, arrested protestors' phones. The day after that, anyone who is arrested for any reason gets their phone swept. And so on. The Supreme Court has already said that a locked phone is protected under the 4th amendment. Just exactly where does the line get drawn on who that amendment no longer applies to?
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.
Apple actually is capable of cooperating (in this particular case), since the relevant device is an iPhone 5c (i.e. three generations old), which pre-dates the protections provided by TouchID and the Secure Enclave. Specifically, because the iPhone 5c and earlier devices lack the Secure Enclave, it means that the OS itself is what's responsible for wiping the device after too many failed attempts and for enforcing the delay between login attempts that limits the effectiveness of brute force attacks. As such, replacing the OS installed on the device with a compromised version that has those countermeasures stripped allows the FBI to engage in brute force attacks against the user's passcode.
Not so in later devices, where the Secure Enclave (which is essentially a separate computer in the iPhone with its own, separate OS and its own, separate memory) manages those features and stores the encryption keys, meaning that even if you have a compromised update for iOS, the Secure Enclave will still deny repeated attempts at logging in, along with destroying the keys after a set number of failed attempts.
The FBI is asking Apple to create a custom version of iOS (which some security experts have taken to calling "FBiOS") that is intentionally and knowingly compromised. The reason they need Apple to do it is because Apple holds the keys used to sign iOS updates. So while Apple can't decrypt the iPhone directly, they are the only ones who can create a version of iOS that allows the FBI to engage in a brute force attack against the user's passcode, which can, in turn, be used to decrypt the device.
All of which is to say, yes, Apple IS taking a stand against the FBI. Were it a later device, you might be right (though rumor in the tech press today seems to indicate that Apple is aware of a similar sort of attack which may be possible against the Secure Enclave), but this issue needs to be a line in the sand, because if the FBI can do this the implications are dire. It would mean that there's nothing stopping them from compelling private software companies to create malware versions of their software that can be used to open backdoors that otherwise wouldn't have existed. And the same legal logic that is being applied here by the FBI (i.e. the use of the All Writs Act of 1789) could be applied just as easily to compel Apple to knowingly compromise the Secure Enclave in new devices, thus creating backdoors where otherwise one would not exist. It's a broad overreach of a centuries-old law, and it needs to be stopped here and now.