←back to thread

166 points sjuut | 1 comments | | HN request time: 0.292s | source
Show context
mjg59 ◴[] No.44611125[source]
Having spent a while working in embedded and learning that this is not a lesson that's been internalised: this is why you never sign any executable that can boot on shipped hardware unless you'd be ok with everyone running it on shipped hardware. You can not promise it will not leak. You can not promise all copies will be destroyed. If it needs to run on production hardware then you should have some per-device mechanism for one-off signatures, and if it doesn't then it should either be unsigned (if fusing secure boot happens late) or have the signature invalidated as the last thing that happens before the device is put in the box.

A lot of companies do not appear to understand this. A lot of devices with silicon-level secure boot can be circumvented with signed images that have just never (officially) been distributed to the public, and anyone relying on their security is actually relying on vendors never accidentally trashing a drive containing one. In this case Nintendo (or a contractor) utterly failed to destroy media in the way they were presumably supposed to, but it would have been better to have never existed in this form in the first place.

replies(4): >>44611219 #>>44611369 #>>44614565 #>>44616825 #
1. Nursie ◴[] No.44614565[source]
> never sign any executable that can boot on shipped hardware unless you'd be ok with everyone running it on shipped hardware.

How about if, when the lead engineers are on holiday, you ship the first batch of production units with a root a key that’s on everyone’s laptop and has been pushed to bitbucket, and been used to sign all sorts of things for dev units? Then, when confronted with that, you say “oh right, well… can we delete it from those places and import the key to the HSM? We’ll use it as the prod key going forwards?”

I was sad when that payment terminal never made it to market, but in the end perhaps it was for the best.