4 ms·

This seems to have been written under the assumption that these "elaborate security implementations" discussed are designed to serve the interests of the owner

by c0l0 3y ago

This seems to have been written under the assumption that these "elaborate security implementations" discussed are designed to serve the interests of the owner (or, these days, let's better call that person the "user" instead?) of the particular machine/hardware/node. I do not share that sentiment, and believe they are designed and implemented to service the interests of the content industry and their ilk, and purported benefits for Joe User are a pretty much a gigantic fig leaf.

smashed 3y ago
Yup, and in the embedded world, they are used to achieve encryption of the OS firmware, thus preventing reverse engineering of the device, protecting IP and securing devices through obscurity. I'm thinking of enterprise grade networking hardware for example. Their main OS ROM is encrypted and they will refuse to decrypt if the boot process is altered. There are no real secrets or user data being protected by the encryption. Heck, actual passwords and user configurations can be stored in clear.
- vetinari 3y ago
  It is not for protecting user secrets. It has nothing to do with users. It is about protecting against "after hours" production runs. If you, as a vendor, order manufacturing 1000 pieces of widgets, you want to be sure that only those delivered to you are really produced. You don't want more, and then your own product competing against you on the market. Hence, encryption. Only your devices can run your firmware. All those extras cannot.
  - salawat 3y ago
    Solution: Make your own fab? Enjoy all the benefits of keeping stuff to yourself I guess. Bonus: potentially lowers the barrier to entry to electronics fabrication as more engineer hours are spent getting the fabrication equipment/processes better documented/more accessible. No one wants that though. That'd make too much sense.
immibis 3y ago
It's both. Whoever gets a hold of a secure boot system first can ensure the machine serves them. How else can the machine tell who is its rightful owner?
rocqua 3y ago
Owners and users are different people in the case of enterprise issued devices, which is a very common use cases for things like this. In that case the user isn't trusted, not because of maliciousness, but because of security mistakes, which are quite easy to make. Having attestation to prove the device is not tampered with before letting it connect to the company network is a good idea.
benlivengood 3y ago
Foolproof root of trust would make cloud providers a lot more trustworthy. For example AMD's SME+SEV is in theory able to attest that a cryptographically verified (as opposed to trusted) boot process resulted in an encrypted-RAM VM running on someone else's computer that it would be pretty hard for them to impersonate or read data from (they can always inject errors). It's always up to the person evaluating the measured attestation to determine the trust in the software that was attested. Individuals don't have quite as much to benefit from. I don't bother to run SEV on my personal cloud VMs. Mostly because it's more likely for there to be enough software 0-days to not offer much practical protection. If I was trying to do cryptocurrency in the cloud on top of seL4 or something equally verifiable then maybe SEV/SecureBoot would be worth it?

by c0l0 3y ago

smashed 3y ago

Yup, and in the embedded world, they are used to achieve encryption of the OS firmware, thus preventing reverse engineering of the device, protecting IP and securing devices through obscurity. I'm thinking of enterprise grade networking hardware for example. Their main OS ROM is encrypted and they will refuse to decrypt if the boot process is altered. There are no real secrets or user data being protected by the encryption. Heck, actual passwords and user configurations can be stored in clear.

vetinari 3y ago
It is not for protecting user secrets. It has nothing to do with users. It is about protecting against "after hours" production runs. If you, as a vendor, order manufacturing 1000 pieces of widgets, you want to be sure that only those delivered to you are really produced. You don't want more, and then your own product competing against you on the market. Hence, encryption. Only your devices can run your firmware. All those extras cannot.
- salawat 3y ago
  Solution: Make your own fab? Enjoy all the benefits of keeping stuff to yourself I guess. Bonus: potentially lowers the barrier to entry to electronics fabrication as more engineer hours are spent getting the fabrication equipment/processes better documented/more accessible. No one wants that though. That'd make too much sense.

immibis 3y ago

It's both. Whoever gets a hold of a secure boot system first can ensure the machine serves them. How else can the machine tell who is its rightful owner?

rocqua 3y ago

Owners and users are different people in the case of enterprise issued devices, which is a very common use cases for things like this. In that case the user isn't trusted, not because of maliciousness, but because of security mistakes, which are quite easy to make. Having attestation to prove the device is not tampered with before letting it connect to the company network is a good idea.

benlivengood 3y ago

Foolproof root of trust would make cloud providers a lot more trustworthy. For example AMD's SME+SEV is in theory able to attest that a cryptographically verified (as opposed to trusted) boot process resulted in an encrypted-RAM VM running on someone else's computer that it would be pretty hard for them to impersonate or read data from (they can always inject errors). It's always up to the person evaluating the measured attestation to determine the trust in the software that was attested. Individuals don't have quite as much to benefit from. I don't bother to run SEV on my personal cloud VMs. Mostly because it's more likely for there to be enough software 0-days to not offer much practical protection. If I was trying to do cryptocurrency in the cloud on top of seL4 or something equally verifiable then maybe SEV/SecureBoot would be worth it?