5 ms·

Why would I want my computer to make decisions against my will because of a very carefully defined version of "trust"? When the alternative is software freedom

by sounds 7y ago

Why would I want my computer to make decisions against my will because of a very carefully defined version of "trust"? When the alternative is software freedom which gives me the power (and yes, the responsibility too) to direct my computer the way I want? And yeah, that responsibility includes checking for updates and downloading security fixes. "Trust" is always used in "Root of trust" and "Trustworthy computing" to mean "deny software freedom to the user." That's not even close to what the dictionary says trust means.

Reelin 7y ago
Yes, trusted computing is currently mostly used to curtail user freedom - generally in the name of security. And yes, implementations make use of a cryptographic root of trust to realize their design goals. It doesn't have to be that way though. I'm fine with a root of trust I have complete control over, and a trusted computing chain built on that would be welcome. Such an arrangement would do nothing to curtail my freedom, since I could install my own keys and thus firmware. And it wouldn't require any additional trust in the hardware vendor beyond what I already place in them. It could even ship with the vendor's keys installed by default, the same way Secure Boot works today. I'd still have mixed feelings about something like SGX (in its current form) being standard in consumer hardware though, since at its core it consists of the hardware working against the owner. I can see why such an arrangement is desirable for cloud providers, but widespread consumer adoption would allow a third party (presumably a content provider) to require its use as part of a DRM scheme. That being said, even SGX could be made palatable if there was no vendor provided key in the hardware at all and it instead attested everything with _my_ key. This would still protect remote systems against myriad forms of physical attack and allow for screening VMs from each other, all without compromising the integrity of my system (from my perspective). The downside, of course, is that it would require actually trusting your cloud provider.
- aseipp 7y ago
  FWIW, SGXv2 enabled machines -- to my knowledge -- have a user-programmable MSR that you can stuff your own key into. So Intel is no longer needed at all for attestation. (I think they even released an SDK so you could more easily implement your own attestation services, too, like the ones they run.) The problem is that very few SKUs ship with v2 at all, and zero of those SKUs are in the Xeon lineup as of now. Once the first set of patches for SGX support in Linux got rejected specifically because the user couldn't set their own keys -- I felt it was inevitable Intel was going to cede control on this, only a matter of when the chips appeared. It's just not how they roll; Intel's relatively good and well-prepared-in-advance Linux support is one of their good strengths, and they almost certainly don't want to keep patches around for a major feature like SGX any more than they absolutely have to. (The latest versions of the kernel patches, I think, only support SGXv2 style user controlled attestation. They have yet to be merged upstream.)
  - josh2600 7y ago
    I don't think SGXv2 is available anywhere. Do you have a link to an SGXv2 datasheet/purchaseable chip?
    - aseipp 7y ago
      Flexible Launch Control (setting your own keys) is available in the NUC7CJYH, apparently: https://github.com/ayeks/SGX-hardware#hardware-with-sgx2-support https://github.com/ayeks/SGX-hardware#hardware-with-sgx2-sup... So even worse availability than I thought, I figured more than one SKU was supported. (I think you could at least buy either a NUC or a 1U from Intel for SGXv1 prototyping, but this is all I can find at the moment.) Honestly though given all that it's still hard to find what actually defines SGXv2 in terms of features or errata, though. But FLC is the major requirement that will allow mainstream kernel support, from my understanding.
  - Reelin 7y ago
    That's... slightly better? I think? Honestly SGX is complicated enough that I'm not entirely sure I have this straight. Am I correct in thinking that: 1. A user-programmable MSR would allow the device owner to falsify the attestation of enclave initialization (when using their own keys). 2. The ME (and other firmware) would still not be replaceable or owner controllable. 3. Due to 2, enclave compromise would have to be premeditated. That is, once an enclave is up and running IIUC it can (potentially) use MRENCLAVE to derive the sealing key. Without control of the ME that enclave would be unbreachable, correct? So realistically, to maintain control of code running on my device I would have to set my own SGX keys and configure my system to actively compromise all enclaves at launch. From a security standpoint, there's still a black box (the ME) with super-root that could be compromised by attackers that I can't inspect, modify, or disable. And from a political standpoint, there's still a tragedy of the commons regarding DRM if the majority of providers decide to require SGX with Intel root keys as a condition of service. Have I misunderstood anything? (While responding, I stumbled across an interesting paper regarding using SGX to protect malware against researchers: https://arxiv.org/abs/1902.03256 https://arxiv.org/abs/1902.03256) Edit: It appears I was overly optimistic - playback of 4k BluRay already requires Intel SGX. (https://old.reddit.com/r/Amd/comments/bw0cwq/will_ryzen_3rd_gen_finally_support_4k_bluray https://old.reddit.com/r/Amd/comments/bw0cwq/will_ryzen_3rd_...)
viraptor 7y ago
> "Trust" is always used in "Root of trust" and "Trustworthy computing" to mean "deny software freedom to the user." That's not what "root of trust" means. Root of trust is normally a certificate which signs other certificates. If you trust that top level certificate to be valid, it means you can trust that the certificates signed by it are valid as well. That's all there is to it. What someone does with the certificates - whether that's signing TLS traffic, or execution attestation is completely separate. I don't think you'd argue that TLS is used to "deny software freedom to the user" - right? (https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate) "trustworthy computing" is not a technical term, but a marketing phrase. (https://en.wikipedia.org/wiki/Trustworthy_computing https://en.wikipedia.org/wiki/Trustworthy_computing) You're probably referring to "trusted computing" which is a very specific use of signing and attestation of computing states. It uses the chain of trust in the same way it uses addition (or substitute any higher level concept you want) - you can't say "addition is bad, because it denies software freedom to the user" in this case.
- tremon 7y ago
  You're probably referring to "trusted computing" which is a very specific use of signing and attestation of computing states. If it is so specific, why is it present in every single Intel CPU? And why aren't end users able to delete the built-in root of trust and replace it with their own? Trusted computing, as implemented by Intel, is actively hostile to the citizens of a free society. So in this case, I really can say that it denies software freedom to the user.
  - viraptor 7y ago
    You can disable SGX in your Bios. It don't give you any new features then, it doesn't deny any freedoms either.
- nelgaard 7y ago
  >I don't think you'd argue that TLS is used to "deny software freedom to the user" - right? No, but if I could not make a website that was not signed by e.g. DigiCert, then I would argue that something was not right.

by sounds 7y ago

Reelin 7y ago

Yes, trusted computing is currently mostly used to curtail user freedom - generally in the name of security. And yes, implementations make use of a cryptographic root of trust to realize their design goals. It doesn't have to be that way though. I'm fine with a root of trust I have complete control over, and a trusted computing chain built on that would be welcome. Such an arrangement would do nothing to curtail my freedom, since I could install my own keys and thus firmware. And it wouldn't require any additional trust in the hardware vendor beyond what I already place in them. It could even ship with the vendor's keys installed by default, the same way Secure Boot works today. I'd still have mixed feelings about something like SGX (in its current form) being standard in consumer hardware though, since at its core it consists of the hardware working against the owner. I can see why such an arrangement is desirable for cloud providers, but widespread consumer adoption would allow a third party (presumably a content provider) to require its use as part of a DRM scheme. That being said, even SGX could be made palatable if there was no vendor provided key in the hardware at all and it instead attested everything with _my_ key. This would still protect remote systems against myriad forms of physical attack and allow for screening VMs from each other, all without compromising the integrity of my system (from my perspective). The downside, of course, is that it would require actually trusting your cloud provider.

aseipp 7y ago
FWIW, SGXv2 enabled machines -- to my knowledge -- have a user-programmable MSR that you can stuff your own key into. So Intel is no longer needed at all for attestation. (I think they even released an SDK so you could more easily implement your own attestation services, too, like the ones they run.) The problem is that very few SKUs ship with v2 at all, and zero of those SKUs are in the Xeon lineup as of now. Once the first set of patches for SGX support in Linux got rejected specifically because the user couldn't set their own keys -- I felt it was inevitable Intel was going to cede control on this, only a matter of when the chips appeared. It's just not how they roll; Intel's relatively good and well-prepared-in-advance Linux support is one of their good strengths, and they almost certainly don't want to keep patches around for a major feature like SGX any more than they absolutely have to. (The latest versions of the kernel patches, I think, only support SGXv2 style user controlled attestation. They have yet to be merged upstream.)
- josh2600 7y ago
  I don't think SGXv2 is available anywhere. Do you have a link to an SGXv2 datasheet/purchaseable chip?
  - aseipp 7y ago
    Flexible Launch Control (setting your own keys) is available in the NUC7CJYH, apparently: https://github.com/ayeks/SGX-hardware#hardware-with-sgx2-support https://github.com/ayeks/SGX-hardware#hardware-with-sgx2-sup... So even worse availability than I thought, I figured more than one SKU was supported. (I think you could at least buy either a NUC or a 1U from Intel for SGXv1 prototyping, but this is all I can find at the moment.) Honestly though given all that it's still hard to find what actually defines SGXv2 in terms of features or errata, though. But FLC is the major requirement that will allow mainstream kernel support, from my understanding.
- Reelin 7y ago
  That's... slightly better? I think? Honestly SGX is complicated enough that I'm not entirely sure I have this straight. Am I correct in thinking that: 1. A user-programmable MSR would allow the device owner to falsify the attestation of enclave initialization (when using their own keys). 2. The ME (and other firmware) would still not be replaceable or owner controllable. 3. Due to 2, enclave compromise would have to be premeditated. That is, once an enclave is up and running IIUC it can (potentially) use MRENCLAVE to derive the sealing key. Without control of the ME that enclave would be unbreachable, correct? So realistically, to maintain control of code running on my device I would have to set my own SGX keys and configure my system to actively compromise all enclaves at launch. From a security standpoint, there's still a black box (the ME) with super-root that could be compromised by attackers that I can't inspect, modify, or disable. And from a political standpoint, there's still a tragedy of the commons regarding DRM if the majority of providers decide to require SGX with Intel root keys as a condition of service. Have I misunderstood anything? (While responding, I stumbled across an interesting paper regarding using SGX to protect malware against researchers: https://arxiv.org/abs/1902.03256 https://arxiv.org/abs/1902.03256) Edit: It appears I was overly optimistic - playback of 4k BluRay already requires Intel SGX. (https://old.reddit.com/r/Amd/comments/bw0cwq/will_ryzen_3rd_gen_finally_support_4k_bluray https://old.reddit.com/r/Amd/comments/bw0cwq/will_ryzen_3rd_...)

viraptor 7y ago

> "Trust" is always used in "Root of trust" and "Trustworthy computing" to mean "deny software freedom to the user." That's not what "root of trust" means. Root of trust is normally a certificate which signs other certificates. If you trust that top level certificate to be valid, it means you can trust that the certificates signed by it are valid as well. That's all there is to it. What someone does with the certificates - whether that's signing TLS traffic, or execution attestation is completely separate. I don't think you'd argue that TLS is used to "deny software freedom to the user" - right? (https://en.wikipedia.org/wiki/Root_certificate https://en.wikipedia.org/wiki/Root_certificate) "trustworthy computing" is not a technical term, but a marketing phrase. (https://en.wikipedia.org/wiki/Trustworthy_computing https://en.wikipedia.org/wiki/Trustworthy_computing) You're probably referring to "trusted computing" which is a very specific use of signing and attestation of computing states. It uses the chain of trust in the same way it uses addition (or substitute any higher level concept you want) - you can't say "addition is bad, because it denies software freedom to the user" in this case.

tremon 7y ago
You're probably referring to "trusted computing" which is a very specific use of signing and attestation of computing states. If it is so specific, why is it present in every single Intel CPU? And why aren't end users able to delete the built-in root of trust and replace it with their own? Trusted computing, as implemented by Intel, is actively hostile to the citizens of a free society. So in this case, I really can say that it denies software freedom to the user.
- viraptor 7y ago
  You can disable SGX in your Bios. It don't give you any new features then, it doesn't deny any freedoms either.
nelgaard 7y ago
>I don't think you'd argue that TLS is used to "deny software freedom to the user" - right? No, but if I could not make a website that was not signed by e.g. DigiCert, then I would argue that something was not right.