attachment

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> For those who do not have access to the TCG HCWG mailing list, here is the list of TPM capabilities and benefits as promised during yesterday's TCG HCWG conference call.<br> <br> -------- Original Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="right" nowrap="nowrap" valign="baseline">Subject: </th> <td>RE: [hc_wg] Apr. 29th TCG Hard Copy Work Group Bi-Weekly Teleconference</td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">Date: </th> <td>Thu, 30 Apr 2009 14:42:24 -0400</td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">From: </th> <td>Seigo Kotani <a class="moz-txt-link-rfc2396E" href="mailto:seigo.kotani@us.fujitsu.com"><seigo.kotani@us.fujitsu.com></a></td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">To: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:hc_wg@trustedcomputinggroup.org"><hc_wg@trustedcomputinggroup.org></a>, <a class="moz-txt-link-rfc2396E" href="mailto:Junichiro.Hamaguchi@KTD-Kyocera.com"><Junichiro.Hamaguchi@KTD-Kyocera.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:Graeme.Proudler@hp.com"><Graeme.Proudler@hp.com></a>, "'Stephen Hanna'" <a class="moz-txt-link-rfc2396E" href="mailto:shanna@juniper.net"><shanna@juniper.net></a>, "'Brent Richtsmeier - APST'" <a class="moz-txt-link-rfc2396E" href="mailto:brentr@sisa.samsung.com"><brentr@sisa.samsung.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:KaseyKim@samsung.com"><KaseyKim@samsung.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:n.heo@samsung.com"><n.heo@samsung.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:slivengood@sisa.samsung.com"><slivengood@sisa.samsung.com></a>, <a class="moz-txt-link-rfc2396E" href="mailto:d.obukhov@sisa.samsung.com"><d.obukhov@sisa.samsung.com></a>, "'Volkoff, Brian A'" <a class="moz-txt-link-rfc2396E" href="mailto:brian.volkoff@hp.com"><brian.volkoff@hp.com></a></td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">CC: </th> <td>'TCG Administration' <a class="moz-txt-link-rfc2396E" href="mailto:admin@trustedcomputinggroup.org"><admin@trustedcomputinggroup.org></a></td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">References: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:006c01c9c844$5db600f0$192202d0$@kotani@us.fujitsu.com"><006c01c9c844$5db600f0$192202d0$@kotani@us.fujitsu.com></a></td> </tr> </tbody> </table> <br> <br> <pre>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 </pre> <br> <pre class="moz-signature" cols="76">-- Regards, Brian Smithson PM, Security Research PMP, CISSP, CISA, ISO 27000 PA Advanced Imaging and Network Technologies Ricoh Americas Corporation (408)346-4435</pre> </body> </html>