TNCUtil Source Code Documentation available online
The source code documentation for TNCUtil 0.4.3 is now available online.07 Jan 2009
The source code documentation for TNCUtil 0.4.3 is now available online.07 Jan 2009
This article aims to give a high level introduction to the basic concepts of Trusted Computing (TC) and Trusted Network Connect (TNC). For detailed information please refer to the specifications.
The threats to modern IT-systems, especially networks, have changed significantly in the last years. What used to be quiet static and homogeneous in the past becomes more and more dynamic and heterogeneous nowadays. One reason for the more dynamic structure of modern networks is the growing number of mobile endpoints (PDAs, Laptops), that are dynamically connected to various networks accessing the services they need.
Correctly working IT-systems are necessary for a wide range of modern business processes. As a consequence, they are an attractive target for attacks. Therefore, IT-systems need to be adequately protected.
The latest news of the growing number of vulnerabilities, malware and (successful) attacks on IT-systems make clear that there is a need for new, innovative concepts to increase their security level.
The TCG is a not-for-profit organization consisting of more than 170 members (ranging from hardware and software vendors to academic institutions). The TCG develops an open, vendor-neutral framework that aims to significantly increase the security level of todays IT-systems. The framework is described by a set of specifications which are developed by separate work groups within the TCG. The overall goal is to increase the security level of modern IT-Systems by using so called “trustworthy” hardware and software components.
The crucial tool to achieve the stated goal is a passive hardware chip: the Trusted Platform Module (TPM).
The key concepts of Trusted Computing are summarized in the following sections.
The term “trust” has a special meaning in the area of Trusted Computing. TCG defines it as follows: “Trust is the expectation that a device will behave in a particular manner for a specific purpose.”. That is, the term trust does not directly imply a “good” or “desired” behavior.
Instead, trust means that if one knows the current state of a device (e.g. a platform consisting of hardware and software), one can be sure how this device will behave (“good” or “bad”). The problem here is that one must be able to securely obtain the current status of such a platform. A platform that is able to securely report its own state is referred to as “Trusted Platform”.
TCG defines three fundamental features that each Trusted Platform must provide:
Protected Capabilities refers to a set of “special” commands. Special means that those commands have exclusive permissions to access so called Shielded Locations. Shielded Locations are areas in memory where it is safe to operate on sensitive data. Ordinary commands are not able to access those Shielded Locations.
Attestation is the process of vouching for the accuracy of arbitrary information. This is for example the case when a platform wants to prove that is has a certain state (including used hardware, active software) to a second party (the so called verifier). Thus, the platform must be able to provide two kinds of information to the verifier:
The reasoning whether the prove is sufficient and whether the reported state is “good” or “bad” is up to the verifier.
Integrity Measurement refers to the process of measuring the current state (the integrity) of a platform and storing digests of the taken measurements to Shielded Locations. Integrity Reporting is the process of reporting those taken measurements to a second party (formally: attesting to the taken integrity measurements). Integrity Logging is an (optional) intermediate step. It is about storing the taken measurements + further metadata to a log (the Stored Measurement Log) which does not reside in a Shielded Location. Logs can potentially ease further operations. But one must consider that logs can be easily compromised hence they are not stored in Shielded Locations.
The TPM is normally implemented as a passive hardware chip. Passive means that the TPM itself cannot actively influence the program flow of the CPU. It just receives commands and data from the CPU, fulfills the requested command, and returns a result.
Hardware TPMs are to some extend similar to smartcards (both provide a set of cryptographic features etc), with one major difference: each TPM is bound to a certain platform (e.g. soldered to a motherboard), whereas smartcards are normally bound to a user (and thus can be used across several platforms). Among other things, the TPM provides volatile and non volatile memory, a true random number generator, a SHA-1 engine and a RSA engine.
A TPM enables a platform to provide the fundamental features of Trusted Platforms stated above, including:
Of great importance for providing the stated features are the TPM’s Platform Configuration Registers (PCR). PCRs implement the requested Shielded Locations of a Trusted Platform. PCRs reside inside the TPM and are used to securely store SHA-1 digests of taken integrity measurements. Each TPM has a limited number of PCRs. PCRs can only be accessed by a limited set of commands with exclusive permissions (see Protected Capabilities above). E.g., storing a digest to a PCR is only possible by using the TPM_Extend command provided by a TPM. The command does not simply set the PCR to the value provided as parameter by the caller. Instead, it performs the following function:
PCR new = SHA1(PCR old + measured data).
Furthermore, metadata about the taken and extended measurement is stored to the Stored Measurement Log. Thus, one obtains a chain of digests stored in a single PCR. The history of all taken and extended measurements is contained in the SML. This has two important consequences:
When doing attestation, it is not sufficient to just send the SML an a set of PCR values to the verifier (hence they can be easily compromised on the way to the verifier). There needs to be a proof that the provided data is correct. This proof is implemented by using a digital signature. Therefore, the TPM has several sorts of keys. Two of them are mentioned here:
Both EK and AIKs are bound to a certain TPM. This is the basis for performing attestation of a platform. It is important to note that a TPM alone does not protect a platform from becoming compromised (e.g. by malware). But by using the TPM and its features, it is possible to securely detect the malware (hence it is reflected by the integrity state of the platform).
A fundamental concept of Trusted Computing is referred to as Chain of Trust. For doing attestation, the integrity of a platform has to be measured. The basic functions for obtaining and storing measurements are provided by the TPM as described above. The challenge here is that a platform consists of many separate, interacting components (drivers, OS, applications, etc.). Those components must be measured individually and their measurements must be stored to the PCRs of a TPM. The question that comes up is: When shall a component be measure? The answer is: Before the component is executed respectively control is passed to it. This fact is explained by an analogy to the boot process of modern computing platforms.
The goal is to obtain a measurement of the platform’s operating system. A simple approach would be to write an application (APP) that takes the appropriate measurement and stores it to a PCR of the TPM. The problem here is that such an application uses functions of the underlying operating system that shall be measured. A potential attack could be to modify those functions of the operating system that are used by APP for taking the measurements. This way, the taken measurements can get compromised. Thus, the operating system must be measured before control is passed to it (and its potentially compromised functions).
A boot loader is executed before the operating system and is responsible for passing control to it. Therefore, it seems likely that the boot loader should take the measurements of the operating system. The operating system can still be compromised. But to compromise the taken measurements of the operating system as described above is not possible anymore.
But what if the boot loader is compromised? Then, it would be possible again to do a similar attack as described above: e.g.measure the “good” OS, but start the compromised one. That is, the boot loader itself has to be measure, too - before control is passed to it. Referring to the boot process, the BIOS is executed before the boot loader. Thus, the BIOS should take measurements of the boot loader before passing control to it.
Analogical, the BIOS has to be measured, too. But referring to a ordinary computing platform, the BIOS is the first component that is executed. Therefore, Trusted Platforms need an additional component acting as a root for further measurements, i.e. that is responsible for measuring the BIOS. This component is referred to as Core Root of Trust for Measurement (CRTM).The CRTM consists of instructions for the CPU, that are normally stored within a chip on the motherboard. When booting a platform, these instructions are executed by the CPU, causing that the BIOS is measured. After that, the boot process goes on with the execution of the BIOS.
As the term implies, the CRTM itself cannot be measured before it is executed. It is the root of all following measurements. One has to trust the instructions of the CRTM (which are put to the chip by the manufacturer of the motherboard).
Summing up, the generic flow of measurements when booting a platform is as follow:
The result of this process is a chain of measurements, where one can trust that each component was measured before it was executed. This fundamental concept is referred to as Chain of Trust.
The description of the Chain of Trust made clear that Trusted Platforms need components that act as a Root of Trust (e.g. CRTM) that must work properly. TCG defines three kinds of Roots of Trust:
The Roots of Trust must work properly. Compromised Roots of Trust can not be securely detected.
Trusted Network Connect (TNC) refers to an open, non proprietary framework for enhancing the security of modern networks. The basic concept is called Network Access Control (NAC). NAC is all about securing the connection of endpoints to a network. Besides TNC, there are many proprietary NAC approaches (e.g. MS NAP, Cisco NAC). In addition to being open, TNC distinguishes itself by leveraging the capabilities of Trusted Platforms as described in the previous sections.
Basically, TNC allows you to decide whether an endpoint gets access to you network or not based on the endpoints current integrity state. That is, the administrator of the network can specify a policy that every endpoint has to fulfill before network access is granted (the integrity is checked against the policy). E.g., an enterprise could enforce that any endpoint that wishes to connect to the corporate network must have an anti virus software running whose virus signature is up-to-date. User authentication can be done in addition to this integrity check of an endpoint. If this check fails, the endpoint is considered to be in an unhealthy state and one of the following access restrictions can be enforced:
The access decision is enforced at the network’s edge, e.g. by a switch or by a VPN. TNC aims to leverage existing technologies like VPN or 802.1X. Here is a good introduction to the basic concepts of NAC.
The TNC architecture consists of entities, layers, components and interfaces. A slightly simplified version of the architecture is depicted in the following figure (original version). The TNC architecture depicted below consists of three entities (the columns): Access Requestor (AR), Policy Enforcement Point (PEP) and Policy Decision Point (PDP). Each entity is made up by a set of components (the boxes). Those components are grouped into three layers (the horizontal shaded rectangles). Components communicate via standardized interfaces (blue dotted lines). The red dotted lines indicate interfaces that are not specified by the TCG (i.e., the communication is implementation specific).
There are three logical entities defined in the TNC architecture.
Three layers group similar components of the TNC architecture.
The IML consist of an arbitrary number of components, normally pairs of components. Each pair consists of an IMC (on the AR) and a corresponding IMV (on the PDP). Each of those IMC/IMV pairs is responsible for measuring and evaluating certain, integrity related aspects of the corresponding AR. The IMC performs the measurement on the AR. By using the components of the two lower layers, these measurement messages are communicated to the corresponding IMV. The IMV evaluates the received measurements based upon defined policies. In the end, it knows to what extent the AR conforms to the given policy regarding the measured integrity aspects. This result is communicated as a recommendation to the TNCS in the IEL, stating to what extent network access shall be granted.
There are two components located in the IEL: the TNC Client (TNCC) on the AR and the TNC Server (TNCS) on the PDP. Their primary task is to enable the communication between IMCs and IMVs by gathering and forwarding/receiving their messages to/from the components of the NAL. Furthermore, the TNCS is responsible for making an overall access decision based on the recommendations provided by the IMVs. The overall access decision is forwarded to the NAA component (NAL).
There are three components located in the NAL. Within the AR, the Network Access Requestor (NAR) component realizes the technical network access (e.g. a IEEE 802.1X supplicant). On the PDP, this task is performed by the Network Access Authority component (NAA). Furthermore, the NAA is the component that decides whether an AR is granted access, based upon the access decision made by the TNCS.
The components normally communicate via interfaces that are standardized by the TCG. For a detailed description of each interface, please refer to the corresponding specification. However, two aspects should be noted.
One special aspect of TNC is its support for the capabilities of a Trusted Platform. This enables to prevent a certain type of attack, referred to as Lying Endpoint Attacks. As described above, there are several components located on the AR. Those components are responsible for measuring the integrity of the AR. If those components are compromised, an AR is able to lie about its real integrity state. Thus, access to a protected network could be allowed, even though the requesting AR does not comply with the given policy on the PDP.
To prevent this kind of attacks, the integrity of the TNC components on the AR have to be measured and evaluated within the TNC handshake. That is, a Chain of Trust must be established, starting from system boot and including the TNC components on the AR. Therefore, TCG has specified an interface for Platform Trust Services (IF-PTS) that enables the use of the necessary Trusted Platform capabilities within a TNC handshake. Thus, lying endpoints can still be created. But thanks to the Trusted Platform capabilities, they can be securely detected.
The Trusted Computing approach specified by the TCG promises to significantly increase the security level of modern computing systems. However, the proposed concepts and the TCG itself had to face an immense amount of criticism in the past. One of the most prominent critics is Ross Anderson. Since the new foundation of the TCG (formerly known as Trusted Computing Platform Alliance TCPA), one aims to polish up the reputation. Higher transparency of the specification process and the free availability of published specifications shall regain the trust of others.
Critics claim that a TPM threatens the privacy of the user. The thesis is that any transaction or communication that is secured by using the TPM can be correlated just because a TPM was used (specifically keys that are bound to a certain TPM were use). This is not true. The current version 1.2 of the TPM specification provides two mechanisms that ensure the privacy of a user (AIK-CA and DAA). Thus, a TPM rather provides mechanisms to increase the privacy of the users.
Critics claim that a user might lose control of its own computing platform due to Trusted Computing technology. This is true, to some extent. Reasons are the functions of Attestation and Sealing. That is, in principle, a service provider could dictate a user which software he or she has to use to be able to consume a provided service. Imagine a provider of MP3 files. This provider could seal the MP3 files to a integrity state of a system in such a way, that the file can only be used by a certain player.
It is important to note that this issue does not refer to Trusted Computing or the TCG itself. Instead of that, the described scenario is a kind of abuse. TCG has reacted on this topic and points out that the described scenario is not a desired use of the Trusted Computing technology. There is a best practises document available at the TCG.21 Nov 2008
The new website of the Trust@FHH group is now online.21 Nov 2008