RE: [Nea] RE: Detecting Compromised Endpoints

["Marcus Leech" <mleech at nortel.com>]

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.

The essential problem is that for any *practical* operating system for
  purposes of general-purpose computing, there *is* application code,
  the compromise of which, can cause the system to violate its security
  policies.

The only thing the hash does is to assert that the code is free from any
  *known* vulnerabilities.  Once the system is compromised, it can
continue
  to provide an idyllic view to the TPM/PCR machinery.


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.

You have to assume that a compromised system would be able to maintain
  a consistently-idyllic view using some similar type of "subscription
service".
  Essentially, a compromised system can continue to update the view of
the
  world it wishes to present to the TCG subsystems.  The *reality*,
however,
  will be quite different.
 

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.

There's also the scenario of a NAT-like device in a
TCG/TPM/NAP/NAC/whatever
  world.  You have a "policy-compliant" system act as a proxy for a pool
  of non-compliant nodes.  "Fixing" that kind of scenario tends to
produce
  a system that is unusable for ordinary use.  Perfectly secure, and
utterly
  unusable.

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.

That only applies to "compromised on disk".  The state of said software
  at some time T after it has begun executing *cannot* be attested-to
  by anything.  If that were possible, then it would imply having a
  general solution to the halting problem.  In fact, even the known-good
  PCR values are only attesting to the fact that the software is known
to
  be resistant to all the vulnerabilities we *know about* in the
software.
  With the emergence of zero-day exploits of vulnerabilities, I wonder
  how useful this will actually be.
   
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).

The problem is that *real* generally-useful computing environments are
still
  going to have very large components that have to be trusted to behave
  correctly at all times.   If you have an operating system that has all
those
  desirable properties, then you don't need any of this TPM/TNC/NEA/TCG
goop.

The raison d'etre for this stuff is precisely because operating systems
today
  are vulnerable due to a large number of factors, including broken
architectures,
  programming language design, human frailty, etc, etc.  And it is
precisely because
  of that that this stuff can't be made to work, for any
sufficiently-rigorous
  definition of the word "work".

The bad guys are getting cleverer, and a large fraction of the "good
guys" haven't
  actually done any detailed analysis of all this TCG/TNC/TPM/NEA stuff
yet.
  I fully expect that there will be gaping holes found within two years.

I'd be perfectly delighted to be proven wrong.


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