3 ms·

Seems pretty clear how they do this -- booting the device off an Apple-signed image which just extracts unencrypted data and exports it. (I suppose it's possib

by rdl 13y ago

Seems pretty clear how they do this -- booting the device off an Apple-signed image which just extracts unencrypted data and exports it. (I suppose it's possible there's some weird signed-apple-driver way to do this on a running phone, too.) Only Apple can do it because only Apple can sign an evil bootloader like this. There is a lot of room to improve the iOS security model against Apple/USG threats, but otherwise, it's still pretty good. A non-Apple-friendly intelligence agency would still probably be better off attacking the actual security element; DPA, physical attacks, etc. should be able to pull the key. I'd estimate this capability would cost $10mm to develop and maybe $10k per device to attack, which would be great if you knew your adversaries used iPhones. The biggest ongoing risk I see is that Apple could push an "evil" OS update to specific users if it wanted; if it can get the users to install it, all the hardware protections are irrelevant; you just get the user to enter the passcode, decrypt, exfiltrate. Solving that problem is really difficult without somehow having your own organization handle all OS updates.

matthewmacleod 13y ago
Seems pretty clear how they do this -- booting the device off an Apple-signed image which just extracts unencrypted data and exports it. (I suppose it's possible there's some weird signed-apple-driver way to do this on a running phone, too.) Only Apple can do it because only Apple can sign an evil bootloader like this. That would seem correct. However, given that some of the data on the device is also encrypted by a derivation of the passcode, this limits the scope of data which could be retrieved. A non-Apple-friendly intelligence agency would still probably be better off attacking the actual security element; DPA, physical attacks, etc. should be able to pull the key. I'd estimate this capability would cost $10mm to develop and maybe $10k per device to attack, which would be great if you knew your adversaries used iPhones. I expect you'd need physical access, and indeed that you'd probably need to uncap the AES chip to retrieve the UID - barring any unknown vulnerabilities. Possible, but destructive and not cheap The biggest ongoing risk I see is that Apple could push an "evil" OS update to specific users if it wanted; if it can get the users to install it, all the hardware protections are irrelevant; you just get the user to enter the passcode, decrypt, exfiltrate. Solving that problem is really difficult without somehow having your own organization handle all OS updates. That's the problem. The secure boot chain gives Apple ultimate control over the software on the device, and that requires trust.
- rdl 13y ago
  On #2, if you were Ministry of State Security, you could also use 0-day code execution to gain the same data the Apple process retrieves. I guess existence-of-0-days is pretty reasonable, but I'd rather build the repeatable physical attack, as I could then pull a lot more than just Dkey, and do it forever. (I'm more interested in the "built an enterprise-root-of-trust mobile platform", but "build an awesome, repeatable attack against everything" is also pretty tempting, if only to sell the former.)

by rdl 13y ago

matthewmacleod 13y ago

Seems pretty clear how they do this -- booting the device off an Apple-signed image which just extracts unencrypted data and exports it. (I suppose it's possible there's some weird signed-apple-driver way to do this on a running phone, too.) Only Apple can do it because only Apple can sign an evil bootloader like this. That would seem correct. However, given that some of the data on the device is also encrypted by a derivation of the passcode, this limits the scope of data which could be retrieved. A non-Apple-friendly intelligence agency would still probably be better off attacking the actual security element; DPA, physical attacks, etc. should be able to pull the key. I'd estimate this capability would cost $10mm to develop and maybe $10k per device to attack, which would be great if you knew your adversaries used iPhones. I expect you'd need physical access, and indeed that you'd probably need to uncap the AES chip to retrieve the UID - barring any unknown vulnerabilities. Possible, but destructive and not cheap The biggest ongoing risk I see is that Apple could push an "evil" OS update to specific users if it wanted; if it can get the users to install it, all the hardware protections are irrelevant; you just get the user to enter the passcode, decrypt, exfiltrate. Solving that problem is really difficult without somehow having your own organization handle all OS updates. That's the problem. The secure boot chain gives Apple ultimate control over the software on the device, and that requires trust.

rdl 13y ago
On #2, if you were Ministry of State Security, you could also use 0-day code execution to gain the same data the Apple process retrieves. I guess existence-of-0-days is pretty reasonable, but I'd rather build the repeatable physical attack, as I could then pull a lot more than just Dkey, and do it forever. (I'm more interested in the "built an enterprise-root-of-trust mobile platform", but "build an awesome, repeatable attack against everything" is also pretty tempting, if only to sell the former.)