[Nea] RE: Detecting Compromised Endpoints

["Stephen Hanna" <shanna at juniper.net>]

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