7 Remote Attestation – Trusted Computing

7Remote Attestation

Remote attestation is one of the most important functionalities of the trusted computing. The Trusted Platform Module (TPM)/Trusted Cryptography Module (TCM) user can complete the attestation of the trusted computing platform identity and the platform configuration integrity by using security chip. From a certain point of view, even the TPM/TCM can be regarded as a dedicated security chip to do remote attestation. Remote attestation can attest the hardware, firmware and software of the trusted computing platform. It can attest all the softwares running on every layer of the software stack, and even the running states of the virtual machine on the platform in communication with the remote verifier. Remote attestation can attest both the identity of the security chip and the platform states at the same time, which greatly improves the security of the network communication terminals.

Remote attestation is the extension of the trust of the trusted computing platform from the terminal to the network. In practice, it can satisfy the security requirements of the users in many aspects: (1) It can help determine whether or not the computing platform in communication is trusted, namely whether or not it can support the trusted computing capabilities. (2) It can help detect the integrity of the input and output of the softwares running in the platform as well as the platform configuration. (3) It can help verify whether or not the current platform configuration satisfies the verifier security policy. Remote attestation can be widely used in PC, network servers, embedded devices, mobile Internet, cloud computing and other different environments. It is one of the most important applications of the trusted computing.

In a narrow sense, the remote attestation refers to the attestation of the platform integrity of the current platform configuration and the running state by the TPM/TCM security chip, but in practice, the trusted computing platform will inevitably attest the platform identity in the attestation of the platform configuration. Therefore, the platform identity based on TPM/TCM can also be included in the category of the remote attestation. Remote attestation can be divided into two categories according to the different attested objectives, namely the Attestation of Platform Integrity and the Attestation of Identity. There is also a more generalized interpretation of the remote attestation. It includes the attestation of all the entities in the trusted computing platform. In addition to the identity and integrity, the attestations of the key and data in the trusted computing platform are also regarded as the remote attestation. For example, the key certification is to attest that the key is generated by the TPM chip and it is bound with the TPM. The Subject Key Attestation Evidence (SKAE) is the mechanism to attest the key source (can be seen as the key identity), and to support the subject key certificate extension. The certification of data unsealing requires the configuration state for unsealing the data is the same to that for sealing data. It essentially attests that the current configuration state is exactly the same to that for the unsealing and can be regarded as the attestation of the use of data. These are both the extension of the remote attestation semantics and belong to the category of the generalized attestation of the trusted computing platform. However, in this chapter we use the common classification of the remote attestations and divide them into the attestations of platform integrity and identity to discuss.

7.1Remote Attestation Principle

Remote attestation is an advanced security service provided by the TPM/TCM security chip. It needs the auxiliary supports of other basic functions such as key management and integrity measurement. In general, the remote attestation principle is to outline the procedure of attestation from the macroscopic view, but in this section, we will give a comprehensive introduction of the detailed remote attestation principle from the view of the foundation, the protocol, the interfaces and other aspects.

7.1.1Technology Foundation

Remote attestation involves what the content in the platform is to be attested and how to attest by the TPM/TCM. These are the technology foundations for the remote attestation (or the necessary conditions). TPM/TCM security chip must provide these basic functions to support attestation. Integrity measurement and quoting of the identity key are the two most critical basic security functions. Integrity measurement and reporting are to solve the problem of what to be attested. The TPM/TCM identity keys and quoting are to solve the problem of how to attest.

7.1.1.1Integrity Measurement

Integrity measurement is the process for the TPM/TCM security chip to acquire the platform software and hardware characteristic values of trust degree. Usually, these values are extended into the Platform Configuration Registers (PCRs) in the form of digests. The starting point of the integrity measurement is called the Root of Trust for Measurement (RTM), which is located within the TPM/TCM security chip, and is trust by default. When the computer starts, the trusted computing platform begins to execute the integrity measurement process. From BIOS, bootloader, OS to the applications, each entity will be measured by the TPM/TCM. For every measurement, the security chip will create a measurement event, which contains the measured values (characteristic value of the executed program code or the data) and the measurement digest (the hash value of the characteristic value), which is extended into the PCRs. The measurement evente, which is caused by any changes in the integrity at any system layer, will inevitably make the system transit from one trusted state to another trusted state. For example, S i e i+1 S i+1 e i+j S i+j represents the sequence of events ei+1, ei+2, . . . , ei+j, which lead to the transitions of the state sequence Si+1, Si+2, . . . , Si+j. If Si and each measurement event e is known to be trusted, the state sequence is transited from Si to Sj, the final state Sj is trusted.

By using the integrity measurement, the trusted computing platform can record the integrity states of the executions of all modules (hardware and software) in the platform to build the chain of trust of the trusted computing platform. If there is any module that has been maliciously infected, its digest value must be changed so that we can know which module in the system has problems. The integrity measurement values need to be stored following a specific format, which forms the storage measurement list (SML). The list might be very large and need to be stored outside the security chip. It records all the integrity measurement events during the system startup and running. Based on SML, the TPM/TCM chip can attest the integrity configurations and running states of the trusted computing platform identified by SML.

7.1.1.2Platform Identity Key Quote

TPM/TCM security chip supports multiple key types. TPM defines seven key types including the signing key, the storage key, the identity key, the endorsement key (EK), the binding key, the migratable key and the certified key. Although the TCM adopts different cryptographic algorithms, it also defines the similar key types. Among these key types, only the platform identity key (PIK) can be used for remote attestation. The PIK in the TPM specification is called the attestation identity key (AIK), and is called the PIK) in the TCM specification. AIK is an RSA key and PIK is an elliptic curve cryptology (ECC) key. Except for these key types, they are the same for the other aspects.

The PIK can only be created and used by the trusted computing platform owner. Common users can neither use the PIK nor do the remote attestation. The TPM owner can use the command TPM_MakeIdentity to create the AIK with the type of identity key. This key can be used to do remote attestation by signing the TPM internal PCRs. In addition, when used in the remote attestation, the AIK should be used with the AIK certificate. Thus the TPM specification specifies that the trusted third-party Privacy CA can issue the AIK certificate. The certificate can be imported into the platform for use through the TPM command TPM_ActivateIdentity. In the remote attestation, the remote verifier usually determines the TPM identity by checking the validity of the AIK certificate. Then it can verify the signature in the TPM remote attestation by using the public key of the AIK, and finally complete the integrity verification.

The signing process of TPM remote attestation is also called PIK quote. TPM uses the command TPM_Quote to sign the integrity measurement value stored in the internal PCR. Before the remote attestation, the TPM owner first loads the PIK AIK. When the verifier starts the remote attestation challenge, the TPM owner chooses the PCR to be attested which represents the platform integrity. Then the owner inputs the challenge nonce and the selected PCR to invoke the TPM command TPM_Quote. The TPM outputs the signature of the corresponding remote attestation. The detailed process will be given in the following interface implementation (Section 7.1.3) of the remote attestation.

7.1.2Protocol Model

Remote attestation is achieved by the attestation protocol based on the TPM/TCM cryptographic functions. Although there are a variety of different specific protocols, they all have a unified protocol model. In this section, we will take as an example the most basic remote attestation based on AIK to discuss the remote attestation protocol model. In the remote attestation model, the main participants include the trusted computing platform, the remote verifier and the trusted third party. It is presented in Figure 7.1.

The trusted computing platform includes the TPM/TCM security chip and the host, which together complete the attestation of the platform integrity. The host is mainly to measure and report the platform integrity, and the TPM/TCM security chip is mainly to generate signature in the remote attestation.

The remote verifier is the challenger of the remote attestation. It requests the trusted computing platform to attest the integrity states of the current system, and according to the corresponding verification policy it verifies the trusted computing platform integrity log and the signature from the security chip. Before the remote attestation, it must obtain the public key of the AIK and the trusted third party, in order to ensure the trusted relationship between the participants of remote attestation and to prevent that the attacker forges the identity to deceive other participants.

The trusted third party in the basic remote attestation protocol is the Privacy CA. It issues the certificate for the identity key of trusted computing platform and provides checking of the validation of the certificates. When the trusted third party issues the AIK certificate for the trusted computing platform, it must verify the EK of the TPM/TCM chip so as to ensure the authenticity of the TPM/TCM identity.

Figure 7.1: Remote attestation model.
Figure 7.2: Remote attestation process: (a) protocol process between trusted computing platform and verifier and (b) protocol process in trusted computing platform.

The core step of the remote attestation occurs between the trusted computing platform and the remote verifier. It is a typical two-party protocol that is composed of the remote challenge request AttestReq (nonce) and the response AttestRes (quote, SML, cert (AIKpub)). The detailed process is shown in Figure 7.2: Figure 7.2(a) describes the main steps of the trusted computing platform and the verifier; Figure 7.2(b) describes the process of the attestation in the trusted computing platform between the host and the TPM/TCM, where log is the SML, x denotes the index of the extended PCR and comp denotes the measured components.

7.1.3Interface Implementation

Remote attestation is achieved by using the TPM/TCM security chip to sign the platform integrity value (represented by PCR). The security chip interface to complete the remote attestation is TPM_Quote. The TPM security chip provides a variety of different layers of operation interfaces, mainly including the TPM kernel driver interface, TDDL interface, Trusted Core Service (TCS) service layer interface and TSPI application layer interface. The interfaces for each layer can realize the function of quote. TPM_Quote is the command interface that can be directly identified and executed by the TPM security chip. The other interfaces, such as TDDL, TCS and TSPI, only provide the package of this command function. For example, Tspi_ TPM_Quote is the packaging application interface of TPM_Quote by the TSPI layer. Except the differences in the uses and the interface names, the principles of the interface Quote are exactly the same. The interface of the upper layer is easy to use and that of the lower layer requires complex settings.

TPM_Quote is essentially the process of signing TPM internal PCR by using the identity key AIK and then outputting the signature of quote. The outputting signature contains two parts: the original message QuoteInfo and the signature SignatureOnQuoteInfo. The command TPM_Quote can be described as SignedInfo = QuoteInfo || SignatureOnQuoteInfo = TPM_Quote(selectedPCR, serverNonce). Its interface diagram (Figure 7.3) is described as follows.

The first part of the TPM_Quote signed message QuoteInfo is a 48-byte data object which has the data structure TPM_QUOTE_INFO. The second part SignatureOnQuoteInfo is a 256-byte digital signature on QutoeInfo which follows the format RSASSA-PKCS1-v1.5, namely the signature result of the selected PCR by using the private key of AIK.

The specific meaning of each item in the data structure TPM_QUOTE_INFO of QuoteInfo is as follows:

Figure 7.3: TPM_Quote interface.

Theitemversion denotes the version number of the TCG (Trusted Computing Group) specification. If it follows the TPM specification v1.1, the two bytes of version are defined as 0×01 and 0×01. For the TPM specification v1.2, they are 0×01 and 0 × 02.

Theitemfixed is a default value, filled as the ASCII strings of “QUOT.”

TheitemdigestValue contains the SHA1 digest values of all the selected PCR values with the data structure TPM_PCR_COMPOSITE.

TheitemexternalData denotes the challenge nonce sent by the verifier, which is a 160-bit nonce (in the form of the output strings of the SHA1 algorithm).

When the remote verifier receives the attestation message SignedInfo = QuoteInfo || SignatureOnQuoteInfo, it first divides SignedInfo into two parts and does the verification as follows:

(1)It verifies whether QuoteInfo is the valid data structure of TPM_QUOTE_INFO. It needs to check whether the item version meets the requirement of the TCG and the item fixed is a default ASCII string of “QUOT.”

(2)It verifies whether the item externalDatainQuoteInfo is the same with the nonce used as the challenge nonce by the verifier.

(3)It uses the public key certificate of AIK to verify whether SignatureOnQuoteInfo is a signature of QuoteInfo.

For the command TPM_ Quote, we have implemented the corresponding interface in remote attestation system prototype. The followings are the codes of the TPM_Quote interface by using the Java. It performs the following TPM_ Quote interface to output the TPM remote attestation signature.

7.2Comparison of Remote Attestation Researches

Based on the TPM/TCM security chip, the remote attestation mechanism achieves the attestation of the platform identity and integrity state. It is an important technological method to assure the trust of the platform computing environment and to enhance the security of network communications. The security problems in the remote attestation that need to be solved are in many aspects. Its main security goals are to ensure the unforgeability (authenticity) of attestation of the platform identity and integrity, and to assure that the platform identity and the platform integrity configuration cannot be leaked (anonymity/privacy). Moreover, it needs to prevent TOCTOU (time of check/time of use) attacks, replay attacks, man-in-the-middle attacks, etc. To solve these problems, many researchers in different institutions have conducted in-depth researches, put forward some innovations to solve the security issues and achieved a lot of research results.

7.2.1Attestation of Platform Identity

The main method to attest platform identity is to certify that the trusted computing platform is a communication entity whose identity can be trusted by remote verifier through a series of platform-related certificates. The identity of the trusted computing platform is identified by the TPM EK credential. The role of the credential is to provide the evidence that a legitimate TPM has been embedded into the trusted computing platform, and to show the binding relationship between the security chip and the platform. The direct use of EK credential for remote attestation can obviously disclose the platform identity. Thus in the TCG specification, it uses the method based on the trusted third-party Privacy CA to help TPM complete the attestation of platform identity and avoid the platform identity leakage. The attestation method based on Privacy CA is to identify the identity by issuing the AIK certificate for the TPM identity key. In the attestation, the verifier needs to confirm the correctness of the AIK identity with Privacy CA. This method requires an online CA. Compared with the commonly used offline CA, it needs a high level of trust assurance and requires a higher security level of CA.

In 2004, Brickell et al. proposed the TPM-based Direct Anonymous Attestation (DAA) scheme [21]. It adopts the zero-knowledge proof, group signature and other cryptographic techniques to anonymously attest platform identity. Through the DAA signature, the remote verifier can confirm that the party in communication is a genuine trusted computing platform embedded with a legitimate TPM. It can also avoid the disclosure of the platform authentic identity. DAA currently has been accepted as part of the TCG TPM v1.2 specification, and the TPM chips have supported the DAA protocol. However, since the original DAA scheme uses too many zero-knowledge proofs, it has high complexity in the implementation and its practical applications are infeasible. Therefore, many researchers have put forward the continuous improvement and innovation of the DAA scheme and proposed many improved schemes [22, 24, 26, 29, 133, 134].

He et al. proposed an improved DAA scheme [22] for embedded devices. Since the DAA scheme based on the RSA cryptosystem has the disadvantages that the signature length is long and the efficiency is low, Brickel et al. proposed the first DAA scheme [24] based on ECC and bilinear map. It adopts the LRSW assumptions and the CL-LRSWsignature. Both its computation efficiency and communication performance have been greatly improved. Subsequently, Feng et al. also proposed an improved DAA scheme [26] based on the q-SDH assumption and the BBS+ signature, which further improves the computation and communication efficiency. In recent years, Chen et al. have performed an in-depth research on DAA. By using new cryptographic assumptions and the optimization method, they fully studied the possibility of protocol improvement and promoted the protocol computational optimization to a higher level [29, 134].

Table 7.1 lists the comparison of several representative schemes. The latest DAA schemes have experienced a very large increase in the computational efficiency. In the development of DAA researches, the main idea of the improvements is to use the latest elliptic curve cryptosystem to improve the DAA signing efficiency based on bilinear map. It reduces the computation cost of DAA Join and Sign, especially the cost of the TPM chip. At the same time, it reduces the DAA signature length so as to adapt to the bandwidth of the mobile and wireless network environments.

Table 7.1: Comparison of direct anonymous attestation schemes.

7.2.2Attestation of Platform Integrity

Based on the security chip TPM/TCM, the basic way to attest the platform integrity is the TCG binary remote attestation. In it, the TPM uses the AIK to sign the PCR values which represents the platform integrity, and then sends to the remote verifier the TPM signature and the integrity measurement log in order to attest the current running state of the platform. IBM Integrity Measurement Architecture (IMA) and tcglinux system [135] are based on this idea to implement the binary remote attestation system. The binary attestation mechanism has many disadvantages. On the one hand, it discloses the local software and hardware configuration information of the trusted computing platform, which somewhat makes the platform more vulnerable to various attacks. On the other hand, the problem is the diversity of the platform state information. Considering that the types and versions of the system softwares and hardwares are varied, and the system needs to be updated, it is very difficult to check the validity of the system integrity configuration in practice.

In order to overcome the shortcomings of the binary remote attestation mechanism, in 2004, Sadeghi and Stüble of Ruhr University Bochum in Germany adopt the idea of integrity and property mappings to propose the property-based attestation (PBA) [32]. Then IBM proposed the implementation of PBA [31]. In 2006, Chen et al. proposed the first PBA protocol [33]. It gave out the theoretical method to achieve the concrete PBA protocol, and thus began a more in-depth study on PBA. Through the definition of the trusted computing platform security properties, PBA can give out the mappings between the platform configurations and properties. In the remote attestation, it directly attests the properties and their mappings so as to avoid the disclosure of the specific platform configurations. Among the remote attestation methods, PBA overcomes several faults of the original remote attestation, such as high complexity, leakage of privacy and abuse of the attestation results. It is the most promising and practical method to do the remote attestation.

Researchers have focused on the extension of the PBA protocols and proposed the PBA without the trusted third-party issued property certificates (referred to as PBA-RS protocol [34]). It uses the ring signature to attest that the target platform configurations and states meet the verifier’s requirements. It does not need the support of the trusted third party and protects the privacy of platform. The general way of PBA is to attest the commitments on platform configuration based on the property certificates by using the zero-knowledge proof method. However, they are all based on an offline trusted third party. The verification of the property revocation is complex and the attestation efficiency is not high enough. Chinese researchers have carried out in-depth study [67, 69]. By fining the granularity, they proposed the component property-based remote attestation [69]. This method is adapted to the small-scale computing environment. It is easy to issue, verify and revoke the property certificates. According to the features of the TCM security chip, the property-based remote attestation protocol based on bilinear mapping [67] was proposed to further reduce the computation cost of the PBA protocol and the signature length of the property attestation.

In the implementation of PBA, researchers in Ruhr University Bochum use the property certificate issued by the online trusted third party to convert the binary measurement value in boot to properties [35], and achieve the system attestation and sealing based on the properties. The study is based on the online trusted third party, which is convenient for the integrity management and security property management. It uses the Certificate Revocation List (CRL) to validate the revocation of the properties. However, it lacks the practical protocol to protect the privacy of the platform configurations.

In addition to the researches on binary attestation and property-based attestation, there are some other works on the semantics and the specific application scenarios of the remote attestation. In the extension study of remote attestation semantics, Haldar et al. proposed the semantic remote attestation [36]. Its basic idea is to use a language-based trusted virtual machine and achieve the attestation by checking the security policy of the running code in the virtual machine. However, the trusted virtual machine still needs the support of binary attestation. Researchers in Carnegie Mellon University proposed a fine-grained attestation [12] which can dynamically attest the program code semantics by using the secure kernel provided by the CPU. This method has the obvious advantage for the attestation of the sensitive kernel. Moreover, it solves the problem of TOCTOU. Zhang et al. proposed the behavioral attestation [136], which is based on the access control policy and system semantics of usage control (UCON) policy. It is suitable to the checking and verification of the subject behaviors in the policy model. In specific application scenarios of the remote attestation, the works are quite rich. We do not list them here. The representative works include the software-based attestation for embedded devices [37], attestation for Web Service [137], etc.

7.3Attestation of Platform Identity

7.3.1 Attestation of Platform Identity Based on Privacy CA

Attestation of platform identity is to attest the authentic identity of trusted computing platform by using the identity credential. In general, the identity of trusted computing platform is identified by the security chip, namely the attestation of platform identity is essentially the authentication of the identity of the TPM/TCM security chip. Among the many attestation methods of platform identity, the widely accepted and the most practical method is the attestation based on Privacy CA. Since it is compatible with the existing PKI authentication architecture and has advantages of convenient deployment and simple operation, many solutions based on security chips utilize this method to attest platform identity.

In TCG Privacy CA-based attestation architecture, the platform is identified by the TPM EK. Once this key is disclosed, the platform identity will be completely exposed. Thus TCG does not adopt the attestation based on EK. Instead, it uses the identity key AIK as the alias of EK to authenticate the identity. Even in this way, Privacy CA-based attestation method with the assistance of the trusted third party just reduces the risk of leaking the privacy of platform identity. However, this method does not guarantee the privacy of the platform identity. Attestation of platform identity based on Privacy CA can be divided into two main processes: issuing the platform identity certificate and attestation of the platform identity.

7.3.1.1Issuing Platform Identity Certificate

When the TPM owner purchases a trusted computing platform, the TPM does not have an identity. The TPM owner must apply for the platform identity from a trusted third-party Privacy CA to obtain the platform identity certificate. Its main steps are as follows (Figure 7.4):

Figure 7.4: Issuing process of platform identity certificate.

(1)The TPM owner uses the TPM security chip to create an RSA key with the key type of identity key (i. e. AIK). Then he executes the command TPM_MakeIdentity to wrap the public key of AIK, the EK certificate, the platform certificate and the conformance certificate.

(2)The trusted computing platform sends these wrapped data to the Privacy CA as an application for the AIK certificate.

(3)Privacy CA verifies the application for AIK certificate by authenticating the certificates such as the EK certificate and the platform certificate.

(4)Privacy CA uses its own signing key to sign the AIK certificate and uses the public key of EK to encrypt the AIK certificate.

(5)Privacy CA sends to the TPM the response of the AIK certificate. The TPM owner executes the command TPM_ActivateIdentity to decrypt and obtain the AIK certificate.

After the trusted computing platform obtains the AIK certificate, the TPM can use the AIK and the AIK certificate to attest the platform identity. Then it has the capability to attest the platform integrity, namely the capability to do remote attestation.

7.3.1.2Attestation of Platform Identity

The main steps for the attestation of the platform identity are as follows (Figure 7.5):

(1)The owner of platform A sends a request of attestation to the platform B.

(2)The platform B sends to the platform A the challenge nonce and specifies the selected PCR to be attested.

(3)The owner of platform A loads the AIK and then uses the private key of AIK to sign the selected PCR value.

(4)Platform A sends to the verifier of platform B the remote attestation signature and the integrity log.

Figure 7.5: Attestation of platform identity.

(5)Platform B sends a request to Privacy CA to query whether or not the identity of the TPM in platform A is trusted.

(6)Platform B verifies the remote attestation signature of platform A, as well as the platform configuration integrity log.

The last two steps of the platform identity attestation achieve both the authentication of the platform identity and the evaluation of the trustworthiness of the platform environment configurations. This ensures the trustworthiness of the platform identity and the platform states for both sides, and helps to enhance the ability to resist a variety of malicious software. Since a trusted computing platform can theoretically generate an infinite number of AIKs and certificates, when the trusted computing platform is in communication, only the trusted third-party Privacy CA knows the authentic identity of the user. The verifier does not know it. Thus, to some extent, it reduces the exposure of the privacy of platform identity. However, it does not achieve completely anonymity.

7.3.2Direct Anonymous Attestation

Although attestation based on the Privacy CA provides a certain degree of the privacy protection of platform identity, the privacy CA knows the TPM’s authentic identity. So if the verifier and the privacy CA collude, the privacy of the TPM identity has no guarantee. In addition, since the verifier needs to query the Privacy CA every time in the verification of the platform identity, the performance of Privacy CA will become a major bottleneck in the attestation of platform identity.

To compensate the defects in the attestation based on the Privacy CA, TCG proposed the DAA for authenticating identity of TPM, and supports DAA in the TPM specification v1.2. DAA uses the cryptographic technologies such as group signature and zero-knowledge proof to attest the identity anonymously so as to ensure that the remote attestation is indeed from an authentic TPM, but the remote verifier does not know which one of TPMs. DAA scheme originates from the study of anonymous credential systems. The issuer in DAA does not provide any identification. Instead, it issues the anonymous credential. The TPM can use the zero-knowledge proof method to prove its identity to the remote verifier by using the pseudonym.

7.3.2.1DAA Model

DAA mainly includes three participants: issuer, prover and verifier. The prover can be divided into host and TPM/TCM security chip according to the different computing entities in the DAA protocol. They both collaborate to complete the process of the TPM/TCM anonymous credential application and the anonymous attestation.

Issuer: It is responsible to set up the DAA system parameters, issue the DAA credential for the TPM/TCM security chips and verify whether the identity of the TPM/TCM security chip has already been revoked. In general, the TPM/TCM manufacturers can be regarded as the issuer. Different security chip manufacturers can choose different DAA parameters. Or an independent authority can act as the DAA issuer. The management of all the TPM/TCM anonymous credentials is centralized.

Prover: It is the platform embedded with the TPM/TCM security chip, such as security PC, laptop and other trusted computing platforms that support the DAA specification. The main functionality of the prover is the application of DAA anonymous credentials and the attestation of the anonymous identity.

Verifier: It mainly verifies the DAA signature to authenticate the TPM/TCM anonymous identity so as to make sure that the DAA signature is indeed from an authentic TPM/TCM. During the verification of the anonymous identity, the verifier also needs to query the issuer that whether the TPM/TCM identity has been revoked.

In a DAA scheme, the anonymous identity key and its credential can be created for many times, but one remote attestation can only use one anonymous identity. The private key f of anonymous identity identifies the TPM/TCM anonymous identity. It can only be stored in TPM/TCM internal memory and cannot be exported. The DAA anonymous credential can be stored in the host platform outside the chip, or in other storage devices. The TPM/TCM anonymous attestation commands (including DAA_Join and DAA_Sign) can only be invoked by the TPM/TCM owner, and only the TPM/TCM owner can clear the existing insecure private key of anonymous identity.

The main procedures in the DAA protocol include four sub-protocols: Setup, Join, Sign and Verify. Among them, the most important sub-protocols are DAA Join and DAA Sign.

(1)Setup: Set up the public parameters of the DAA system and generate the key pair (skI , pkI) for the issuer to sign the anonymous credentials, where skI is the issuer’s private key and pkI is the issuer’s public key.

(2)DAA Join: The TPM/TCM sends to the issuer the application and then obtains the anonymous credential.

(3)DAA Sign: With the anonymous private key f and its anonymous credential, the TPM/TCM uses the zero-knowledge proof method to generate the DAA signature.

(4)Verify: The verifier verifieswhether the DAA signature is valid, and further checks whether the TPM/TCM identity is revoked.

The DAA protocol is mainly to solve the problem of how to anonymously attest the TPM/TCM identity to the remote verifier, namely to ensure the privacy of TPM/TCM identity. It requests that the remote verifier cannot know the specific identity of the TPM/TCM security chip and cannot link multiple DAA sessions to distinguish whether or not they are from the same TPM/TCM identity. Thus the DAA protocol must satisfy the following security properties:

(1)Unforgeability: Only the TPM/TCM that has applied for the anonymous credentials can do the anonymous attestation. Any other attacker without the knowledge of the anonymous identity cannot forge the DAA signatures.

(2)Anonymity: In the case that the TPM/TCM cryptographic algorithms are not compromised, the attacker cannot obtain the authentic identity of the TPM/TCM through the protocol data.

(3)Unlinkability: The verifier cannot distinguish the correlation between two DAA sessions. That is to say, for two different DAA sessions, the verifier cannot determine whether or not they are from the same TPM/TCM.

(4)Rogue TPM Detection: When the corresponding private key of the anonymous credential of the TPM/TCM is disclosed, the verifier and the issuer can detect the disclosure in the running process of the protocol in time.

Although there are various DAA protocols, all of them follow the above basic DAA model. The difference is mainly due to the different group signature schemes and the different zero-knowledge proof methods used in the DAA protocol design. Figure 7.6 shows the main process of the original DAA protocol, which is based on the CL signature [20] and DDH assumptions to ensure its security. The subsequent DAA protocol researches are all based on its design.

7.3.2.2Researches on DAA

In recent years, many works have been done on the DAA protocol from the original RSA-DAA scheme in 2004 to the following ECC-DAA scheme based on the elliptic curve and bilinear map. Its proof is simplified, and its computation cost and the signature length are reduced. DAA research has experienced a great breakthrough. In this section, we take our schemes as examples to discuss the related issues of the DAA research.

Figure 7.6: The DAA Join phase (above) and DAA Sign phase (below) of BCC04 scheme.

Design of DAA Protocol Based on Pairing. Since the BCC04 scheme based on RSA was proposed in 2004, many researchers have improved the DAA protocols. Under the same security level, elliptic curve cryptosystem is more efficient than the RSA cryptosystem, and it has the shorter private key and signature length. Thus the elliptic curve and pairing are more suitable for the design of the next-generation trusted computing DAA protocols. In 2008, we improved the DAA protocol by using ECC and put forward the next-generation trusted computing DAA protocol [26, 64]. It greatly improves the efficiency of the DAA protocol and promotes the improvement of the DAA protocol. The protocol skeleton of the scheme is as follows:

DAAJoin

(1)TPM/TCM chooses the private key fR ℤ/pℤ and the nonce tʹ ∈R ℤ/pℤ, computes the Pedersen commitment C= g f h t and sends it to the issuer. Then the TPM/TCM proves it has the private dataf , tʹ.

(a)Randomly chooses r f , r t R ( / p ) 2 ,computes C= g r f h r t and sends to the issuer.

(b)Issuer randomly chooses cR ℤ/pℤ and sends it to the TPM/TCM.

(c)TPM/TCM computes s f = r f +cf, s t = r t +c t and sends s f , s t to the issuer.

(d)Issuer checks C = ? C c g s f h s t .

(2)Issuer chooses xR ℤ/pℤ, tʹʹ ∈R ℤ/pℤ, computesA= ( g 1 C h t ) 1/ ( y+x ) and sends A, x, t ʹʹ to the host.

(3)Host storesA, x and sends tʹʹ to the TPM/TCM.

(4)TPM/TCM computes t = tʹ + tʹʹ, stores f , t and checks the following equation:

e( A,Y g 2 x )=e( g 1 , g 2 )e( g f , g 2 )e( h t , g 2 ).

DAA-Sign

(1)Host randomly chooses wR ℤ/pℤ, computes T1 = (Ahw), T2 = gwhx, where T1, T2 are the commitments onA, x, and then proves the following two equations:

e ( T 1 ,Y )/ e( g 1 , g 2 )=e ( h,Y ) w e ( h, g 2 ) wx+l e ( g, g 2 ) f / e ( T 1 , g 2 ) x , T 2 = g w h x T 2 x g wx h xx =1.

(2) Host (including TPM/TCM) proves it has the witnesses f,x,w,t which satisfy the above equations, and computes the auxiliary valuesδ1 = wx, δ2 = –xx.

(a)TPM/TCM randomly chooses rf ∈ ℤ/pℤ, rt ∈ ℤ/pℤ, computes R̃1 and sends R̃1 to the host:

R ˜ 1 =e ( g, g 2 ) r f e ( h, g 2 ) r t .

(b)Host chooses r x , r w , r δ 1 , r δ 2 ∈ ℤ/pℤ and computes

R 1 = R ˜ 1 e ( h,Y ) r w e ( T 1 , g 2 ) r x e ( h, g 2 ) r δ 1 R 2 = g r w h r x R 3 = T 2 r x g r δ 1 h r δ 2 .

(c)Host computes ch = H (g||h||g1||g2||gT||Y||T1||T2||R1||R2||R3) and sends chto the TPM/TCM.

(d)TPM/TCM chooses ntR ℤ/pℤ and computes c = H (H (ch||nt) ||m).

(e)Host computes s x = r x +c( x ), s δ 1 = r δ 1 +c δ 1 , s w = r w +cw. s δ 2 = r δ 2 +c δ 2 .TPM/TCM computes sf = rf + cf , st = rt + c (–t).

(3)Host outputs the signature σ=( T 1 , T 2 ,c, n t , s f , s x , s t , s w , s δ 1 , s δ 2 ).

DAA-Verify

(1)Given the signature σ=( T 1 , T 2 ,c, n t , s f , s x , s t , s w , s δ 1 , s δ 2 )of the message mand the public key(p, g1, g2, gT, Y, g, h), the verifier computes

R 1 =e ( g, g 2 ) s f e ( h,Y ) s w e ( h, g 2 ) s δ 1 + s t e ( T 1 , g 2 ) s x ( e( T 1 ,Y )/ e( g 1 , g 2 ) ) c R 2 = T 2 c g sw h s x , R 3 = T 2 s x g s δ 1 h s δ 2 .

(2)Verifier checks the following equation:

c = ? H ( H( H( gh g 1 g 2 g T Y T 1 T 2 R 1 R 2 R 3 ) n t ) ).

The above scheme is based on the q-SDH assumption and DDH assumption. It is the first DAA scheme based on bilinear mapping and q-SDH assumption. Reference [26] uses the ideal/real system model to prove the security of the protocol. The method mainly simulates the protocol running by designing the simulator S of the ideal system, which makes the environment to not distinguish between the ideal and real systems, thus proving the protocol is secure under the DDH assumption and q-SDH assumption. This scheme essentially uses the BBS+ signature to issue the anonymous credential (A, x, t) for the TPM/TCM and uses the characteristics of the pairing and the zero-knowledge signature to anonymously prove the platform identity and its credential. Since it uses the ECC and pairing, the signature length is shortened by 90 % compared with the original DAA scheme, and the computation cost is reduced significantly, which greatly improves the efficiency of the DAA protocol. In order to further reduce the computation cost of DAA Join, we propose a new DAA protocol [64] based on the improved BB signature by using the similar design method. The computational efficiency of the Join process is nearly doubled.

Although the above scheme is not perfect, the efficiency of its knowledge signature is not high. However, it highlights the way to design DAA protocols based on the q-SDH assumption. A lot of following researches are based on this scheme and constantly improve the BBS+ signature. The current research in this field has gradually become mature.

Forward-Secure DAA Protocol. The basic security properties of the DAA protocol are the user-controlled anonymity and user-controlled traceability. It considers less about the leakage of the TPM internal secret f. Once f leaks, it not only breaks the security of the DAA scheme but also affects the security of the DAA signatures signed before the leakage. To solve this problem, reference [65] puts forward a new protocol to support forward-secure DAA signature, and researched the extension of security of DAA scheme.

The forward-secure DAA scheme extends the original model with the key f updating algorithm. It periodically updates f to ensure that even if the current f leaks, the attacker cannot break the anonymity and unlinkability of the DAA signature signed before. The protocol is based on the strong RSA assumption and DDH assumption. The issuer uses a way that is similar to the CL signature to issue the anonymous credential (A, e, t) for the initial cycle f0. The TPM DAA private key is updated by using one-way function on each cycle. The key fi updated after the first i cycle follows the verification equation of anonymous credential:

A e = a f i s Ti b t modn.

The DAA signing and verification are similar to those of the original DAA scheme. The difference is that in DAA Sign, it needs to use the root discrete logarithm signature of knowledge method to compute the signature of knowledge by using the private key fi of the latest cycle. Under the strong RSA assumption, the proposed scheme can be proved to be secure. The protocol not only satisfies the basic security properties of the DAA model but also provides the forward security for DAA scheme and enhances securitywhen the DAA private key is disclosed. At present, the research on the extension and enhancement of the DAA security is still preliminary. There are many problems to be solved.

Application of DAA Protocol. Although the TPM/TCM provides the support for DAA protocol, its direct applications in the real network system still confront many security issues, such as the DAA cross-domain problem, DAA network connection and so on.

DAA scheme is mainly designed for the small-scale network environment where the boundary is determined. In general, it is a single network domain. For the multi-domain application scenarios, in addition to the problem that they cannot be mutually authenticated, it also faces man-in-the-middle attack in the cross-domain. Reference [66] proposed a cross-domain DAA scheme to solve the TPM anonymous authentication problem in trusted multi-domain. The basic idea in cross-domain DAA is as follows. A trusted computing platform A (host/TPM A) in domain A needs to attest its identity to the verifier B in domain B. First of all, platform A needs to apply for a passport certificate from the local passport issuer, which certifies the identity of the trusted platform A in the trust domain A. Then the trusted computing platform A uses the passport certificate to apply for the visa certificate from the visa issuer in domain B. Finally, the trusted computing platform A uses the passport certificate and the visa certificate to anonymously attest its identity to the verifier B in trust domain B. The system architecture is shown in Figure 7.7. The major improvement of the cross-domain DAA protocol is to extend the original DAA protocol with two sub-protocols IDAA-IssuePassport and IDAA-IssueVisa for obtaining the passport certificate and the visa certificate, respectively. It achieves the anonymous attestation in multi-domain environments.

Following the protocol, we implement the prototype system of the cross-domain DAA and conduct the experiment to test and analyze the cross-domain DAA scheme. Compared with the original DAA scheme, its computational overhead increases a little, but the computational overhead of the TPM almost has no increase. The increased computation is mainly done by the host. The test results (as in Table 7.2) show that the performance of the cross-domain DAA scheme meets the requirements of the practical application even extended with the cross-domain anonymous attestation.

In addition to the application in security PC, DAA protocols can also be widely applied in wireless terminals, mobile phones and other embedded devices. The DAA protocol needs to be improved to adapt to these applications. The existing DAA design has become gradually mature, but there are still many technical problems to be solved for the practical application of the DAA protocol. Thus the implementation and security analysis of the DAA schemes is an important research direction in DAA’s development.

Figure 7.7: Crossdomain DAA system architecture.

Table 7.2: Evaluation results of the crossdomain DAA system.

7.3.2.3Security Analysis and Test of DAA Protocols

Security Analysis of DAA Protocols. In the design of the DAA protocols, it is proved that the TPM/TCM DAA scheme is secure. It is not feasible to computationally break the DAA in the case that the cryptographic building block used in the scheme is secure. DAA protocol is not adequate to only ensure the security in cryptography. It also needs to conduct the security analysis from multiple aspects such as the logic analysis of protocol process, the attacker model checking and the API analysis, and in this way to ensure the security of the implementation of DAA protocol.

Security analysis achievements of the simple protocols in trusted computing (such as the authorization protocols [AP]) are very rich. The researchers in the University of Milan used the tool SPIN to detect the TPM OIAP and found the replay attacks [49]. The researchers in the University of Birmingham analyzed the TPM AP and found the off-line dictionary attack [138]. The researchers in HP laboratories used the protocol analysis tool ProVerif to detect that there exists the impersonation attack in the case of shared secret information [50]. Chinese researchers have analyzed the TCM AP and found the security deficiencies of replay attack and the off-line dictionary attacks [53]. However, there are few works for the security analysis of complex protocols (such as DAA protocol) in trusted computing. The researchers in Saarland University adopted π calculus to model the DAA protocol [51] and used the tool ProVerif to give the DAA mechanized verification results. They found a tiny security flaw: in the process of issuing, the authentication of the security chip cannot be guaranteed. The adversary can make the issuer unable to accurately figure out how many platforms have DAA credentials.

Because the DAA protocol analysis does not model the attackers’ ability adequately, Chinese researchers have conducted the researches on the DAA attacker model [139]. Aiming at the attacker model of the general DAA protocol process, they extended the standard Dolev–Yao attacker, which has the capabilities of intercepting, tampering, forging and replaying messages. It added the ability of collusion where the attacker can collude with the issuer and dishonest trusted computing platforms. In order to simplify the analysis process, it does not distinguish the TPM and the host and ignores the communications between them. The simplified DAA protocol process is shown in Figure 7.8.

Figure 7.8: DAA communication process.

According to the above simplified message flows, we can respectively establish the states of finite state machines for the DAA protocol participants: issuer, platform, verifier. Then according to the attacker model, we can determine the attacking rules, and such that the DAA protocol analysis model can be established. We use the model checking tool Murphi to check the above DAA analysis model (the checking results are in Table 7.3). We find the link attack by using issuer base name, Rudolph attack and the masquerading attack by replaying DAA requests. These attacks are relatively simple but not easy to be found, especially when an attacker colludes with a participant. Due to the extension of the attacker’s ability, it makes the security analysis of DAA protocol more in depth. It is of great significance for the improvement of the DAA protocol design and system implementation.

Simulation Test of DAA Protocols and Result Analysis. The theoretical research

of DAA protocol has experienced a breakthrough, but for these schemes, there is a certain distance away from the practice application, especially for the schemes based on ECC and bilinear mapping (the so-called ECC-DAA). There are many problems to be solved in the specific parameters, interfaces and implementation ways. To solve these problems, we have carried on the tests of ECC-DAA schemes [140] and attempted to give good suggestions for the tests and implementation of the DAA system.

Table 7.3: The verification result using Murphi tool.

We adopt the TPM simulation method to analyze and evaluate several critical factors that can affect security and efficiency of the DAA protocol, including the elliptic curve selection, parameter selection, preprocessing, optimization of point multiplication and pairing, signature length and so on. Through the simulation test of the DAA protocol, we find that the most influential factors are the elliptic curve and the parameter selection. We take as an example the analysis of the supersingular curves and the MNT curves. We choose the supersingular curve parameters such that it is with the length |q| = 512 of the finite field Fq, the cyclic groups G1, G2 order |r| = 160, embedding degree k =2, symmetric pairing and MNT curve parameters such that |q| = |r| = 159 (denoted by MNT159), embedding degree k = 6, asymmetric pairing. The algorithm strength with the above two curves selection is approximately equal to 80 bits security level. In addition, we have chosen the curves MNT201 and MNT224 with a higher security strength. The experiment results are depicted in Figure 7.9:

For the curve selection, supersingular curve is the most efficient curve, which is at least 3 times faster or more than MNT curve in every stage of DAA sub-protocol. However, the security strength of the supersingular curve only has 80 bits, which cannot satisfy the higher application requirement. The DAA signature length is 6,386 bits if supersingular curve is chosen, which is almost 0.5 times longer than that of the MNT159 curve of 4,216 bits. Thus for the application with a low security strength requirement, DAA with supersingular curve is certainly the best selection. For the applications with a high-level security, MNT curves support multiple security strength and are more flexible. Preprocessing can significantly decrease the running time for DAA scheme. In the stage of DAA sign, for supersingular curves and MNT curves, the computation cost can be, respectively, reduced by 36.85 % and 37.6 % with preprocessing. In the stage of DAA verify, it is reduced by 57.78 % and 65.96 %. Thus preprocessing is an important way to reduce the computation cost of the DAA protocol.