Hacker News Reader

Comment by naoru | Hacker News Reader

The article says:

> According to The Cybersec Guru, this is an unpatchable problem for Sony, because these keys cannot be changed and are burned directly in the APU.

I'm just speculating at this point, but what could prevent Sony from anticipating this exact situation and burning several keys in the APU? I mean, eFuse is not exactly a new technology. That way, once a key is leaked, Sony could push a firmware update switching the APU to a new key which hasn't been leaked yet.

View on HN

I have seen some manufacturers enroll multiple manufacturer keys, probably with this notion, but this isn’t useful against almost any threat model.

If keys are recovered using some form of low level hardware attack, as was almost surely the case here, the attacker can usually recover the unused key sets too.

If the chip manufacturing provisioning supply chain is leaky the new keys will probably be disclosed anyway, and if the key custody chain is broken (ie, keys are shared with OEMs or third parties) they will definitely be disclosed anyway.

Wouldn't the other reason to have multiple manufacturer keys, be to guard against them losing the private key for one in a way that means they can't sign anything any more?

I mean, sure, but to what end does that madness lead? Who backs up the backups?

Usually this is to allow different departments / divisions / customers (in the case of an OEM model) to all sign code or encrypt binaries, although this is likewise a bit off as each enrolled key increases the amount of material which is available to leak in the leak model. Or to allow model line differentiation with crossover.

Nothing. But if the keys weren't stored in an HSM (seems likely), attackers getting one of them implies they could get the others as well.

HSM or TPM?

Hypothetically Secure Memory

(I guess)

A TPM is a form of HSM (Hardware Security Module).

HSMs come in all sizes, from a chip in your phone (secure element) or even a dedicated part of a SoC chip, to a big box in a datacenter that can handle tons of requests per second.

The idea is having dedicated hardware to protect the private key material. This hardware can execute signing operations, so it can use the key but it can't share the key material itself. It is usually also physically hardened with techniques to extract said keys, like sidechannel attacks based on power draw, X-ray inspection, decapping etc.

Thanks - I know the difference

This also sounds very AI-like

I'm not AI and I didn't use it for that, I just thought it was a genuine question and tried to explain it clearly :)

I don't really get why anyone would let an AI put random comments on discussions anyway but that's another story.

If you knew the difference why ask such a question that makes it seem as though you didn't?

Fair enough. I was asking more about which class of hardware Sony was likely relying on, not the definition. Thanks.

The story implies that these are signing keys, so there is no reason for the private halves to be present in the product's silicon in any form. If these were encryption keys stored in a TPM, they'd have been extracted not leaked.

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.

Even if trivial it could be manufacturing savings.

Reply on news.ycombinator.com