"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.
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?
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.
"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.
> "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.
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)
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.