From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752417AbcEMJnK (ORCPT ); Fri, 13 May 2016 05:43:10 -0400 Received: from wind.enjellic.com ([76.10.64.91]:53281 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751312AbcEMJnH (ORCPT ); Fri, 13 May 2016 05:43:07 -0400 Date: Fri, 13 May 2016 04:42:37 -0500 From: "Dr. Greg Wettstein" To: Andy Lutomirski Cc: "Dr. Greg Wettstein" , "linux-doc@vger.kernel.org" , Thomas Gleixner , Mathias Krause , "open list:STAGING SUBSYSTEM" , "Austin S. Hemmelgarn" , Pavel Machek , Ingo Molnar , Greg KH , Boris Ostrovsky , Borislav Petkov , Jarkko Sakkinen , Wan Zongshun , Kristen Carlson Accardi , open list Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions Message-ID: <20160513094237.GA19210@wind.enjellic.com> Reply-To: "Dr. Greg Wettstein" References: <1461605698-12385-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20160426190009.GC8162@amd> <20160429201744.GD27821@intel.com> <142feb98-3a97-0b00-0b17-b029fa2c637f@gmail.com> <20160503090627.GA27301@wind.enjellic.com> <20160506113944.GE24074@intel.com> <20160508095843.GA5144@wind.enjellic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: name -s -r X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [0.0.0.0]); Fri, 13 May 2016 04:42:38 -0500 (CDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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" 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. All of this changes in a future which includes unlocked identity modulus 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. > 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. 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. 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. > * 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. 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. Once again I leave the discussion with the fact that security is all about economics and risk management. Provable security is not going to exist in practice, particularly in an environment where aggressors have unfettered access to a hardware platform. Our experience suggests that there are economic opportunities and needs for making platforms which are 3-4 orders of magnitude more difficult to compromise. Currently our industry revolves around hopelessly trying to patch software vulnerabilities, so we need to be open to trying different things and ideas.... :-)( > --Andy Have a good weekend. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102 development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "Man, despite his artistic pretensions, his sophistication and many accomplishments, owes the fact of his existence to a six-inch layer of topsoil and the fact that it rains." -- Anonymous writer on perspective. GAUSSIAN quote.