Hacker News Reader

Comment by ghshephard | Hacker News Reader

Would that not break every other firmware release that relied on that older key?

Yes, but console vendors generally prefer not to allow downgrades.

So if v1 is signed by key A, v2 is signed by key B and invalidates key A; a console that installs v2 wouldn't be able to install v1 after, but that's not a problem for Sony.

But, I'm not sure how many companies would be able to manage their keys properly to ensure that someone with access to key A doesn't have access to key B.

If these are asymmetric key pairs and the device side key was extracted from the device... Switching keys wouldn't help, and it's not a huge deal by itself --- having the device side key doesn't allow you to make a firmware image the device would accept.

Fun fact, the Nintendo Switch blows fuses [0] when they do a patch that’s for security/jailbreaking. If I recall there’s something like 12 or 16 fuses they can employ over the life of the product to ensure you can’t rollback updates that prevent piracy. Nvidia builds these fuses into the board.

So if you’ve blown 4 fuses you can’t do a patch that requires only 2 fuses to have blown, it’s a pretty wild solution.

Edit: it’s actually 22 fuses

[0] https://switchbrew.org/wiki/Fuses

I’m not following. Why would it be helpful to check how many fuses had been blown? And how could you have more blown fuses than you’re supposed to?

Firmware v1 requires a switch with zero fuses blown.

Firmware v2 requires a switch with no more than one fuse blown and blows the first fuse.

If you install v2, you can't install v1.

Nintendo can make 22 firmware releases that disallow rollback.

Got it. Thanks. For some reason I was imagining a new firmware that some people couldn’t install because they had blown too many fuses.

Yeah, that shouldn't happen (although I think I've seen reports of eFuses blowing spontaneously as well as eFuses self-repairing)

If your console blows a fuse before Nintendo intends to, you won't be able to install firmware until a firmware is released that will run with that number of fuses blown. And, depending on how things are implemented, you might not be able to run the firmware that you have either.

Here's an excerpt about the anti-rollback feature from Nvidia's docs on how the Tegra X1 SoC in the switch 1 boots [0] (called Tegra210 in the document)

> By default, the boot ROM will only consider bootloader entries with a version field that matches the version field of the first entry, and will stop iterating through the entries is a mismatch is found. The intent is to ensure that if some subset of the bootloader entries are upgraded, and hence the version field of their entries is modified, then the boot ROM will only boot the most recent version of the bootloader. This prevents an accidental rollback to an earlier version of the bootloader in the face of boot memory read errors, corruption, or tampering. Observe that this relies on upgraded bootloader entries being placed contiguously at the start of the array.

[0] https://http.download.nvidia.com/tegra-public-appnotes/tegra...

It isn't that wild; the typical name for it is anti-rollback, and you probably have at least one device that implements it. Most Android devices have anti-rollback efuses to prevent installing older versions of the bootchain\bootloader; they might still allow you to downgrade the OS (depends on the vendor, if memory serves). Instead of using efuse counters, anti-rollback counters can also be implemented by Replay Protected Memory Block (RPMB), which is implemented by many flash storage (eMMC often supports RPMB, but other storage types can as well). It is possible to implement anti-rollback mechanisms on x86_64 by utilizing a TPM [0], but as far as I know, only Chrome OS does this.

[0]: https://www.chromium.org/developers/design-documents/tpm-usa...

Wouldn't it be great if companies spent the time and effort needed for all these wonderful things that prevent the owner from using the hardware they own how they see fit and instead invested the resources into making the product better ?

All this is basically a fragile anti-user timebomb that will only generate more avoidable e-waste eventually.

For some users, preventing downgrades to an insecure version is a better product since it protects against evil maid attacks.

(Although ideally they would itself trap that functionality behind a fuse, so you have to opt-in but can't be opted out.)

You can get a similar level of protection against evil maids by requiring a wipe to downgrade.

They're on the die. efuses existed on the ps3 and 360 too. The 360 used them to prevent downgrades, but the ps3 used all of theirs to store bluray drive keys.

Reply on news.ycombinator.com