Chin. Sci. Bull. (2014) 59(32):4173–4189 DOI 10.1007/s11434-014-0578-x

csb.scichina.com www.springer.com/scp

Review

Computer Science & Technology

The theory and practice in the evolution of trusted computing Dengguo Feng • Yu Qin • Wei Feng Jianxiong Shao

•

Received: 10 October 2013 / Accepted: 15 July 2014 / Published online: 12 August 2014 Ó Science China Press and Springer-Verlag Berlin Heidelberg 2014

Abstract Trusted computing (TC) is an emerging technology to enhance the security of various computing platforms by a dedicated secure chip (TPM/TCM), which is widely accepted by both the industrial and academic world. This paper attempts to sketch the evolution of TC from the view of our theoretical and engineering work. In theory, we focus on protocol design and security analysis. We have proposed the first ECDAA protocol scheme based on q-SDH assumption, which highlights a new way to design direct anonymous attestation scheme. In technical evolution, we discuss the key technologies of trust chain, trusted network connection and TC testing and evaluation. We break through several key technologies such as trusted boot, OS measurement and remote attestation, and implement a TC system from TPM/TCM to network. We also design and implement a testing and evaluation system of TC platform, which is the first one put into practical application in China. Finally, with the rapid development of cloud computing and mobile applications, TC is moving toward some new directions, such as the trust in cloud and mobile environments, new TPM standard, and flexible trust execution environment trust establishment method.

SPECIAL TOPIC: Network and Information Security D. Feng  Y. Qin  W. Feng  J. Shao Trusted Computing and Information Assurance Laboratory, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China D. Feng (&) State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China e-mail: [email protected]

Keywords Trusted computing  TPM  TCM  Direct anonymous attestation  Trusted network connection  Trust chain

1 Introduction With the rapid development of information technologies, computer system plays a more and more important role in processing information for the state, military, business and individuals. Information resource, as a kind of strategic resource, becomes increasingly critical in modern society. Cyberspace has already been the fourth space in succession to territory, territorial seas and airspace for the national security. But in contrast to the above-mentioned trends, a variety of facts, such as frequently occurred Hacker’s attack, powerful virus and seriously violated personal privacy, indicate that the situation is extremely serious for network and information security. Recently occurred event of Snowdon PRISM scandal further shows that USA has already kept global nations under its surveillance. The events on information security show that the original design of computer and network architecture ignores the protection of information system, which leads to large weaknesses in security. Thus, the best way to solve the problem is to reinforce the entire computer architecture that includes chip, motherboard, BIOS, operating system. Trusted computing (TC) emerges at the right moment based on this idea: it is a new architectural technology aiming to build system and network trust with TPM/TCM as the root of trust. As TC has been developed rapidly for decades, many new research hot spots have emerged during recent years. This paper attempts to sketch the evolution of TC from our research work.

123

4174

Chin. Sci. Bull. (2014) 59(32):4173–4189

1.1 Understanding of trusted computing How can a platform be regarded as ‘‘trusted’’? Does trust equal to security? There are several different definitions about TC in the academic world. ISO/IEC defines trust as ‘‘A trusted component, operation or process is one whose behavior is predictable under almost any operating condition and that is highly resistant to subversion by application software, viruses and a given level of physical interference’’. IEEE [1] defines trust as ‘‘Trust is the criterion for deciding if the service is dependable and a system is the ability to avoid service failures that are more frequent and more severe than is acceptable’’. TCG [2] defines trust as ‘‘an entity can be trusted, if it always behaves in the expected manner for the intended purpose’’. Among these three representative definitions, ISO/IEC [3] highlights security and attacking resistance, IEEE focuses on dependability and reliability (this definition is also referred to as dependable computing), and TCG emphasizes behavior expectation. Our understanding of TC is similar to that of the TCG: trust is established based on the security chip TPM/TCM, aiming at building trust execution environment (TrEE) and ensuring system entities to run as expected. The definition of trust has the following two aspects of meanings: (1)

(2)

Transitive trust across system borders: Trust is transferred to build system trust from the trust root of security chip; Isolated Trust within fixed border: Trust of core computing environment is built in fixed compartment by isolation technique.

Transitive trust is the traditional way to enlarge system trust, and it can be achieved by TPM/TCM, trust chain, remote attestation, trusted network connection, etc. Isolated trust is the dynamic trust relying on special CPU mode, and its typical techniques include trusted execution technology (TXT), TrustZone, Hypervisor for VM.

(2)

(3)

(4)

(5)

With the booming development of international TC, China started its own TC technologies and specifications. The cryptographic workgroup of TC was set up under the leadership of State Cryptography Administration Office. The workgroup made the cryptographic scheme of TC through the scientific consultations and industrial assessments. In 2007, TCMU was founded to promote the development of Chinese specifications [4], technology and industry of TC, which unites the academic institutes and enterprises of security chip, computer manufacture, system software and application in China. TCMU’s members mainly include Lenovo, Nationz Technologies Inc., TongFang PC, Institute of Software Chinese Academy of Sciences. Under the principle of independence and innovation on core technology, China pays close attention to develop TC. Its history can be divided into 4 developing stages: (1)

(2)

1.2 History of trusted computing TCG, as a leading force, is a nonprofit organization to develop, define and promote open, vendor neutral, global industry standards based on a hardware-based root of trust (called TPM [3]), which is started by IT giants AMD, Cisco, Hewlett-Packard, IBM, Intel, Microsoft, etc. Currently, there are more than 200 members involving integrated circuit, motherboard, computer manufacture, OS, application software, network, cellular phone and other IT fields. TCG specifications have been improved and upgraded continuously over the last 10 years: (1)

In 1999, since it has been widely approved and accepted that security chip can be used to build trust,

123

IT giants set up trusted computing platform alliance (TCPA) to implement TC; In 2001, TCPA released the specification of TPM 1.1, and Intel, Microsoft, etc., put the TC products into the business markets; In 2003, TCPA was renamed to TCG and released specification of TPM 1.2. The new specification extended TC technologies to almost every IT field; In 2009, TPM specifications were accepted to be ISO/ IEC standard and had a stronger influence on the global computer world; In 2012, TCG released the draft specification of TPM 2.0, expanding the new technology from traditional PC to cloud computing and mobile internet etc.

(3)

(4)

Stage 1 (2001–2005): Lenovo, Sinosun etc. researched and developed products based on TCG technology and then turned to study on Chinese own TC specifications according to the national cryptography policies; Stage 2 (2006–2007): Under the leadership of State Cryptography Administration Office, TCMU released ‘‘Functionality and Interface Specification of Cryptographic Supporting Platform for TC’’ [5] in Dec. 2007; Stage 3 (2008–2011): China built the complete industrial chain, including security chip, security PC and trust applications. Products based on TCM had been put into large-scale applications; Stage 4 (2012–present): Addressing the security needs of cloud computing and mobile internet, TCMU started to study on TCM 2.0 specification, which had a more flexible application in the new TC platforms.

Thanks to the efforts in the last few years, TCM specifications have become increasingly mature in both technology and market aspects. In China, a complete industry of TC has been formed, which includes chip design, PC

Chin. Sci. Bull. (2014) 59(32):4173–4189

manufacture, system enhancement and application development. Not only Chinese own products and technologies constitute each link of industry, and break the monopoly of the foreign IT giants but also some technical advantages of TCM significantly affect the future TPM specifications. 1.3 Technical comparison between TPM and TCM TPM and TCM adopt the same technical architecture and design principle. Although TCM draws lessons from TPM, TCM has some innovations in cryptographic algorithm, interaction protocol and application functionality. Especially TCM applies the symmetric algorithm to improve the efficiency of key operations. TCM specification with China intellectual property has significant influence, so that newly released TPM 2.0 has taken some technical advantages of TCM. The comparison results are shown in Table 1. 1.4 Overview of trusted computing application TC has come to pervade every aspect of IT technologies. The products and technologies have achieved a good prospect of application. In terminal, TPM is equipped in more than 600 million PCs, notebooks and servers in global market, almost all of brand PCs such as Dell, Lenovo, HP, Toshiba, Sony, Asus have installed TPM. The general commodity operating systems such as Windows, Linux, the Solaris, support technology of TC, particularly Windows applied TPM security functionality in core security component BitLocker. Windows 8 further comprehensively supports TC including system trust chain and BitLocker. Microsoft even declares that all smart phones, tablets of Windows-on-ARM will be integrated with TPM. In network, Cisco, Huawei, Juniper, etc. have

4175

researched and developed their switch and gateway supporting trusted network connection (TNC) specification and technology based on TC. In storage, Seagate, Hitachi, etc. storage manufactures have adopted secure encryption drive (SED)-based TC for storage security enhancement. In trust cloud, IT giants such as Intel promote the development of trust cloud, applying TC technologies in virtualization server, multi-tenant, the datacenter. In mobile TPM, ARM joins TCG and starts research on new mobile TPM technology and standard for upgrading the mobile trusted module (MTM) specification.

2 Theoretical evolution of trusted computing 2.1 Protocol design The protocol design of TC is based on cryptographic techniques. Subjects in study involve a series of practical cryptographic algorithms and protocols. Protocol design in TC is always an active field in theoretical research. The transformation from TPM 1.2 to 2.0 is a giant promotion in protocols. Architecture of the protocols in TC can be classified to three levels as in Fig. 1. Security of the highlevel protocols depends on that of the low levels. Cryptographic algorithms include international common algorithms and Chinese commercial algorithms; module-level protocols consist of functionalities and protocols implemented by TPM/TCM API commands; the highest level includes applications and protocols built on TPM/TCM. Among them, research on designing direct anonymous attestation (DAA) protocol has drawn a lot of attention and been always an active field. Development in this branch

Table 1 TPM and TCM technical comparison TCM/TSM

TPM 1.2

TPM 2.0

Crypto alg

SM2 (256 bit), SM3 (256 bit), SMS4, RNG

RSA (2,048 bit), SHA1 (160 bit), RNG

RSA, ECC, SM2, SM3, SMS4, SHA1, RNG

Integrity measurement and PCR

Length 256 bit

Length 160 bit

Multiple hash algs

Symmetric alg

Protect critical data with SMS-4 alg

No symmetric alg

Support AES and SMS4

Key protection

Key storage architecture is protected with symmetric and asymmetric key, storage root key is symmetric key

Key storage architecture is protected only by asymmetric key

Three primary seeds: EPS, SPS, PPS

Authorization protocol

Simplified authorization protocol, support OIAP/OSAP

OIAP/OSAP/ADIP/ADCP/AACP

Enhanced authorization (EA)

Key agreement

Yes

No

Yes

Digital envelop

Yes

No

Yes

Certificate

Support double certificate system of China, simple certificate management

Don’t support double certificate system

Don’t support double certificate system

Key migration

New migration method

TCG migration method

Key duplication

Session

Anti-replay attack

No anti-replay attack

Anti-replay attack

123

4176

Chin. Sci. Bull. (2014) 59(32):4173–4189

Fig. 1 (Color online) Architecture of protocols in trusted computing

Fig. 2 (Color online) Evolution of DAA protocol

has achieved a lot of successes in both theoretical research and implementation. 2.1.1 Direct anonymous attestation DAA is an anonymous digital signature scheme that aims at conducting remote authentication of TPM while preserving the privacy of TPM and the platform. Since DAA protocol is a practical anonymous attestation scheme that is adopted by TCG in the implementation of TPM API commands, it has attracted many researchers to design and improve the schemes. Since first proposed in 2004, DAA schemes have experienced more than 20 important improvements and extensions. Up to now, the latest research has been done for the API designs of DAA schemes [6], which has been adopted by the TPM 2.0 specification. The theoretical evolution of DAA protocol is shown in Fig. 2. (1)

(2)

RSA-DAA schemes (BCC04, HT07) The first DAA protocol based on TPM was proposed by Brickell et al. [7] in 2004 (denoted by BCC04). Their scheme was based on the cryptographic primitives such as zero-knowledge proof and Camenisch–Lysyanskaya (CL) signature scheme. It was adopted by the TCG and included in TPM 1.2 specification. One disadvantage of BCC04 was that the complexity of computation was quite high for a TPM since its security was based on RSA cryptography. As a result, many improved DAA schemes had been proposed. For example, in 2007, Ge and Tate [8] proposed a DAA scheme for embedded devices with low computing capabilities (denoted by HT07). ECC-DAA schemes in LRSW family (BCL08, BCL09, CMS09, CPS10) The first DAA scheme based on elliptic curve cryptology and bilinear map was proposed by Brickell et al. [9] in 2008 (denoted by BCL08), which brought down much cost than the original scheme. They built their model upon the CL signature scheme and their proof of security was under the LRSW assumption. In 2009, a simplified security notion was proposed by

123

(3)

Brickell et al. [10] (denoted by BCL09). They defined the security of DAA scheme as user-controlled anonymity and user-controlled traceability by game-based security model rather than the original simulation-based model. Most of the following researches adopted their model and security definitions. In the same year, Chen et al. [11] improved the work of BCL08 by a simplification of the signature of zero-knowledge proof (denoted by CMS09). In 2010, Chen et al. [12] proposed an ECDAA scheme optimizing the signature of zeroknowledge proof (denoted by CPS10). Their scheme was the most efficient among the ones using LRSW assumption and was adopted by the TPM 2.0 specification. ECC-DAA schemes in q-SDH family (CF08, Ch09, BL10) In 2008, we proposed a novel ECDAA scheme (denoted by CF08 [13] ). It is the first DAA scheme based on q-SDH assumption and highlights a new way to design ECDAA schemes. The efficiency of computation and communication is improved a lot than the schemes of BCC04 and BCL08. In 2010, Chen [14] improved the work of CF08 and reduced the computation of TPM in signing process by using pre-computation (denoted by Ch09). Up to now, the most efficient ECDAA scheme based upon q-SDH assumption was proposed by Brickell and Li [15] in 2010 (denoted by BL10).

2.1.2 Our DAA scheme In the following, we will present our ECC-based DAA scheme [13]. DAA scheme is a digital signature scheme with 5-tuple of polynomial-time algorithms (KeyGen, DAA-Join, DAA-Sign, DAA-Verify, Rogue tagging). (1)

KeyGen On the input of a security parameter, the issuer produces a pair of the group master keys that can be used to create DAA credentials for the signer’s secret key.

Chin. Sci. Bull. (2014) 59(32):4173–4189

4177

Table 2 Performance results for Ref. [13] Scheme

Signature length (bits)

Total computation cost of sign process

The computation cost of join process

The computation cost of sign process

Assumption

BCC04

20,555

8 ME ? 0 NP

4 ME ? 0 NP

4 ME ? 0 NP

Strong RSA, DDH

HT07

7,614

3 ME ? 0 NP

5 ME ? 0 NP

3 ME ? 0 NP

Strong RSA, DDH

BCL08

4,163

10 ME ? 3 NP

3 ME ? 0 NP

7 ME ? 5 NP

LRSW, DBDH

CF08

2,044

9 ME ? 0 NP

4 ME ? 0 NP

4 ME ? 1 NP

q-SDH, DDH

(2)

(3)

DAA-join It is an interactive protocol between a signer and the issuer, where the signer is composed of a TPM/TCM and its corresponding host. In the protocol, the TPM/TCM chooses its secret key f, 0 computes its commit value C ¼ gf ht , and sends the commitment to the issuer. To make sure that the signer knows the secret key, the TPM/TCM needs to prove to the issuer the knowledge of f by an Rprotocol. If the proof is verified, the issuer creates a DAA credential cre ¼ ðA; xÞ for f. The credential is a signature on the commit value C (thus a blind signature on f) that can be verified by     e A; Ygx2 ¼ eðg1 ; g2 Þ  e gf ; g2  eðht ; g2 Þ, where t is the blinding factor used in cre. The credential is given to both the TPM/TCM and the host, but the secret key f is only known by the TPM/TCM. DAA-sign In this protocol, the signer creates an anonymous signature for the message m. The host can randomize cre to obtain another credential (Ahw, gwh-x), which is the commitment of cre (therefore of f). By using the randomized credential, even the issuer could not tell whether two credentials are signatures on the same secret key. Then the signer (with a TPM/TCM) has the knowledge of f, x, w, t and needs to generate a proof of knowledge of signature, denoted by: 8 9 < ðf ; x; w; tÞ : eðT1 ; YÞ=eðg1 ; g2 Þ ¼ = SPK eðh; YÞw eðh; g2 Þwxþt eðg; g2 Þf =eðT1 ; g2 Þx ðmÞ: : ; ^T2 ¼ gw hx ^ T2x gwx hxx ¼ 1

(4)

(5)

DAA-verify Given the signature r on message m and the public key, the verifier could check it to make sure it originates from a legitimate TPM without knowledge of which particular one. Rogue tagging A rogue TPM can be identified and excluded from the group. Compared to other schemes, this DAA scheme is the first one that utilizes the bilinear maps and is based on the decisional Diffie–Hellman (DDH) assumption and q-SDH assumption. The security proof is based on the

construction of a simulator (in an ideal system) to simulate the protocol and the fact that an adversary succeeds with a non-negligible probability to distinguish the ideal/real system under the assumptions of DDH and q-SDH. Due to the utilization of the bilinear maps and the elliptic curve cryptography (ECC), this scheme shortens 90 % of the signature length compared with the original scheme and brings down the TPM’s computation cost in the sign process. The comparison is in Table 2. The above DAA scheme is based on an improved short signature to cut down the computational cost to a half in the join process. It provides a new way to design the schemes under the q-SDH assumption. A lot of researches follow to improve the above DAA scheme. 2.2 Security analysis and verification 2.2.1 Overview As the deepgoing study on TC technologies and applications, security analysis of TC has been an important field in theoretical research. In practice, security analysis of the mechanisms in TC may discover potential flaws and promote security level of the corresponding systems. Moreover, it may improve the technical architecture and specifications of TC. Security analysis in TC typically utilizes the formal method to analyze and verify properties of protocols and abstract description of running mechanisms. We give a brief introduction to the typical methods such as model checking, process calculus, type system and the theoremproving-based approaches. Model-checking-based analysis models the target systems (such as protocols) as finite-state transition systems. Typical model checkers include Murphi, SMV and SPASS. The advantage of this method is its accuracy and high level of automation. Given the model of target system and security requirement, model-checking method can solve such a problem algorithmically. Furthermore, an attacking trace can be built by model checkers while flaws are detected. However, with the growth of the scale of target

123

4178

system, the state space to be checked often blows up dramatically (which is often referred to as ‘‘state explosion problem’’), and model-checking-based analysis is helpless when facing infinite-state cases. Thus, model checking is more suitable for analyzing protocols or API commands with bounded number of sessions such as the authentication protocols of TPM/TCM. Process calculus provides a tool for the high-level description of concurrent systems. The typical one, applied pi calculus, defines a fine-grained process description of protocols, which formally models the entities in a protocol as a collection of independent processes, and the protocol as the interaction between these processes. It also provides algebraic laws that allow process descriptions to be manipulated and analyzed and permits formal reasoning about equivalences between processes. This method can be applied to protocols with unbounded number of sessions and some complex systems such as DAA protocol and API analysis. The automatic tools include Proverif and Statverif. However, Proverif may not terminate for some cases and may have false attacks in its results. Type system is a collection of rules that dictate how typed data and protocols should be programmed according to the security property. These typing rules often over approximate the security of the description of protocols and lead to a tight bound. Thus, well-typed protocols are secure. One interesting point of this method is that it forces a better understanding of how security property is achieved and leads to a clarification of the protocol specification by types. However, it needs manual intervention to some extent when defining the initial types of the underlying programs. Besides protocols, this approach may also be applied to the analysis of API commands in TPM/TCM. Theorem-proving-based approaches are a collection of methods using a tight logic system to analyze security mechanisms. These methods usually depend on an abstract model to specify all the behaviors of entities and a reasoning system to prove the invariants in this system as the security properties. The advantage of these methods is soundness, which means once the security property is proved, and then it by all means keeps true in the semantics of the model. In general, these methods are often used to verify the security property of some complex applications such as trust chain system, remote attestation and Bitlocker, rather than find out their flaws. Due to the diversity of the reasoning methods, theorem-proving-based approaches are more difficult to be algorithmic. The typical theorem-proving-based analyzing techniques include protocol composition logic (PCL) and logic of secure systems (LSS). 2.2.2 Research status Formal methods have shown their power when analyzing and developing critical mechanisms and systems in TC,

123

Chin. Sci. Bull. (2014) 59(32):4173–4189

where safety or security is important. The field of security analysis in TC has seen significant advances during the last few years. We now have a better understanding of the flaws in some critical security mechanisms. The field of security analysis in TC has been transformed from a few scattered researches to a systematic framework composed of the security analysis of API commands, authentication protocols, DAA protocol and critical systems. (1)

(2)

(3)

Security analysis of API commands There are a lot of researches in the analysis of TPM/TCM API commands. Lin [16] described an analysis of various fragments of the TPM API commands using a modelfinder Alloy and a theorem-prover Otter. By using Alloy, he developed techniques to capture a potential attack on the delegation model of the TPM. In 2007, Gurgens et al. [17] described an analysis of a large part of the TPM API commands using a finite-state verification tool SHVT. Their analysis of remote attestation scenario showed how an attacker can illegally obtain a certificate on a TPM key of his choice by the TPM command TPM_CertifyKey. In 2011, Delaune et al. [18] used Proverif to analyze four TPM API commands and found some unknown flaws in the process of key certification. Security analysis of authentication protocol For the authentication protocol OIAP/OSAP in TPM, Bruschi et al. [19] proved in 2005, with the support of the model checker SPIN, that the authentication protocol OIAP in the TPM is exposed to replay attacks. Chen and Ryan [20] found that dictionary attacks could be performed offline on authdata in 2008 and showed that sharing authdata between users allows a TPM impersonation attack [21]. They further proposed a new authorization protocol SKAP to solve the above problems and gave out a thorough verification of authentication and secrecy in SKAP using Proverif. This amendment has already been accepted in the new edition of TPM specification. Security analysis of DAA protocol For the DAA protocol, Backes et al. [22] specified and analyzed DAA protocol within applied pi calculus using a novel equational theory that abstractly characterized the cryptographic semantics of zero-knowledge proofs. They found a novel attack on DAA protocol where the issuer cannot know exactly how many platforms have applied the DAA certificates. In 2012, Smyth et al. [23] modeled ECC-DAA and RSA-DAA by applied pi calculus and analyzed the privacy properties under the model of biprocess by Proverif. Brickell et al. [24] stated that a large number of DAA schemes can be treated as a static Diffie–Hellman (DH) oracle by a malicious user, which means that the

Chin. Sci. Bull. (2014) 59(32):4173–4189

(4)

security level might be reduced to only 2/3 of the claimed one. Security analysis of trust systems For the trust systems, Datta et al. [25] proposed a logic for reasoning properties of secure systems (LSS) extended from PCL to reason about the construction of trust chain and the process of remote attestation. In 2010, Delaune et al. [26] modeled the protocols relating to PCR and extended Proverif to analyze a simplified version of Microsoft Bitlocker and a digital envelope protocol.

2.2.3 Our work We have focused on the security analysis of mechanisms in TC for a long time and done a lot of work. In 2012, Qin et al. [27] modeled the key management API commands using applied pi calculus and found a key-handle hijack attack on some commands. Chang et al. [28] extended LSS to verify the correctness and uniqueness of trust chain under some conditions. In Ref. [29], we proposed a DAA analysis model and found out some known attacks and some new variants on them by using the model checker, Murphi, which is a novel supplement to the DAA cryptographic proof. In Ref. [30], we presented a type-based analysis on the protected storage part of TPM 2.0 API commands, which is the first API analysis on TPM 2.0. An introduction about the type-based analysis is given in the following. In the TPM 2.0 specification, the TPM-protected key objects are arranged in a tree structure, which is called protected storage hierarchy. A hierarchy is constructed with storage keys as the non-leaf nodes to which other decryption key objects or non-leaf nodes maybe attached. The protected storage of TPM 2.0 API commands achieves the process of creation, loading, and duplication of key objects. In order to specify these commands, we propose a simple imperative language. In our model, an API is specified as a set of commands. Each command contains a binding of values to parameters and a sequence of inner execution of clauses including generation of new key or seed values, retrieving the values of the resident objects, loading new objects, checking the hierarchy attributes and destructing the decryption. The semantics of commands are modeled as a set of conditional transition rules. All of the free variables (variables that have no evaluation) in clauses appear in input parameters. We only focus on the API commands that return the output at the last clause. For the key objects, we use template to describe the properties. A template is represented as a set of attributes. Set an attribute for a key object is to include such an

4179

attribute in its template set. Formally, a template is a subset of {W, E, A, S, N, F}. First two attributes are used to identify the basic groups of key objects: W for storage key object; E for decryption key object. Second, we use A (Asymmetric) and S (Symmetric) to specify the field type in the public area of the key object. Third, for the hierarchy attributes FixedTPM and FixedParent, we use N to denote FixedParent CLEAR and F to denote FixedTPM SET. (W, E), (A, S), (N, F), and (W, S) are on the list of conflicting attribute pairs. We have three kinds of key objects: the storage key object, the symmetric decryption key object and the asymmetric decryption key object. The attacker is formalized in a classic Dolev–Yao model where API commands can be called by him in any sequences and with any parameters in his knowledge. The returned values will be added to his set of known values. The main property of the protected storage hierarchy required by TPM 2.0 specifications is secrecy. More specifically, the value of private keys loaded on a TPM should never be revealed under the attacker model. Then, we present a type system to statically enforce secrecy in API commands. The type syntax is based on the principles of information flow. Each type has a pair of associated security level to specify the levels of confidentiality and integrity. For each, we consider two levels: High (H) and Low (L). Intuitively, the attackers could only read values with low confidentiality and modify data with low integrity. We map all variables to their types and assign types to the permitted templates. We also devise a set of typing rules that dictate how typed data and formalized commands should be programmed so to respect the secrecy property of the API commands. Finally, we prove our main results that welltyped API commands are secure to keep secrecy of private keys with FixedTPM SET [30]. By using this type system, we have proved that a set of the commands can guarantee the secrecy of key values in security devices under the worst cases, which is an interesting work on using type system to enforce and prove commands security.

3 Technical evolution of trusted computing This section discusses the key technologies and technical evolution of TC from our practical work. Firstly, we give the trust chain establishment methods for various computing platforms. Then, we describe the evolution process of TNC and our implementation for TNC system. Finally, we present the methods and tools used in the testing and evaluation of TC.

123

4180

3.1 Trust chain establishment 3.1.1 Basic principle of trust chain During the process of trust chain establishment, each entity must be measured before it starts to execute and obtains system control (Fig. 3). For a trust chain, there are two important problems to be addressed: (1) which entity can be the first point in the chain and used as the root of trust for measurement; (2) How to measure an entity and transfer the platform trust to the next entity. The first entity in the chain should ensure a trust anchor of the whole computing platform without any attacks. TC employs a secure chip TPM/TCM as the hardware-based root of trust [3]. Similarly with the TCG’s principles, there are several specifications [5, 31–33] to guide the establishment of trust chain based on TCM in China. Starting from the Root of Trust (Fig. 3), the system transfers the trust from one entity to another step by step. Firstly, system initializes the trust chain by measuring the initial BIOS code, which is often referred to as the Core Root of Trust for Measurement (CRTM) [34]. Then the BIOS measures and executes the bootloader, and the bootloader continues to measure and execute the operating system (OS) code. Finally, the OS code will measure each loaded applications. For each entity, a hash function (e.g., SHA1 or SM3) is used to generate the measurement value, which will be sent to TPM/TCM and extended to the Platform Configuration Registers (PCRs). As a result, the final PCRs of TPM/TCM can form a hash chain: PCRs = H(H(En)||||H(H(E2) ||H(H(E1)||Init))), where H is the hash function, Init is the initial PCR values (00 or FF), Ei is the ith loaded entity. Each entity measurement and associated event description constitute an event, which is also recorded in a measurement event log (MEL). In details, the MEL may include

Chin. Sci. Bull. (2014) 59(32):4173–4189

any meaningful measurement objects. At the level of system or user components, such as BIOS, bootloader, OS kernel and user-space application, the measurement objects may include kernel image, configuration file, script file, driver module, executable program, dynamic linking library, code segment and input/output arguments. At the micro level, the measurement objects even contain memory pages, system events, register and kernel variables. All these measurement objects form a ‘‘Platform Integrity View’’ representing the security status of the whole computing system. 3.1.2 Trust establishment for various computing platforms The principle of trust chain above is mainly designed for traditional PC platforms, but with the development of cloud computing, big data and mobile applications, there is a demand for applying it to the virtualized platforms and smart phones. Due to different hardware architecture and software environment, these new platforms adopt different implementing techniques to build the platform trust. For PC platforms, the root of trust is a TPM/TCM hardware chip that has an independent state isolated from the host platform system. TPM/TCM provides protected capabilities and shielded locations to establish trust in the computing platform and defend against various software attacks. However, TPM/TCM is not suitable to virtualized or mobile platforms. A virtualized platform may run multiple virtual machines (VMs) at the same time. It is impossible to have each VM equipped with a specialized secure chip, and the common solution is to establish the VM trust by virtualizing hardware chip TPM/TCM. There are three methods to virtualize the root of trust: (1)

(2)

Fig. 3 The transfer flow of trust chain

123

Software vTPM. This is the most typical method of virtual root of trust, which was provided by IBM [35]. In this method, the hypervisor creates a virtual TPM (called vTPM instance) for each guest VM. The vTPM instance implements most TPM commands in software and may internally use the hardware TPM to protect its own secrets. All vTPM instances are bound to the same physical TPM chip. This method is easy to deploy and manage, but may increase the complexity of hypervisor and TPM implementation. TPM Para-Virtualization. In this method [36], a hardware TPM chip can be safely shared among two or more guest VMs, so that each can use the full complement of TPM functions. The hypervisor should provide a software component to mediate guest accesses from multiple VMs and ensure TPM device sharing safely and fairly. This method reduces the complexity of vTPM, but it is difficult to mediate accesses and keep efficiency of TPM.

Chin. Sci. Bull. (2014) 59(32):4173–4189

(3)

Hardware vTPM. This method, introduced by IBM [36, 37], enhances current TPM so as to allow creation and maintenance of full virtual TPM contexts inside a physical TPM. It needs to modify hardware TPM to provide a separate context for each guest VMs, and the hypervisor can transparently use each context as the root of trust for its related VM. This method can provide better protection against physical tampering than a software vTPM, but it needs to make some substantial changes to the current TPM chips.

4181

The trust chain establishment system is our basic work to build the platform and network trust. For platform trust (Fig. 5), we have applied the technique to a PC, a cloud and a mobile phone, respectively, which achieves a security enhancement for different computing environments. We also extend the trust chain establishment system and build a trusted network service system (called TCWG TNC), so that the platform trust can be further transferred to the network. TNC will be introduced in the next section. (1)

For mobile devices, due to the limits in computing resources and device spaces, it is infeasible to embed a hardware chip in a mobile device. Thus, TCG proposed its MTM [38] specification for mobile platform, which allows to implement root of trust in software. Obviously, MTM is incapable to provide an isolated execution environment by itself, so it usually relies on the security features of mobile CPUs (e.g., ARM TrustZone) or some onboard smart cards (e.g., Java Cards). In conclusion, the basic principles of different trust establishment methods are almost the same. However, due to heterogeneous hardware/software environments and subsequent different implementations of roots of trust, each kind of trust establishment method has its own characteristic. 3.1.3 Our architecture for trust chain Based on the principle of trust chain, we have implemented a trust chain establishment system. Our system starts from a root of trust and forms a complete trust chain. Each link of the trust chain accomplishes the trust transfer through a corresponding subsystem. For example, TCWG GRUB (Fig. 4) is a trusted boot subsystem, which transfers the trust from Bootloader to OS and builds a secure environment for the upper OS, measurement subsystems and applications. The system can establish a TC platform locally; what’s more, it can be further used to extend trust to the network.

(2)

Fig. 4 (Color online) TCWG trust chain establishment system

Trust PC The trust chain only boots a trust system and obtains the integrity states of the system, but it does not completely solve the trust verification problem in practice. So we also implemented a trust attestation service so as to build a trust PC platform, which has the function of verifying the TCM identity and the PC’s integrity state. The system is composed of a secure client, a verification service and an integrity management service. The secure client is equipped with a TCM and our trust chain establishment system described above, and a measurement agent (MA) is built to obtain the identity and integrity information of the secure client and further interact with the verification service. The verification service and the integrity management service are usually located in the same server platform and share a database storing the integrity metadata. The former service is responsible for checking the identity and integrity information from MA according to the standard values in database, and the latter service provides a web interface for the administrator to maintain the standard metadata. Only integrity values published by a trusted authority can be added into the database. According to the diversity of clients, we have customized several different templates of integrity metadata for Linux, OpenSolaris, Kylin OS and Windows, respectively. Up to now, our Trust PC system has already been put into practice applications in the industrial information system. Current trust PC is mainly based on the open source Linux system, because it is easy to modify the kernel to implement the integrity measurement. However, our system can implement both the Linux and Windows kernel measurement by the TCM chip. What is more, we have modified the kernel to enable the process control based on a whitelist policy. And all the programs that are not included in the whitelist will be prohibited from running, which can keep our system always in the initial trust state. Trust cloud We have designed a new approach for virtualization platforms: we implemented a virtual trust system in an isolated trust domain, which provides various trust services (including virtual root

123

4182

Chin. Sci. Bull. (2014) 59(32):4173–4189

Fig. 5 (Color online) Implementation of various trust platforms based on TCWG trust chain architecture

of trust) for other guest VMs. Our method is similar to the software vTPM method and can provide specialized virtual root of trust for every guest VM system using one hardware TPM chip. However, it does not need any essential changes to the secure chip or hypervisor. We adopt a special trust domain to host our trust services rather than using the management domain or hypervisor, so the TCB is smaller and the virtual TPM service will not be influenced by other services in the management domain. Furthermore, it is easier to deploy and migrate the virtual root of trust. Based on the physical hardware TPM and virtual TPM, the trust chain in the cloud platform is divided into two layers. The first layer is to establish a trust chain from hardware TPM to the hypervisor and management domain; the second layer is to further extend the trust chain from the hypervisor to a special guest VM system. The second layer is built on the first one as the part of TCB. The first layer is similar to the trust chain establishment process of the traditional PC platform: starting from CRTM, BIOS, bootloader, hypervisor and our vTPM domain are successively measured and executed. The first layer uses the hardware TPM to extend integrity value of loaded entities. After the vTPM domain obtains the control, it prepares multiple vTPM instances for other guest VMs. Based on the vTPM, we can boot a trusted guest virtual system and finish the second layer of the trust chain. The second layer uses the virtual TPM to extend the integrity value of guest OS and various guest applications. Compared with existing work [35–37], our Trust Cloud belongs to the software vTPM type. But we distinguish the virtual trust domain from the

123

(3)

management domain. Our implementation is based on Xen hypervisor and the open source TPM emulator (http://tpm-emulator.berlios.de/). Trust mobile phone Currently, Android is one of the most dominant smartphone OSes, which is a Linux system in essence. Given trust chain establishment system for PC Linux, it is largely easy to port the system to mobile platforms such as Android, except one remaining problem: how to implement the TC function securely and provide a root of trust for mobile platforms. Addressing on this problem, we carried out researches of trust chain establishment method for mobile and embedded platforms and presented a mobile TC architecture called TEEM [39, 40]. TEEM runs a TPM/TCM/MTM emulator in the isolated environment provided by ARM TrustZone [41]. ARM’s TrustZone Security Extensions enable a single physical processor core to safely and efficiently execute code in two worlds [39]: the secure world for security sensitive codes and the normal world for universal programs. A new processor mode, called the monitor mode, supports context switching between the two worlds. TEEM is deployed in the secure world of mobile device, which contains the necessary protected capabilities of TC. The normal mobile OS and software in the normal world cannot access TEEM without the authorization from secure world, but can call a mobile trusted software library to use the TC functions of TEEM. Therefore, TEEM can provide TC services (like platform identity, protected storage, integrity measurement, etc.) and the root of trust for smart phones. As the vast majority of mobile devices are based on ARM CPUs, we believe TEEM is a good choice to establish trust in mobile and embedded platforms.

Chin. Sci. Bull. (2014) 59(32):4173–4189

To establish a trust chain for mobile platforms with TEEM, we adopt a two-stage process. In the first stage, we boot the secure world using the secure boot mechanism and start the TEEM TC services and instances. When power is on, the mobile platform first executes the BootROM code to initialize the system. The BootROM will load a lightweight hypervisor after verifying the integrity. The hypervisor is responsible for isolating the secure world and the normal world and providing some secure communication mechanisms between the two worlds based on ARM TrustZone. Then, the hypervisor first boots into the secure world by measuring and verifying the bootloader, the TEEM kernel and the TEEM instances one by one. After that, the TEEM can provide TC functions for normal mobile environment. To boot the normal world in the second stage, we use the trusted boot method. For an Android platform, the hypervisor will measure and execute the bootloader, and the bootloader, in turn, measures and executes the Linux kernel. The kernel will measure and execute the Android native services and Android framework services. At last, the framework will measure every loaded Android application. All the measuring values will be extended into the PCRs of TEEM. Above all, there are two features for the trust chain establishment system of TEEM-enabled mobile platforms: (1) the root of trust is a TC environment based on ARM TrustZone instead of hardware TPM/TCM, (2) the root of trust and the running system are on the same platform, but different isolated spaces. Current trust mobile phone uses a secure element (such as TrustZone or Smart card) to protect the mobile apps and programs, and the trusted functions are from the software MTMs. As a contrast, our implementation contains all trusted modules (TPM/TCM/MTM) in the TrustZone secure world and can provide TC support for both mobile and desktop applications. What is more, the trusted modules can be updated and extended easily to satisfy new secure requirements. For more details, please refer to our previous work in TEEM [39]. In conclusion, we have implemented roots of trust and trust chain establishment systems for various computing platforms. On one hand, the trust PC has already matured and been put into practical applications. On the other hand, it is a promising future direction to develop trust chain techniques for virtualized and mobile platforms. And it is also an interesting work to build secure cloud services based on virtual trust chain and develop lightweight mobile-trusted functions based on TEEM. From our engineering practice, the establishment method of trust chain is closely related to the hardware/ software architecture of computing platforms. The implementation of trust chain has its own characteristic on each type of platform. The traditional PC platform relies on the

4183

static transitive trust based on secure chip, which is the basic form for trust chain. While the technology of trust chain is applied in new virtualized or mobile platform, it evolves into the dynamic isolated trust. The virtualized platform uses a hypervisor to achieve isolation, and its trust chain is two-layer compared with the traditional one. The mobile platform usually uses a special CPU mode (like ARM TrustZone) to obtain an isolated TrEE environment. Recently, a more flexible root of trust called cTPM [42] is proposed to build the trust domain for cloud computing, which can secure users’ data sharing among multiple computing devices. 3.2 Trusted network connection 3.2.1 Overview It is widely accepted that terminal vulnerability is a major threat to network security. On this consideration, TCG proposed TNC specifications [43], which prevent insecure terminal from accessing protected or internal network so as to strengthen the security of network. And the similar specification, the Trusted connect architecture [44] was released in China. Basic idea of TNC is verifying connecting end points’ trustworthiness and rejecting those insecure ones. TNC is a kind of network access control (NAC) solution. From this point of view, it is rather similar as Cisco’s Network Admission Control [45] and Microsoft’s Network Access Protection [46]. But in detail, TNC, consists of a set of standards or specifications for trusted network access, aims at providing an open architecture rather than some specific product. TNC successfully brings TC technology to the applications of network access control. IETF [47] published a reference framework for network access control (Fig. 6). The framework is composed of a client, a server and a network enforcement point. The client is resident on an end point device and comprised of three functional components: posture collector(s), client broker and network access requestor. Correspondingly, the functional components of server are posture validator(s), server broker and network access authority. The client is responsible for responding to requests for security attributes describing the configuration of the client system. The

Fig. 6 (Color online) The IETF framework of network access control

123

4184

server verifies the security attributes from each client and computes an assessment decision based on the verification result. The decision will be sent to the network enforcement point, which controls access to a protected network by enforcing access polices. Usually, the network enforcement point is a network component implemented in 802.1x switch, VPN gateway or firewall. All these functional components constitute a basic framework for network access control. TCG’s TNC, Microsoft’s NAP and Cisco’s NAC have the similar architecture and functional components. IETF and TCG group are trying to achieve interoperability between these NAC solutions, and it has become a general trend for them to integrate together in technology, application and standard. 3.2.2 Implementation To meet the increasing requirements of network access and management, we have designed and implemented a trusted network service system (called TCWG TNC) based on our trust chain establishment system. It is compatible with TCG specification and IETF framework. Our system uses the terminal trust to verify the platform identity and integrity state of accessing endpoints, and thus establish a trusted network environment. Furthermore, our system supports TCM chip to satisfy the demand of trusted applications in China. The system architecture of TCWG TNC is described in Fig. 7. It contains three entities: network access terminal, network access device (or policy enforcement point) and AAA server (or policy decision point). The three entities correspond to Network Access Requestor, Network Enforcement Point and Network Access Authority in the IETF framework, respectively. The communication protocols of these entities follow the TCG’s standards. TCWG

Fig. 7 (Color online) TCWG TNC architecture

123

Chin. Sci. Bull. (2014) 59(32):4173–4189

TNC strengthens the terminal verification functions. For identity verification, it implements the two-factor identity authentication based on both user and platform. For integrity verification, our system collects four types of information: platform integrity log of system boot process, anti-virus software configuration, firewall configuration and the OS version and patches. Only after the successful verification of terminal information, the terminal can obtain the permissions to access the protected network resources; otherwise, the terminal has limited network permissions. Based on TCWG TNC architecture, we have implemented two network-accessing technology methods. The first method enforces access control in the network layer (the third layer of the OSI model), i.e., messages are forwarded in the network layer and the access policy is based on ip-tables. The second method is implemented in the data-link layer by extending the 802.1x network authentication protocol with TNC integrity request and response (Fig. 8). In the data-link method, TNC server gives VLANbased access control policy, and then the ports on the switch or router will enforce the policy to isolate the terminal or VLAN. The two implementation methods are different in control granularity and application scope. The network layer method can control the granularity of IP address, while the data-link method can control the ports of switch/router or VLAN. The first method is usually more convenient and cheap to implement and deploy, so it is suitable for smallscale networks. The second method has high performance but needs the support of particular switch/router, so it is relatively suitable for large-scale networks. In conclusion, our TNC system has the following characteristics and advantages: (1) it is compatible with TCG standards and provides good interoperability; (2) it

Chin. Sci. Bull. (2014) 59(32):4173–4189

4185

Fig. 8 (Color online) TNC extension for 802.19 authentication protocol

supports both TPM and TCM secure chip and provides platform identity/integrity verification and integrity metadata management; (3) it supports wired LAN, wireless 802.1x and can be easily extended to various network environment; and (4) it realizes several security functions including platform authentication, network connection control and network access audit. By performance test in the data-link method, the access time for a single terminal is \0.5 s and the time for multiple simultaneous terminals is no more than 1 s. So our TNC implementation can meet the demand of practical application for network access.

the following aspects: (1) we have built the extended finitestate machine model (EFSM) for TPM/TCM secure chips and proposed an automatic method for generating test cases; (2) Aiming at the internal cryptographic algorithms of TPM/TCM, we have developed the tools to test and analyze these algorithms; and (3) Based on above methods, we have implemented an integrated testing and evaluation system for TC, which contains the compliance test for all TPM/TCM algorithms, API and security functions. We have also finished one cryptographic industry standard (GM standard) [5] based on our engineering work. In this section, we will introduce these researches.

3.3 Trusted computing testing and evaluation TC technology plays an important role in security assurance and trust establishment of various computing platforms. Does TC really achieve the security properties it claims to? Testing and evaluation can provide a reliable guarantee to the application of TC technology. Usually, the major testing and evaluation objects contain three aspects: secure chip (such as TPM/TCM module), trusted software stack (such as TSS and TSM) and TC platform (secure desktop, laptop, etc.). The main goal is to test and evaluate the standard compliance, security and implementation features of these TC products according to the corresponding standards of cryptographic module, TC and security evaluation. Since 2007, we have carried out a series of studies in the field of TC testing and evaluation. Our researches focus on

3.3.1 Test method of standard compliance for TPM/TCM Sadeghi et al. [48] first proposed a test suite for TPM compliance tests according to the TCG specification. But the method relied on a lot of manual operations and specific professional knowledge and was lack of effective analysis to test results. So we provided EFSM-based testing model and the automatic method for TPM/TCM standard compliance testing [49, 50]. TPM/TCM specifications are all described by natural language and are prone to contain ambiguity. Thus, we use Z language to describe the specifications formally. We perform the function division according to the TPM/TCM specifications and abstract and simplify each function class

123

4186

Chin. Sci. Bull. (2014) 59(32):4173–4189

Fig. 9 Formal description for key management operations

(or subsystem) to highlight the core functions. Then, we use Z language to give an accurate formal description for each subsystem. Figure 9 illustrates the examples of formal description for three TPM key management operations (create, load and evict). For more detail about the Z language description, please refer to our previous work [49, 50]. Based on the formal description in Z language, we establish the extended finite-state machine model. EFSM defines a six-tuple \S; S0 ; I; O; T; V [ , where S is a non-empty state set, S0 is the initial state set, I is a nonempty input message set, O is a non-empty output message set, V is the variable set and for each state transition t 2 T, T is also a six-tuple (s; x; P; op; y; s0 ), s; s0 2 S are the initial state and the terminate state, x 2 I is the input, y 2 O is the output, P is the precondition (it may be empty) and op is the operation. We use the EFSM definition to establish the testing and evaluation model of TPM/TCM. For TPM cryptography subsystem, the state transition operations include TPM_CreateKey, TPM_LoadKey, TPM_EvictKey, TPM_Seal, TPM_UnSeal, TPM_Sign, TPM_Verify, TPM_Encrypt and TPM_Decrypt, and its corresponding EFSM model is given in Fig. 10. The model describes the internal variables related to TPM/TCM state and adopts the equivalence partitioning method to simplify the combination numbers of TPM/TCM command sequence and output parameters. So the model can avoid the state space explosion and meanwhile describe the TPM/TCM state transformation effectively. Based on the EFSM model, we further propose the specification-based method to generate test cases automatically. The generation process is mainly divided into two stages. The first stage generates abstract test cases according to the dependency and execution flow of

123

Fig. 10 EFSM model for TPM/TCM cryptography subsystem

TPM/TCM commands. The abstract test cases cannot be used and executed directly, but can identify the command execution order and reflect the control flow and data flow relation between commands. The second stage transfers the abstract test cases to concrete test cases by adding concrete parameters to test commands. This method needs less manual intervention and has a relative high automatic level, which can improve the efficiency of test. Finally, after the generation of test cases, we use the reachability analysis tree to analyze the paths and verify the coverage rate of test cases. By experiment, the coverage rate of the test cases for TPM/TCM cryptography subsystem is up to 95 %. And the detection rate to error test cases is 9.35 %, which is higher than the 4 % of Sadeghi’s method. So our method can better meet the needs of actual test applications. In conclusion, a whole test process is given in Fig. 11. Firstly, we give the formal description of trusted platform module. According to the Z specification, we then build the EFSM-based formal model. And next, we utilize the case

Chin. Sci. Bull. (2014) 59(32):4173–4189

4187

3.3.3 Integrated testing and evaluation system

Fig. 11 The test flow of TPM/TCM

generation tool to produce executable test scripts. Finally, the test platform performs testing on the scripts and outputs the test report. Up to now, we have finished the standard compliance testing of multiple trusted chips including Atmel AT97SC3203, NSC TPM 1.2, Lenovo TPM 1.1b and two mainstream TCM products. Although their manufacturers claimed that their products conform to the TPM 1.2 specification [3] or TCM standards [5], we found that the real testing results are not optimistic. Errors are detected in several products, such as wrong resource handle, the command code error and the return code error, which may lead to some attacks and create the serious consequences. 3.3.2 Cryptography algorithm testing Cryptography algorithm testing is to verify the correctness and compliance of signature algorithms and encryption/ decryption algorithms used inside the secure chips and trusted software stacks. Based on the pre-built test cases, our tool uses the blackbox testing method to test various cryptography algorithms such as RSA, SM2, SM3, SM4 and HMAC. Furthermore, the testing process accords with the corresponding standards. For example, for SM2, SM3 and SM4 algorithm used by TCM/TSM, we call the interfaces to encrypt, sign and hash random messages and verify the correctness of output results according to the SM series standards released by State Cryptography Administration Office. For TPM and TSS, we use the test vectors recommended by RSA PKCS#1 and FIPS 180-1 standards to test RSA and SHA-1, respectively. The random number generation is tested according to the FIPS 140-1 specification. Furthermore, we also test the performance of related cryptography algorithms and the quality of the random number generation. Through comparing the performance, we confirm that SM2 is faster than RSA and that the SM4 symmetric algorithm is more suitable for encryption and decryption operations. For the random number generation, we focus on the randomness testing including frequency test, frequency test within a block, runs test, binary matrix rank test, linear complexity test, approximate entropy test.

Based on the above testing methods, we have designed and implemented an integrated testing and evaluation system. This is the first testing system for TC products in China, which has been successfully put into practical applications by domestic information security evaluation organization. The system supports the standard compliance testing and security functions testing of various TPM/TCM products. What is more, the system has good scalability and can provide a comprehensive analysis for testing results. At present, we have finished the test of TCM chips from Nationz Technologies and Tongfang Microelectronics Company. We have also successfully performed testing and analysis to some security PCs of Lenovo, Tongfang and Founder. Figure 12 shows the architecture of our testing and evaluation system. Aiming at supporting concurrent testing of multiple TC products, the system adopts C/S architecture and can be mainly divided into three subsystems: test agent, test control module and supporting databases. Test agent is a software built into testing objects (e.g., platforms with TPM/TCM), which invokes the trusted software stack APIs or TDDL interfaces to perform testing and data collection. Test control module is the central of the entire system. It provides testing and management functions for testers. The supporting database is responsible for storing related test data and result. The system has been practically applied to the testing of a variety of secure chips, trusted software stacks and TC platforms, and a number of problems have been found in existing products, such as incomplete support of command parameters, understanding deviations of specifications, bad robustness of interfaces. Based on methods and experience in both theoretical and technical aspects, we have formed one testing and evaluation standard for TC: ‘‘Compliance Test of Trusted Cryptography Module’’. The standard has played a crucial role in guiding the production, test and certification of TC products in China. 4 Direction of future evolution At present, TC has become a new hotspot for network and information security. During the evolution of TC, the products are put into large-scale applications in industrial world, and the theories and technologies are continued to be improved and upgraded in academic world. From the above introduction of evolution on theory and practice, some new directions of TC are summarized for future work: (1)

TC on traditional PC advances toward the new computing platform such as virtualization, trust cloud, mobile TC.

123

4188

Chin. Sci. Bull. (2014) 59(32):4173–4189

Fig. 12 (Color online) Integrated testing and evaluation system for trusted computing

(2)

(3)

(4)

TC theories and technologies for PC are quite mature to equip TPM/TCM in almost every desktop terminal. With the new emerging mobile trust computing and trust cloud, TC confronts many special challenges for new platform. It is a very important research to build trust for new computing platforms in future; TPM 1.2 has been upgraded to TPM 2.0, which supports different cryptographic algorithms and provides more flexible trust mechanisms. The design principles and application scenarios are different between TPM 1.2 and 2.0. TPM 2.0 attempts to provide trust service for mobile trust computing, such as cellular phone, tablet, embedding devices. In the future development, TPM 2.0 still needs to verify its compatibility, security and availability for the new platforms; On theoretical evolution of TC, the research on design theory stimulates the theoretical development of security analysis. Conversely, the security analysis advances the development of design theory. The TC protocol and system have faced serious security challenges in engineering practice, so that it compels security analysis theory to advance quickly. The researches on security analysis have improved TC technology and specification. Security analysis finds a series of vulnerabilities for TPM 1.2, and new TPM 2.0 alleviates these problems in its research and design. For example, authorization session of TPM 2.0 adds salt against offline dictionary attack of TPM 1.2; TPM 2.0 adds counter to protect session against OIAP man-in-the-middle attack of TPM 1.2; The method of trust building is from static transitive trust to isolated trust like TrEE system integrating

123

hardware/software. In mobile generation of TPM 2.0, trust building depends on the hardware/software implementation of root of trust. TrEE is a technical trend, but we must combine these two kinds of trust to build TrEE system. Acknowledgments The work was supported by the National Basic Research Program of China (2013CB338003) and the National Natural Science Foundation of China (91118006 and 61202414).

References 1. Common Criteria Project Sponsoring Organisation (1999) Common criteria for information technology security evaluation. ISO/ IEC international stan 15408 ver 2.1. Common Criteria Project Sponsoring Organisation, Genevese 2. Avizienis A, Laprie J-C, Randell B et al (2004) Basic concepts and taxonomy of dependable and secure computing. IEEE Trans Dependable Secur 1:11–33 3. Trusted Computing Group (2003) TCG specification architecture overview, ver 1.2. https://www.trustedcomputinggroup.org 4. Feng D (2013) Trusted computing—theory and practise. Beijing Tsinghua University Press, Beijing (in Chinese) 5. China National Information Security Standardization Technology Committee (2013) Functionality and interface specification of cryptographic support platform for trusted computing. GB/T 29829-2013 (in Chinese) 6. Chen L, Li J (2013) Flexible and scalable digital signatures in TPM 2.0. In: Proceedings of the 2013 ACM SIGSAC conference on computer and communications security (ACM-CCS), pp 37–48 7. Brickell E, Camenisch J, Chen L (2004) Direct anonymous attestation. In: Proceedings of the 11th ACM conference on computer and communications security, pp 132–145 8. Ge H, Tate SR (2007) A direct anonymous attestation scheme for embedded devices. In: Proceedings of the 10th international

Chin. Sci. Bull. (2014) 59(32):4173–4189

9.

10.

11. 12.

13. 14.

15.

16. 17.

18.

19.

20.

21.

22.

23.

24.

25.

26.

27.

28.

conference on practice and theory in public-key cryptography, pp 16–30 Brickell E, Chen L, Li J (2008) A new direct anonymous attestation scheme from bilinear maps. In: Lipp P, Sadeghi AR, Koch KM (eds) Trusted computing—challenges and applications, Springer, Berlin, pp 166–178 Brickell E, Chen L, Li J (2009) Simplified security notions of direct anonymous attestation and a concrete scheme from pairings. Int J Inf Secur 8:315–330 Chen L, Morrissey P, Smart NP (2009) DAA: fixing the pairing based protocols. IACR Cryptol ePrint Arch 2009:198 Chen L, Page D, Smart NP (2010) On the design and implementation of an efficient DAA scheme. In: Proceedings of the 9th IFIP WG 8.8/11.2 international conference on smart card research and advanced application, pp 223–237 Chen X, Feng D (2008) Direct anonymous attestation for next generation TPM. J Comput 3:8 Chen L (2010) A DAA scheme requiring less TPM resources. In: Proceedings of the 5th international conference on information security and cryptology, pp 350–365 Brickell E, Li J (2010) A pairing-based DAA scheme further reducing TPM resources. In: Proceedings of the 3rd international conference on trust and trustworthy computing, pp 181–195 Lin AH (2005) Automated analysis of security APIs. Master Thesis, Massachusetts Institute of Technology Gurgens S, Rudolph C, Scheuermann D et al (2007) Security evaluation of scenarios based on the TCG’s TPM specification. In: Proceedings of 12th European symposium on research in computer security (ESORICS), pp 438–453 Delaune S, Kremer S, Ryan MD et al (2011) A formal analysis of authentication in the TPM. In: Proceedings of 7th international workshop on formal aspects of security and trust (FAST), pp 111–125 Bruschi D, Cavallaro L, Lanzi A (2005) Replay attack in TCG specification and solution. In: Proceedings of 21st annual computer security applications conference (ACSAC), pp 127–137 Chen L, Ryan M (2008) Offline dictionary attack on TCG TPM weak authorisation data. In: Proceedings of the first international conference future of trust in computing, pp 193–196 Chen L, Ryan M (2010) Attack, solution and verification for shared authorisation data in TCG TPM. In: Proceedings of 6th international workshop on formal aspects of security and trust (FAST), pp 201–216 Backes M, Maffei M, Unruh D (2008) Zero-knowledge in the applied pi-calculus and automated verification of the direct anonymous attestation protocol. In: Proceedings of the 2008 IEEE symposium on security and privacy, pp 202–215 Smyth B, Ryan MD, Chen L (2012) Formal analysis of privacy in direct anonymous attestation schemes. IACR Cryptol ePrint Arch 2012:650 Brickell E, Chen L, Li J (2012) A static diffie-hellman attack on several direct anonymous attestation schemes. In: Mitchell CJ, Tomlinson A (eds) Trusted systems. Springer, Berlin, pp 95–111 Datta A, Franklin J, Garg D et al (2009) A logic of secure systems and its application to trusted computing. In: Proceedings of the 2009 30th IEEE symposium on security and privacy, pp 221–236 Delaune S, Kremer S, Ryan M et al (2010) Formal analysis of protocols based on TPM state registers. In: Proceedings of the 2011 IEEE 24th computer security foundations symposium, pp 66–80 Qin Y, Zhao S, Zhang Q (2012) Formal analysis of trusted platform module commands for compromising user key. China Commun 9:91–102 Chang D, Feng D, Qin Y et al (2012) Analyzing the trust chain of trusted virtualization platform based on the extended LS^2. J Commun 2013:31–41

4189 29. Qin Y, Chu X, Feng D et al (2012) DAA protocol analysis and verification. In: Chen LQ, Yung M , Zhu LH (eds) Trusted systems. Springer, Berlin, pp 338–350 30. Shao J, Feng D, Qin Y (2013) Type-based analysis of protected storage in the TPM. In: Proceedings of the 15th international conference on information and communications security, pp 135–150 31. State Cryptography Administration Office (2012) Trusted computing—interface specification of trusted cryptography module. GM/T 0012-2012 (in Chinese) 32. China National Information Security Standardization Technology Committee (2012) Trusted computing—trusted cryptography module interface compliance. GM/T 0013-2012 (in Chinese) 33. China National Information Security Standardization Technology Committee (2013) Trusted computing specification—motherboard function and interface of trusted platform. GB/T 29827-2013 (in Chinese) 34. Parno B, McCune J M, Perrig A (2010) Bootstrapping trust in commodity computers. In: Proceedings of the 2010 IEEE symposium on security and privacy (S&P), pp 414–429 35. Berger S, Cceres R, Goldman K A et al (2006) vTPM: virtualizing the trusted platform module. In: Proceedings of the 15th conference on USENIX security symposium (Security), pp 305–320 36. England P, Loeser J (2008) Para-virtualized TPM sharing. In: Proceedings of the first international conference on trusted computing and trust in information technologies, pp 119–132 37. Goldman KA, Berger S (2008) TPM main part 3—IBM commands. http://domino.research.ibm.com/ 38. TCG Mobile Phone Working Group (2010) TCG mobile trusted module specification. ver 1.0, revision 7.02 39. Feng W, Feng D, Wei G et al (2013) TEEM: a user-oriented trusted mobile device for multi-platform security applications. In: Proceedings of the 6th international conference on trust and trustworthy computing (Trust), pp 133–141 40. Feng W, Qin Y, Feng D et al (2013) Mobile trusted agent (MTA): build user-based trust for general-purpose computer platform. In: Proceedings of 7th international conference on network and system security (NSS), pp 307–320 41. ARM Limited (2009) ARM security technology: building a secure system using trustzone technology. ARM technical white paper 42. Chen C, Raj H, Saroiu S et al (2014) cTPM: a cloud TPM for cross-device trusted applications. In: Proceedings of the 11th USENIX conference on networked systems design and implementation, pp 187–201 43. TCG Trusted Network Connect (2009) TNC architecture for interoperability, ver 1.4, revision 4. http://www.trustedcomputinggroup. org/developers/trusted_network_connect.specification 44. China National Information Security Standardization Technology Committee (2013) Trusted computing specification—trusted connect architecture. GB/T 29828-2013 (in Chinese) 45. Cisco. Home of network cisco admission control. http://www.cisco. com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gt_nac.html 46. Microsoft. Home of microsoft network access protection. http:// technet.microsoft.com/en-us/network/bb545879.aspx 47. Sangster P, Khosravi H, Mani M et al (2008) Network endpoint assessment (NEA): overview and requirements, RFC 5209 48. Sadeghi AR, Selhorst M, Stble C et al (2006) TCG inside? A note on TPM specification compliance. In: Proceedings of the first ACM workshop on scalable trusted computing, pp 47–56 49. Chen X (2009) The formal analysis and testing of trusted platform module. Chin J Comput 32:27–34 (in Chinese) 50. Li H, Hu H, Chen X (2009) Research on compliant testing method of trusted cryptography module. Chin J Comput 32:1–10 (in Chinese)

123