Dailydave mailing list archives
Re: CSI 2008 Redux
From: RB <aoz.syn () gmail com>
Date: Wed, 26 Nov 2008 23:18:47 -0700
On Wed, Nov 26, 2008 at 05:52, Matthijs Koot <matthijs () koot biz> wrote:
You mention that you were looking at TPM "while trying to solve the (...) physical presence security problem". Although you didn't claim that TPMs provide any solution there, I'd like to emphasize (for other readers) that according to the TCG-specs, TPM is not designed to protect itself against non-"simple" hardware attacks:
:-) I try not to go off half-cocked, and it would have been foolish to claim a TPM guards strongly against physical compromise. It is my understanding that If used properly, they can improve defense against physical compromise to a level slightly less than that of a smartcard, advantage going to the smartcard since they may be readily removed and separately secured.
So 1) being able to manipulate the (locality) modifier is bad, and 2) TPM only provides modest protection against attacker's with physical access. The TCG-people confirm this: TPM is intended to protect against software-based threats (which it may not do very effectively, as Joanna's post suggested, as long as integrity checks can only be done at boot/load-time).
The key is maintaining the chain of trust, and the TPM is only a facility used to aid the process. Mild physical protection aside, it doesn't know or really care whether a link in the chain is compromised, only what each link reports to it. Therefore, the software itself must be "vigilant", as the TPM only provides a safer storage location for a less subvertible canary.
association. It is _just_ a [presumed] secure cryptography facility that supports a wide variety of functionality.Although you didn't claim the opposite, it may be useful to mention that the TPM does not directly expose an interface to its encryption capabilities: TPM does not (yet?) give us general-purpose hardware-accelerated encryption. I'm not sure about hashing and signing.
The state of TPM support is slightly more complex than that. While some cryptography facilities are available (since the EK and SRK private material would otherwise have to be exposed), the hardware is sufficiently slow as to discourage use beyond priming other, much faster routines. I don't think it's ever going to be an accelerant over even the slowest software implementations.
Btw, it is interesting to see TPM being discussed so gentle and reasonable on this list. Perhaps everyone's anticipating TPM to become a new fun target for pentesting :)
Software is software, and many of us have our jobs based on humanity's record on software security. Unless the TC model changes vastly, programmers are still going to have to exercise due diligence in secure programming and monitoring integrity. That isn't happening on a large scale today, so I don't much expect the immediate future to change. I, for one, am glad to see at least some people share my opinion: yes, TPMs could be used for evil, but right now they're just interesting hooks upon which to hang greater security. RB _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://lists.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- CSI 2008 Redux Dave Aitel (Nov 22)
- Re: CSI 2008 Redux RB (Nov 23)
- Re: CSI 2008 Redux Matthijs Koot (Nov 26)
- Re: CSI 2008 Redux RB (Nov 27)
- Re: CSI 2008 Redux Bruce Ediger (Nov 27)
- Re: CSI 2008 Redux RB (Nov 28)
- Re: CSI 2008 Redux Matthijs Koot (Nov 26)
- Re: CSI 2008 Redux RB (Nov 23)
- Re: CSI 2008 Redux Joanna Rutkowska (Nov 23)
- Re: CSI 2008 Redux Alexander Sotirov (Nov 24)