Comment by naoru
6 days ago
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.
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?
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.
4 replies →
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.
Hypothetically Secure Memory
(I guess)
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
10 replies →
Even if trivial it could be manufacturing savings.