Hacker News new | ask | show | jobs
by pluckytree 3767 days ago
Why can’t it be leaked? The software needs to be created and installed on the device. Even if it’s entirely in Apple hands, there’s no guarantee it will ever be leaked.

It wouldn’t need editing. It’s intended to disable the timeout when brute forcing passwords. It’s incredibly dangerous software to even exist. And also insanely valuable. Even more incentive for someone to leak it, even at Apple.

2 comments

The software would only disable those features on that specific device, which would be hard coded. Even if you moved the software to another device, it wouldn't work. Even if you had the source code, and modified to work on a different device or all devices, you wouldn't be able to do it unless Apple signed the modified software as well.
It's not clear to me at least that the phone identifier they would be hard-coding into the build is actually designed to be a cryptographically secure and unalterable identifier protected by the secure enclave. Well the 5C has no secure enclave anyway so how is this ID secured?

If you can reprogram or electronically intercept and alter the ID as it is read by the firmware, the backdoor build could be run on any phone.

For example if it is tied to the UDID, the UDID = SHA1(serial + ECID + wifiMac + bluetoothMac). Here's an article where Apple says the ECID is alterable through the BPP (Baseband processor) [1] so perhaps exploitable by connecting to a BSE and hacking the BPP via LTE vulnerabilities. The serial number, WiFi and Bluetooth MACs can all be altered as well. So I'm not convinced UDID locked builds cannot be worked around by a motivated adversary.

Heck, finding a SHA1 hash collision by altering only the most easily set MAC addresses is computationally feasible and costs less than $1 million!

[1] - http://www.infoworld.com/article/2631100/mobile-security/app...

It's shocking to me that people who ostensibly know something about software development are comfortable making statements like "it would never be able to leak because Apple can simply write a (bug-free, unexploitable, perfectly secure) set of checks locking it to the device"
It's shocking to me that people who ostensibly know something about software development take Apple at their word in this case.

Apple already has the backdoor.

Are you willing to guarantee that Apple will never lose control over their signing keys, giving whoever acquires them the ability to end-run the security of a locked device and install software that you, the device owner, are sandboxed from inspecting?

> Are you willing to guarantee that Apple will never lose control over their signing keys, giving whoever acquires them the ability to end-run the security of a locked device and install software that you, the device owner, are sandboxed from inspecting?

No. But this doesn't mean I don't think there's ALSO harm in the FBI or any government agency being able to demand companies build tools that expand the use and usability of that backdoor to parties beyond the company holding the key.

It sucks that Apple has a one ring when it comes to iOS security. It's incredibly dangerous if a government can require them to wield that one ring for arbitrary purposes via a contortion of the All Writs Act. And it's just plain stupid for software professionals to base their opinions on a belief that anyone is capable of writing an unexploitable check for device identity.

The FBI or any other government agency has always been able to demand companies do exactly this.

It was the height of naivety to think otherwise; it's not like we lack historical examples of what happens when a small number of companies make themselves the linchpin of trust/security:

https://en.wikipedia.org/wiki/Communications_Assistance_for_...

https://en.wikipedia.org/wiki/Room_641A

Prior to this event, I had no idea that this generation of programmers seriously thought they could centralize so much information and control into their own hands, and somehow keep it out of the government's hands when they eventually came knocking.

Even if Apple wins this argument, they'll have to keep winning every argument, every network intrusion, every espionage attempt, forever. This particular argument is pointless; the high-value-single-point-of-failure security model is fundamentally flawed.

The risk footprint is rather limited at this point, that much I trust. Each step in the sequence required to arrive at a compromised version of iOS that behaves the way FBI wants, is a step that increases the risk footprint for Apple and everyone with an iOS device. We could argue the size of this expansion, but we can all agree it is non-zero. And by definition trust is lost in proportion to that increased risk footprint.

I think that's an unreasonable burden on any company, but including users. This isn't just limited to Apple. Any company signing code is at risk of being asked to apply digital signatures to the code equivalent of malware, and to the free speech equivalent of falsehood. No.

Your argument is no different than the arguments that claim crypto backdoors can be kept secure. The problem is the existence of the backdoor, not the processes or politics that ostensibly will prevent its abuse.

Apple could ship encrypted backdoored binaries under an NSL gag order tomorrow, might not even know it themselves, and we'd never notice because we can't even introspect the device. In a few years, the federal government could extend CALEA to cover Apple, and there'd be little we could do because we can't override Apple's control over the software.

The security model is flawed; it requires Apple to fight and win every argument, every battle, every espionage attempt, in our favor, forever. The longer we propagate this security myth that putting absolute trust in the hands of the few is a viable security model, the worse things will be when it fails.

In the meantime, complying with this legal request doesn't meaningfully move the risk needle. The risk already existed. All it does is force Apple to admit that they hold a backdoor -- something they obviously are loathe to do, as noted by the US Attorney when she was forced to submit an additional court filing responding to Apple's public, calculated attempt to define the public debate before even responding to the court.

That's a good point. The unique device ID is baked into the hardware, but it doesn't look like it can be read directly, so it might not even be able to put in logic based on the ID into the firmware anyways.
Even if the original software was built to work only one device, if it's ever leaked it provides a roadmap for targeted attacks which may apply similar workarounds though other means than the update path.
I would imagine the difficult part would not be writing the firmware (or rather, the changes), but code signing it.
It could be leaked but if properly designed it just wouldn't work on other devices.

If you mean that Apple could leak it, that isn't a real risk. There is already a risk that Apple has it's key that it signs updates leak. If that leaks anyone can write the modified software.

Apple should just write the modified software to only work on that specific iphone (by serial number).

The software already exists. You just have to lightly modify the existing software to turn off security features. The problem is that we don't have apple's key.

The problem is, Apple has to fight this now because once they've done this once, they're in a losing position when the government wants it done 800 more times.

Right now, Apple can argue undue burden. Someone needs to sit down, nop out a bunch of security measure in an older branch of iOS, add boot and installation tests that lock it down to a particular serial number in a way that isn't vulnerable to any easy spoofing, test it all, and finally sign it.

If they do all this now, the second time the FBI shows up at the door Apple can't decide to then start arguing undue burden. Any government lawyer could win the argument that Apple already did all the heavy lifting, and that merely changing the serial code checked for could obviously not now constitute an undue burden on the company.

Once they've started down this road it's just a slow frog boil of "obviously not undue burden" small changes to "here's a list of 500,000 potential terrorists whose data we may need to access. Push an OTA update to them that has bypassable security"

>The problem is, Apple has to fight this now because once they've done this once, they're in a losing position when the government wants it done 800 more times.

Since each of those 800 times will used after court issued a legal warrant, that is actually good.

Suffice to say, we appear to be operating off of entirely incompatible definitions of "good"
Which countries will be issuing these good warrants? All of them?
All except the bad ones. They'll be prohibited by statute from taking advantage of any of this.
That is until they for torture someone to get around it.