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

From: Randy Turner (rturner@amalfisystems.com)
Date: Thu Apr 30 2009 - 16:19:05 EDT

  • Next message: thrasher@lexmark.com: "IDS> Fw: Notice of Change to June 2009 F2F meeting dates (new dates June 23-25, 2009)"

    To emphasize something in Steve's TPM text below....we left the last
    HCWG with an action item for vendors to ask their respective customers/
    marketing folks whether or not a TPM was required....what we should
    actually be asking is whether the "features" of the TPM are required,
    specifically those features that differentiate TPMs from ordinary
    hardware security modules (HSMs). Especially remote attestation and
    secure booting.

    Randy

    On Apr 30, 2009, at 12:23 PM, Brian Smithson wrote:

    > 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.
    >
    > -------- Original Message --------
    > Subject:
    > RE: [hc_wg] Apr. 29th TCG Hard Copy Work Group Bi-Weekly
    > Teleconference
    > Date:
    > Thu, 30 Apr 2009 14:42:24 -0400
    > From:
    > Seigo Kotani <seigo.kotani@us.fujitsu.com>
    > To:
    > <hc_wg@trustedcomputinggroup.org>, <Junichiro.Hamaguchi@KTD-Kyocera.com
    > >, <Graeme.Proudler@hp.com>, "'Stephen Hanna'" <shanna@juniper.net>,
    > "'Brent Richtsmeier - APST'" <brentr@sisa.samsung.com>, <KaseyKim@samsung.com
    > >, <n.heo@samsung.com>, <slivengood@sisa.samsung.com>, <d.obukhov@sisa.samsung.com
    > >, "'Volkoff, Brian A'" <brian.volkoff@hp.com>
    > CC:
    > 'TCG Administration' <admin@trustedcomputinggroup.org>
    > References:
    > <006c01c9c844$5db600f0$192202d0$@kotani@us.fujitsu.com>
    >
    >
    > 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



    • application/pkcs7-signature attachment: smime.p7s


    This archive was generated by hypermail 2.1.4 : Thu Apr 30 2009 - 16:19:13 EDT