Doesn't the fact that Apple is capable of unlocking the phone mean that a backdoor already exists ? Then it's just a question of a lone wolf telling the FBI how to do it, maybe along with using some secret keys that could be stolen if Apple is hacked like Sony was. I would like a phone that is unhackable even by its creator. Anything else is just a question of time to get broken into.
It all depends on how you define a backdoor. The 5c doesn't have the secure enclave†, so all of it's encryption routines are done in the CPU, as software/firmware.
That software doesn't contain a backdoor, but the fact that a new software load could be created and installed could be viewed as the backdoor itself. But if that software doesn't currently exist, is the mere potential of it a backdoor? Somewhat of a philosophical question.
If Apple prevails and doesn't write the software the FBI is demanding, then the backdoor is not there.
The later iPhones with the Secure Enclave may truly be unbreakable if they protect their secrets with hardware in the chip.
But my understanding of it is that Apple is NOT capable of unlocking the phone right now. The FBI is demanding that they develop that capability. So I guess they're capable of being capable...
How would a backdoor look? Some secret additional encryption key capable of unlocking the encrypted data?
Such a key exists, and it is whatever key Apple uses to sign the iOS updates. Only Apple can sign a new iOS release, so only Apple can update the code to remove all security features. This looks a lot like a backdoor to me, just that the implementation hasn't been written. But all you really would need, in theory, is the signing key.
From the Judge's request and Tim Cook's response, it looks like the updated OS with the backdoor would no longer wait after each passcode try, and would allow inputting a passcode through WiFi. That allows remotely bruteforcing the passcode.
I would guess that that passcode encrypts the phone, which is why they can't decrypt it.
There's probably more to it (otherwise, they could copy the encrypted data elsewhere to bruteforce it, in which case it would all be a show from the FBI and their real target is other phones).
I'll agree that the ability to update the firmware without the phone being unlocked is poor design on Apple's part. Given the security flaws they've had in the past, this one seems genuine.
You make a very good point: why do they even need to update the firmware? Surely, just cloning the phone's encrypted memory should be possible? (I have no knowledge of hardware at all, but I would have thought that the data is stored on a memory chip somewhere in a phone, and it should(?) be possible to copy the data from that chip to process it offline?)
In some of the other threads on this topic there were very many explanations why that is not possible.
At root of it is that even with a flash memory image, brute-forcing AES-256 is impossible. And the key is key fused into the processor and no software or firmware can read it directly.
They are capable of unlocking the phone. There is no philosophical question about this, as they have the knowledge and the ability and the authority.
That it might take some expertise and effort is not really relevant - some is required in any case even if the firmware already existed, so its just a matter of scale. For example I know several people who could not update a phone firmware without supervision, and probably some who could at a stretch (given massive time and resources) reverse engineer it. Apple firmly occupy the sweet spot in this range, they have the secret knowledge that would otherwise have to be reproduced and it would be a bit of effort to build on this but not huge. Changing a bit of code [to remove the delay] and rebuilding a binary image is not a complicated task for their engineers, it is likely something they do all the time.
Personally, I think they should just do it if they are legally compelled to do so. They have done in the past and this is an older device and in 5 years the issue will be moot, as any firmware they create now would be useless.
>Personally, I think they should just do it if they are legally compelled to do so. They have done in the past and this is an older device and in 5 years the issue will be moot, as any firmware they create now would be useless.
If they do it now, they the point will indeed be moot in 5 years, not because of technology, but because it will be required of them to make sure they can do this to ALL iPhones.
> Personally, I think they should just do it if they are
> legally compelled to do so. They have done in the past and
> this is an older device and in 5 years the issue will be
> moot, as any firmware they create now would be useless.
If they lose this lawsuit they will be forced again and again to build backdoors into their own systems. It's a very unreasonable request that does not find the right balance and the reasons are laid out eloquently in Apple's letter.
Only Apple is able to sign iOS updates. The FBI wants Apple to make an Evil Update and sign it with their key so the phone will accept the update. Apple has to hold the signing key so the phone can reject Evil Updates in general.
Does this count as a "backdoor"? It's built into the way signed updates work. Nobody stole Sony's master signing key for the PS4, even when their entire network was pwned. They're probably stored offline in specialized hardware.
(as I understand it, newer iPhones use crypto magic + special hardware to make it arguably impossible to update the phone while it's locked, so they're more secure against Evil Updates, even ones signed by Apple)
Mostly because they would need Apple source code and toolchain, too, and dozens of coders willing to make evil updates. Of course they could get those, too. But imagine what an expensive botch some "security contractor" would make of the project of crafting evil updates for the FBI. They would probably be found out and publicly humiliated, and there would be a terrible trust hit to the whole tech industry.
For apple to do it,they have to make some signed software that can then be installed to the phone as an update which then allows the crack. If this is considered a back door, then everything that will accept signed updates has that same backdoor, which is a lot of things.
Theoretically yes,a lone wolf plus the FBI could do it, but they would need to get the software they make signed by Apple or steal the key to make it appear so, which would not be simple.
The big issue is that once it is signed by Apple, it could then be used to crack any phone it was installed on as a trusted update, which it is because it was signed.
Except the order notes that Apple should lock the update to only function with that phone. It also allows them control of the hardware if they choose, provided they turn over the data.
The more I've heard about this the more it seems like cynical grandstanding for marketing purposes: Apple don't want regular people fiction to become "Apple can always unlock your phone".
As has been said many times over, this is setting a precedent where the FBI can ask Apple to do this again, with the software already created. The "only function with that phone" is a negligible hinderance to using this on another phone.
And it would only work for that specific model of phone. And to do so the FBI would have to have a public warrant for the search, granted by public courts. What exactly is the problem with that power? It's the same as one which lets them search your home.
Apple goes to the effort of designing the software to be secure to the point of inaccessible, even when Apple is asked to work against the user, so it's a selling point. If the FBI is known to be able to get into a secure phone it commercially affects Apple.
Why would it only work for that model of phone? Why would iOS vary its repeated attempt lock out code between models?
Also another issue is that Apple are questioning whether this warrant was ever legal to exist.
It appears that the firmwire of the Secure Enclave can be updated with the Apple private key. It isn't iOS, but for the purposes of this, it might as well be.
The Evil Update could just refuse to function if it's being used on a phone with a different IMEID. You wouldn't be able to remove the check without breaking the signature, so it wouldn't be possible to use it to hack any other phone.
Sure - until you realize IMEI is a baseband ID and you can desolder tha baseband IC and use it on all phones you need access to. Heck - you can probably just intercept and change the output of 'get IMEI' command - it's not like the communication between those chips is protected by crypto (only baseband firmware upgrade uses crypto)
> If this is considered a back door, then everything that will accept signed updates has that same backdoor, which is a lot of things.
Yes.
So.. we should think about that and make it so that the keys are stored in a box which cannot be broken into. I think Apple have been working on this, but it is not clear that they are yet successful.
The pin is so short (4 or 6 digits) that if you can remove the 10 tries limitation and time escalation (Apple can with a new firmware) it's a matter of time to hack the phone (22 hours. 80ms [1] per attempt * 10^6 pins). It seems a farce to me that Apple says that they can't decrypt it (or maybe they never said that?). With a stronger pw it would be a different story though.
that is correct for a 6 digit pin, of course if you used an alphaumeric passcode it would take much longer. brute force 8 characters would take millions of years, though in practice you could significantly reduce the search space in typical password cracking ways (word lists, etc) but never the less.
the takeaway is that you should use a much more complex password.
At 80ms per attempt you need 3 months to brute force an 8 pin password. Things get ugly soon btw, 9 characters 2.5 years, 10 characters 25 years and so on. We reach millions of years at 15 characters
edit: I was calculating on the assumption that you can only use numbers as a pin
It's a backdoor like a bank vault wall is a backdoor. It is entirely a shield so far, with no actual vulnerability in itself, but in the meta it can be replaced.
