On May 13, 2016 2:42 AM, "Dr. Greg Wettstein" <greg@xxxxxxxxxxxx> wrote: > > On Sun, May 08, 2016 at 06:32:10PM -0700, Andy Lutomirski wrote: > > Good morning, running behind on e-mail this week but wanted to get > some reflections out on Andy's well taken comments and concerns. > > > On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" <greg@xxxxxxxxxxxx> wrote: > > > > > > > > > This now means the security of SGX on 'unlocked' platforms, at least > > > from a trust perspective, will be dependent on using TXT so as to > > > provide a hardware root of trust on which to base the SGX trust model. > > > Can you explain what you mean by "trust"? In particular, what kind > > of "trust" would you have with a verified or trusted boot plus > > verified SGX launch root key that you would not have in the complete > > absence of hardware launch control. > > > > I've heard multiple people say they want launch control but I've > > never heard a cogent explanation of a threat model in which it's > > useful. > > Trust means a lot of things and does not always have a 'threat model' > associated with it. Security is all about the intersection of > technology and economics and moving forward, will be driven by > contractual obligations and re-insurance requirements, that is at > least what we see happening and are involved with. > > In a single root of trust, as was originally developed for SGX, trust > consists of a bi-lateral contractual guarantee between Intel and a > software developer. A contractual guarantee by Intel that an enclave > launched under the security of its root key will have prescribed > integrity and confidentiality guarantees. In reciprocation the > developer delivers to Intel an implied trust that it will not use > those guarantees to protect illicit or malicious software behavior. > > That may not have implications with respect to a specific threat model > but it could have significance in a re-insurance model where a client > of the software environment can indicate that they had an expectation > that code/data which was committed to this environment was > appropriately protected. The refusal to launch, ie. a launch control > policy, provides a hardware implementation of that trust guarantee. > If so, this means that the client and/or their lawyers screwed up severely. The certification that integrity and confidentiality are protected has *nothing* to do with launch control. (It's trivial to break, too - just run the code in an SGX simulator or tweak the MACs and launch in debug mode. The code can't directly tell the difference.) In this regard, SGX is very much like TPM-based security. With a TPM, even if the hardware is somehow fully protected against physical attacks, the TPM will not prevent corrupted or malicious code from running. At best, it prevents such code from unsealing things protected by PCRs or from attesting to PCR state. Similarly, SGX won't prevent code from running on a corrupted platform (e.g. one that simulates SGX instructions). Instead, it prevents EREPORT and EGETKEY from deriving the expected keys in such an environment. The correct way to do this is using the Quoting Enclave from Intel or using a differently bootstrapped approach -- see below. The verifier and Intel have an agreement and share some keys, and quoting actually checks something relevant. > All of this changes in a future which includes unlocked identity > modulus signatures. No, the only thing that changes is that the the ability for the lawyers or security architects to screw up in this particular way is reduced. EREPORT still checks signatures. > > > > I would assume that everyone is using signed Launch Control Policies > > > (LCP) as we are. This means that TXT/tboot already has access to the > > > public key which is used for the LCP data file signature. It would > > > seem logical to have tboot compute the signature on that public key > > > and program that signature into the module signature registers. That > > > would tie the hardware root of trust to the SGX root of trust. > > > Now I'm confused. TXT, in theory*, lets you establish a good root > > of trust for TPM PCR measurements. So, with TXT, if you had > > one-shop launch control MSRs, you could attest that you've locked > > the launch control policy. > > Correct. > > In the absence of launch control with an authoritative root of trust > an alternative trust root has to be established. Integrating the load > of the SGX identity signatures into tboot provides a framework where > the trust guarantees discussed previously can be tied to the identity > of the hardware platform and its provisioner. > > This in turn provides a framework for contractual security guarantees > between the platform provisioner and potential clients. No, at most it provides a way for the platform provisioner and the client to mess up. I can see two ways to get these types of assurances. 1. Use Intel's provisioning and quoting mechanism and sign Intel's quoting service contract. 2. Bootstrap your own. That is, when provisioning hardware, the platform provisioner stashes something derived from EGETKEY output in the provider's database. (This is more or less what Intel does when provisioning new Skylake chips, but nothing (except the current Launch Control mess) prevents another platform provisioner from doing the same thing when the buy the chip from Intel. Then use EREPORT to verify client enclaves to an enclave supplied by the provisioner and use EGETKEY in an enclave from the provisioner to allow that enclave to assert the client enclave's signer and the platform identity to the provisioner's cloud service, which can do whatever it likes with this assertion. Launch Control doesn't help at all. In fact, it hurts, as the client would need to contract with their platform provisioner *and* with Intel if launch control is enabled. > > > But what do you gain by doing such a thing? All you're actually > > attesting is that you locked it until the next reboot. Someone who > > subsequently compromises you can reboot you, bypass TXT on the next > > boot, and launch any enclave they want. In any event, SGX is > > supposed to make it so that your enclaves remain secure regardless > > of what happens to the kernel, so I'm at a loss for what you're > > trying to do. > > As a Trusted Execution Environment (TEE) the notion of SGX is that it > run run code and data in an Iago threat environment, where the > hardware and operating system have been lost to an aggressor. You can > technically provide that guarantee in the original SGX root of trust > model but that changes in the presence of an unlocked identity model. > I think you're still confusing launch control with attestation. They're so different that Intel's policy pages about them don't even appear to reference each other. > The TPM2 architecture will be the hardware security model moving > forward. If you look at the new attestation model the hardware > reference quote includes an irreversible clock field in order to > defeat the threat model you describe above with a malware induced > platform reboot. > > Beyond that, at least in our work, we directly tie the launch of our > security supervisor to an integrity chain which must be delivered from > a functional TXT/TPM implementation. Our platform won't boot and > deliver its qualifying attestation to a security counter-party if the > TXT based boot was bypassed. Emphasis missing on "deliver its qualifying attestation to a security counter-party". The really annoying thing about TPM and TEE-style security is that you have to root your trust in boot-time configuration. SGX is supposed to get us away from that. By trying to assert things about MSRs, you're forcing yourself to get stuck with boot-time configuration checks, and you're losing the advantage of SGX. You might as well rely solely on the TPM if you want to do this. > > Given Microsoft's findings in their follow on paper to their Haven > work a hardware/OS root of trust model is still important in a single > root of trust model. At least until Intel comes up with a constant > time hardware memory model, which is what we expect to see if Intel > continues to move forward with refinenments to SGX and the notion of a > commodity TEE. > > Given the published vulnerabilities to memory side channel analysis > the SGX platform currently requires that the hardware provisioner > implement a guarantee that the platform is in a deterministic state > and has not been influenced by interlopers. So platform behavior > attestation is going to be an essential component moving forward, > hence the need for involving TXT. AFAICT Intel does this already. SGX won't launch enclaves at all unless some ACM certifies that the MEE is set up right. <off-topic> > > > * There are some serious concerns about the security of TXT. SGX is > > supposed to be better. > > SGX and TXT address different issues and, as noted above, will be > synergistic with one another. > > As somewhat of a nitpic, TXT is actually about a lot more then a root > root of trust for the TPM2 PCR registers, since it addresses a lot of > issues regarding the initialization of the chipset and processor to > known states. Getting the PCR registers into a provable state is more > or less a side effect of everything else it does. I think you're thinking about this wrong. TXT is about doing various things to securely set up the platform and then, critically, certifying that it did those things by setting up the PCRs. Just like SGX is about launching an enclave securely and then certifying it with EGETKEY and EREPORT. If all you do is boot your kernel with TXT + tboot and ignore the PCRs, you gain nothing at all except for some cold-boot protection. > > The issue of the security of TXT comes up often and is secondary to > the excellent work which Joanna Rutkowska and her colleagues did in > defeating the early implementations of TXT. That work is five years > old now and secondary to Intel reacting rather aggressively with > modifications to their ACM, the technology hasn't seemed to be > fruitful for security researchers since then. > > One of the valid criticisms which Joanna leveled was over the lack of > protection for SMI and the need for an STM monitor to protect the > system in advance of tboot/TXT beginning its trust chain. Intel > published the first revision of their documentation on their STM > monitor in August 2015 so they have closed the loop on that aspect of > her concerns. We will have to see how availability for that > technology appears and how it stands up in practice. Availability appears to be nil. Also, AFAIK there's no point unless you can audit the monitor, which is more or less the same as auditing the SMRAM code. Also, have you noticed that the TPM2 appears to be a *software* thing, running in the same privilege domain as the Intel AMT *web server*? Maybe Intel finally ditched that -- I haven't checked. </off-topic> --Andy _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
