Can someone explain the whole FBI-Apple debate? I don't understand Apple's argument about a universal backdoor being created. From what I've read it seems that Apple is just full of shit, if alternative firmware is created to bypass the security it would only bypass it on any device with that firmware, which would be only that device. All the encryption keys are stored somewhere in iOS itself since it's an older iPhone, meaning the security won't be affected except on that device.
I do sympathize with the argument that the government doesn't have the right to force the software to be created, I just don't understand the technical part that Apple is protesting.
The FBI wants to set a legal precedent where they can use the courts to force companies to break their own encryption.
>>53756201
This > >>53756300
Also the FBI like any US authority is less than clean and the knowledge of an exploit backed by insider Apple knowledge will spread to rogue operators both inside the FBI and outside.
That would also give power to anyone else wanting the same request that was granted to the FBI such as foreign countries which could have a poor Human Rights standards or other poor civil standards.
Other obvious point is Apple don't want to be in the business of unlocking encrypted mobile phones for other cases for any authority in the US be that the FBI or regular police.
If that case successfully force Apple to unlock the iPhone for that one case there would be many more cases which would likely be approved due to similarities to the first case that was approved.
Also if the iPhone's security was unlocked it would devalue and ruin people's confidence in the security of the iPhone which is a major selling point for those devices.
If those devices wasn't secure Apple wouldn't be able to compete with Android phones with how the iPhones are at the moment in terms of hardware.
>>53756201
>Can someone explain the whole FBI-Apple debate?
>>53756748
Correction.
>Jewgle
>Muslims: boom!
>FBI: Hey Apple, we can't crack this iPhone without losing data that stops terrorists
>Apple: Go pound sand.
>FBI: You love terrorists that much?
>Apple: Look, are you going to buy something or just stand here all day?
>FBI: Nevermind, we cracked it without you.
>Apple: Really? Tell us how so we can fix that vulnerability.
>Muslims: boom!
>FBI: Maybe they'll fall for it THIS time.
>>53756201
https://www.youtube.com/watch?v=MG0bAaK7p9s
>>53757127
Is that actually true, or is it a simplification?
>>53757127
http://arstechnica.com/security/2016/03/john-mcafee-better-prepare-to-eat-a-shoe-because-he-doesnt-know-how-iphones-work/
>>53756201
>Can someone explain the whole FBI-Apple debate?
It's a golden opportunity for people who can't be bothered to read the facts to attack Apple.
The FBI set up a contrived situation purely to create a precedent. Once Apple turned them down and didn't fold under pressure, the FBI found another way out.
We'll probably never know if they did crack the phone and if they did if there was anything on the phone that justified their actions.
>>53757170
This is pretty accurate, though it might take slightly more effort than he makes it out to be if they've obfuscated their code enough.
What the FBI wanted Apple to make was an over-the-air update that would disable the "too many bad tries" lockout so they could guess loads of PINs. They could push this to this phone and attack it pretty easily. Apple's complaint about it was that it could (and would) be used on any other same generation iPhone they wanted to crack. There'd also be the chance of this modified firmware getting into the wild and being used by Tyrone to unlock his stolen iPhones.
Apple could go a long way to make this harder by disallowing OTA upgrades while the phone is locked. There'd still be the possibility of desoldering the flash chip from the board and flashing new modified firmware onto it like that, but various hardware-based security functions could help prevent this. If they wanted to go all the way, they could put the encryption functionality inside the same chip as the flash memory. Try a PIN, it gets sent to the chip which then either uses it to decrypt anything accessed from the chip on the fly, or rejects it. Too many bad PINs and the chip erases the flash inside itself.
>>53757414
I was more on Apple's side until I started reading the facts of the case. The whole notion that it's a universal backdoor seems like utter bullshit.
>>53757233
>The core claim, the part on which everything else hinges, is that there is a location on the iPhone's flash storage (or perhaps RAM; he uses "memory" pretty interchangeably for both) that contains a plaintext, readable copy of the device's PIN, and that iOS compares the PIN typed in to this stored value.
This is where Ars goes full retard. McAfee might not have explained it as well as he could have while dumbing it down for normies. Of course the plaintext PIN is not stored anywhere in RAM. What the FBI wants to do, and presumably what McAfee would do, is find an instruction that increments a variable after each bad PIN attempt, or a check for whether this count is high enough to trigger a 30 minute lockout, or possibly find the 30 minute time figure and change it to 0 seconds.
The goal is not to extract the PIN, it's to make the phone accept unlimited amounts of bad guesses so the FBI can connect it to something that guesses millions of PINs very quickly.
>>53757443
I was reading about having the phone enter DFU mode. Would the method of getting the new firmware on the phone be overair? I was under the impression it would be put on locally.
>>53757553
How does one change it?
>>53756201
So Jeremy Irons was in Lolita? I'd totally watch that if it was James Woods instead. James Woods is great.
>>53757569
What I'd read about the FBI's request to Apple seemed to imply they'd send it as an update.
Either way, there's no reason that a locked phone should accept either an OTA update or a request to go into DFU mode without first being unlocked.
>>53757582
Find the instruction(s) responsible and change them to nops or other instructions that don't limit the number of bad PIN tries.
But if Apple was clever, they probably have a signing check on this bit of firmware so it won't load if it's modified by anyone other than Apple. However, there are a couple possible ways around this:
- Exploit or bypass the signature check in some way. May be as simple as modifying another bit of code to disable the check or replace the key it's validating it against with one you create and can sign your modified code using.
- Get someone really good with soldering tiny things. Put 2 flash chips, one with the original firmware and one with your modified one. Use a timer to switch between them. After the linear scan over all data in the modified piece to check the signature, switch to the other chip that has your modded one. Or maybe it loads it into RAM once and then checks the signature on that, in which case you can manipulate the RAM chip to control its contents after the signature check.
- Figure out the precise number of clock pulses between entering a bad PIN and the bad PIN count being incremented. At that precise time, disconnect the write-enable line to the RAM and/or flash chips to prevent the changed value of that variable from being written.
