Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

the failure mode of having a single provisioning key instead of limited batch keys derived from ones in an HSM creates the incentive where this is inevitable.

if one key gets you all chips, then someone is going to get that because the payout is total dominion. I've seen this trade off in similar protocols, and every time it's like "thanks for the advice, we're going to go with just the one, it's easier." There is one OEM/protocol I suspect actually uses diversified batch keys as their root provisioning secret, and really it's the way to go if you do business globally now.

What's more interesting is what the consequences will be, as if there are none (it's not like the stock will hurt) then the market is saying crypto can be sabotaged with impunity.



> There is one OEM/protocol I suspect actually uses diversified batch keys as their root provisioning secret, and really it's the way to go if you do business globally now.

seems like apple, since it’s actually an important factor to them and not just to third parties?


Is there a trade-off wrt attestation privacy here - i.e. using a single root key is better for privacy?


Ideally, at least for headless server hardware, if you have physical access, you could wipe the provisioning key and replace it with your own.

Doing so should blow away the disk keys, etc.

I’ve always assumed systems that relied on a key and didn’t support that were backdoored.


Which systems support that?


with batch sizes in the millions less so, but agreed it's still a differentiating attribute. I would solve that higher up in the protocols that used it, as the initialization keys shouldn't be related to post-provisioning keys in a way that is verifiable to anyone except the OEM, again arguable, but it's a higher level protocol question imo.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: