Trusted Computing: Just Wishful Thinking?

"Plays well with others" aren't the first words that come to mind when we think of Microsoft and Sun Microsystems. Throw Intel and AMD into that mix, along with Hewlett-Packard, IBM and Sony, and you have the seven principal members of the Trusted Computing Group. The TCG is augmented by an impressive roster of contributors, including prominent desktop-security and patch-management vendors, but not everyone who should be involved is. Cisco Systems, Computer Associates, Novell, PalmOne, Red Hat and 3Com aren't on board.

Still, enough major players are involved in the group that there's a corresponding load of hype. One whopper is that the TPM (Trusted Platform Module) and trusted computing are synonymous with DRM (digital-rights management). The reality is that strengthening content key distribution to enable DRM is one use of a TPM, but the main attacks against digital rights, such as copying data in memory after it has been decrypted, are possible with or without the TPM (for more on the rumors versus the reality, see "Myths and Legends,").

Have Faith, Will Compute

Like most security pros, we don't view the world through rose-colored glasses, so we don't expect products based on TCG specs to work perfectly and interoperate from the get-go. Time and again, we've seen well-meaning, smart people develop specifications that result in interoperability nightmares--the standards around PKI and IPsec come to mind. But if TCG specifications don't get bogged down in infighting or go awry (see "Enforcing Trustworthy Use,"), there's a good chance these initiatives will make our lives easier. The TCG specs address the technical aspects of trusted computing, but the real challenge will be incorporating the technology into products that will be useful without adding undue administrative overhead.The TCG's notion of trusted computing centers on three core concepts that revolve around a PC or server incorporating a TPM. TPMs are embedded in PCs or servers and perform functions on silicon that enable a TPM-equipped computer to authenticate itself, store data securely and make authoritative assertions about that data, and measure and report on its state.

The idea is that a computer in a known state, running known programs, can be trusted more than a computer in an unknown state. Makes sense to us. But the devil is, as always, in the details.

Computers are prone to attacks through a variety of methods--exploited vulnerabilities, virus and worm infections, malicious users installing Trojan horses, keystroke logging and so on. Compromised computers can be used as zombies to carry out all kinds of nasty functions, like spamming, denial of service and data capture. All these attacks involve changes to the way the OS and applications work--all cause alterations in the executing programs that take the system from normal to abnormal. If the subseven back door gets installed and executed on a computer, for example, all of a sudden it's listening on a port and interacting with the OS. Likewise, if an application is Trojaned, the executing code has been modified.

Plenty of products attempt to address these weaknesses, but there are two main problems with current security wares: They lack a way to get trusted measurements of programs or data so we can be assured that our programs are authorized and have not been subverted; and there's no way to ensure that disparate products on the hosts and the network will use that data.

So how has the TCG addressed these problems? The group has defined a set of specifications, currently TPM 1.2, that describe how to perform integrity measurements of hardware and software and allow for protected storage and reporting of these measurements. The TNC (Trusted Network Connect) initiative defines methods and specifications vendors can use to store and report integrity data within the TPM and protocols that let a platform interoperate with external services, such as a policy server or the infrastructure (TNC specifications are being finalized at the time of this writing).A TPM is the hardware component of a trusted platform. Chip vendors such as Broadcom Corp. and Atmel Corp. are shipping TPMs to PC vendors, including HP and IBM. The TPM holds a handful of keys and performs all cryptographic functions on the chip. It serves three main functions: trusted measurement, trusted reporting and secure storage.

The TPM is attached to the motherboard and is loaded prior to shipping with a public-private key pair, called an endorsement key (EK), and the associated credential, which is a digital certificate containing the EK public key and other identifying information. The endorsement credential identifies that TPM and, by extension, the platform on which it resides. The endorsement key and credential pose a privacy risk if the credential is used by external parties because it ties the TPM to a platform and a user.

TPM use is an opt-in process--the platform owner, whether an individual user or a corporate IT department, must enable and initialize the TPM. Subsequent operations also must be gated through the user.

One of the main functions of the TPM--making authoritative statements about the condition of the platform, also called attestation--requires the TPM to prove that, at the very least, it is a valid TPM, and it may also require the TPM to identify itself. Sometimes, the unique identifier is useful for asset management and platform authentication, similar to how Windows 2000 Active Directory and NT Domains function. But when dealing with external entities, any identifying leakage can pose a risk.

The TCG has come up with two ways of anonymizing identifying information while trying to retain the benefits of a TPM. Both methods use an attestation identity credential and associated public-private key pair.The first approach uses a trusted third party, similar to a certificate authority, to validate and sign an AIK (attestation identity key) for the TPM. During the enrollment process, the TPM generates a public-private AIK pair and sends the AIK public key and other data signed by the endorsement key to the issuer. The TPM authenticates with the issuer using the TPM endorsement public key, and the signed AIK is returned to the TPM. The trusted third party can, of course, identify a specific TPM using the EK. However, operational controls should forbid such disclosure. When a TPM signs something, it will use the appropriate signed AIK to prove it's a valid TPM.

After the European Union raised privacy concerns about the endorsement key and the trusted third party, the TCG came up with an alternative solution, called direct anonymous attestation. It relates a DAA private key generated by the TPM with a group public key of a DAA issuer. Through a complex protocol, the TPM authenticates itself and proves to a DAA issuer that it's valid without revealing its identity. The TPM does not ensure that the issuer is authorized to issue DAA credentials. The user must make sure the issuer is valid through some external means, such as a digital certificate.

DAA may not be completely anonymous: A TPM using name-based DAA creates a pseudonym for a DAA key that can be reused. However, multiple uses of the same name-based DAA key by a TPM allows tracking. Random-based DAA generates a new DAA key for each transaction, making for a virtually untraceable signed operation. When a TPM signs something, it uses an AIK and proves it's a valid TPM using the DAA key to sign the transaction.

It's important to understand the level of anonymity DAA offers. The DAA process means your TPM can be identified as part of a group of computers, but not a specific one, and if you use name-based DAA, your activity can be tracked because you're a returning entity, much like with HTTP cookies. Only random-based DAA provides full anonymity because your DAA key changes per transaction, but the downside is you have to complete a new DAA enrollment each time. In theory, anyone can run a DAA issuer service, including your IT department. Once the TPM on a platform is enrolled with an issuer, you can treat the platforms as group members. For example, your VPN users could have a DAA key signed by the VPN DAA group public key.

Only a few functions of the TPM reside in silicon. Many components are software that interface with the OS and applications through a defined set of methods and procedures. You don't have to know the details of how the TPM works to use it. And though your platform will need OS support to leverage the TPM, TCG specifications are OS-agnostic.TPM implementations are already running in Windows and Linux. For example, IBM ships some ThinkPad T-series notebooks and NetVista desktops with Atmel TPMs installed. Users can download and install the drivers and application, called Embedded Security Subsystem 2.0, to provide secure storage for passwords, file and folder encryption, and a Microsoft GINA (Graphical Identification and Authorization) replacement that leverages the TPM.

With flagrant disregard for our IT policies, we enabled the TPM and installed the software on a ThinkPad T41. During the TPM initialization, we created an admin account and designated authorized users of the TPM, a simple process. HP ships TPM in its d520 and dc7100 desktops, and models of its xw workstations and nc notebooks. Embedded Security for HP Protect Tools offers functionality similar to IBM's Embedded Security Subsystem. For Linux, IBM Research has developed a Linux TPM driver, and Applied Data Security Group has a Linux driver for the Infineon SLD 9630 TPM and a trusted GRUB boot loader. These forays by commercial and open-source projects demonstrate the viability of the TPM to operate on nearly any platform.

The TPM helps form a trusted platform when the software components can be measured, stored and reported in a trustworthy manner. Ideally, there should be no way for the TPM or its software components to be subverted, and with the exception of physical attacks against the TPM (a possibility acknowledged by the TCG), this is largely the case.

Using a variety of methods, the computer hardware and software are measured and collectively form a baseline of the computer configuration. The measurements could be of the entire system, such as a trusted boot process (see diagram below), or a subset of components, such as the OS, configuration data and security software. Variations from the baseline on subsequent measurements mean a change in the computer may--or may not--have rendered it untrustworthy. Changes could be authorized, such as patches or configuration changes, or unauthorized, such as a worm or virus infection. One of the TCG's design goals is that when change is detected, individual users and organizations must determine if the change is authorized and trustworthy.

That's a tall order. For example, if you download and install ZoneAlarm, Check Point ZoneLabs' desktop firewall, the package contents are signed using ZoneLabs' code-signing certificate. The certificate is trusted because it's signed by a third-party CA (certificate authority) that's in your OS certificate store. If the issuing CA properly verified the identity of the person who requested the signing certificate, and the private key associated with that code-signing certificate is properly protected, you can trust that the signature over the installation package identifies the issuer, ZoneLabs, and that the package has not been compromised. Once you install the software, ZoneAlarm runs its own integrity check on initialization and should fail if it was compromised. Of course, it is possible, though not probable, that the program could be compromised and remain undetected. Assurances that the executable code has not been changed can be enhanced during installation by having the software managing the TPM, called the trusted software stack (TSS), measure executable files and store those files within the TPM. Each time the application is launched, the TSS measures the software and continues the execution only if the software has not changed.

All the TPM adds to this scenario is external measurement and reporting of the program. Important? Perhaps. Existing measures work, for the most part, and you'll get better protection by removing local administrator rights from users so that worms can't change the local HOSTS file or install software in start-up locations. In addition, the TCG specifications don't address a painfully common security problem--exploitation of running software. Of course, using a TPM to measure and report on system configuration should provide strong assurance that the system is functioning as expected, because it should be impossible, without the use of a hardware attack, to compromise the measurement and reporting mechanisms.

Bottom line, the TCG TPM is a bandage for a more systemic problem: Trusted computing must consist of more than measuring a block of bits at a point in time. Rather, it should be focused on ensuring that the platform operates in a known manner, and that there are hardware and software mechanisms that cordon the platform off into protected silos. Code reviews of applications and assertions that vendors use secure software models are all important to trusted computing. Intel's LaGrande Technology, which enhances hardware security, is a promising initiative we'll be watching, and technologies such as SE Linux and Trusted Solaris attempt similar functionality in the OS.

Network ConnectThe TCG's most promising work is happening within the Trusted Network Connect working group. The TNC is focused on standardizing the protocols, message formats and APIs that let disparate security products interoperate, so that a host can report its condition to a policy server, which, in turn, can inform the network infrastructure to provide intelligent access control.

Today's network access control products, like the ones we reviewed last issue (see "Inspected/Approved," at www.security pipeline.com/showArticle.jhtml?articleID=57701928), can assess endpoint configurations and grant or deny access. An agent attempts to determine if the antivirus, firewall and local policies are current and running, and that the executables have not been infected. The problem is that there are no standards for integration, and each vendor must write integration code for every other product it wants its wares to work with. Cisco, Microsoft and other vendors have integration programs in place, but of course, integration is product by product and the level of success varies. There's no guarantee, for example, that antivirus software, desktop firewalls and patch-management systems will work together. We view this as a major roadblock to NAC adoption (see "Network Access Control Within Reach?," at nwc. securitypipeline.com/trends/48800457). The work in the TNC promises to change that situation.

All Together Now

An ongoing issue is the certification of products to interoperate. The TCG conformance group is tasked with developing specifications. Currently, there are tools available exclusively to TCG members to self-validate parts of TCG specifications, but when we asked the TCG about conformance plans, it didn't have a story to tell regarding an external certification process, products or even bake-offs, nor has it determined if the validation tools will be made public or if membership is required to access the tools. Without third-party certification and bake-offs, there is scant chance that interoperability will be seamless; this will negatively impact the scope the TNC members are striving for.

Mike Fratto is editor of Secure Enterprise. Previously, he served as a senior technology editor for Network Computing at its Syracuse University Real-World Labs and as an independent consultant in central New York. Write to him at [email protected].• Trusted Measurement: The TPM forms the root of trusted measurement for a given platform. In this case, "measurement" means taking an SHA-1 (Secure Hashing Algorithm 1) hash of executable code or data when requested. Data hashed using SHA-1 has a unique hash value. Deviations--even by one bit--result in a different hash value, so Trojan-affected applications or unauthorized data can be detected.

The thorny question is, how do we know the measurements are correct? The answer lies in the Core Root of Trusted Measurement (CRTM), which is part of the TPM and commonly on the same chip. At system boot (see "Trusted Boot Process,"), the TPM starts up and runs a small series of self-tests, then the CRTM measures each subsequent component in the BIOS boot sequence and stores the values. The BIOS takes over and measures other components as directed, storing those values. After the BIOS completes its initialization, the boot loader is measured, and boot-up is passed to the boot loader. Further measurements are handled by the OS in software, with values stored in the TPM. We assume the TPM is operating properly and that the CRTM has not been subverted.

• Trusted Storage: To be trusted to report data, the TPM must securely store that data. The TPM forms the Root of Trusted Storage (RTS). When the TPM is initialized, a storage root key (SRK) is generated by the TPM and stored on the chip. There is limited storage capacity in the TPM, so the SRK is used to encrypt other keys for off-chip storage. Because the SRK never leaves the TPM, it forms the basis for protected storage. A TPM can store measurements performed by itself or trusted software, other storage keys, signing keys, passwords and other small units of data. It is not a bulk encryptor, however. A key-cache manager, running outside the TPM, moves data to and from external storage. When data protected by the TPM is needed, the key cache manager retrieves the data and passes it into the TPM, which decrypts the data and sends it on its way. For example, if the data is a password, the TPM passes it up to the caller.

• Trusted Reporting: Of course, taking and storing measurements does little good if the data can't be used. Trusted reporting is a way for the TPM to attest to making accurate measurements of system components, securely storing those measurements and then securely reporting them. This process is called "attestation" within the TCG. Attestation doesn't imply anything more than that the TPM accurately measured a component. It's up to the consumer of the attestation to pass judgment on the results.

The Trusted Computing Group is striving to balance the needs and wants of its members against its goals of providing methodologies for trustworthy computing systems. But make no mistake: The TCG is a vendor-facing organization. Vendors pay its bills, and vendor employees staff its working groups.There are two areas of concern for both enterprises and the consumer markets regarding trusted computing: privacy and lock-in. In both, the TCG has shied away from taking bold stands.

Enterprises and consumers alike bristle when a privacy threat rears its ugly head. Consumers don't want to be tracked and monitored. Organizations don't want to be tracked and monitored by external parties either, but some operational benefits to internal asset tracking and monitoring exist. So, what about external tracking?

The TCG says user choice must be preserved when using the TPM. Users can allow or disallow an application to access the TPM. But what if an application developer requires its use? Moreover, what if that use is to track activity? What can the user do then? Avoid using the product? That may be easier said than done. The activity that the TPM is used for may be obfuscated in a EULA or buried in modal dialogs. At any rate, users may not understand why the vendor wants to use the TPM.

As for product lock-in, misguided software vendors, under the rubric of enforcing copyright or enhancing licensing, may attempt to lock a user to a specific application to access certain types of files. We could see a vendor using the TPM to generate and store encryption keys used to encrypt documents or music files such that only their proprietary applications can open them.

The TCG condemns abuses of the TPM, and we believe the people in the working groups are well-meaning individuals. We certainly wouldn't blame the TCG for outsiders' misuse of its work, but the group's position is that such abuse is beyond the scope of its charter. That's not good enough.The Trusted Computing Group has a responsibility to state precise guidelines about acceptable use of the TPM and to develop ways to ensure that the spirit of the TCG is enforced. Surely a group of people who can develop anonymous authentication are up to this less complex task.

The Trusted Computing Group is undertaking an enormous task: to enable trusted computing through open standards. But we're not convinced the Trusted Platform Model, by itself, is that big a deal. As with other well-founded technologies, there isn't much market pressure to use trusted storage and attestation, outside of a few niche applications. But the operational and organizational changes required to use the TPM for simple uses, such as key storage for Microsoft EFS (Encrypting File System) or digital signatures, are huge.

We see the real short-term value in the Trusted Network Connect--provided the members truly develop reliably interoperable solutions and that the TCG and you, its constituents' customers, pressure other vendors to follow suit.

There's confusion about trusted computing and the Trusted Platform Module, much of it arising from misunderstandings of the guidelines promulgated by the Trusted Computing Group. Certainly the TPM can be abused (see "Enforcing Trustworthy Use,"), and there'll be attempts to misuse its features. But market pressures and public FUD are more significant hurdles. Here are some myths that need debunking:

• The TPM will not allow open-source software to run. The TPM can store and report on software, and the OS and components enforce a policy, but any problems running open-source applications are due to the operating system or component. Besides, market pressure isn't likely to allow this type of use. Additionally, the TPM must be enabled manually; if it isn't, it has no effect on the platform.• TPM use means exposing identifying information. This is quite possible, but it isn't a requirement.

• Protected data can't be extracted from the TPM. This one has a grain of truth. The TPM makes extracting protected information much more difficult, and the TCG encourages, but doesn't require, hardware protection mechanisms for the TPM. The TPM specification requires that a TPM be capable of passing FIPS-140-2, but if your organization needs active hardware protection mechanisms, look for a TPM that has passed the appropriate FIPS-140-2 certification.

• Trusted computing is required to combat threats to computers. Not true by any stretch. Trusted computing does help protect computers through attestation and sealing, but this isn't a requirement. Many problems can be mitigated through improved operations.

• Trusted computing will strengthen authentication. This is true only for machine authentication because the private key is generated and protected by the TPM and never leaves the TPM's protection. Sadly, user authentication to unlock credentials stored by the TPM will inherit the shortfalls of the authentication method used. If a password is used to lock a user credential in the TPM, the authentication is only as strong as the password. Credential storage, on the other hand, is strengthened, though credentials stored by the TPM may be passed into software in the clear.

• Trusted computing is going to kick off PKI deployments. This is wishful thinking on the part of PKI vendors. Nothing is going to kick off PKI except for a sound business advantage. The TPM is supporting technology.0