MSc Information Security
Royal Holloway University of London
Copyright © Demetrios Lambrou, 01 September 2003
The problem of inadequate security on computing platforms has been identified since the early '70s [24]. It was recognized that the design of general purpose computers lacks fundamental mechanisms which could be used to build more secure computers. Since then there has been extensive research on this issue and many alternatives have been developed.
These include architectural designs that meet security requirements [11], formal security models for operating systems [2] , add on hardware security devices (smart-cards, secure co-processors) and software (IDS, antiviral software, security kernels). However all of the above solutions where not designed according to one open and standard security framework, or their implementation was not always cost effective. The requirement to ``restructure'' is still essential [13] for building more secure systems. Restructuring or redesigning the PC architecture could be an expensive and risky process. Hence, the process should be done one step at a time.
The Trusted Computing Platform Alliance is an effort to produce an Open Specification for a cost-effective security chip, which will be integrated on every platform. This chip will enable for the provision of a minimal set of trusted functions which the platform can utilize to enhance confidentiality and integrity of data.
One of the main objectives of TCPA is to protect the privacy, of the platform users and their data. This Chapter presents a brief overview of the technology. It is not the goal to give a detailed description but rather to introduce the reader to some basic concepts of operation in order to understand the latter chapters in this paper.
The core concept of TCPA is to add a minimum set of trusted services to a general purpose platform, which is logically distinct from the main CPU and is exportable to the rest of the platform. These trusted services are based on well known and scrutinized security and cryptographic properties which are used to provide authentication, integrity and confidentiality. Once support for the new security services is developed and the specification is mature enough, the hardware design can be ``upgraded'' in order to integrate the chip in a cost-effective and secure way and finally becoming an integral part of the core PC architecture. Some underlying concepts of TCPA have already been around for some time, see e.g. IBM's Embedded Security Subsystem or concepts that have been developed by [12].
The Trusted Computing Group is responsible for developing and controlling the TCPA specification. TCG has 15 leading member companies at announce: AMD, HP, IBM, Intel, and Microsoft as Promoters and Atmel, Infineon, National Semiconductor, Nokia, Philips, Phoenix, Sony, ST Microelectronics, VeriSign, and Wave Systems as Contributors. Becoming a member of the TCG requires a yearly fee which depends on the type of membership. More details and information about the process can be found at the TCPA website [27].
The TCG is in the process of creating a specification for the integration of the security chip on a computing platform and for producing a common standard API for applications to be able to utilize the TCPA services. A good reference that describes what TCPA is and offers can be found in the document "The need for TCPA" [23].
For a quick introduction of the reader to the TCPA concept I will briefly describe the functionality of a trusted platform. At boot time (that is when a platform reset occurs), the first portion of code that is executed measures a digest of the next component to be executed, stores the digest into a tamper-resistant module and some information about the code (such as configuration, version etc.) and then passes on the execution to the measured component. Each component in the boot chain must perform the same operation until all the necessary metrics have been collected. The integrity metrics are essentially cryptographic digests of the code (based on SHA1 hashing algorithm). This ensures a standard representation of software components since the output of the SHA1 hashing algorithm always produces an output of 160 bits length regardless of the size of the input.
The very first piece of code that is executed is known as Core Root of Trust for Measurement (CRTM). It is an immutable part of the platform which cannot be subverted by any known software attacks and typically resides in the BIOS. If a rogue component is detected the trusted module will reflect the event. Integrity metrics from the trusted module cannot be erased and will be present until the platform resets. To retain the platform capability of storing the sequence of events, the trusted hardware module is capable of storing an infinite number of sequences by means of -concatenated cryptographic hashes. When a report is asked for the software state of the platform the module exports a reliable full history of every component executed. A more detailed overview on why TCPA is needed and the basic concept of operation can be found at [20,23].
The main objective of TCPA is to provide a standard way of adding a small trusted subsystem at the basis of the platform, based on low cost hardware and exported by the chip via well defined restricted functions. It is essential to define clearly what is meant by the term ``trust'' in the TCPA context.
The TCPA definition of trust is that something is trusted if it always behaves in the expected manner for the intended purpose[reference]. Following this definition, improving trustworthiness of a platform requires mechanisms to monitor and log what is going on on a system, including unexpected events. TCPA supports these requirements by an integrated security chip (Trusted Platform Module or TPM) and a limited set of software functions (Trusted Services Subsystem or TSS) which interfaces the TPM services to the rest of the system. The TPM is a tamper-resistant module which meets the requirements of a CC Security Target and it is initialized at a very early stage during the boot process. TCPA concepts are very similar to the recent works of [10], the hardware root of trust being similar in functionality with that of a smart card.
In this context trust in a platform is obtained by a combination of security mechanisms, software and certification of these components by a third party which is capable of certifying the behavior of a Trusted Platform (TP). The components which provide trust to the platform are the minimum required, and are integrated into the platform in a secure and trustworthy manner. Proofs of existence of these components on a specific platform as well as their conformance to the TCPA specification and Protection Profiles can be obtained by a local as well as a remote entity.
A Trusted Platform (TP) is a computing platform that has a trusted component, probably in the form of built-in hardware, that is used to create a foundation of trust for software processes. Because the term Trusted Platform is used variably in security literature, for the purposes of this paper I will use the term in the context of the TCPA Spec.
1.1For a general purpose platform to be converted to a TP, it requires that TCPA roots of trust be embedded in the platform.These roots of trust are the components which enable the platform to be trusted by local and remote entities.
Next I describe in more detail the core components of the technology and the new enhanced functionality of a Trusted Platform.
The hardware root of trust or the root of trust for storing (RTS) integrity metrics is the first component that enables trust in the platform. This is a hardware security chip, incorporated into the platform, which has its own processing capability and storage, completely separate from the platform CPU. It is capable of providing a minimum set of autonomous security properties which will serve as the foundation for trust for software processes.
A typical TPM chip will have a CPU core, internal volatile memory, cryptographic accelerators, firmware installed on internal non-volatile memory, and shielded locations. As can be observed the functionality is very similar to a typical smart card with the only difference that the TPM is integrated on the motherboard. The physical connection of the TPM will vary between different platforms and it depends on the Protection Profile (PP) of the TPM. Both Infineon and Atmel (IBM GPL driver) offer very similar TCPA compliant TPM chips and I will base my description on their implementation.
The TPM chip incorporates a basic operating system in firmware, which provides the TCPA functionality as described in the TCPA Spec. The first versions of TPMs are likely to be integrated on the motherboard as soldered ICs. Current implementations of TPMs on platforms use as hardware interface the Low Pin Count (LPC) interface as defined by Intel1.2 . The TPM is basically a secure controller with added cryptographic services. Typical cryptographic services include:
Integration of the TPM into the platform can be done in a number of different ways. The options used for manufacturing a TP will depend on the platform's intended purpose. The chip might be physically attached and integrated to the platform and bound to the platform via a strong physical connection, or the TPM can be attached on the platform by other means and the connection to the chip is protected via cryptographically secure protocols.
The TPM only contains the functions that need to be trusted in order for the owner or a remote entity to trust the platform. The TCPA Spec. does not include any functions to the TPM if there not security critical. All non-TPM functionality should be ``working'' as described in the TCPA Spec. and the case of not them working properly must be detected via various consistency checks. TCPA defines the TPM in terms of protected capabilities and shielded locations.
TCPA describes that, a protected capability is one whose correct operation is essential for the operation of the platform to be trusted and a shielded location is an area in which data is protected against interference and snooping. Protected capabilities have access to shielded locations. For practical reasons only a small amount of platform information should be stored in a shielded location. In particular, this concerns private TPM keys, such as the private endorsement key and the key at the root of the hierarchy for encrypted keys (the storage root key). Other information that need to be protected can be stored as cryptographically protected blobs outside the TPM, the cryptographic protection being provided by the TPM. For example, the storage root key can be used to encrypt a symmetric key on the disk. Protected storage is described in more detail in Chapter 2.
One of the features that makes the TPM different from similar technologies is the availability of PCRs. These are protected storage locations inside the TPM which serve secure repositories of integrity metrics. PCRs are 160 bits (SHA1 digest length) long and can store an infinite number of integrity metrics. A logical requirement is a repository for storing information about the contents of the PCRs. This component does not require special protection and thus it can be external to the TPM.
PCRs store integrity metrics in a way that prevents misrepresentation of the sequence of the reported metrics. This is achieved by never overwriting or erasing existing integrity metrics from PCRs, but extending them instead. PCRs will be initialized at platform reset with predefined values, and whenever a new integrity metric is to be reported to a specific PCR, the existing value is concatenated with the new one and the digest of the two is stored as the new integrity metric. This way, a cumulative hash value can be produced that represents all measured components in a single 160 bit value.
By concatenating the hashes, it is therefore possible to store an infinite number of integrity metrics. In order to make sense of how the values of the PCRs were updated, a repository for storing information about the history of changes to the PCRs might be required. This component does not need special protection and can therefore be maintained external to the TPM. The uniqueness of the digests is based on the assumption that the SHA1 hashing algorithm does not produce the same output for different inputs. Chapter 2 gives some additional information how TCPA defines the usage of PCRs.
Since the TPM is the underlying mechanism to prove the trustworthiness of a platform, it is natural that the TPM itself must be reasonably secure and protected from attacks. The TPM should be protected from software attacks and offer a limited protection against physical attacks. The extent of protection against hardware attacks depends on the platform's intended purpose. As of July 2003,a TPM offers some limited degree of tamper-resistance, including tamper-evidence. The main reason of this constraint is the cost of the chip and its integration to the platform. Future platforms might provide better levels of tamper-resistance, but will differ in the cost of manufacturing. TCPA explicitly states that the TPM must be a logically isolated device, and the first generation of TPMs therefore mainly offers protection against software attacks.
TCPA security evaluation is done according to the Common Criteria. Conformance to the TCPA specification requires two pairs of protection profiles (PP) and security targets (ST). The first pair covers the TPM; its manufacturer obtains a conformance certificate that vouches for the correct design and implementation of the TPM. The second pair is defined and issued for the platform (to the extent that the security of the TCPA subsystem is concerned).
Detailed information about the TPM protection profile can be found at [30] and [29].
A TPM becomes a distinguishable entity by installing an endorsement key and certifying its public key in an endorsement certificate. The TCPA defines two ways of creating the endorsement key: either inside or outside the TPM.
Privacy advocates will argue that it is preferential to generate the endorsement key pair inside the TPM. The TCPA specification also allows to insert externally created keys, a method that is also used in the smart card industry. This is due to the fact that the creation of an asymmetric key pair is a statistical process which can vary in time. This variation is highly undesirable for a chip production line. If the second option is to be used, there must exist a guarantee that no record of the key exists outside the chip and that the process conforms to the TCPA procedure of generating and inserting keys to the TPM. The TPM contains a CEKPUsed flag which indicates whether the endorsement key was created inside the TPM or it was inserted.
Details and protection mechanisms for the endorsement key will be discussed in a later section where I describe the creation of platform identity and the activation of the TPM. This is the most privacy sensitive component of the platform and TCPA restricts the use of this key in order to preserve the privacy of the platform owner.
The second root of trust on a trusted platform is the root of trust for measuring integrity metrics. This Core Root of Trust for Measurement (CRTM) must be an immutable portion of the Platform's initialization code that executes upon a platform reset as defined in Section 1.3.4 in TCPA PC Spec. v1.0.
There are at least two types of CRTM architectures:
The protection of the CRTM varies from that of a TPM. Ideally the RTM should be incorporated to the TPM, which is better protected than the BIOS. However due to the fact that TCPA regards moving the BIOS into the TPM a commercial risk, the RTM will be incorporated together with the BBB/BIOS which offers less physical protection. This will at least be the case of first generation Trusted Platforms. The CRTM is preferably tamper-evident instead of the TPM requirement of tamper-resistant.
Various techniques can be implemented to check for tamper evidence on the CRTM. Attacking the RTM also involves complete physical access to the underlying machine. Evidence about the tampering of the CRTM can be obtained even by a remote challenger who does not have physical access to the platform. This is because the challenger receives information signed by a TPM. The challenger can verify if the TPM used is a genuine one using certificate information: the Privacy-CA (described in further sections) implicitly certifies that the TPM is a genuine one, as well as its proper integration of the TPM to a TCPA compliant platform. Since the integration of the CRTM requires for the BBB/BIOS to adhere to the protection profile that the specific TPM is attached to. In future releases of the TCPA Spec. the CRTM might be required to be part of the platform TPM.
As mentioned earlier in the definition of trust in TCPA, a number of entities must vouch for various aspects and components of a TP. The end user's trusting in a platform ultimately stems from his trust in the entities which vouch for the platform. It might be argued that not every individual and group might put the same amount of trust into these entities. This issue is discussed further in Chapter 3.
The following section outlines the entities involved in vouching for a trusted platform and their interrelationships.
Fig. 1.1 1.4 TCPA trust relationships
The underlying table shows the entities involved in attesting that a platform is a genuine Trusted Platform. In some cases the role of the entity will vary, depending on the implementation. If, for example, the platform is to be used with in-house software, the VE can be the company's IT staff. Some TP components are highly specialized and will typically be confidential. In this case, it will be their manufacturers or vendors who vouch for conformance to standards, probably by presenting an attestation from an accredited laboratory (obtaining such an attestation is a costly and lengthy process and thus it will be difficult to acquire for corporate IT or administrators).
| Entity | Function |
| Privacy Certification Authority (P-CA) | Issues identities to the platform owner |
| Validation Entity (VE) | Certifies the values of integrity measurements |
| Platform Entity (PE) | Vouches for a platform containing a specific class of TPM |
| Conformance Entity (CE) | Vouches for the design of the TCPA Subsystem |
| Trusted Platform Module Entity (TPME) | Vouches that the TPM is genuine. Signs the endorsement certificate |
When a platform is said to be trusted in the TCPA context it is meant that the platform ``behaves the way it is intended to behave, for the intended purpose''. The notion of trust in this case is based on social trust: one trusts an entity to be credible enough to vouch for the behavior and implementation of a TP component, which roots his trust that the TP operates according to the specification. To illustrate the trust relations I briefly describe how the web of trust is built.
In order for the Privacy-CA to issue an identity to a TP owner, it must trust the entities who vouch for the validity of the platform. This means that the P-CA trusts the TP manufacturer's assertion (expressed in the endorsement certificate) that a TPM is a genuine one. The Platform Entity (PE) vouches that a TP is a genuine TP containing a specific TPM. The Conformance Entity (CE) vouches for the TPM design and that the platform is TCPA compliant, meaning that the TPM is incorporated correctly on to the TP. When a Privacy-CA is to attest for a TP identity, it requires certificates from the TPME, CE, PE and it must be satisfied that it can trust these entities.
If all of the above entities conform to their roles, then if a TPM identity is issued by a Privacy-CA it means that the platform conforms to the TCPA specification and that it carries a genuine TPM conforming to a specific protection profile. The owner as well as a challenger can then trust that the integrity metrics signed by the TPM are valid. Last the challenger or the owner must trust the Certification authority which vouches for the validity of the Privacy-CA signature.
A PKI infrastructure is necessary for this web of social trust to work as expected. It is crucial that validation of credentials prior to issuing a certificate is carried out correctly. It is obvious that the notion of trust depends on the environment the TP is operating in. If, for example, the TP is to operate within a closed group, the confidence level can be quite high, whereas in an open environment this web of trust might not offer the same levels of trust. A company located in one country might not trust a certificate issued by a CA which is owned and controlled by a foreign country. This is further discussed in Chapter 3.
A TPM platform identity is the key to bringing a Trusted Platform to life and using the security services offered by the TP. In this section I will describe what constitutes the TPM identity, how it is used and at which stage of a TP lifetime is likely to be generated.
The last step in the manufacturing process of a TPM is to create the TPM endorsement key pair. The private part of this asymmetric key is kept in non-volatile memory inside a TPM shielded location. This "endorsement key" is at least 2048 bits long and will be associated with the TPM for the lifetime of the TP. Part of the TPM protection profile dictates the private part of this key never to leave the TPM and provides guidelines for the method of creating the key pair.
The public part of the key can be stored outside the TPM, or it might be accessible via a command to the TPM. It is certified in order to attest that it belongs to a conformant TPM and was produced using the proper procedure of creating an endorsement key in conformance with the TCPA specification.
The issuer of this so-called endorsement certificate is referred to in the TCPA Spec as the TPME. TCPA gives a number of recommendations on how to distribute the TPM endorsement certificates to platform manufacturers for incorporation on the designated platform [XXX Reference].
After the TPM has been initialized, it must be incorporated in the designated platform. The operation must result in a well defined binding between the chip and the platform. Whoever is responsible for the integration of the TPM onto the platform must acquire a Platform conformance certificate. This is to assert that the referenced platform conforms to the TCPA Spec. This is to certify that the binding of the CRTM and the TPM conform to the TCPA Spec. The entity issuing that certificate might be the manufacturer or an independent Common Criteria certification laboratory.
The platform conformance certificate will include a reference to the TPM conformance certificate that should have been obtained by the TPM manufacturer. When the TPM is finally physically bound to the platform, the manufacturer issues a platform certificate, indicating among other things, a reference to the endorsement certificate. This is the link between the TPM and the platform and indicates the security level and properties of the link. This certificate is as privacy sensitive as the endorsement certificate and must be stored in an area that enforces an appropriate access-control mechanism. The end-user (owner) of the platform will have a unique platform certificate together with the endorsement certificate.
The integrator has shipped the TP, together with all the required certificates and information, to the prospective owner, who must take factual ownership of the platform. A TP without an owner is of little use since the trusted mechanisms are not functional until ownership is completed. A TP owner is the entity which will configure the TP and initialize the trusted properties of the platform. The platform owner has the ability to execute "privileged commands" on the TP. Whenever a privileged operation is requested from the TPM the owner must authorize the TPM by cryptographic means to execute the command.
Up to this point, the TP offers a very limited set of services (such as enabling/disabling ownership), which require physical presence (i.e. a switch on the motherboard, or by POST BIOS functions). The process of taking ownership is as follows:
Ownership is enabled via a function that requires physical presence, and the owner uses the public endorsement key in order to securely set up a shared secret with the TPM. Access to the public endorsement key must be controlled in order to prevent a rogue from taking ownership of the platform. The owner generates two shared secrets (160 bits) which he/she will encrypt with the public endorsement key to sent them to the TPM. The owner must be confident that at the time of generating the secrets there is no third party eavesdropping the session. For added security, a smart card could be used as the shared secret generator and encryption engine. After that the owner's software can issue the TPM_TakeOwnership command to provide the TPM with the encrypted shared secrets. The secrets can then only be decrypted inside the TPM and are stored in non-volatile memory. The TPM then will create the Storage Root Key (SRK), store it in non-volatile memory, and export the public part of the key. After that the Protected Storage facilities of the TPM become available.
The private endorsement key of the TPM can not be used to sign arbitrary data outside the TPM. TCPA has defined a different approach to enable trusted signing capability from the TP. TPM identities are used to sign arbitrary data or encrypt other keys used for symmetric cryptography.
When a TP is part of a transaction the platform must prove that this is a genuine and compliant TP. This is accomplished if the TP signs data to be sent to an entity, with a key that is proved to come from a genuine TP. However for the TP to be able to prove its trusted capabilities it must provide all the certificates that attest that the TPM is a genuine one. This would allow for a remote entity to correlate information about the owner of the platform and the platform. This is due to the fact that the Endorsement credential includes the public value of the TPM endorsement key.
To protect the privacy of the user TCPA has invented the P-CA. A TP must have at least one identity which is attested by an external entity as described briefly in Section 1.4.1. This external entity must be a TTP which is capable of attesting the validity of the TP credentials. This TTP is referred in the TCPA Spec as the Privacy CA. The P-CA does not have to be a well known CA but any third party that the user chooses. However in a closed user group using a TTP that is not well known can serve the purpose of creating a TP identity. However when the TP is to be used in an Open environment there is an issue of which P-CAs are trusted. This issue will be further discussed in Chapter 3.
1.5A TPM identity is a cryptographic identity based on an asymmetric algorithm. The public representation of a TPM identity is a digital certificate which binds a public key to a specific TP. The attestation that the public key was created by a genuine TP which conforms to TCPA is provided by a P-CA.
In order to preserve the privacy of the owner a P-CA is responsible for attesting the TP once, when a TPM identity is generated and from thereon the remote entity must only trust the P-CA. The P_CA will issue an Identity credential which includes references to the TPM identity key, the TPM type and properties, the platform type and the P-CA that issued the certificate. As a consequence the P-CA must be ultimately trusted by the owner and must meet the privacy requirements of the user. Also the P-CA must have a certain reputation in order for the challenger to trust that the P-CA carried out the issuing of the identity in a conformant way.
The owner of a TP can create a pseudonymous identity, for use by the system. The protocol TCPA has produced for identity creation has minimized the work the TPM must carry out. When the operation is time consuming and requires extra processing power TCPA delegates the task to the management system. The operation of creating a TPM identity is described in a simplified way.
The TPM does not provide for the capability to protect and store arbitrary data inside the TPM, but it serves as a cryptographic portal capable of protecting a large number of secrets on the platform. The TPM has a non-migratable master key, the SRK, and its private part of the key never leaves the TPM. This is the key that is used to protect other data objects which leave outside the TPM. These data objects can be symmetric keys used for bulk encryption or other asymmetric keys that are used for signing other data objects.
The TPM has the capability of wrapping and unwrapping data objects. As illustrated in Fig 1.2 , branches of the tree can only be used as storage keys and leaves of the tree can be used as signature keys or data that will be exported from the TPM. Each child object is protected by its parent and unwrapping secrets requires the use of the keys that are higher in the hierarchy and part of the branch that the child belongs.
Fig.1.2 TPM object hierarchy [20] page 39
When the OS is running it can provide support of multiple users and applications. A key management system should be responsible for enforcing access control to TPM services. Prior to the usage of TPM services, authorization data is required by the TPM. TCPA has defined cryptographic protocols which ensure the correct and un-interruptible exchange of authorization data between an entity, local or remote, and the TPM. Privileged commands are used when the TPM services are required to protect TPM data objects or key objects. When a TPM object is created authorization data is required to identify the owner of the data. The protected object's owner does not have to be the TPM owner. A normal platform user can request from the TPM to protect an object, stored outside the TPM, with the help of the owner of the parent object which the new object is protected under.
Due to the key hierarchy in the TPM, authorization data must be presented for the parent object which will be used to protect a child object. This can create a management problem when a platform is to support the capability of arbitrary users to utilize the protection capabilities of the TPM. Unless the owner of the parent object owns all child objects or in the case where parent objects do not require authorization for using them. I will not describe the exact cryptographic protocols, for all possible case but only give a brief overview. A detailed description can be found in section 5.2 of the [29].
To access the various services the TPM provides, proof of knowledge of the associated secret is required in most cases. Authorization is required when the owner of the TP takes ownership of the TPM, when TPM identity keys are created and when the TPM is requested to protect objects. There are additional cases where authorization is required but these are the most commonly used services of the TPM. The protocols supporting each action are different and sometimes a combination of them is required.
The authorization process of taking ownership was briefly described in section 1.4.3.1 and this is a special case which is likely to happen only once at the lifetime of the TP. As described in earlier sections, when a TPM object is protected a parent key is used to protect the child. The parent key will most of the times belong to a different entity or to an application. In order for a user to take advantage of the protecting capabilities of the parent, authorization data for the parent object is required.
TCPA defines two protocols which allow for the secure exchange of authorization data from the requestor to the TPM. The two protocols are:
When a new object is created TCPA defines that authorization data should be associated with the new object. It allows however for the creation of new TPM objects which do not require authorization. It is at the discretion of the administrator to the user to decide depending on the usage of the object. TCPA recommends the use of authorization data at all times, even if it is a public value, because it serves as implicit checksum on data exchanged with the TPM. The protocol used for inserting authorization data to new objects is the Authorization Data Insertion Protocol (ADIP) defined in section 5.4 of [29].
The advantage of the OS-AP session is that if a third party intercepts the XOR of the new authorization data, during the ADIP session, and the new authorization data for the newly created entity, he/she will not be able to deduce the authorization data of the parent object. This is because the ephemeral secret is only a hash of the concatenation of the authorization data and nonces. However this can allow the owner of the parent object, the one who authorized the use of the parent, to deduce the authorization data of any child object. This is sometimes acceptable but in some cases complete user privacy is required.
TCPA provides a mechanism to allow the owner of the parent object to hand off any knowledge about the authorization secret used to create a new child object. This is a two step process, involving first the creation of a TPM child object and then the use of the Asymmetric Authorization Change Protocol (AACP) defined in section 5.7 of [29]. In the case where the owner of the parent object is trusted and the new entity requires to change authorization data of the object created under the parent object then TCPA defines the use of the Authorization Data Change Protocol (ADCP) (section 5.5 of TCPA Spec.).
Hence the the TPM owner does not always have ``superuser'' privileges to all TPM objects. This is one of the main objectives of TCPA. To provide for full confidentiality of user data on a Trusted Platform.
When using 1.6protected storage on a TP it is possible to state the future state of the software on the platform that must exist in order for the TPM to release a key to be used by an entity to wrap or unwrap an object. This 1.7facility whereby the platform software or firmware may store secrets that are accessible only when the platform is in a defined configuration is called sealing by the TCPA. The platform state is defined by the PCR contents as described in section 1.2 earlier in this paper and in more detail in Chapter 6 of the TCPA Spec 1.1b.
Both TPM data objects and TPM key objects can be sealed to the platform state. This is useful in a wide range of applications. For example sealing data to a specific platform state can preserve the confidentiality and integrity of the data when the data storage is not under the control of the designated OS and software or when the data is moved to another platform. Hence if data is stolen there is no practical way to deduce the plain-text data.
One of the criticisms about TCPA is its relation to a Microsoft project code named ``Palladium''. The main goal of Palladium is to construct a security perimeter around the Trusted Computing Base (TCB) which isolates and authenticates the software and provides for the capability of sealed storage and secure I/O. Both Palladium and TCPA are based on the common idea of depending on a trusted component inside the platform independent of the main CPU which provides for enhanced services to protect integrity of data and protect user privacy. In this section I briefly describe the main components and the operation of Palladium pointing out where TCPA currently differs.
Microsoft aims at transforming the general purpose PC to a closed box, while maintaining developer and customer flexibility. A combination of trusted hardware, similar to TCPA, and software will ensure system integrity, personal privacy and information integrity. Palladium involves industry wide participation in order to succeed.
One of the main differences with TCPA is that Palladium will be able to run aside the normal OS. The main concept is based on the existence of a security kernel, the Nexus, which the user will be able to load at any time while the system runs. The Nexus is identified by its digest value and once it is loaded it will be completely independent and isolated from the rest of the system. A special reset signal is sent to the main CPU which will then isolate some part of the physical memory from the main system, load the Nexus to the isolated memory area and any protected applications, called NCAs, and initialize Nexus. Direct memory access is not allowed to that protected memory area. The Nexus however has complete control over to which memory it can access. While the Nexus can access all the platform resources the rest of the system is unaware of the protected side. The NCAs gain access to the system only via the security kernel and are isolated from each other.
One extra platform adaptation is the implementation of trusted I/O. The Nexus requires access to system resources, but when it does no normal software will be able to interfere with the relevant I/O. Adaptations must be made to the core CPU, the Southbridge, the Graphics Processing unit (GPU) and the USB interface. It will then be able to access the main input and output interfaces (screen and keyboard) in a trusted way. Secure I/O is required so that the user knows that what is showing on the screen comes from the Nexus and when Nexus requests for input no other software can interfere with input data.
When a Nexus is loaded the event will be captured to a TPM like device. The PCRs will reflect which Nexus and which NCAs are loaded. Palladium will be capable of providing the same capabilities with a TCPA enabled platform such as sealed storage. The SCP is the name given to the TPM like device that is incorporated on the platform. A Palladium machine will have two sets of keys. One which is similar to the endorsement key of the TPM and it resides inside the hardware and any other keys that are maintained by the Nexus. The Nexus will carry various keys for the NCAs and it will have the capability to seal data to the specific platform and the NCA. Sealed data will only be decrypted on the specific platform and it will only allow release of the data to the NCA that the data belongs to. A user will be able to debug an NCA and if he/she wishes so, he/she can compile and check the digest against the binary version of the NCA. In addition it is most likely that the Nexus will be ``Open Source'', maybe under NDA, so that confidence in the operation of the trusted subsystem is higher1.8.
Palladium will protect the system from remote software attacks and from local software attacks. In the first generation Palladium systems the tamper-resistance of the SCP will adhere to the protection profile of current TPM v1.2. The Nexus core will be as small as possible and it is most likely to offer a limited set of functions compared to the normal Windows kernel. However the services of the Nexus will be adequate to provide all the necessary support for enhanced applications that are written for Palladium.
As can be observed from the above brief description of Palladium, TCPA can be used as the starting point of a first generation Palladium system, without offering the curtained memory, secure I/O and hence the load on demand of the trusted kernel. Although I can not be certain for the intention or relation of Microsoft Palladium and a DRM enabled OS, Palladium could be a first step towards the implementation of a DRM system as described in the United States Patent 6,330,670 which can be found at http://cryptome.org/ms-drm-os.htm.
The above description of Palladium is only my personal understanding of the technology as gathered from a public presentation of Palladium during the Trusted Computing Masterclass organized by Netproject on 7th November 2002, and presented by John Manferdelli.
More references on Palladium can be found at [4,7].
When trusted mechanisms are in place and a trusted platform is ready for deployment, the Operating System should take advantage of the Trusted Subsystem and provide OS support for TCPA capabilities. This way the chain of trust is extended to the OS and there is added value to the concept of a Trusted platform. In addition for a TP to be able to be part of a transaction which requires proof of trust, the OS must be able to manage these trusted mechanisms and provide support for enhanced applications.
The Trusted Computing Platform Alliance Specification v1.1b (TCPA Main Spec) specifies the services which are provided by a Trusted Subsystem (TS) and not the integration or the implementation of the TCPA services into the Operating System. If a platform is to become a TCPA enabled one it must meet some basic requirements:
This Chapter describes where the TCPA specification stops, how TCPA can be used to enforce a MAC policy on a general purpose platform, the issues of integrating TCPA extensions to the Linux OS and how, it can be extended to support an OS level MAC security policy. This Chapter also provides an overview of why Linux is the ideal OS for becoming a TCPA enabled system.
TCPA can be used as a policy enforcement mechanism. What is different from other mechanisms is that the enforcement mechanism
Fig. 2.1 Layers defined by TCPA
The TPM PCRs are the secure repository for storing integrity metrics, reported by the TP agent. PCR usage is described in the TCPA Main Spec. and Table 2.1 illustrates the PCR usage summary.
These metrics can then be used by an entity to determine the state of the software environment in the platform. The goal is for the challenger to be able to verify the state of the platform, in order to decide if it will engage into a transaction that involves the processing of personal or confidential data by the remote platform. TCPA is capable of sealing data to a specific platform configuration and to protect the data from being processed into an environment that the challenger does not trust.
| PCR Index | PCR Usage |
| 0 | CRTM, BIOS and platform extensions |
| 1 | Platform configuration |
| 2 | Option ROM Code |
| 3 | Option ROM configuration and data |
| 4 | IPL Code (usually the MBR) |
| 5 | IPL code, configuration and data |
| 6 | State transition and Wake events |
| 7 | Reserved for future usage |
Table 2.1 PCR Usage summary
The reason the TCPA Main Spec stops at the IPL code, is because it is assumed that once the kernel of the OS is loaded, the integrity of the platform is protected by security mechanisms incorporated into the kernel. Since the kernel is verified and reported we are assured that no attack2.1 ,under the level of the kernel has taken place and that the system will operate as expected.
Depending on the usage of the platform this might be all that a challenger needs to be assured of. However this chain of trust can be extended further into the OS. The advantages of extending the chain is that the challenger might need to know specific details about the services and software the platform is ``capable'' to execute, the configuration of a service, the version of software running and any additional properties of the platform at run-time.
A clear example would be in the case of a safe cryptographic repository. Where the remote end is capable of storing data on the platform, but requires further assurance that the secret key for the user cannot be obtained, not even by the platform administrator. This provides full confidentiality of the user's private data. In such a case the challenger needs to know that there is no software running capable of intercepting (legally) the transaction and thus compromising the key.
For the rest of this chapter I describe how well Linux supports the concept of security policies and how TCPA extensions can be built in the kernel to serve as the TP agent. In addition I will describe how TCPA can be used to protect private/confidential data while the system is not under the control of the OS or when data is required to be processed only under a specific well-known state.
The current access model that exists with mainstream Linux is based on Discretionary Access Control, with some lightweight MAC capabilities. While DAC mechanisms offer simplicity and ease of maintenance, it lacks some features that are necessary to provide adequate system protection against kernel compromise. DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data.
An answer to this problem is a model based on Mandatory Access Controls (MAC). A MAC architecture grants limited or "fine-grained" privileges to users and processes and "is considered to be any security policy where the definition of the policy logic and the assignment of security attributes is tightly controlled by a system security policy administrator"[15]. With such a mechanism the distribution of access rights becomes more confined and controlled and if a single application is compromised, it will not necessarily allow for the compromise of the rest of the system.There has been a lot of research in the field of MAC based systems since early 1970s [2][3]. Such systems have been implemented in the past but only operating in a constrained and static environment.
Business production systems are today part of a vast open network of interconnected dynamic entities, each one with different requirements, facilities and operating environment. Thus implementing a security architecture for more static and restrictive environments would be impractical.
Extended research has been made in order to overcome the problem of DAC with general purpose platforms. Amongst others the most recent and promising ones include the works of Security Enhanced Linux by NSA and Trusted Linux by Hewlett Packard.
HP Trusted Linux [8,5] was designed to meet the requirements of a mainstream trusted OS that is capable of providing mechanisms that enforce MAC access control at the kernel level. A similar system is the SELinux [16] which is based on the Flask [25] system architecture which is a micro-kernel based prototype system for supporting diverse security policies. HP Trusted Linux is based on the concept of implementing kernel level MAC mechanisms to confine applications or objects in a containment. Containment is used to ensure that only the interfaces (input and output) that a particular application needs to function are exposed by the OS. Containment helps also to preserve the integrity of the hosting platform as a whole and not just individual applications. The SELinux is designed to support such a concept, although the actual working implementation is based on Role Based Access Control (RBAC), Type Enforcement (TE) and optionally multi-level security (MLS).
The TCG subsystem aims at providing the basis for trust. It must provide useful trust and security capabilities while minimizing the number of functions that must be trusted. Measuring and reporting up to the IPL meets the requirements of the TCG.
The state of the platform however is most likely to change while the system is up and running. To add to the value offered by the TCG we extend the chain of trust to the OS.
As mentioned earlier on, TCPA extensions for the OS are not an integral part of the original TCG as described by the specification. This distinction serves to preserve the agnostic nature of TCPA towards the OS. In addition the Platform_Credential can be issued by a TCPA entity without having to vouch for the additional TCPA extensions, leaving the choice of implementation to the Open Source community and not restricting the control of the implementation to the TCG.
The TCPA specification is describing the operations for the TSS to perform in order to boot the OS. The Spec describes the Pre-boot and Post-boot process up and including the Initial Program Loader (IPL) which for the purposes of TCPA this is the first step in capturing the platform state.
The next logical step is to modify the IPL to be able to measure and report the digital fingerprint (SHA1) of the kernel image 2.2 to be loaded. Then any other relevant OS components and applications must be measured to represent the state of the platform at a given time.
What is meant by the term integrity metric of software state is defined in Chapter 1 (Section 1.2) and in Chapter 2 of [28] . In order to integrate the platform agent into the OS and extend the chain of trust to collect and report integrity metrics during OS initialization and run-time, we must first analyze what constitutes the software state of a running Linux system.
Under this section I describe the sequence of events from the time the IPL has measured, logged and load the kernel image into memory. To be able to identify what constitutes the platform state at the OS level, I briefly describe the initialization of the Linux system. The description will cover how a compressed kernel image (bzImage) is loaded and the sequence of events from there on. The kernel running is linux-2.4.18 with module support and no additional security modules.2.3.
The TCG describes the process of measuring and reporting the integrity metrics as follows.
``The trusted measurement root might also measure the characteristics of another measurement agent before passing control to the second agent. That second agent might repeat the process of measuring platform characteristics, storing measurement data and the final result, passing control to a third measurement agent, and so on.''
Figure 2.3 shows that the relationships and the design of the pre and post boot stages is fundamentally different. At the OS level applications, interleave with each other, the set of software components is a lot larger than the pre-boot stage and the OS components are interrelated between them.
In the pre-boot stage every component in the chain has the ability to be a measurement agent as well. However this is impractical to implement at run-time. A different approach will be presented for the implementation of the measurement agent for the OS which is described further in the following section.
Fig 2.3 Loading sequence of OS components
The TP agent is the component within the platform that reports integrity metrics, logs, Validation Data, etc. to a Challenger, as mentioned in the specification. However the TP agent is out of the scope of the specification. In this section I will define what constitutes the integrity metrics for the system and a proposed mechanism to measure and report these metrics. As can be seen in Fig. 2.3 the boot process is changing completely once the kernel loads into memory and executes.
The loading of executable code is not serial and the concept of code extends to include binary executables, shared libraries, kernel drivers, configuration files etc. The Linux kernel is multitasking and several applications may interleave. Thus we can not follow the concept of TCPA which is to measure an object and then pass execution to the next one. In order to keep to the concept of executing only trusted software we follow a different approach.
This section describes the functionality of the TP agent which must be integrated into the OS in order to serve as the main root of trust for measurement since the OS is loaded. First I describe what is the role of the TP agent, how it should be integrated into the OS and what are the entities involved in the operation of the agent.
At the pre-boot stage the code is highly specialized and supports only a limited set of functions. In the OS level applications are made to support a wide range of configuration options and tend to be dynamically linked with shared libraries. In addition Linux supports an increased amount of ``executables'' ,like various powerful scripting languages (Perl, bash, tcsh etc.). Depending on the level at which we measure the applications and system services, the state of the platform reflected to the challenger will vary in detail together with the assurance that the reported state is reliably measured.
The system analysis which follows first identifies the components to be measured and then the mechanism which must be integrated to the kernel in order to support the functionality required by a Trusted platform agent. At his stage I focus on the most standard and commonly used format of Linux executables (ELF).
After identifying the components I will describe the loading mechanism of the system in order to integrate the correct functions and the placement of hooks for measuring these components. By clearly identifying the entry points to the kernel, the hooks can be placed in the most appropriate place for the agent to be able to reliably perform the operations of measuring and reporting to the TPM.
Further assumptions include the following:
Any component that is likely to change the platform state is considered a security critical component and must be measured and logged to the TPM before execution/loading to the system. All objects are loaded from the disk which tends to be a read/write medium and access to the disk is mediated by the kernel, based on the traditional super user access rights. A list of the components follows, in the order which are loaded by the kernel at initialization time.
The security critical software components that constitute the OS are:
After the hardware and internal structure initialization the kernel will attempt to load any additional kernel code that comes in the form of Loadable Kernel Modules (LKMs). The kernel relies to a helper function to load any LKMs from the disk. This special helper function is a user space application that is responsible for installing the LKM into the kernel. Since the first object loaded from the disk is this user space application we need the capability of monitoring the loading of executables in the very early stages of the system initialization. Early initialization of the hooks is therefore essential.
Binary applications however tend to be dynamically linked object files which hide their function implementation inside shared libraries. It is already obvious that the load and execution of just one component is interrelated with at least one more object. To outline the object relations we must analyze the mechanism the kernel implements for loading binaries.
The only system call offered by Linux to deal with program execution (of ELF binary files) is do_execve (sys_execve ). This is the first time the kernel receives any information about the file to be executed. It then passes control to prepare_binprm which is responsible for identifying the file format, locating any shared libraries needed, finds the program interpreter, performs memory mapping, and prepares the execution environment for the application.
This is an oversimplified view of how the kernel executes a binary file. By looking the mechanism closer we observe that the kernel at its first open request for the executable only reads the first couple of bytes to identify the type of file and implement specific functions for the loading and execution. Since the most common format on mainstream Linux systems is the ELF type I will concentrate on that.
It is common practice that services or drivers that are not used by the system at all times, to be compiled separately from the kernel as modules, so that they do not occupy system resources when they are not in use. Linux makes use of a helper function (in user space) called insmod. Insmod installs a loadable module to the running kernel. Modules are again binary files which reside on the disk and are of ELF type.
The Linux kernel is relying on insmod to prepare the module for the kernel space system call to handle it. Insmod carries out a number of operations before passing the binary object to the kernel. The sys_call that handles the preparation of the module is sys_create_module. It will then pass the module object to sys_init_module which carries out the final preparations to start the module and register its functions. Modules however are not dependent on loading shared libraries. Their implementation functions reside inside the kernel. This makes the monitoring of modules a lot easier, since we only have to check the file on disk the time insmod loads the file.
From the previous sections we have identified three types of files that need to be measured and reported before they enter the kernel. At this point we can define the state of the platform as the set of binary applications, loadable modules and shared libraries that exist on the system. Capturing the integrity metrics for the above objects is the first step for the process of defining the state of the platform.
The above description yields the first objects and its properties. To be able to identify the binary files and shared libraries we use the most distinct properties of the file on the disk which are the file inode and the pathname.
Fig. 2.4 Linux Object properties
The relationship however of the binaries is further extended by the command arguments the binary is executed with. The arguments can be read from a configuration file or as command line arguments. I will not go further, however at this stage, instead I describe this issue in Section 2.5.6.
The set of software comprising the OS as described here, can be characterized as a coarse-grained representation of the platform state. At this stage this is an acceptable level of integrity metrics, which can serve as the basis to built a prototype TP agent for Linux. Later on I describe other components of the system which would provide finer granularity of the platform state. To illustrate the concept and observe the system the level of simplicity at this point is adequate for the purposes of this paper.
The TPM serves as the secure repository for an unlimited number of integrity metrics. We could have the TP agent to measure the digest of every component and log that to the TPM. A log could be used as the reference for an entity to be able to interpret the contents of the PCRs. However this would be impractical from the side of the challenger since the process of measuring and extending the PCRs would be time consuming and not accurate. In addition memory requirement will be high and it a finite resource. By the time the challenger performs the interpretation of the PCRs it very likely that the PCRs will have been extended again.
I will refer to the TP agent from now on as ``keeper''. Keeper could be compared as on-demand Tripwire at the kernel level. The main function of keeper is to mediate the access of the OS components, identified earlier, to the kernel.
Keeper is a LKM which is responsible for monitoring the execution of binaries together with their shared libraries, and the insertion of other LKMs. When such an event is detected keeper identifies reliably the object, consults a list of trusted objects and if an object is not in the trusted list then it will log the digest of the file to the TPM PCR. The decision of whether the object will be allowed access to the system after it is logged to the TPM depends on the implementation. Logging of un-trusted software is the default action. This is the minimum functionality of keeper. The system policy can decide if the system is halted, allows execution, or disallows the execution of the unauthorized object.
In order to give more context to the operation of keeper I will use a case scenario. I assume that the TP will serve as the gateway to some internal network. The administrator of the network wants to be assured that anyone who connects to the network from outside runs her own preferred set of software. This for example can prevent from the situation where unauthorized software has been installed on the connecting machine, from a third party, in order to intercept sensitive information with the intent to secure access to the internal network by intercepting for example the SSH password.
To capture the OS components defined earlier we need a list which keeper will be able to consult before reaching a decision. The administrator can set up a Linux platform with the minimum set of software for use only for connecting to a remote network. This could be a Linux PC with networking capabilities and an ssh client. As this can be a lengthy process if it is manual, keeper can be used to provide the initial list automatically. The process of creating the list is described at a later section.
I have chosen to create a separate list for each component group. The lists are based on the relationship of the OS components. Thus there are four types of lists.
Fig. 2.5 System components and their relationships
Keeper is designed as a module but it is compiled into the kernel for three main reasons. First by compiling keeper into the kernel the digital fingerprint of the, measured by the IPL kernel, is used to distinguish a normal kernel image from the one with the capability to measure integrity metrics. Also we want the keeper functionality for the whole lifetime of the system, so there is no need to compile it as a module. Last if it was not compiled the first instance of insmod could not be measured.
All the keeper functionality is developed as an independent module, including SHA1 kernel support, and the only point where a call is added is in main.c after the initial boot-up code has finished. This is a call to keeper which carries out the following functions:
Fig. 2.6 Keeper reference monitor. Mediates security critical objects
The implementation of keeper is only at a development stage at this time and it serves the purpose of a prototype for an initial investigation to implement the measurement and reporting of critical system objects into the kernel. This section outlines the issues identified and some recommendations about improving the security and performance for future implementations.
The format of the clear text lists should be in a standard representation format (e.g. XML) to allow for potential integration to other applications. These lists will be used extensively and manipulated for various reasons, such as management, distribution etc. Also there might be the need to embed some authentication headers used for version management, origin etc.
Intercepting system calls to implement the desired functionality is not recommended in general. Interception of sys calls can result into various race-conditions and system vulnerabilities. Further investigation must be carried out to integrate the hooks lower into the kernel.
Executing code in Linux is a complicated process and there is a time lag between the point of calling the execve system call and actually memory mapping the file. Demand paging also adds to the issue of possible race-conditions. Thus the hook would be more efficient if it was integrated with the memory mapping mechanism. The module loading mechanism is simpler and is more straightforward to control. However one major drawback of the module loading mechanism is the insufficient information that insmod passes to the kernel. This can be complemented by intercepting monitoring the sys_open system call so that when insmod opens the file the check is carried out. Insmod will lock a file at the time of opening so it could serve as a better place to place the hook for intercepting modules, since the lock on the file makes the file immutable while insmod loads it into memory.
Another issue is the interception of shared libraries. Shared libraries are loaded from various locations on the disk sometimes depending on current environment variables. A possible solution would be to monitor the execution of the library handler and integrate the check within the loader. Kernel support however will provide for better performance, and security. One approach to reliably detect shared libraries from the kernel is to only allow loading of libraries from the location that is registered at the time the lists were created. The name of the library will always be the same but the path location may change. Detection of libraries can be carried out based on the name of the library. This way whenever a library is loaded, the name of the library is extracted from the full pathname, the kernel checks (by name) if the specific library is in the list and if it is it will use the full path as known from the list to load the specified library. The same approach is used for the binaries. So when the list authorizes a file to be loaded e.g. /lib/i686/libc.so.6 and a file is loaded which points to ``libc.so.6'' but via a different path /tmp/libc.so.6, it consults the list, resolves the lib name to its proper path and after checking the file it will load it from the location registered at the time the list was created. This might restrict the ability of loading libraries from arbitrary locations but a properly built system for use as a TP should reflect the image exposed by the trusted lists.
The performance of the system will degrade from the added functionality of keeper. Some preliminary benchmarks show decrease of performance up to 70% when modules, binaries, shared libraries and configuration files are monitored. It is therefore necessary for the implementation to be optimized, which is in all practical terms feasible. Keeper was only designed as proof of concept and optimization was not one of the original requirements.
The use of a kernel cache will decrease the times a given file should be checked. If the file is held into swap memory and it is not loaded from the disk we can be assured that the integrity of the file in memory is intact. This however depends on the protection enforced by a system wide policy to control access to the swap or RAM memory. As it stands now the performance of the system degrades from redundant operations of keeper. By integrating the checks deeper into the kernel it will improve the performance of the overall mechanism. Another point of optimization is the also the way the internal lists are searched. At this point no special algorithm was used.
One major argument for integrating all the necessary security into the kernel, for the reliable operation of a trusted agent, is the one of performance cost. This is one of the reasons that a TCPA OS will mostly serve as the platform for dedicated and optimized services where this extra assurance will be desirable.
In some cases, where the service offered by a Trusted Platform, is specialized a different approach can be utilized. Linux support of Memory Technology (DoC) devices, can be used to serve as a protected (by the kernel) mid-tier storage medium, where the measurement of the device storage space is a one-off process. For example a DoC device could be used to store the most frequently used binaries, and the kernel measures the entire memory space at once. Then there is no need to perform the check each and every time if we enforce the loading of the objects from the DoC device.
Enforcing the system to load from read-only medium can also be an alternative although this is not enough. Hence the need for a TCPA enabled Linux to support a MAC mechanism that provides adequate protection of the system. This way the logging of the MAC security policy to the TPM can provide the assurance needed for an entity to trust the platform and minimize the measurement of components.
The implementation of similar projects can also provide some recommendations. One particular (Execverify) is implementing a rather clever way to intercept the execution of binaries without sys call interception. This is similar to the already existing mechanism that Linux provides, the binfmt_misc module. Execverify is adding a new binary handler which extends the classic binary handler behavior to measure the binary before execution.
The concept of checking the binaries on a system is definetelly not a new one. Many mainstream Linux distributions have embedded in their package management system tools to verify the correcteness of the binary before installed. There are also similar projects , in which different implementation techniques are deployed. Such projects are Cryptomark by Immunix, exec_verify Linux Kernel Module and others.
By porting keeper to the LSM framework, and utilizing the more appropriately placed hooks in the kernel, will improve security and performance. However it is not guaranteed that the appropriate hooks are in place and the LSM maintainers will have to be involved and authorize the potential addition of new hooks.
The level of trust, for the OS, will dependent on the reliability and security of the TP agent. Hence the need for a well integrated and well tested solution and the additional protection of the system by other traditional means.
Another issue is the monitoring of non-ELF code, such as Perl, scripts, etc. Although keeper could protect itself from illegal binaries that try to attack keeper, it can not protect from exploits that are written in Perl or similar ``languages'' or buffer overflows. Such languages have the capability of manipulating binary data, opening network connections etc. making it a powerful non binary root kit, Trojan or exploit. Keeper has no support to capture such code. This can be integrated by adding support to monitor command line arguments or by providing only native support for interpreted and other similar ``languages''. Linux provides a binfmt_misc module that will register various handlers for every file and only allow their execution through the binfmt_misc module.
Except the various languages which Linux does not natively support, the usage of configuration options can affect the state of the platform. For example the common Linux utility netcat is a powerful networking utility. The actual behavior of netcat is based on the command line arguments used to initiate it. The administrator might want to allow netcat to run and to be able to connect to other hosts but she might not want to allow netcat to be used as a listening service. Such behavior can be restricted by other means such as the use of firewall rules. It still however remains that to have a more fine-grained platform state, command line arguments are part of the information used to make a PCR_Extend decision.
As mentioned earlier the system this prototype was developed did not support an Xserver. This is because X is not just an application but it extends into the kernel via X modules which will have to be monitored. X also is using direct memory access which is a point of entering the kernel that the prototype does not look at.
A potential solution for protecting against swap or direct memory attacks would be to run keeper on a kernel that supports a MAC security policy with support of fine-grained and restricted privilege (SELinux, TLinux). On a system supporting such a policy, keeper would only have to measure the policy files the security kernel loads to support the MAC policy hence adding value to the trusted state of the platform.
To protect from illegal entry points to the kernel, protection against buffer overflows and other similar attacks [18,17,9]is also recommended. 2.4
This section describes how Linux can provide support for the new functionality required by a TCPA enabled OS. As well as the following mechanisms Linux can be used to develop the idea of a TP since it is the ideal platform for rapid development of new OS features. At the time of this writing the only components that are available for Linux integration is a modified version of the GRUB, which is a powerful boot loader for Linux and a low level driver (IBM) to support the TPM Atmel chip. Utilizing the TPM however, requires the development of a management layer between the TPM driver and the rest of the system. Typically such a management system will provide (as the minimum) support for TCPA authorization protocols, management of the state of TPM operations and creation of TPM identities, keys and access control to the TPM. The management system can either reside inside the kernel or just provide kernel support for the more security critical operations and implement the interface as a user space library.
In addition the Linux kernel supports a wide range of symmetric cryptographic algorithms (DES, 3DES, , Cast-128, Twofish, AES, IDEA, SHA1, MD5 etc.) which is one of the requirements for a Trusted Software Subsystem. In the current stable series cryptographic support is added as a patch to the main kernel in the new kernel version 2.6 CryptoAPI is supported in the mainstream kernel. Adding to the security mechanisms offered by Linux, is support for a diverge range of MAC policies and support for strong authentication mechanisms such as smart card support. Following I describe how Linux is made to support dynamic MAC policies.
At the Linux Kernel 2.5 Summit [26], the NSA presented their work on SELinux, and emphasized the need for flexible access control support in the mainstream Linux kernel. Linus Torvalds accepted that there is a need for a general access control framework for the Linux kernel, but favored a new infrastructure that would provide the necessary support for kernel modules to implement security.
In response to Linus' guidance the Linux security modules (LSM) [6] project has developed a lightweight, general purpose, access control framework for the mainstream Linux kernel. The LSM framework is now available as a Linux kernel module tracking 2.4 stable series and 2.5 development of the kernel. The LSM framework design must meet three basic requirements:
- Truly generic, where using a different security model is merely a matter of loading a different kernel module
- Conceptually simple, minimally invasive, and efficient
Currently the LSM project is still under development. However since its introduction to the community it has evolved into supporting a wide range of security policies. At the time of this writing the LSM policy enforcement mechanism supports the following security modules:
LSM allows modules to mediate access to kernel objects by placing hooks in the kernel code just ahead of the access, as shown in Fig.2.7. Thus just before the kernel would have accessed an internal object a hook makes a call to a function that the LSM module must provide. The LSM design is primarily restrictive. In the sense that where the kernel was about to allow access to internal objects the security module can deny access and when the kernel does not allow access the security module is not called. Also there are some occasions where the kernel short-circuits many of the access decisions without reaching the point where the hook is placed and access is denied in an earlier stage.
Fig. 2.7 LSM hooks integrated to the kernel2.5
With the new LSM framework that Linux supports the functionality of the TP agent can be integrated into the kernel and can be made as the primary LSM module. LSM supports the capability of stacking different security modules on top of other ones. Although the stacking mechanism is at the experimental state, it provides support for the concept of loading multiple security modules.
As mentioned earlier measuring files, by means of their SHA1 digest provides only a coarse-grained platform state. However the measurement of the ``trusted lists'' can be used to reflect the services offered by the system. This way an entity involved in a transaction can be assured that the platform has only the capability of processing data for specific usage. For example, an e-business site can prove that the personal data is encrypted while on the system and that the system does not have the capability to export the data to a third party.
It is clear however that the underlying security kernel must support mandatory access control, to protect from unauthorized tampering of the TP agent. Extended research has been made for making sure that data flow adheres to a MAC policy. The most promising techniques for achieving fine granularity of MAC policies are:
This section describes how the TPM can be used to enhance security of the crypto loop device, available on Linux. This is a feature the Linux kernel supports whereby encrypted file-storage is implemented for user applications.
When creating an encrypted filesystem or file, the storage location is filled up with random data provided by /dev/random. The kernel random number generator uses environmental noise from device drivers and other sources and feeds them into an entropy pool. Random numbers are generated by this entropy pool. When the pool becomes empty the process is blocked until further input is available. The encrypted storage becomes available via the loop device. A cipher is chosen at mount time and a pass-phrase is requested, which is used as the symmetric encryption key. The Crypto API can also be used to encrypt network traffic.
A TCPA enhanced platform can be used to add confidentiality and complete user privacy for encrypted file storage with high levels of trust. Once a user mounts the storage space allocated, to be used for a confidential repository, any user with access privileges to the location can look at the data stored while the storage space is mounted. On mainstream Linux at least the super-user has access at all times. Hence complete confidentiality cannot be guaranteed. A second issue is with the encryption key used for the encrypted loop device. The administrator of the platform has the ability to either intercept the pass-phrase when the user is requested for one and thus deduce the encryption key. Alternatively the key can be retrieved, for example by using a kernel debugger, during the storage operations. In order for the user to be guaranteed complete confidentiality and assurance that no one can have access to his/her data there must be a MAC policy enforced to restrict super-user privileges from accessing user information and there must be a guarantee that no interception software is run at the time.
TCPA services can be utilized to provide assurance to the user, either local or remote, that the above preconditions exist. The user must be able to verify the state of the platform at the time and deduce that only needed software is executed, and the MAC policy enforced by the system.
DAC is not adequate to provide enough confidence for the user in terms of who has access to his/her data. In cases where the administrator is trusted DAC might be adequate but in a more hostile environment a MAC policy should be enforced. Access to user data can be restricted by implementing an SELinux policy. The policy enforced is measured and reported to the TPM PCRs. A second policy that reflects the software the platform is allowed to execute can be represented by implementing keeper-like functionality. The keeper policy is measured and reported to the TPM PCRs as described earlier in section 2.5.4.
The sealing capability can be used to lock the encryption key that belongs to the user who requires encrypted storage, to the particular software state. The platform state is defined both from the software that is allowed to be executed on the platform and the SELinux policy enforced.
TPM capabilities can be used to enhance the following components of the system:
The aim of a challenge is to provide information about the software state of the platform, as it is reflected by the PCRs. The entity that performs the challenge can be either local or remote to the platform to be challenged and it is not dependent on the communication channel or protocol. The communication can, for example carried out between two hosts that communicate via TCP/IP or it can be a smart card linked to a PC over the serial line. The case scenarios about where the TP is and who the challenger is vary widely depending on the deployment of a TP. The two entities that may be involved may have one of the following roles:
TCPA defines a command for requesting PCR values, TPM_Quote, and it is the responsibility of the management software to request from the TPM to extract the required PCRs, signed them with a TPM identity key and hand it over to the management software. A complete history of all the events recorded to the PCRs is sent together with the signed values. The receiving end will then perform all the necessary checks to verify that the data is signed by a genuine TPM integrated to a TCPA conformant platform. This will depend on the key used to sign the PCRs. If it is a genuine TPM the challenger can verify the information signed by a public key that has been certified by a P-CA. The challenger will check that the P-CA is trusted and if he/she (it, might be a software component) decides that the P-CA is trusted it will then carry on and check the PCR values to verify that it trusts the software state of the platform.
TCPA does not define how the received data is interpreted. If the software state of the platform can be represented by a predefined PCR value then the challenger can make a decision based on the received PCR value. A challenger might however go through the event history and carry out the same TPM_Extend functions as the TP and check the if the final value is the same as the PCR value it received.
The interpretation of the PCR values can become a very complex process. A simple approach would be for the challenger to have a list of predefined SHA1 values that have been certified as trusted, by a Validation Entity that the challenger trusts. In the Linux system described above the following might be all the challenger needs to know:
The implementation of enhanced services which take advantage of the trusted TCPA mechanisms are not part of TCPA. Making the TP agent resistant to all known software attacks however, is essential but it might not be trivial. Depending on the platform the TP agent is implemented it will offer different levels of trust about its reliability and security. A system that supports MAC, is patched to protect from buffer overflows and provides additional mechanisms such as kernel intrusion detection will offer a higher level of trust than a mainstream Linux system. For confidentiality services MAC is the minimum requirement for Linux. Therefore mainstream Linux could not be employed as a secure data repository similar to the one described in 2.8.1.
TCPA mechanisms can be used in a plethora of security enhanced applications. Especially when the platform when the platform owner is not trusted or when the TP is deployed in a hostile environment where the user has no knowledge of the physical protection and security policy that is enforced at the location of the TP.
TCPA is based on social trust. Trusting the entities that certify basic properties of the platform, such as TPM functionality, integration of the TPM to the platform and the CRTM of the platform. From there on however combinations of additional hardware and software are immense. There is not one vendor manufacturing video cards, hard disks, supporting drivers etc. When we reach at the OS level the configuration options and the software is again unlimited.
When TCPA is used with proprietary closed systems its implementation is not as complex as when implementing TCPA with an Open Source OS such as Linux. The main reason for this is because there is only one version of ,for example, Windows Server 2000 with a common standard kernel and with standard Windows services. When it comes to Linux however the situation is rather different. There is a plethora of different Linux distributions and each one of them may have a different kernel configured. A linux kernel is highly customizable and it is likely that the default configuration will vary from platform to platform. Furthermore although a distribution may ship with a standard kernel, the user is likely to compile and load his/her kernel of choice. No one can mandate what software and kernel a Linux system can run. While this is not an issue in a closed group it might be a problem in the wide deployment of Linux and TCPA in an Open environment. In this section I look into the pros and cons of using an Open Source OS such as Linux in a TCPA world.
Trust is a complex notion. As it is mentioned in [19] noted by Nielsen: ``Trust is hard to build and easy to lose: a single violation of trust can destroy years of slowly accumulated credibility''. Whoever vouches for a trusted component on a TP, is putting their reputation at stake. The vouching entities certify that a component is trusted in the sense that a TP component will operate as expected. In the case of the TPM which is a highly trusted and privacy sensitive component of a TP, the TPM is guaranteed by the manufacturer that private endorsement keys have been injected into the TPM and that a copy of the key exists nowhere else other than inside the TPM. In addition the TPM provides no function for the release of the private endorsement key outside the shielded location of the TPM. It is most unlikely that a TPM manufacturer will put at stake their reputation just to serve any other purpose such as keeping a copy of the private key to be used in the interests of national security and law enforcement.
Auditing of the key generation process is most likely to be carried out when the TPM manufacturers receive their Common Criteria evaluation. Similarly the firmware that the TPM is executing is part of the CC evaluation received for the TPM. When it comes to widely available software the situation is different. Spyware is a common application that comes in the form of proprietary code. One of the biggest stories, although never confirmed, of a breach of trust was in 1999 where Andrew Fernandes, based on the works of Nicko van Someren, a leading scientist for security software company Cryptonym, a Canadian software firm, claimed that NSA (National security Agency) may have a key that could access the core security for the windows operating system. Microsoft has made it clear and explained3.1 what was the purpose of these keys and that the allegations where not true. This story illustrates how easy it is to loose confidence to a particular entity. China for example has decided to build their own version of Open Source OS and software to be used in government and military establishments, from fear that if US software is implemented there is a possibility that in the case of a ``cyber war'' China will be defenseless.
Since the notion of trust is not always transitive; whereby A trusts B and B vouches for C, which doesn't necessarily mean that A trusts C, makes the argument of trusting in social trust more difficult. However as mentioned earlier a company is not likely to put in stake their reputation and not serve the interests of the consumers.
Linux has gained a respectable share of the market, mostly for back-end services, as a server OS of high availability and reliability. Big industry players are now funding the development of Open Source software and Linux has been transformed from the ``hackers'' OS to an alternative solution for e-business. Support for enhanced security services has also added to the value of the Open Source OS. In addition recently SuSE Linux Enterprise Server 8 on IBM eServer xSeries has achieved the world's first Common Criteria certification (EAL2+) for an Open Source operating system. This shows that putting an Open Source system in the certification process of CC is not impossible and this is the first step towards certifying Linux.
One of the advantages of Open Source software is that the notion of social trust becomes less of an issue. Since the code is open source there is no issue if the software is trusted, in the sense that behaves as expected. If a TP is to be employed in an environment that high levels of security and trust is a requirement the code can be audited and checked by the interested party. Furthermore the code is exposed to such a large group of people that a backdoor or a bug in Open Source software would be noticed in less time than in proprietary code. With Open Source software if a vulnerability arises, patches are available in a very short time and even the user can implement the fix without having to wait for the time consuming process of waiting for a patch from the software vendor. A more detailed report on the advantages of using Open Source software can be found at [31]{put reference}tsdfr.
In this section I look into the entities that vouch for the various components of a TP and who these entities could be in an Open Source environment. Maybe the ideal situation would be for every part of the TP to be ``Open Source''. This could include both hardware and software. However it is not as simple as that to have Open Source hardware designs3.2. The process of developing a microprocessor is, however, very different from that of developing software, as commercial IP core licensor ARM is keen to point out. A more practical approach is one that the University of Maryland is pursuing. The project called SEBOS [10] aims at bringing Open Source at the lowest level possible. At this stage they have successfully implemented a reliable bootstrap mechanism which starts from the BIOS. They have implemented an Open Source version of the BIOS which is also capable of booting proprietary systems.
TCPA defines two implementations for the CRTM component of a TP. The most flexible one is when the BIOS is composed of two distinct core components, the BBB and the post-BIOS. With this approach the motherboard manufacturer can implement all the necessary functionality in the BBB to measure and report the BIOS block to the TPM; the BBB is a read-only protected area of the BIOS.
At this stage there is no support for LinuxBios for any TCPA motherboard, hence I assume that when TCPA becomes a de-facto for PCs, motherboard manufacturers/vendors will cooperate and provide support to implement LinuxBios3.3.
Figure 3.1 illustrates the layers that can be substituted by Open Source software. At the bottom layer, the TCPA roots of trust provide the trusted mechanisms that enable the measuring and reporting of integrity metrics for the rest of the system. Next I describe who would be the ideal entities to issue the relevant certificates for an Open Source platform.
Fig. 3.1 Open Source vs. Proprietary system layers
Entities that vouch for the TCPA roots of trust, the TPME, PE and CE, are likely to be the manufacturer of the TPM and the manufacturer of the platform which the TPM is integrated.
The P-CA must be a well known entity that has the ability to be trusted by the wider community since it carries out on of the most sensitive operation in issuing a TPM identity and it is the only entity which can correlate information about the identity of the platform owner. This entity must be able to obtain a certificate signed by one of the major CAs, or in the case of a closed group by the P-CA itself. It should also have the resources to provide the services of a P-CA. TCG members can validate and sponsor the entity to provide the service. There is also the need for the entity to have a reputation and have the ability to communicate with similar entities around the world.
Most of the countries around the world have a local Unix User Group. A UUG could serve as a P-CA, with the proper support, since it is most likely that the Open Source community will trust such an entity. Becoming off course a CA, is not a trivial process. However some UUGs have already the capability to provide their members with SSL certificates. Off course there is the need for additional work to extend the services of a CA to be able to validate other TCPA entities. This would require TCPA education and support, sponsorship from vendors or TCG members that favor Open Source software and the creation of management processes to support such a service. UUGs around the world have established communication links making the web of trust extend outside the scope of a specific country.
Other entities that can serve as P-CAs are well known non-profit organizations and academic institutions. Since such entities do not have commercial interests and thus minimizing the issue of a P-CA to co-operate with a CA and marketing organizations which could use the private information for the purposes of data mining. Maybe the use of a Zero Knowledge Protocol would eliminate all the worries about a P-CA being able to correlate information about the owner of the platform. The use of ZKP would allow for P-CA to verify that a TPM is a genuine one without requiring the TP to send all the privacy sensitive information to the P-CA.
One of the main issues with Open Source software and the wide deployment of TCPA is the validation of integrity metrics. The same proposed entities that will take the role of a P-CA can also be the Validation Entity (VE). However the issue is not really who will be the VE but how.
As described in section 2.7, depending on the granularity of the integrity metrics, it might not be adequate to just validate the digest of individual applications but also to validate configuration data. With Open Source there is no ``one-way'' of implementing a service. When a challenger wants to verify that the integrity metrics received from a TP are valid, it will have to either store locally the desired values or contact an on-line repository. With both scenarios there are two basic requirements.