IDS> [Fwd: RE: [hc_wg] Apr. 29th TCG Hard Copy Work Group Bi-Weekly Teleconference]

• Previous message: Brian Smithson: "IDS> meeting minutes from today's TCG HCWG teleconference"
• Next in thread: Randy Turner: "Re: IDS> [Fwd: RE: [hc_wg] Apr. 29th TCG Hard Copy Work Group Bi-Weekly Teleconference]"
• Reply: Randy Turner: "Re: IDS> [Fwd: RE: [hc_wg] Apr. 29th TCG Hard Copy Work Group Bi-Weekly Teleconference]"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Dear Member of the Hard Copy Community,

Here is "Brief description of the TPM's capabilities and the benefits"
edited by Steve. 

I believe this is very useful to explain TPM/ TNC benefits.

Best regards,
Seigo

--------------------------------------------------------
------------

From: Steve Hanna
To: P2600, HCWG, PWG
Subject: TPM capabilities for HCD

On Wednesday's HCWG chartering discussion call, I promised to send a brief
description of the TPM's capabilities and the benefits it provides,
especially things that TPM can do that other Hardware Security Modules
(HSMs) cannot.
Here is that summary.

TPM includes secure storage and cryptographic functions, like an HSM.
However, there are a few important differences.
First, a TPM is usually much cheaper than an HSM. That's because a TPM is
simpler and because large quantities of TPMs are built into chipsets and
shipped in enterprise PCs.
Second, TPM is built on open standards. All TPMs support the same commands.
There will soon be a certification program for TPMs and a Common Criteria
protection profile is already available. But the thing that makes TPM
special is its ability to perform trusted boot, sealing, secure boot, and
remote attestation. I'll describe these features and then discuss their
relevance to HCD applications.

For trusted boot, the TPM is used to measure the critical hardware,
software, and configuration elements on a system.
I won't go into the details of how this works but basically the TPM ends up
with a hash of all the components that need to be trusted to keep the system
secure. This hash is stored in a Platform Configuration Register (PCR) on
the TPM. The trusted boot process is designed so that any bad software in
the boot sequence will show up in the resulting PCR value. Therefore, bad
software can't hide.

One use for trusted boot and measurement in general is to ensure that
certain special data can only be decrypted in a trustworthy environment.
That's called "sealing".
The TPM is given some special data (like an encryption
key) and told to encrypt the data and never decrypt it unless a certain PCR
has a certain value. That ensures that the data can only be read when the
system is in the desired state with the desired software and such.

Why would you want to seal things? If you're concerned that your OS might
become infected and you want to make sure that your secrets can't be read in
that circumstance.
This is really useful for Digital Rights Management, among other things.
People can't load up your DVD playing software on a VM and then step through
and grab the DVD decryption key out of memory. But it's also useful any time
you're concerned about your OS becoming infected.

Secure boot is easy to implement now. Just encrypt the main partition of
your hard drive and seal the encryption key so that it can only be decrypted
when the proper boot sequence (BIOS and boot loader) has been loaded. You
can even do this in several stages: seal your OS to the right BIOS and boot
loader then seal your data to the right BIOS, boot loader, and OS. Now
you're protected against bad software under the OS and in the OS.

TPM has one more trick up its sleeve: remote attestation.
This allows a remote server to determine exactly how a machine is
configured. The machine does a trusted boot and then the TPM engages in a
secure handshake with the remote server. The TPM sends its PCR value to the
remote server in a secure manner so that the remote server can verify that
this is a current PCR value from that machine and that the value hasn't been
tampered with.

This foils the "lying endpoint problem", a classic problem with
software-only Network Access Control (NAC). What if the endpoint becomes
infected with software that causes it to lie about its health, saying its
healthy when it isn't?
With trusted boot and remote attestation, the NAC server can query the TPM
to verify exactly what's running on the endpoint. Bad software can't lie or
hide itself. Of course, TPM-assisted NAC provides all the benefits of NAC:
preventing unauthorized users and devices from connecting to your network
(if desired), identifying unhealthy devices and enabling automatic
remediation of problems, etc. Having the TPM just makes NAC much more
secure.

The bottom line is that TPM provides the same features as an HSM but it also
provides several ways to detect bad software on the endpoint and limit its
effects.
This protection works against even the most sophisticated rootkits. There
are ways to slow down these rootkits by making an endpoint resistant to
infection. But TPM is the only way to detect a really stealthy infection
once it sets in.

I won't claim that TPM is perfectly secure. Nothing is perfect in security.
You can mount physical attacks on the TPM if you get ahold of it but TPMs
generally resist physical attacks. You can try to infect the machine after
it has booted but post-boot attacks must be mounted every time the machine
reboots so they're easier to detect.
In general, TPM provides the best security available in the commercial
world. That's why NSA is using it in the High Assurance Platform and
Microsoft is using it as the basis for their Trustworthy Computing project.

So you need to ask yourself whether there are customers or applications
where you need to be able to reliably and with high certainty detect bad
software on an HCD.
Today, it may be true that only government customers are really concerned
about infection of an HCD. However, malware keeps getting more
sophisticated. I'm afraid that infection of HCDs may soon become
commonplace.
In that environment, the ability to detect and stop such infections will be
essential. Government customers already require TPM in PCs. If HCD
infections become a big problem, they may require TPM in HCDs. We'll see.
Commercial customers may wish to have TPMs in HCDs to meet compliance
requirements or just to make their networks more secure.

You may also want to consider whether Digital Rights Management is important
to HCD devices. I will admit that I'm not a big fan of DRM. A sufficiently
determined and well funded adversary with physical access to a system that
can read DRM-protected content will always be able to reproduce that
content. That's why audio and video DRM have not worked. But I know that
some folks really like DRM and it may be important to you.
If it is, TPM provides better DRM than software alone.

I hope that this description of TPM capabilities is useful in helping you
decide whether TPM is important for HCD applications. Please consider this
and bring feedback on May 13. As we agreed, this is the key element in
deciding whether to restart the HCWG.

Thanks,

Steve

-- 
Regards,
Brian Smithson
PM, Security Research
PMP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435