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.
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@xxxxxxxxxxxx
------------------------------------------------------------------------------
"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.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
