RE: [Nea] RE: Detecting Compromised Endpoints

["Paul Sangster" <Paul_Sangster at symantec.com>]

Nice summary.

There are longer answers to how a number of the mechanisms you describe
below work safely, but this is a great e-mail to kick off the thread.
One other question for the FAQ below would be about the bootstrapping
problem which is interesting to discuss. 

8) If the TPM is passive and software is performing the measurements,
who measures the 1st measurer?

The TCG architecture includes a hardware/firmware component called the
CRTM (Core Root of Trust for Measurement.)  This component is utilized
during the IPL of the system to measure (e.g. SHA-1 hash) the initial
piece of software to be loaded into memory and run on the CPU such as a
more capable loader which is also instrumented to measure subsequent
components establishing the chain of trust. The chain of trust is
maintained in the running PCR values (as discuss below) and is
documented in a verifiable measurement integrity log.  Clearly integrity
protection of the CRTM is very important so its mutability must be
tightly controlled (must be more controlled then normal software on the
disk.)  How this component is bound to the platform and protected gets
into implementation specifics. 

As security people we all know the bootstrapping problem is very
difficult to pragmatically address but we try to raise the bar on
exploits as much as is possible.

Paul

> -----Original Message-----
> From: Stephen Hanna [mailto:shanna at juniper.net] 
> Sent: Thursday, May 25, 2006 10:04 AM
> To: nea at ietf.org
> Subject: [Nea] RE: Detecting Compromised Endpoints
> 
> OK. Let's tackle that nasty question. Can trusted hardware 
> actually detect endpoint compromise?
> 
> I'll give my answer about the TPM here, trying to strip 
> things down to the essentials. I'm sure others from TCG will 
> correct any errors or add any important nuances.
> 
> TPM stands for Trusted Platform Module. A TPM is a trusted 
> security component, usually implemented in hardware. It can 
> do several things and has several applications but the main 
> one we're concerned with here is Trusted Boot.
> 
> If you have a TPM on your machine and Trusted Boot is 
> implemented and enabled, then the TPM is involved in the boot 
> sequence. Before any piece of trusted code is run, it is 
> first measured by the TPM. Measuring means that the TPM takes 
> a hash of the code and combines that hash with all the 
> previous hashes made in the boot sequence, storing the result 
> in a Platform Configuration Register (PCR). The TPM doesn't 
> make any decision about whether each piece of code in the 
> boot sequence is good. It just includes it in the hash.
> 
> When your machine starts an NEA handshake, a Posture 
> Collector on your machine gathers the PCR value from the TPM 
> and sends it securely (more later) to a Posture Validator on 
> the server. The Posture Validator compares the PCR value 
> against a list of PCR values that would come from known good 
> configurations. If the PCR value from the endpoint matches 
> one of the known good values, the machine is fine. If not, it 
> is probably compromised.
> It should be quarantined and examined carefully.
> 
> That's the essence of the answer to how a TPM can detect 
> endpoint compromise. But there are a lot of things I need to clarify.
> 
> 1) What needs to be measured?
> 
>    All the trusted code on the endpoint needs to be measured.
>    That includes all the software and firmware in the Trusted
>    Computing Base, any code whose compromise would potentially
>    cause the system to violate its security policies. This
>    includes the BIOS, the boot loader, the OS kernel, the
>    kernel drivers, etc. If the operating system is well written,
>    it should not include application code since that code
>    cannot cause the system to violate its security policies.
> 
> 2) How does the Posture Collector send the PCR securely
>    to the Posture Validator?
> 
>    The Posture Validator sends a nonce. The TPM signs the
>    nonce and the PCR with a private key stored only on the
>    TPM. The Posture Collector sends the signed nonce and
>    PCR back to the Posture Validator along with certificates
>    that vouch for the TPM's public key. The nonce prevents
>    replay.
> 
> 3) How does the Posture Validator get that list of PCR values
>    for known good configurations?
> 
>    Typically from a subscription service that maintains a
>    list of PCR values for various versions of software from
>    all the major vendors. The decision about which software
>    versions are "good" is a policy decision generally left
>    to the network owner.
> 
> 4) Won't this prevent me from using my favorite OS?
> 
>    That depends on your network's policy. If you don't like
>    their policy, you're free to shop around. Remember that
>    the TPM is an optional component and comes disabled. You
>    can just leave it disabled. Or you can run your favorite
>    OS within an untrusted application. Or you can have an
>    untrusted application forward packets from your favorite OS.
>    Anyway, those subscription services aren't cheap. Trusted
>    boot will probably be mainly deployed in high-security
>    environments.
> 
> 5) How does this let the server detect endpoint compromise?
> 
>    If a trusted software component on the endpoint has been
>    compromised, that will show up as a PCR with an unrecognized
>    value. Because the TPM hashes the software before it's run
>    and won't let the software zero the PCR (and because the
>    hash is preimage resistant), the compromised software can't
>    get the TPM to report a valid PCR value. And it can't
>    replay an old PCR value because of the nonce.
> 
> 6) Aren't there ways to attack this system?
> 
>    Yes. You can break the system if you can successfully attack
>    any one of these: the TPM (with physical attacks or by finding
>    flaws in it), the CAs that signed the TPM's certificates (or
>    their operators), the trusted software that's listed in the
>    known good configs, the cryptographic algorithms and protocols
>    involved, or the Network Enforcer or the NEA server or their
>    operators. There's also a clever attack described in Appendix A
>    of the TNC IF-T document. Countermeasures for that attack are
>    given in that document.
> 
>    I have omitted some attacks for which countermeasures are
>    available. If you have other attacks you're interested in,
>    please raise them and I'd be glad to address them.
> 
> 7) Won't there inevitably be vulnerabilities in the trusted software?
> 
>    Yes. That's true today. It will probably always be true. 
> The best way
>    to handle it is to reduce the number of vulnerabilities by making
>    the trusted software as small and secure as possible. Beyond that,
>    identify vulnerabilities as soon as possible (preferably before
>    exploits are available), prepare fixes, and then remove 
> the old buggy
>    software from the list of known good configurations (or 
> move it to a
>    list of configurations that require quarantine and mandatory
>    remediation).
> 
> Thanks,
> 
> Steve
> 
> _______________________________________________
> Nea mailing list
> Nea at ietf.org
> https://www1.ietf.org/mailman/listinfo/nea
> 

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea