3 ms·

Probably everything uploaded after the intercept is in place if you can convince a court to compel it. One option is to release a malicious software update, si

by gpm 2y ago

Probably everything uploaded after the intercept is in place if you can convince a court to compel it. One option is to release a malicious software update, sign it, publish the signature on the public chain, and then simply not release the binaries until after whatever associated gag orders there are (if any) expire. Apple gave themselves a 90 day timeline for this before they'd even be in violation of their promises. Another option is to use the cryptographic keys used to make the hardware that attests to the software running on it, to simply falsely attest to what software is running. Unless Apple's somehow moved those keys outside of the courts jurisdiction (which means outside of Apple's control in the case of most courts) that should be within the courts power. If they can still create new hardware, it seems likely whoever is making that hardware must still have access to the keys... Both of these attacks are outside the "threat model" proposed, because they are broad compromises against the entire PCC infrastructure. The fact that they are possible and within the legal systems power... well... why are we advertising this as secure again? The main value of this whole architecture in my mind isn't actually security though, it's that it's Apple implicitly making the promise that they won't under any circumstance use the data, or let anyone else use the data, for business purposes (not even for running the service itself).

aalimov_ 2y ago
> One option is to release a malicious software update, sign it, publish the signature on the public chain, In this option it would be Apple releasing a malicious software update? > If they can still create new hardware, it seems likely whoever is making that hardware must still have access to the keys... This option reads like the keys are stored in apple-keys.txt > Both of these attacks are outside the "threat model" proposed, because they are broad compromises against the entire PCC infrastructure They mentioned that the in-depth write up will be shared later, might they still address this concern in writing? Your wording makes you sound so certain, but this is just a broad overview. How are you so sure?
- gpm 2y ago
  > In this option it would be Apple releasing a malicious software update? Yes, compelled by something like the all writs act (if the US is the one doing the compelling). > This option reads like the keys are stored in apple-keys.txt They probably are. That file might live on a CD drive in a safe that requires two people to open it, but ultimately it's a short chunk of binary data that exists somewhere (until it is destroyed)... > might they still address this concern in writing? Can I say beyond all doubt that this won't happen? Of course not. On the first approach I'm quite confident though, because it's both the type of attack they discuss in their initial press release, and pretty fundamental to and explicitly allowed by their model of updating the software. On the second approach I'm reasonably confident. Like the first issue it's the type of issue that they were discussing in their initial press release. Unlike the first issue it's not something that is explicitly allowed in the model. If Apple can find a way to make the attestation keys irretrievable while still allowing themselves to manufacture hardware I believe they'd do it - I just don't see a method and think it would have warranted a mention if they had one. I tried to insert a level of uncertainty in my original writing on this one because I could be missing a way to solve it. Ultimately I'd rather over-correct now then have people start thinking this is going to be more secure than it is and then have some fraction of them miss the extremely-likely follow up of "and we could be compelled to work around our security".
  - jahewson 2y ago
    Allow me to introduce you to HSMs: https://en.m.wikipedia.org/wiki/Hardware_security_module https://en.m.wikipedia.org/wiki/Hardware_security_module
    - gpm 2y ago
      I'm well aware of these. They don't solve the problem at hand. You need a way to put keys into new hardware. Thus you need a way to get keys out of wherever you've stored your cryptographic material. Thus it can't be on a HSM (or it can be if it's a master key signing child keys, but in that case the attack only needs a signed child key).
      - 2y ago

by gpm 2y ago

aalimov_ 2y ago

> One option is to release a malicious software update, sign it, publish the signature on the public chain, In this option it would be Apple releasing a malicious software update? > If they can still create new hardware, it seems likely whoever is making that hardware must still have access to the keys... This option reads like the keys are stored in apple-keys.txt > Both of these attacks are outside the "threat model" proposed, because they are broad compromises against the entire PCC infrastructure They mentioned that the in-depth write up will be shared later, might they still address this concern in writing? Your wording makes you sound so certain, but this is just a broad overview. How are you so sure?

gpm 2y ago
> In this option it would be Apple releasing a malicious software update? Yes, compelled by something like the all writs act (if the US is the one doing the compelling). > This option reads like the keys are stored in apple-keys.txt They probably are. That file might live on a CD drive in a safe that requires two people to open it, but ultimately it's a short chunk of binary data that exists somewhere (until it is destroyed)... > might they still address this concern in writing? Can I say beyond all doubt that this won't happen? Of course not. On the first approach I'm quite confident though, because it's both the type of attack they discuss in their initial press release, and pretty fundamental to and explicitly allowed by their model of updating the software. On the second approach I'm reasonably confident. Like the first issue it's the type of issue that they were discussing in their initial press release. Unlike the first issue it's not something that is explicitly allowed in the model. If Apple can find a way to make the attestation keys irretrievable while still allowing themselves to manufacture hardware I believe they'd do it - I just don't see a method and think it would have warranted a mention if they had one. I tried to insert a level of uncertainty in my original writing on this one because I could be missing a way to solve it. Ultimately I'd rather over-correct now then have people start thinking this is going to be more secure than it is and then have some fraction of them miss the extremely-likely follow up of "and we could be compelled to work around our security".
- jahewson 2y ago
  Allow me to introduce you to HSMs: https://en.m.wikipedia.org/wiki/Hardware_security_module https://en.m.wikipedia.org/wiki/Hardware_security_module
  - gpm 2y ago
    I'm well aware of these. They don't solve the problem at hand. You need a way to put keys into new hardware. Thus you need a way to get keys out of wherever you've stored your cryptographic material. Thus it can't be on a HSM (or it can be if it's a master key signing child keys, but in that case the attack only needs a signed child key).
    - 2y ago