Hacker News Reader

Comment by spdustin | Hacker News Reader

Imagine a later hardline: "FBI Ordered to Reveal the Code Used to Backdoor San Bernadino Suspect's Phone"

The 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.

Maybe we should appoint public defenders for the conveniently dead.

If 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.

The 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.

The 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.

But 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.

It'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.

If 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.

Patching 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.

You're right, that's a good point.

Also, 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://www.theiphonewiki.com/wiki/SHSH, http://www.saurik.com/id/12

Are 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.

3GS and later introduced SHSH blobs. See sources I linked to in https://news.ycombinator.com/item?id=11141965

Every update is signed specifically to the device being updated.

Reply on news.ycombinator.com