5 ms·

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 th

by naoru 9mo 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.

ghshephard 9mo ago
Would that not break every other firmware release that relied on that older key?
- deleted 9mo ago
  [deleted]
- toast0 9mo ago
  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.
  - wincy 9mo ago
    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 https://switchbrew.org/wiki/Fuses
    - jtbayly 9mo ago
      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?
      - toast0 9mo ago
        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.
        jtbayly 9mo ago
        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.
        toast0 9mo ago
        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.
      - zorgmonkey 9mo ago
        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-boot-flow.html#_bootloader_redundancy https://http.download.nvidia.com/tegra-public-appnotes/tegra...
j45 9mo ago
Even if trivial it could be manufacturing savings.
EPWN3D 9mo ago
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.
- firesteelrain 9mo ago
  HSM or TPM?
  - tosti 9mo ago
    Hypothetically Secure Memory (I guess)
  - wolvoleo 9mo ago
    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.
    - firesteelrain 9mo ago
      Thanks - I know the difference This also sounds very AI-like
      - wolvoleo 9mo ago
        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.
      - JCattheATM 9mo ago
        If you knew the difference why ask such a question that makes it seem as though you didn't?
bri3d 9mo ago
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.
- deleted 9mo ago
  [deleted]
- trebligdivad 9mo ago
  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?
  - bri3d 9mo ago
    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.

by naoru 9mo ago

ghshephard 9mo ago

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

deleted 9mo ago
[deleted]
toast0 9mo ago
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.
- wincy 9mo ago
  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 https://switchbrew.org/wiki/Fuses
  - jtbayly 9mo ago
    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?
    - toast0 9mo ago
      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.
      - jtbayly 9mo ago
        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.
        toast0 9mo ago
        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.
    - zorgmonkey 9mo ago
      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-boot-flow.html#_bootloader_redundancy https://http.download.nvidia.com/tegra-public-appnotes/tegra...

j45 9mo ago

Even if trivial it could be manufacturing savings.

EPWN3D 9mo ago

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.

firesteelrain 9mo ago
HSM or TPM?
- tosti 9mo ago
  Hypothetically Secure Memory (I guess)
- wolvoleo 9mo ago
  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.
  - firesteelrain 9mo ago
    Thanks - I know the difference This also sounds very AI-like
    - wolvoleo 9mo ago
      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.
    - JCattheATM 9mo ago
      If you knew the difference why ask such a question that makes it seem as though you didn't?

bri3d 9mo ago

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.

deleted 9mo ago
[deleted]
trebligdivad 9mo ago
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?
- bri3d 9mo ago
  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.