- Email: [email protected]
Computing Platform Security in Cyberspace
Information Security Technical Report, Vol 5, No. 1 (2000) 54-63
Computing Platform Security in Cyberspace Boris Balacheff, Liqun Chen, Siani Pearson, Graeme Proudler and David Chan, Hewlett Packard Laboratories
Consumers worldwide are very concerned about security for E-commerce 60
USA
50
Europe
Introduction
40
Other
% 30 20
In this paper, we start by describing the concerns people have with cyberspace security. This might seem unnecessary to security practitioners but the number of times the authors experience arguments to the contrary suggest that it would be useful to start by relating concerns expressed in this area. Cyberspace security is indeed in its infancy compared with physical security. A comprehensive programme is urgently needed to make progress in this area. After a brief overview of typical security measures currently in place and their issues, we focus on the main topic of this paper: namely platform security. We describe a particular approach of enhancing platform security that is architecture independent and aims to provide a root of trust on computing platforms. Finally, we are delighted to report that an industry alliance has been formed to define a specification of platform security with the aim of promoting that specification for broad adoption.
10 0 Not at all
A little Somewhat
Very
How Concerned
Should be, but not
(Source: GVU's 10th WWW User Survey)
Figure 1: Survey showing concern for E-commerce security. about the vulnerabilities in the system (see Figure 1). The following quote from the UK prime minister succinctly captured the worries people have: “… build trust … the biggest barrier to the spread of E-commerce is cultural. Companies are worried they won’t get paid. Customers are concerned that their personal details will be misused. Copyright holders fear piracy… We need to … communicate that Britain is a safe place to trade electronically, as safe as any in the world” Prime Minister Blair — 13 September 1999.
Cyberspace Security Concerns
Given the increased significance and reliance on electronic business and commerce, the security issues in Cyberspace are of critical importance. Consumers are rightly worried
54
President Clinton expressed the deep concern of consumers in security and privacy: “I want to work with you to find ways to give consumers the same protection in the virtual mall they now have at the shopping mall — to enhance the security and privacy
0167-4048/00/$20.00 © 2000, Elsevier Science Ltd
Computing Platform Security in Cyberspace
of financial transactions on the Internet, an increasingly deep concern of citizens everywhere” President Clinton — 20 March 1999. It is worth noting another similarity of the above quotes. Neither of them talks about ‘bullet-proof’ security, instead the goal is to be “as safe as”. In the case of Tony Blair, the goal is to be as safe as any in the world — presumably that implies the US. In the case of Bill Clinton, the goal is to make the virtual mall as safe as the shopping mall.
Security Threats Enterprise Clients
Communications Gateway
Partners Inappropriate access Liability for our access to them Traffic analysis reveals deals
Unauthorized log-in Virus introduction Software tampering, piracy Theft (data, SW, HW)
Modification of content Denial of service Inappropriate access Virus introduction
Database Servers Unauthorized access Mis -classified information Unsecured classified information Attacker sniffs internal network Active attack from internal node Virus migration Denial of service attack (un un)intentional )intentional
Intranet Internet Other Sites Capture data in transit Masquerading as others Direct attack on firewall Hijacking legitimate sessions
Remote User Unauthorized log-in, attack Virus introduction Software tampering, piracy Theft (data, SW, HW) Connected laptop as entry point
HP Labs Extended Enterprise Security
Figure 2: Security Threats.
The Need for a Comprehensive Programme
• SSL for confidential communication. Security in Cyberspace is in its infancy. It lacks the maturity of physical security that has taken many years to evolve. Critical technology infrastructure such as public key infrastructure and intrusion detection systems are only at early stages of deployment. Legislation in cyberspace is lagging, and fundamental notions like digital signature have only just been introduced. The often cross-border nature of cyber activities adds to difficulties of that task. The general public has only limited understanding of cyberspace and often do not know what measures they need to take to protect their interest. A comprehensive programme like the recently announced US security initiative is urgently needed. The Clinton Administration’s National Plan for Information Systems Protection covers education, and legislation as well as technology aspects. The Need to evolve the Current Infrastructure
Existing security infrastructure currently consists primarily of : • firewalls for ‘edge’ protection
Information Security Technical Report, Vol. 5, No. 1
• IPsec (and other techniques) for virtual Private Networks. • Virus checking software. • And increasingly PGP and S/MIME for secure E-mail. With the insatiable demand for new functionalities and the rapid pace of software development, it is crucially important to evolve the security infrastructure to meet new challenges. The need for evolution can clearly be seen in firewalls. Firewalls were initially designed to allow the traffic of passive HTML data files over the HTTP protocol. However, to enable new functionalities and services, dynamic content and programs are ‘punched’ through firewalls. An organization is therefore faced with either restricting such new traffic, often an unpopular move, or evolving the firewall to deal with the new situation. The same is true for virus-checking software: the virus signature files need to be and often are frequently updated. However, as there are a potentially infinite number of viruses, a more scalable approach would be needed.
55
Computing Platform Security in Cyberspace
Figure 2 depicts the different types of threats in a typical networked environment. The Need for Platform Security
The need for platform security at the firewall is clear. If the firewall functionality is not implemented on a trusted platform, its value is dubious. In addition, we perceive the need for platform security within the perimeter, in other parts of the computing infrastructure, in order to build a multi-level defence mechanism as well as alleviating the performance bottleneck at the perimeter. The biggest challenge of platform security is to make the clients secure. At the server end, business could deploy secure operating systems and strong physical security at the site to protect the server. It is significantly harder to do the same for clients because of: • the number of clients • the diversity of systems • the diversity of locations of clients As far as clients are concerned, securing the PC is perhaps the biggest challenge. In the PC industry, no single company dictates the complete architecture. Customers do not welcome non-standard, proprietary solutions even if they are better in certain dimensions. PCs are considered to be a commodity, and customers want to be able to mix and match systems from different vendors. Furthermore, the PC platform needs to support a general set of application software. On top of that, the system must remain cost-effective.
Trusted Platform
introduced here may be applied to any computing platform, including Personal Computers. We are addressing the problem of improving the level of trust in a computing platform. One important mechanism in a ‘Trusted Platform’ detects changes in the computing environment in the platform caused by software changes to the platform. That ‘software threat’ arises from programs with undesirable behaviour, which corrupt data or make unauthorized use of data. This risk is increasing because computing platforms are increasingly becoming communication devices, and programs are increasing dynamically supplied by third parties or actually executed by third parties on remote platforms. A Trusted Platform addresses the problem by reliably measuring the identity and integrity of a platform, and reliably reporting on that identity and integrity, whether to a local entity (a user) or to a remote entity. At the same time, a Trusted Platform maintains privacy and is cost effective, so that its implementation can be ubiquitous. By its very nature, a Trusted Platform provides some security services to the platform. Trusted Measurement and Reporting
We use the following definition of trust: an entity can be trusted if it always behaves in the expected manner for the intended purpose. The special methods installed in a Trusted platform enable a challenger (called an ‘Integrity Challenger’) to obtain information and hence determine whether the target platform is behaving in the expected manner, and can be trusted for the intended purpose. As will be seen, the challenger ultimately relies on the integrity of people who vouch that the platform is operating in the expected manner.
Trusted Subsystem and Platform
The concepts of a ‘Trusted Platform’
56
The platform supplies the challenger with results of measurements (called ‘integrity
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
metrics’) taken on the platform, plus the details of the measurement processes that produced those metrics. The platform also supplies the challenger with the values that are produced by those measurements when the platform is behaving in an expected manner. The challenger checks the appropriateness of the measurement processes, and compares the supplied metrics with the expected values. Then the challenger may use his particular policies to determine whether the platform may be trusted for the intended purpose. The challenger obviously needs to know that the measurement data and the metrics are reliable. This requires a trusted mechanism (called a ‘Subsystem’) in the platform, which reliably measures the integrity of the platform and reliably reports the results of those measurements. The challenger needs to verify the integrity of the Subsystem, and needs to verify the integrity of the expected values. Since all trust can ultimately be traced to a trust in people (an individual or an organization), trust in the Subsystem and trust in the expected values must derive from trusted people who vouch for that Subsystem and those values. Those trusted people publish data that attests to the integrity of the Subsystem and integrity of the expected values, and a conventional Public Key Infrastructure attests to the cryptographic identity of those trusted people. Once a challenger has decided the names of the people it will trust, and has a trusted Certification Authority to provide access to the PKI, it can obtain attestation to the Subsystem and to the expected values. Protection and Identity
Although the Trusted platform enables detection of software attack (not hardware attack), the Subsystem itself must be protected
Information Security Technical Report, Vol. 5, No. 1
against both physical and software attack. It needs protection against physical attack in order that it can be trusted by a remote entity. It needs protection against software attack in order that it can be trusted by both local and remote entities. The Subsystem must protect its methods from subversion, and not every combination of hardware and software has the necessary properties. In a Trusted platform, therefore, the Subsystem must have an identity. Then (trusted) people can attest that the Subsystem with a particular identity has the necessary properties and can be trusted. The Subsystem must be able to prove its identity at a distance. A TRUSTED Subsystem therefore uses a cryptographic identity, based on an asymmetric key pair. Specifically, the public key is the Subsystem’s identity, and the private key is the Subsystem’s signature. To prevent forgery of the Subsystem identity, the Subsystem must (obviously) protect its signature key. Data Protection
Data (especially the signature key and the integrity metrics) and methods in the Subsystem must be absolutely protected against logical (software) attack, or the Subsystem just cannot be trusted. The degree of physical protection, however, depends on the balance between the cost of that physical protection and the value of the data in the platform. Some Subsystems will require a high degree of physical protection, while others can accept a lower degree of physical protection. All Subsystems require enough physical protection to dissuade a simple physical attack, where the definition of ‘simple’ depends on exact circumstances. Since the Subsystem signature is not a global secret, the incentive to physically subvert a Subsystem is low. To summarize, a primary purpose of a trusted Subsystem is to reliably measure and reliably
57
Computing Platform Security in Cyberspace
Measurement Store
Measurement Module
Platform characteristic
Platform characteristic
Measurement agent
Measurement agent
Reporting Module
Root of trust in integrity measurement
Validation Store
Reporting Agent
Integrity Challenge & response
measuring reporting
Root of trust in integrity reporting
storing values storing methods
Figure 3: General TRUSTED Subsystem. report integrity metrics of the associated platform. In order to do that, a Subsystem must have some cryptographic capabilities, plus the capability to protect some methods from subversion and protect secrets from eavesdropping 1 . The general model of a trusted Subsystem is shown in Figure 3. 1. The Measurement Module (MM) is trusted functionality that starts the measurement of integrity metrics. The Measurement Module may do measurements itself, and/or may verify other measurement agents before handing control of the measurement process over to those agents. Each agent may itself do measurements, and/or may verify other measurement agents before handing control of the measurement process over to those agents. 2. The ‘Measurement Store’ (MS) is unprotected memory where details of intermediate integrity measurement processes and intermediate integrity measurement results are stored. 1 Observe that the Subsystem’s identity can easily serve as the platform’s identity, and that the basic Subsystem capabilities lend themselves to other security purposes. Such extensions, however, are not discussed here.
58
3. The ‘Reporting Module’ (RM) is trusted functionality that stores the Subsystem’s signature key plus the results of integrity measurements, and can sign data using the signature key. 4. The ‘Validation Store’ (VS) is unprotected memory where expected results of integrity measurements are stored. These data are signed by the (trusted) people who vouch for the values of integrity metrics that should be obtained in a platform that is behaving as expected. Conventional certificates that attest to the identities (public key) of those people may also be stored in the VS. 5. The ‘Reporting Agent’ (RA) is untrusted functionality that manages the interaction with the Subsystem. The general operation of the Subsystem is as follows: 1. The MM and/or its agents makes integrity measurements of the platform before other programs have had the opportunity to subvert the measurement process. Details of the intermediate measurement processes and the intermediate results are stored in the MS. The final results, obtained by hashing a concatenation of the intermediate results, are stored in the RM. 2. The expected values are stored in the Validation Store at any convenient time, probably during manufacture of the platform or when new components are added to the platform. 3. When the platform receives an ‘integrity challenge’ containing a nonce, the RA submits the nonce to the RM, which concatenates the nonce to the measurement results and signs the result. The RA collects the intermediate measurement data from
Information Security Technical Report, Vol. 5, No.1
Computing Platform Security in Cyberspace
the MS, the signed measurement results from the RM, the signed expected values from the VS, and inserts the data into an ‘integrity response’. The TPA sends the integrity response to the challenger. The challenger checks the self-consistency and integrity of the integrity response. The challenger: 1. Validates the signatures on the certificates supplied by the VS using the identity (public key) of a trusted CA. 2. Validates the signature on the expected values supplied by the VS using certificates supplied by the VS. 3. Validates the signature on the values signed by the RM using a certificate supplied by the VS. 4. Uses the intermediate measurement data to verify that the measurement process was as expected, and reproduces the integrity metrics from the intermediate measurement data. 5. Compares the reproduced integrity metrics with the integrity results signed by the RM. 6. Compares the integrity results signed by the RM with the expected values supplied by the VS. 7. If any of the untrusted or unprotected parts of the Subsystem have lied, at least one of the above tests will fail. If any of the measurements do not match with the expected value, at least one of the above tests will fail. The challenger can therefore determine whether the target platform is operating as expected. As noted above, the MM and the RM are both required to have trusted functionality. Any
Information Security Technical Report, Vol. 5, No. 1
secrets in the MM and the RM must be protected from eavesdropping (both physically and logically). Any trusted methods in the MM or the RM must be protected from subversion (both physically and logically). Platform Identity and Privacy
As mentioned above, an identity is required in order to prove that the Subsystem is trusted. Since the MM and the RM are the roots of trust in a Subsystem, it follows that only the MM and the RM actually have an identity (or, indeed, separate identities). Although imprecise, this MM and RM identity is, however, called the Subsystem identity and may also used as a platform identity. (That topic is, however, beyond the scope of this document.) At the same time, the privacy of the platform owner must be maintained. This implies that the platform owner must have full control over the identity, and the disclosure of that identity. One way to satisfy these requirements is a two-stage process that enables a Subsystem to have multiple anonymous PKI identities. Each PKI identity is completely separate from each other identity, and is determined by the platform owner, but attests that the identity describes a genuine Subsystem. The first stage of the process occurs during the manufacture of a trusted component (such as the MM or the RM). Typically, a trusted component has some level of physical protection and cannot be internally inspected after manufacture. Hence only the manufacturer (at the time of manufacture) can honestly attest to the trustworthiness of the component. In the TRUSTED process, the manufacturer causes the trusted component to generate an asymmetric key pair, called
59
Computing Platform Security in Cyberspace
the endorsement keys, and export the public key. (The private key never leaves the component, nor signs data that leaves the component, nor encrypts data that leaves the component.) The component manufacturer then signs data that binds the public endorsement key to the statement “this is an endorsement key of a genuine trusted component (model XYZ built by company ABC)”. That signed data is shipped with the particular platform that contains that particular trusted component. The (private) endorsement key in the trusted component is used only for the process of obtaining an identity, and (as noted above) never leaves the component, nor signs data that leaves the component, nor encrypts data that leaves the component. Hence the fact that a trusted component contains a (private) endorsement key cannot be used to identify that trusted component. Only signed data containing the (public) endorsement key identifies a trusted component, and that only in the sense that the (public) endorsement key may be used to send encrypted data to a trusted component for the purpose of installing an identity. The second stage of the process occurs whenever the owner of the platform wishes, and only when the owner wishes it. It enables the owner of the platform to create multiple anonymous platform identities. The trusted component generates an identity and uses the signed endorsement data to prove to a Certification Authority that the identity belongs to a genuine trusted component. Trusted Subsystem in a PC
The design of a Subsystem in a PC must be compatible with the architecture of existing PCs in order to be realistic and cost effective. This restricts the initial choice of Subsystem implementation in a PC.
60
One approach is to map the entities in the following manner: • MM is the BIOS-boot-block. • MS is normal memory. • RM is a separate computing engine with a level of physical tamper protection which balances cost against the value of the data in the platform. • VS is memory, potentially distributed throughout the platform, and potentially of many different types (ROM, FLASH, EEPROM, HDD, etc.). • RA is a combination of Operating System drivers and an application program. The integrity metrics could be: • A digest of the BIOS. This is the result of a cryptographic hash computed by the BIOSboot-block over the rest of the BIOS. • A digest of the physical devices in the platform. This is the result of a cryptographic hash computed by the BIOS over device-type identification data stored in physical devices, such as the Hard Disk Drive. Note that only generic device information may be used. It is forbidden, in order to preserve privacy, to include anything that serves to identify a specific platform (such as a serial number). • A digest of each Option ROM. This is the result of a cryptographic hash computed by the BIOS over an Option ROM such as the ROM in a Network Interface Card, or in the SCSI ROM on the motherboard. The digest of an Option ROM must be computed before that Option ROM is allowed to execute.
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
• A digest of the Operating System. This is the result of a cryptographic hash computed by the BIOS over the OS loader before the OS loader is allowed to execute.
The RA extracts the integrity measurement data from the MS and the expected values from the VS. It uses that data plus the signed data from the RM to construct a responsePDU, and sends that response back to the challenger.
Installing expected values in a PC A Usage Scenario
The VS is loaded at any convenient time with the values of integrity metrics that should be obtained if the PC is operating as expected. Normally this will be done implicitly when the PC is manufactured or altered. It is anticipated that the manufacturer of all devices and functional modules that comprise a PC will install (in the device or functional module) a signed copy of the integrity value that should be produced when that device or function is operating correctly. The device or function manufacturer may also include a certificate attesting to its public (identity) key. This implicitly loads much of the necessary ‘expected values’ into the platform in the normal course of building the platform, or adding new devices or functional modules to a platform. Reliably reporting integrity metrics from a PC
A challenger builds an integrity challenge Protocol Data Unit according to a specification, and sends it to the target platform. It includes, at the very least, a nonce. The RA in the target PC receives the challengePDU and passes it to the RM. The RM extracts the nonce, concatenates it with the values of the integrity metrics stored in the RM, and signs that concatenated data. The RM returns the signed data to the RA.
2 A Trusted Platform generally provides other features in addition to those described in this document, which have benefits that are not mentioned here.
Information Security Technical Report, Vol. 5, No. 1
This description restricts 2 itself to an application of the ability to issue an ‘integrity challenge’ and examine an ‘integrity response’. Generally, this enables users and applications to determine whether a target platform is operating as expected, and hence whether to trust the target platform for the intended purpose. This property is expected to become of increasing importance as electronic services proliferate, and the value of electronic business transactions increase. This scenario illustrates the use of a Trusted Platform in a ‘Chapter-2’ use of the Internet, when a distributed program is running between a mobile computer and a fixed computing engine, dynamically located in a fixed network and not necessarily previously known to the mobile computer. In this scenario, the mobile computer has increased trust that the fixed engine will provide the negotiated service, and will not misuse the data provided. The application is assumed to require more resources than are conveniently available on the mobile computer, or to require a long execution time without user interaction. The mobile computer uses a Subsystem (aka. Platform) identity that is exclusive to this application. Then the fixed infrastructure cannot use platform identity to correlate the use of this application with the use of any other application. The user starts the application on the mobile device, which reaches into the network to
61
Computing Platform Security in Cyberspace
locate suitable resources and negotiate the quality and cost of those services. When a suitable computing engine (probably a large server or a farm of PCs) has been found, the mobile device issues an integrity challenge to the computing engine. The engine responds with an integrity response, which enables the mobile computer to reliably determine the ownership of that fixed engine and the software environment in that fixed engine. The mobile computer may verify, for example, that the fixed engine is running an operating system with an acceptable level of security properties and isolation of threads and system resources. Once verification is complete, the mobile computer authorizes the loading of the appropriate program to the fixed engine. The fixed engine issues an integrity challenge to the mobile computer, to determine that the mobile computer has the type of software environment that is approved for the particular application. Finally, the mobile computer loads particular initialization data into the fixed engine. The distributed application then executes, with communication between the fixed engine and the mobile computer as and when required. When the application terminates, the fixed engine wipes any resources that were touched by the application, so that resources may be reallocated without revealing data belonging to the mobile computer.
Trusted Computing Platform Alliance In October 1999, the Trusted Computing Platform Alliance was chartered to encourage industry participation in the development and adoption of an open specification for an improved computing platform. The Alliance was founded by Compaq, IBM, Intel, Microsoft and HP and consists of close to 100 member companies. The goal of this effort is to build a solid foundation for improved trust in the PC over time. The TCPA participants further agreed that the specification for the
62
trusted computing PC platform should focus on two areas — ensuring privacy and enhancing security. Privacy is extremely important to every business and individual concerned about protecting confidential and personal information. In the computing context, privacy provides a way to prevent others from gaining access to information without the informed consent of its owners. Cell phones, telephone caller ID, credit cards and the Internet provide people with dramatic new levels of freedom that can enhance business processes and personal lives, but these innovations come with a privacy price tag. All of these systems are capable of providing information, including financial and personal data that most users assume to be confidential. The TCPA believes that the ability to ensure such confidentiality through privacy controls is an essential prerequisite of a trusted system. Computer security involves protecting data from unauthorized access. Traditional PC security in business ultimately depends on a chain of trust, beginning with the IT manager who must trust the computer ’s operating system, trust the PC manufacturer, trust the users of the system, and also trust that physical security is adequate. While physical security is a matter of keeping the doors locked at night, PC security is typically not so straightforward. A large part of every IT manager’s time is spent contending with the myriad issues involved in keeping users up and running. This includes providing authenticated owners with access to authorized information and keeping unauthorized persons out. An important goal of the TCPA is therefore to provide stronger authentication of platforms and to enhance the integrity of internal and external networks. Stronger platform authentication and network integrity will
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
TCPA Complements
Operating System System Software Hardware, BIOS
Services
Products
Standards
Technology
Trusted Domains
x.509 IPSEC IKE PKI Smartcard Biometrics S-MIME SSL
Trusted Computing Platform Alliance Specification
Figure 4. enable IT managers to raise the level of trust for an external network, such as the Internet. In addition, the TCPA specification will define a baseline set of security features and capabilities that will be easy to deploy, use and manage by IT organizations. Today’s PCs provide a tremendous amount of trustworthiness to users. For example, businesses routinely depend on the ability to trust PC functions such as Secure Sockets Layer (SSL) to help transact online business with security. The objective of the TCPA is to enhance security at the level of the platform hardware, BIOS, system software and operating system (see Figure 4). Such a comprehensive standard does not currently exist. The Alliance aims to create and deliver a specification proposal to a standard’s body by mid-2000. This specification would be the foundation for a base-level security standard. It would complement existing capabilities,
Information Security Technical Report, Vol. 5, No.1
including the X.509 standard for digital certificates, Internet Protocol Security Protocol (IPSEC), Internet Key Encryption (IKE), Virtual Private Network (VPN), Public Key Infrastructure (PKI), PC/SC Specification for smart cards, biometrics, Secure Multi-Purpose Internet Mail Extensions (S/MIME), SSL and Secure Electronic Transaction (SET).
Conclusion Cyberspace security is in its infancy. Consumers, businesses and governments are right in their concern of cyberspace security and privacy. In this paper, we focus on the need for enhancing the trustworthiness of general purpose computing platform and describe a particular approach of achieving it. More importantly, an industry alliance, Trusted Computing Platform Alliance, aimed at addressing platform security issues was formed last year. We are hopeful that the TCPA specification will one day be implemented across a wide range of computing platforms.
Acknowledgement The authors wish to acknowledge support and contributions from our colleagues at HP – Henry Lieu, Martin Sadler, Ian Cole, David Dack, Fred Luiz, Dick Lampman as well as our partners in the Trusted Computing Platform Alliance, particularly David Grawrock, Paul England, Bob Meinshein, Manny Novoa, Dhruv Desai, Michael Angelo, David Scheer and David Rasmussen.
63
Computing Platform Security in Cyberspace Boris Balacheff, Liqun Chen, Siani Pearson, Graeme Proudler and David Chan, Hewlett Packard Laboratories
Consumers worldwide are very concerned about security for E-commerce 60
USA
50
Europe
Introduction
40
Other
% 30 20
In this paper, we start by describing the concerns people have with cyberspace security. This might seem unnecessary to security practitioners but the number of times the authors experience arguments to the contrary suggest that it would be useful to start by relating concerns expressed in this area. Cyberspace security is indeed in its infancy compared with physical security. A comprehensive programme is urgently needed to make progress in this area. After a brief overview of typical security measures currently in place and their issues, we focus on the main topic of this paper: namely platform security. We describe a particular approach of enhancing platform security that is architecture independent and aims to provide a root of trust on computing platforms. Finally, we are delighted to report that an industry alliance has been formed to define a specification of platform security with the aim of promoting that specification for broad adoption.
10 0 Not at all
A little Somewhat
Very
How Concerned
Should be, but not
(Source: GVU's 10th WWW User Survey)
Figure 1: Survey showing concern for E-commerce security. about the vulnerabilities in the system (see Figure 1). The following quote from the UK prime minister succinctly captured the worries people have: “… build trust … the biggest barrier to the spread of E-commerce is cultural. Companies are worried they won’t get paid. Customers are concerned that their personal details will be misused. Copyright holders fear piracy… We need to … communicate that Britain is a safe place to trade electronically, as safe as any in the world” Prime Minister Blair — 13 September 1999.
Cyberspace Security Concerns
Given the increased significance and reliance on electronic business and commerce, the security issues in Cyberspace are of critical importance. Consumers are rightly worried
54
President Clinton expressed the deep concern of consumers in security and privacy: “I want to work with you to find ways to give consumers the same protection in the virtual mall they now have at the shopping mall — to enhance the security and privacy
0167-4048/00/$20.00 © 2000, Elsevier Science Ltd
Computing Platform Security in Cyberspace
of financial transactions on the Internet, an increasingly deep concern of citizens everywhere” President Clinton — 20 March 1999. It is worth noting another similarity of the above quotes. Neither of them talks about ‘bullet-proof’ security, instead the goal is to be “as safe as”. In the case of Tony Blair, the goal is to be as safe as any in the world — presumably that implies the US. In the case of Bill Clinton, the goal is to make the virtual mall as safe as the shopping mall.
Security Threats Enterprise Clients
Communications Gateway
Partners Inappropriate access Liability for our access to them Traffic analysis reveals deals
Unauthorized log-in Virus introduction Software tampering, piracy Theft (data, SW, HW)
Modification of content Denial of service Inappropriate access Virus introduction
Database Servers Unauthorized access Mis -classified information Unsecured classified information Attacker sniffs internal network Active attack from internal node Virus migration Denial of service attack (un un)intentional )intentional
Intranet Internet Other Sites Capture data in transit Masquerading as others Direct attack on firewall Hijacking legitimate sessions
Remote User Unauthorized log-in, attack Virus introduction Software tampering, piracy Theft (data, SW, HW) Connected laptop as entry point
HP Labs Extended Enterprise Security
Figure 2: Security Threats.
The Need for a Comprehensive Programme
• SSL for confidential communication. Security in Cyberspace is in its infancy. It lacks the maturity of physical security that has taken many years to evolve. Critical technology infrastructure such as public key infrastructure and intrusion detection systems are only at early stages of deployment. Legislation in cyberspace is lagging, and fundamental notions like digital signature have only just been introduced. The often cross-border nature of cyber activities adds to difficulties of that task. The general public has only limited understanding of cyberspace and often do not know what measures they need to take to protect their interest. A comprehensive programme like the recently announced US security initiative is urgently needed. The Clinton Administration’s National Plan for Information Systems Protection covers education, and legislation as well as technology aspects. The Need to evolve the Current Infrastructure
Existing security infrastructure currently consists primarily of : • firewalls for ‘edge’ protection
Information Security Technical Report, Vol. 5, No. 1
• IPsec (and other techniques) for virtual Private Networks. • Virus checking software. • And increasingly PGP and S/MIME for secure E-mail. With the insatiable demand for new functionalities and the rapid pace of software development, it is crucially important to evolve the security infrastructure to meet new challenges. The need for evolution can clearly be seen in firewalls. Firewalls were initially designed to allow the traffic of passive HTML data files over the HTTP protocol. However, to enable new functionalities and services, dynamic content and programs are ‘punched’ through firewalls. An organization is therefore faced with either restricting such new traffic, often an unpopular move, or evolving the firewall to deal with the new situation. The same is true for virus-checking software: the virus signature files need to be and often are frequently updated. However, as there are a potentially infinite number of viruses, a more scalable approach would be needed.
55
Computing Platform Security in Cyberspace
Figure 2 depicts the different types of threats in a typical networked environment. The Need for Platform Security
The need for platform security at the firewall is clear. If the firewall functionality is not implemented on a trusted platform, its value is dubious. In addition, we perceive the need for platform security within the perimeter, in other parts of the computing infrastructure, in order to build a multi-level defence mechanism as well as alleviating the performance bottleneck at the perimeter. The biggest challenge of platform security is to make the clients secure. At the server end, business could deploy secure operating systems and strong physical security at the site to protect the server. It is significantly harder to do the same for clients because of: • the number of clients • the diversity of systems • the diversity of locations of clients As far as clients are concerned, securing the PC is perhaps the biggest challenge. In the PC industry, no single company dictates the complete architecture. Customers do not welcome non-standard, proprietary solutions even if they are better in certain dimensions. PCs are considered to be a commodity, and customers want to be able to mix and match systems from different vendors. Furthermore, the PC platform needs to support a general set of application software. On top of that, the system must remain cost-effective.
Trusted Platform
introduced here may be applied to any computing platform, including Personal Computers. We are addressing the problem of improving the level of trust in a computing platform. One important mechanism in a ‘Trusted Platform’ detects changes in the computing environment in the platform caused by software changes to the platform. That ‘software threat’ arises from programs with undesirable behaviour, which corrupt data or make unauthorized use of data. This risk is increasing because computing platforms are increasingly becoming communication devices, and programs are increasing dynamically supplied by third parties or actually executed by third parties on remote platforms. A Trusted Platform addresses the problem by reliably measuring the identity and integrity of a platform, and reliably reporting on that identity and integrity, whether to a local entity (a user) or to a remote entity. At the same time, a Trusted Platform maintains privacy and is cost effective, so that its implementation can be ubiquitous. By its very nature, a Trusted Platform provides some security services to the platform. Trusted Measurement and Reporting
We use the following definition of trust: an entity can be trusted if it always behaves in the expected manner for the intended purpose. The special methods installed in a Trusted platform enable a challenger (called an ‘Integrity Challenger’) to obtain information and hence determine whether the target platform is behaving in the expected manner, and can be trusted for the intended purpose. As will be seen, the challenger ultimately relies on the integrity of people who vouch that the platform is operating in the expected manner.
Trusted Subsystem and Platform
The concepts of a ‘Trusted Platform’
56
The platform supplies the challenger with results of measurements (called ‘integrity
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
metrics’) taken on the platform, plus the details of the measurement processes that produced those metrics. The platform also supplies the challenger with the values that are produced by those measurements when the platform is behaving in an expected manner. The challenger checks the appropriateness of the measurement processes, and compares the supplied metrics with the expected values. Then the challenger may use his particular policies to determine whether the platform may be trusted for the intended purpose. The challenger obviously needs to know that the measurement data and the metrics are reliable. This requires a trusted mechanism (called a ‘Subsystem’) in the platform, which reliably measures the integrity of the platform and reliably reports the results of those measurements. The challenger needs to verify the integrity of the Subsystem, and needs to verify the integrity of the expected values. Since all trust can ultimately be traced to a trust in people (an individual or an organization), trust in the Subsystem and trust in the expected values must derive from trusted people who vouch for that Subsystem and those values. Those trusted people publish data that attests to the integrity of the Subsystem and integrity of the expected values, and a conventional Public Key Infrastructure attests to the cryptographic identity of those trusted people. Once a challenger has decided the names of the people it will trust, and has a trusted Certification Authority to provide access to the PKI, it can obtain attestation to the Subsystem and to the expected values. Protection and Identity
Although the Trusted platform enables detection of software attack (not hardware attack), the Subsystem itself must be protected
Information Security Technical Report, Vol. 5, No. 1
against both physical and software attack. It needs protection against physical attack in order that it can be trusted by a remote entity. It needs protection against software attack in order that it can be trusted by both local and remote entities. The Subsystem must protect its methods from subversion, and not every combination of hardware and software has the necessary properties. In a Trusted platform, therefore, the Subsystem must have an identity. Then (trusted) people can attest that the Subsystem with a particular identity has the necessary properties and can be trusted. The Subsystem must be able to prove its identity at a distance. A TRUSTED Subsystem therefore uses a cryptographic identity, based on an asymmetric key pair. Specifically, the public key is the Subsystem’s identity, and the private key is the Subsystem’s signature. To prevent forgery of the Subsystem identity, the Subsystem must (obviously) protect its signature key. Data Protection
Data (especially the signature key and the integrity metrics) and methods in the Subsystem must be absolutely protected against logical (software) attack, or the Subsystem just cannot be trusted. The degree of physical protection, however, depends on the balance between the cost of that physical protection and the value of the data in the platform. Some Subsystems will require a high degree of physical protection, while others can accept a lower degree of physical protection. All Subsystems require enough physical protection to dissuade a simple physical attack, where the definition of ‘simple’ depends on exact circumstances. Since the Subsystem signature is not a global secret, the incentive to physically subvert a Subsystem is low. To summarize, a primary purpose of a trusted Subsystem is to reliably measure and reliably
57
Computing Platform Security in Cyberspace
Measurement Store
Measurement Module
Platform characteristic
Platform characteristic
Measurement agent
Measurement agent
Reporting Module
Root of trust in integrity measurement
Validation Store
Reporting Agent
Integrity Challenge & response
measuring reporting
Root of trust in integrity reporting
storing values storing methods
Figure 3: General TRUSTED Subsystem. report integrity metrics of the associated platform. In order to do that, a Subsystem must have some cryptographic capabilities, plus the capability to protect some methods from subversion and protect secrets from eavesdropping 1 . The general model of a trusted Subsystem is shown in Figure 3. 1. The Measurement Module (MM) is trusted functionality that starts the measurement of integrity metrics. The Measurement Module may do measurements itself, and/or may verify other measurement agents before handing control of the measurement process over to those agents. Each agent may itself do measurements, and/or may verify other measurement agents before handing control of the measurement process over to those agents. 2. The ‘Measurement Store’ (MS) is unprotected memory where details of intermediate integrity measurement processes and intermediate integrity measurement results are stored. 1 Observe that the Subsystem’s identity can easily serve as the platform’s identity, and that the basic Subsystem capabilities lend themselves to other security purposes. Such extensions, however, are not discussed here.
58
3. The ‘Reporting Module’ (RM) is trusted functionality that stores the Subsystem’s signature key plus the results of integrity measurements, and can sign data using the signature key. 4. The ‘Validation Store’ (VS) is unprotected memory where expected results of integrity measurements are stored. These data are signed by the (trusted) people who vouch for the values of integrity metrics that should be obtained in a platform that is behaving as expected. Conventional certificates that attest to the identities (public key) of those people may also be stored in the VS. 5. The ‘Reporting Agent’ (RA) is untrusted functionality that manages the interaction with the Subsystem. The general operation of the Subsystem is as follows: 1. The MM and/or its agents makes integrity measurements of the platform before other programs have had the opportunity to subvert the measurement process. Details of the intermediate measurement processes and the intermediate results are stored in the MS. The final results, obtained by hashing a concatenation of the intermediate results, are stored in the RM. 2. The expected values are stored in the Validation Store at any convenient time, probably during manufacture of the platform or when new components are added to the platform. 3. When the platform receives an ‘integrity challenge’ containing a nonce, the RA submits the nonce to the RM, which concatenates the nonce to the measurement results and signs the result. The RA collects the intermediate measurement data from
Information Security Technical Report, Vol. 5, No.1
Computing Platform Security in Cyberspace
the MS, the signed measurement results from the RM, the signed expected values from the VS, and inserts the data into an ‘integrity response’. The TPA sends the integrity response to the challenger. The challenger checks the self-consistency and integrity of the integrity response. The challenger: 1. Validates the signatures on the certificates supplied by the VS using the identity (public key) of a trusted CA. 2. Validates the signature on the expected values supplied by the VS using certificates supplied by the VS. 3. Validates the signature on the values signed by the RM using a certificate supplied by the VS. 4. Uses the intermediate measurement data to verify that the measurement process was as expected, and reproduces the integrity metrics from the intermediate measurement data. 5. Compares the reproduced integrity metrics with the integrity results signed by the RM. 6. Compares the integrity results signed by the RM with the expected values supplied by the VS. 7. If any of the untrusted or unprotected parts of the Subsystem have lied, at least one of the above tests will fail. If any of the measurements do not match with the expected value, at least one of the above tests will fail. The challenger can therefore determine whether the target platform is operating as expected. As noted above, the MM and the RM are both required to have trusted functionality. Any
Information Security Technical Report, Vol. 5, No. 1
secrets in the MM and the RM must be protected from eavesdropping (both physically and logically). Any trusted methods in the MM or the RM must be protected from subversion (both physically and logically). Platform Identity and Privacy
As mentioned above, an identity is required in order to prove that the Subsystem is trusted. Since the MM and the RM are the roots of trust in a Subsystem, it follows that only the MM and the RM actually have an identity (or, indeed, separate identities). Although imprecise, this MM and RM identity is, however, called the Subsystem identity and may also used as a platform identity. (That topic is, however, beyond the scope of this document.) At the same time, the privacy of the platform owner must be maintained. This implies that the platform owner must have full control over the identity, and the disclosure of that identity. One way to satisfy these requirements is a two-stage process that enables a Subsystem to have multiple anonymous PKI identities. Each PKI identity is completely separate from each other identity, and is determined by the platform owner, but attests that the identity describes a genuine Subsystem. The first stage of the process occurs during the manufacture of a trusted component (such as the MM or the RM). Typically, a trusted component has some level of physical protection and cannot be internally inspected after manufacture. Hence only the manufacturer (at the time of manufacture) can honestly attest to the trustworthiness of the component. In the TRUSTED process, the manufacturer causes the trusted component to generate an asymmetric key pair, called
59
Computing Platform Security in Cyberspace
the endorsement keys, and export the public key. (The private key never leaves the component, nor signs data that leaves the component, nor encrypts data that leaves the component.) The component manufacturer then signs data that binds the public endorsement key to the statement “this is an endorsement key of a genuine trusted component (model XYZ built by company ABC)”. That signed data is shipped with the particular platform that contains that particular trusted component. The (private) endorsement key in the trusted component is used only for the process of obtaining an identity, and (as noted above) never leaves the component, nor signs data that leaves the component, nor encrypts data that leaves the component. Hence the fact that a trusted component contains a (private) endorsement key cannot be used to identify that trusted component. Only signed data containing the (public) endorsement key identifies a trusted component, and that only in the sense that the (public) endorsement key may be used to send encrypted data to a trusted component for the purpose of installing an identity. The second stage of the process occurs whenever the owner of the platform wishes, and only when the owner wishes it. It enables the owner of the platform to create multiple anonymous platform identities. The trusted component generates an identity and uses the signed endorsement data to prove to a Certification Authority that the identity belongs to a genuine trusted component. Trusted Subsystem in a PC
The design of a Subsystem in a PC must be compatible with the architecture of existing PCs in order to be realistic and cost effective. This restricts the initial choice of Subsystem implementation in a PC.
60
One approach is to map the entities in the following manner: • MM is the BIOS-boot-block. • MS is normal memory. • RM is a separate computing engine with a level of physical tamper protection which balances cost against the value of the data in the platform. • VS is memory, potentially distributed throughout the platform, and potentially of many different types (ROM, FLASH, EEPROM, HDD, etc.). • RA is a combination of Operating System drivers and an application program. The integrity metrics could be: • A digest of the BIOS. This is the result of a cryptographic hash computed by the BIOSboot-block over the rest of the BIOS. • A digest of the physical devices in the platform. This is the result of a cryptographic hash computed by the BIOS over device-type identification data stored in physical devices, such as the Hard Disk Drive. Note that only generic device information may be used. It is forbidden, in order to preserve privacy, to include anything that serves to identify a specific platform (such as a serial number). • A digest of each Option ROM. This is the result of a cryptographic hash computed by the BIOS over an Option ROM such as the ROM in a Network Interface Card, or in the SCSI ROM on the motherboard. The digest of an Option ROM must be computed before that Option ROM is allowed to execute.
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
• A digest of the Operating System. This is the result of a cryptographic hash computed by the BIOS over the OS loader before the OS loader is allowed to execute.
The RA extracts the integrity measurement data from the MS and the expected values from the VS. It uses that data plus the signed data from the RM to construct a responsePDU, and sends that response back to the challenger.
Installing expected values in a PC A Usage Scenario
The VS is loaded at any convenient time with the values of integrity metrics that should be obtained if the PC is operating as expected. Normally this will be done implicitly when the PC is manufactured or altered. It is anticipated that the manufacturer of all devices and functional modules that comprise a PC will install (in the device or functional module) a signed copy of the integrity value that should be produced when that device or function is operating correctly. The device or function manufacturer may also include a certificate attesting to its public (identity) key. This implicitly loads much of the necessary ‘expected values’ into the platform in the normal course of building the platform, or adding new devices or functional modules to a platform. Reliably reporting integrity metrics from a PC
A challenger builds an integrity challenge Protocol Data Unit according to a specification, and sends it to the target platform. It includes, at the very least, a nonce. The RA in the target PC receives the challengePDU and passes it to the RM. The RM extracts the nonce, concatenates it with the values of the integrity metrics stored in the RM, and signs that concatenated data. The RM returns the signed data to the RA.
2 A Trusted Platform generally provides other features in addition to those described in this document, which have benefits that are not mentioned here.
Information Security Technical Report, Vol. 5, No. 1
This description restricts 2 itself to an application of the ability to issue an ‘integrity challenge’ and examine an ‘integrity response’. Generally, this enables users and applications to determine whether a target platform is operating as expected, and hence whether to trust the target platform for the intended purpose. This property is expected to become of increasing importance as electronic services proliferate, and the value of electronic business transactions increase. This scenario illustrates the use of a Trusted Platform in a ‘Chapter-2’ use of the Internet, when a distributed program is running between a mobile computer and a fixed computing engine, dynamically located in a fixed network and not necessarily previously known to the mobile computer. In this scenario, the mobile computer has increased trust that the fixed engine will provide the negotiated service, and will not misuse the data provided. The application is assumed to require more resources than are conveniently available on the mobile computer, or to require a long execution time without user interaction. The mobile computer uses a Subsystem (aka. Platform) identity that is exclusive to this application. Then the fixed infrastructure cannot use platform identity to correlate the use of this application with the use of any other application. The user starts the application on the mobile device, which reaches into the network to
61
Computing Platform Security in Cyberspace
locate suitable resources and negotiate the quality and cost of those services. When a suitable computing engine (probably a large server or a farm of PCs) has been found, the mobile device issues an integrity challenge to the computing engine. The engine responds with an integrity response, which enables the mobile computer to reliably determine the ownership of that fixed engine and the software environment in that fixed engine. The mobile computer may verify, for example, that the fixed engine is running an operating system with an acceptable level of security properties and isolation of threads and system resources. Once verification is complete, the mobile computer authorizes the loading of the appropriate program to the fixed engine. The fixed engine issues an integrity challenge to the mobile computer, to determine that the mobile computer has the type of software environment that is approved for the particular application. Finally, the mobile computer loads particular initialization data into the fixed engine. The distributed application then executes, with communication between the fixed engine and the mobile computer as and when required. When the application terminates, the fixed engine wipes any resources that were touched by the application, so that resources may be reallocated without revealing data belonging to the mobile computer.
Trusted Computing Platform Alliance In October 1999, the Trusted Computing Platform Alliance was chartered to encourage industry participation in the development and adoption of an open specification for an improved computing platform. The Alliance was founded by Compaq, IBM, Intel, Microsoft and HP and consists of close to 100 member companies. The goal of this effort is to build a solid foundation for improved trust in the PC over time. The TCPA participants further agreed that the specification for the
62
trusted computing PC platform should focus on two areas — ensuring privacy and enhancing security. Privacy is extremely important to every business and individual concerned about protecting confidential and personal information. In the computing context, privacy provides a way to prevent others from gaining access to information without the informed consent of its owners. Cell phones, telephone caller ID, credit cards and the Internet provide people with dramatic new levels of freedom that can enhance business processes and personal lives, but these innovations come with a privacy price tag. All of these systems are capable of providing information, including financial and personal data that most users assume to be confidential. The TCPA believes that the ability to ensure such confidentiality through privacy controls is an essential prerequisite of a trusted system. Computer security involves protecting data from unauthorized access. Traditional PC security in business ultimately depends on a chain of trust, beginning with the IT manager who must trust the computer ’s operating system, trust the PC manufacturer, trust the users of the system, and also trust that physical security is adequate. While physical security is a matter of keeping the doors locked at night, PC security is typically not so straightforward. A large part of every IT manager’s time is spent contending with the myriad issues involved in keeping users up and running. This includes providing authenticated owners with access to authorized information and keeping unauthorized persons out. An important goal of the TCPA is therefore to provide stronger authentication of platforms and to enhance the integrity of internal and external networks. Stronger platform authentication and network integrity will
Information Security Technical Report, Vol. 5, No. 1
Computing Platform Security in Cyberspace
TCPA Complements
Operating System System Software Hardware, BIOS
Services
Products
Standards
Technology
Trusted Domains
x.509 IPSEC IKE PKI Smartcard Biometrics S-MIME SSL
Trusted Computing Platform Alliance Specification
Figure 4. enable IT managers to raise the level of trust for an external network, such as the Internet. In addition, the TCPA specification will define a baseline set of security features and capabilities that will be easy to deploy, use and manage by IT organizations. Today’s PCs provide a tremendous amount of trustworthiness to users. For example, businesses routinely depend on the ability to trust PC functions such as Secure Sockets Layer (SSL) to help transact online business with security. The objective of the TCPA is to enhance security at the level of the platform hardware, BIOS, system software and operating system (see Figure 4). Such a comprehensive standard does not currently exist. The Alliance aims to create and deliver a specification proposal to a standard’s body by mid-2000. This specification would be the foundation for a base-level security standard. It would complement existing capabilities,
Information Security Technical Report, Vol. 5, No.1
including the X.509 standard for digital certificates, Internet Protocol Security Protocol (IPSEC), Internet Key Encryption (IKE), Virtual Private Network (VPN), Public Key Infrastructure (PKI), PC/SC Specification for smart cards, biometrics, Secure Multi-Purpose Internet Mail Extensions (S/MIME), SSL and Secure Electronic Transaction (SET).
Conclusion Cyberspace security is in its infancy. Consumers, businesses and governments are right in their concern of cyberspace security and privacy. In this paper, we focus on the need for enhancing the trustworthiness of general purpose computing platform and describe a particular approach of achieving it. More importantly, an industry alliance, Trusted Computing Platform Alliance, aimed at addressing platform security issues was formed last year. We are hopeful that the TCPA specification will one day be implemented across a wide range of computing platforms.
Acknowledgement The authors wish to acknowledge support and contributions from our colleagues at HP – Henry Lieu, Martin Sadler, Ian Cole, David Dack, Fred Luiz, Dick Lampman as well as our partners in the Trusted Computing Platform Alliance, particularly David Grawrock, Paul England, Bob Meinshein, Manny Novoa, Dhruv Desai, Michael Angelo, David Scheer and David Rasmussen.
63