5 ms·
Imagine a later hardline: "FBI Ordered to Reveal the Code Used to Backdoor San Bernadino Suspect's Phone"
by spdustin 11y ago
Imagine a later hardline: "FBI Ordered to Reveal the Code Used to Backdoor San Bernadino Suspect's Phone"
- Zigurd 11y agoThe accused is conveniently dead in this case. In the next case, a defendant's lawyer would surely want to inspect the instruments used to gather evidence.
- kiba 11y agoMaybe we should appoint public defenders for the conveniently dead.
- ikeboy 11y agoThe code being released wouldn't matter, because it can't be installed anywhere without Apple signing it. Presumably the keys wouldn't need to be released in any such order.
- geofft 11y agoThe code is only useful on the specific iPhone in question if it is in fact signed, and Apple does not have the technical capability to sign an update for a specific phone but not others; they all trust the same keys. And Apple would deliver it to the FBI with a signature, so there's a high risk that the signature wouldn't be redacted before being available to the public.
- ikeboy 11y agoBut the version signed could check the id of the phone and shut down if not a hard coded id. Yes, it could be installed on any phone, but it would be useless on any other phone. And in order to modify it to work on other phones (even with source code) you'd need Apple's keys.
- nacs 11y agoIt'd be easy for anyone to patch memory at runtime to skip over that `if` check on the phone's ID (or at least easier than hacking the phone without the backdoor code). Once the backdoor/exploit is created and released, there's no securing it to where it will only be used on a single phone.
- daeken 11y agoIf you could trivially patch memory at runtime, they wouldn't need this firmware in the first place -- they'd just patch out the lock-on-fail code. If you assume that the chain of trust is compromised such that memory changes can be made, you own the device.
- moyix 11y agoPatching memory at runtime on an iPhone is not in any sense "easy". If it were the FBI wouldn't need Apple's help right now at all; they could just NOP out the code that implements the increasing timeout and erase-on-too-many-failures code. To put it another way – if it were in fact easy to patch memory at runtime, there would be no need for the jailbreak community to spend huge amounts of time and effort every new OS release.
- geofft 11y agoYou're right, that's a good point.
- ikeboy 11y agoAlso, Apple does have the ability to prevent signed updates from being installed on phones they don't want it to be. Every update must be signed by Apple specifically to the phone that's being updated, and this includes a nonce to prevent replay attacks. (I forgot about this in my reply above). See https://en.wikipedia.org/wiki/SHSH_blob https://en.wikipedia.org/wiki/SHSH_blob, https://www.theiphonewiki.com/wiki/SHSH https://www.theiphonewiki.com/wiki/SHSH, http://www.saurik.com/id/12 http://www.saurik.com/id/12
- ericcumbee 11y agoAre you sure that is the case? Or is that the Case for Iphone 5C and earlier? I remember listening to the Security now episode where they discuss the IOS Security model and it worked something like. 1)Apple Sends A notification that an update is available. 2) the Phone sends a request with certain identifiers for the update. 3) Witchcraft happens 4) Apple sends a update signed specifically for that device and it will work on no other device. Like I said that might be for 5c and older or I might have completely invented that.
- ikeboy 11y ago3GS and later introduced SHSH blobs. See sources I linked to in https://news.ycombinator.com/item?id=11141965 https://news.ycombinator.com/item?id=11141965 Every update is signed specifically to the device being updated.
- jsprogrammer 11y agoIf you are referring to the software Apple is building to circumvent their kill switch, I don't believe Apple is required to give the FBI access to the software.
- mpitt 11y agoRelated: http://www.zdziarski.com/blog/?p=5645 http://www.zdziarski.com/blog/?p=5645