3 ms·

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

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.

zaroth 11y ago
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/apple--iphone-jailbreaking-could-knock-out-transmission-towers.html http://www.infoworld.com/article/2631100/mobile-security/app...
- tedhogan 11y ago
  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.
- msbarnett 11y ago
  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"
  - teacup50 11y ago
    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?
    - msbarnett 11y ago
      > 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.
      - teacup50 11y ago
        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_Law_Enforcement_Act https://en.wikipedia.org/wiki/Communications_Assistance_for_... https://en.wikipedia.org/wiki/Room_641A 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.
digikata 11y ago
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.
- duaneb 11y ago
  I would imagine the difficult part would not be writing the firmware (or rather, the changes), but code signing it.
deleted 11y ago
[deleted]

zaroth 11y ago

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/apple--iphone-jailbreaking-could-knock-out-transmission-towers.html http://www.infoworld.com/article/2631100/mobile-security/app...

tedhogan 11y ago
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.
msbarnett 11y ago
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"
- teacup50 11y ago
  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?
  - msbarnett 11y ago
    > 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.
    - teacup50 11y ago
      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_Law_Enforcement_Act https://en.wikipedia.org/wiki/Communications_Assistance_for_... https://en.wikipedia.org/wiki/Room_641A 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.

digikata 11y ago

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.

duaneb 11y ago
I would imagine the difficult part would not be writing the firmware (or rather, the changes), but code signing it.

deleted 11y ago

[deleted]