lkml.org 
[lkml]   [2016]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/6] Intel Secure Guard Extensions
    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@enjellic.com> 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.

    \
     
     \ /
      Last update: 2016-05-13 12:01    [W:5.253 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site