6 ms·

"Attests the software version is the version that is valid and shipped by the Oxide Computer Company" So in other words these servers will implement restrictiv

"Attests the software version is the version that is valid and shipped by the Oxide Computer Company" So in other words these servers will implement restrictive code signing practices and will be vendor-controlled, not owner-controlled? This is not my idea of "secure", and really in the wake of things like the Solarwinds or RSA hacks it shouldn't be anyone's idea of secure. Vendor-holds-the-keys is not an acceptable security model. A comment below mentions open firmware, open firmware is useless without the right to deploy modified versions of it. Happy to take clarification on this.

gruez 5y ago
"Attest" refers to https://en.wikipedia.org/wiki/Trusted_Computing#REMOTE-ATTESTATION https://en.wikipedia.org/wiki/Trusted_Computing#REMOTE-ATTES..., not forced code signing
- hlandau 5y ago
  I'm familiar with the concept. Does this mean that attestation to a different root of trust than Oxide will also be feasible, and that this is just a default?
  - hobofan 5y ago
    It's an "enterprise" product, so you can be certain that some amount of extra money will buy you that capability (if it's not already included).
  - gruez 5y ago
    Oxide makes the hardware, so it makes sense to use them as the root of trust since you already have to trust them to not make backdoored hardware. Why bother adding more parties? Also, for remote attestation to make sense, it needs to be done in the hardware itself (ie. keys burned into the silicon). I'm not sure how that's supposed to work if you add your own keys, or whether that would even make sense.
    - hlandau 5y ago
      "it needs to be done in the hardware itself (ie. keys burned into the silicon)" - this isn't true; this is confusing Trusted Boot and Secure Boot, which are not the same thing (nor is it the only way of implementing Secure Boot). Owner-controlled remote attestation is entirely viable, e.g. Talos II is capable of this with a FlexVer module.
      - gruez 5y ago
        > "it needs to be done in the hardware itself (ie. keys burned into the silicon)" - this isn't true; this is confusing Trusted Boot and Secure Boot, which are not the same thing (nor is it the only way of implementing Secure Boot). I meant as opposed to keys/signing done in software. >Owner-controlled remote attestation is entirely viable, e.g. Talos II is capable of this with a FlexVer module. I skimmed the product brief[1] and it looks like it's basically a TPM that has a secure communications channel (as opposed to LPC which can be MITMed)? I'm not really sure how this is an improvement, because you're still relying on the hardware vendor to send the PCR values. So at the end of the day you still have to trust the hardware vendor, although the signing is done by you, but I'm not really sure how this adds any benefit. [1] https://www.raptorengineering.com/TALOS/documentation/flexver_intro.pdf https://www.raptorengineering.com/TALOS/documentation/flexve...
        p_l 5y ago
        FlexVer doesn't hardcode any keys - you can fully reinitialize the TPM to your liking, but doing so destroys any secrets already stored. So the trick is that you initialize it for your infrastructure and have to do secure reprovisioning if it ever fails to provide the same key answers (which would indicate tampering)
mmphosis 5y ago
Open source firmware, vs "Open Firmware". The oxide.computer web page mentions open source firmware. Secure boot chain Our boot flow is secure by default. Our firmware is open source and attestable. There is a link to "Explore Repos." Is coreboot the open source firmware? https://github.com/oxidecomputer/coreboot https://github.com/oxidecomputer/coreboot Open Firmware is different than coreboot. https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware

gruez 5y ago

"Attest" refers to https://en.wikipedia.org/wiki/Trusted_Computing#REMOTE-ATTESTATION https://en.wikipedia.org/wiki/Trusted_Computing#REMOTE-ATTES..., not forced code signing

hlandau 5y ago
I'm familiar with the concept. Does this mean that attestation to a different root of trust than Oxide will also be feasible, and that this is just a default?
- hobofan 5y ago
  It's an "enterprise" product, so you can be certain that some amount of extra money will buy you that capability (if it's not already included).
- gruez 5y ago
  Oxide makes the hardware, so it makes sense to use them as the root of trust since you already have to trust them to not make backdoored hardware. Why bother adding more parties? Also, for remote attestation to make sense, it needs to be done in the hardware itself (ie. keys burned into the silicon). I'm not sure how that's supposed to work if you add your own keys, or whether that would even make sense.
  - hlandau 5y ago
    "it needs to be done in the hardware itself (ie. keys burned into the silicon)" - this isn't true; this is confusing Trusted Boot and Secure Boot, which are not the same thing (nor is it the only way of implementing Secure Boot). Owner-controlled remote attestation is entirely viable, e.g. Talos II is capable of this with a FlexVer module.
    - gruez 5y ago
      > "it needs to be done in the hardware itself (ie. keys burned into the silicon)" - this isn't true; this is confusing Trusted Boot and Secure Boot, which are not the same thing (nor is it the only way of implementing Secure Boot). I meant as opposed to keys/signing done in software. >Owner-controlled remote attestation is entirely viable, e.g. Talos II is capable of this with a FlexVer module. I skimmed the product brief[1] and it looks like it's basically a TPM that has a secure communications channel (as opposed to LPC which can be MITMed)? I'm not really sure how this is an improvement, because you're still relying on the hardware vendor to send the PCR values. So at the end of the day you still have to trust the hardware vendor, although the signing is done by you, but I'm not really sure how this adds any benefit. [1] https://www.raptorengineering.com/TALOS/documentation/flexver_intro.pdf https://www.raptorengineering.com/TALOS/documentation/flexve...
      - p_l 5y ago
        FlexVer doesn't hardcode any keys - you can fully reinitialize the TPM to your liking, but doing so destroys any secrets already stored. So the trick is that you initialize it for your infrastructure and have to do secure reprovisioning if it ever fails to provide the same key answers (which would indicate tampering)

mmphosis 5y ago

Open source firmware, vs "Open Firmware". The oxide.computer web page mentions open source firmware. Secure boot chain Our boot flow is secure by default. Our firmware is open source and attestable. There is a link to "Explore Repos." Is coreboot the open source firmware? https://github.com/oxidecomputer/coreboot https://github.com/oxidecomputer/coreboot Open Firmware is different than coreboot. https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware