undefined | Better HN

0 pointsaxoltl1y ago0 comments

How would a warrant work in this case? Using Silicon Data Protection[0] the hash of the currently running firmware (of both the AP _and_ the SEP) is locked into hardware registers in the PKA engine used by the SEP. This hash perturbs the key derivation, and the PKA engine can also attest to the running firmware hash(es) by using an EC key only available to it (they call this BAA, Basic Attestation Authority).

iOS won't send any data to a PCC that isn't running a firmware that's been made public in their transparency logs and compute nodes have no way to be debugged in a way that exposes user data[1]

And at the end of the day, this is going to give the warrant holder a handful of requests from a specific user? Why wouldn't they use that same warrant to get onto the target's device directly and get that same data plus a ton more?

0: https://help.apple.com/pdf/security/en_US/apple-platform-sec... 1: https://security.apple.com/blog/private-cloud-compute/

0 comments

jeroenhd1y ago

Apple controls the hardware and the private keys baked into the hardware. If one of their servers can decrypt the payload, they can intercept, duplicate, and decrypt the payload and its response. I'm sure this'll start a long fight between law enforcement and Apple after the first warrant hits and Apple claims it can't comply.

Warrants to hack devices are a lot less common and generally harder to obtain. That's why police will send Google warrants for "give us info on every device who has been in a radius of x between y and z time".

I'm sure Apple did their very best to protect their users, but I don't think their very best is good enough to warrant this kind of trust. A "secure cloud" solution will also tempt future projects to use the cloud over local processing more, as cloud processing is now readily available. Apple's local processing is a major advantage over the competition but I doubt that'll stay that way if their cloud solution remains this integrated.

axoltlOP1y ago

Apple actually does not control the private keys baked into the hardware, see the "Root Cryptographic Keys" section of their security whitepaper: https://help.apple.com/pdf/security/en_US/apple-platform-sec...

Your example indicates a situation where law enforcement does not know which device belongs to their suspect, if they even have one. That's a very different scenario from a targeted "tell us the requests belonging to this individual".

Warrants to search a device are extremely common place, otherwise the likes of Grayshift and Cellebrite would not be around.

From a threat modeling perspective compromising PCC is high risk (Apple's not just going to comply and the fight will be very public, see the FBI San Bernardino fight) , high effort (Long protracted court case), low reward (I only see requests that are going to get shipped off to the cloud). If I were law enforcement I'd explore every other avenue available to me before I go down that particular rabbit hole which is exactly what this design is intended to achieve.

j / k navigate · click thread line to collapse