Property-Based Attestation without a Trusted Third Party

Transcription

1 Property-Based ttestation without a Trusted Third Party Liqun Chen 1, Hans Löhr 2, Mark Manulis 3, and hmad-reza Sadeghi 2 1 HP Laboratories, Bristol, UK; liqun.chen@hp.com 2 Horst Görtz Institute for IT Security, Ruhr-University of Bochum, Germany {hans.loehr ahmad.sadeghi}@trust.rub.de 3 UCL Crypto Group, Université Catholique de Louvain, Belgium mark.manulis@uclouvain.be bstract. The Trusted Computing Group (TCG) has proposed the binary attestation mechanism that enables a computing platform with a dedicated security chip, the Trusted Platform Module (TPM), to report its state to remote parties. The concept of property-based attestation (PB) improves the binary attestation and compensates for some of its main deficiencies. In particular, PB enhances user privacy by allowing the trusted platform to prove to a remote entity that it has certain properties without revealing its own configuration. The existing PB solutions, however, require a Trusted Third Party (TTP) to provide a reliable link of configurations to properties, e.g., by means of certificates. We present a new privacy-preserving PB approach that avoids such a TTP. We define a formal model, propose an efficient protocol based on the ideas of ring signatures, and prove its security. The cryptographic technique deployed in our protocol is of independent interest, as it shows how ring signatures can be used to efficiently prove the knowledge of an element in a list without disclosing it. Keywords. Property-based attestation, user privacy, ring signatures, proof of membership, configuration anonymity. 1 Introduction and Background fundamental issue in interaction between computing platforms is trust or trustworthiness whether a remote platform behaves in a reliable and predictable manner, or will be (or already has been) subject to subversion. Cryptographic mechanisms support the establishment of secure channels and authorized access, but without assurance about the integrity of the communication endpoints. Commodity computing platforms suffer from inherent vulnerabilities due to high complexity, and lack of efficient protection against tampering or malware. Hence, an important subject of current research is to develop mechanisms for gaining assurance about the trustworthiness of remote peers regarding their integrity, platform configuration, and security policies. The concept of Trusted Computing aims at resolving such issues. The TCG approach and binary attestation. n industrial approach towards the realization of the Trusted Computing functionality within the computing platforms is the initiative of the Trusted Computing Group (TCG). The

2 TCG has published many specifications amongst which the most important one is that of the Trusted Platform Module (TPM) [25]. Currently, TPMs are implemented as small, tamper-evident hardware modules embedded in commodity platforms, providing (i) a set of cryptographic functionalities, (ii) the protection of cryptographic keys, (iii) the authentication of platform configuration (attestation), and (iv) cryptographic sealing of sensitive data to particular system configurations. However, the TCG defines only a limited set of commands, and the firmware cannot be programmed by end-users to execute arbitrary functions. Millions of platforms (PCs, notebooks, and servers) being sold today are equipped with TPMs. One of the main features supported by the TPM is the so-called trusted integrity measurement: a hash value of the platform state is computed during the boot process and stored in specific registers of the TPM, the Platform Configuration Registers (PCRs),those state is also called the platform s configuration. Of potential interest is the offered functionality called binary attestation, which allows a remote party (verifier) to get an authentic report about the binary configuration of another platform (prover), given by the prover s TPM signature on the configuration. Deficiencies of TCG binary attestation. TCG binary attestation suffers from several shortcomings: The slightest change in the measured software or configuration files whether security-relevant or not will lead to a changed binary configuration. In general, it is not clear, how a verifier should derive the trustworthiness of a platform from such a binary value. System updates and backups are highly non-trivial; the multitude of different versions of many pieces of software cause serious manageability problems. From the privacy point of view, binary attestation bears several risks: (1) The TPM s public key needed to verify an attestation could be used to identify a TPM and trace a platform. To solve this problem, Brickell et al. [3] introduced the Direct nonymous ttestation (D) protocol. Improvements of D and alternative D schemes (e.g., [5,4,6]) are orthogonal to our work and could be used as a building block for our protocol. (2) Typically the information about the configuration of a computing platform or application is revealed to a remote party requesting the state of a platform. This information can be misused to discriminate against certain configurations (for example, operating systems) and even vendors, or may be exploited to mount attacks. Property-based attestation. One general concept to overcome shortcomings of the TCG s binary attestation is to transform the binary attestation into the property-based attestation (PB), as described by Sadeghi and Stüble [21], and by Poritz et al. [19]. The basic idea of PB requires a computing platform to attest that it fulfills the desired (security) requirements, so-called properties, without revealing a respective software or/and hardware configuration. The formal definition of properties as well as the development of various practical solutions for PB are still active areas of ongoing research. One concrete solution for PB was proposed by Chen et al. in 2006 [11]. Their protocol requires an off-line Trusted Third Party (TTP) to publish a list 2

3 of trusted configurations and respective certificates which attest that the configurations provide specific properties. prover can use the signed configurations and certificates to prove to a verifier that it has appropriate configurations associated with the certified properties, without disclosing the specific configurations, which the platform holds. nother solution for PB is proposed by Kühn et al. [14]. In their work, the authors suggest a modified system boot architecture, such that not binary hash values of files are stored by the TPM, but instead abstract values representing properties, e.g., a public key associated with a property certificate. However, this approach also requires a TTP to issue certificates for properties and the bootloader must be binary-attested. The drawback of these solutions is that such a TTP might not be available or/and desirable in many real applications, for example if two entities/users want to have a private communication with each other. They have their own understanding of the relation between various configurations and security properties. They do not need (and do not want) to ask any kind of TTPs to certify a correlation between the configurations and properties. However, they still want to keep their platform configuration information secret from each other. Our contribution. In this paper, we propose a protocol for PB that does not require the involvement of a TTP to certify properties, where a platform (equipped with a TPM) convinces a remote party that its configuration satisfies a given property. For this, the two parties first agree on a set of trusted configuration specifications, which they both consider to be trustworthy, i.e., associated with a well-defined security property or properties. The platform then proves that its configuration specification is in this set. In our protocol, TPM and the host software compute the proof jointly. For some applications, it might be unrealistic to assume that the parties in the attestation protocol can decide themselves which configurations are trustworthy and which are not, and thus they still have to rely on third parties in practice. Our protocol has the advantage that even in this case no global trusted party is necessary: both participants can choose independently how to agree on trustworthy configurations or they can delegate this decision to other parties. Further, we define a formal security model for PB, which we also use in our proofs, and where the main security requirements are evidence authentication and configuration privacy. While the former guarantees an unforgeable binding between the platform and its configuration specification, the latter provides the non-disclosure of the configuration specification. In our PB protocol, these requirements are achieved through the use of a ring signature (cf. Section 4.3), i.e. configuration privacy results from the anonymity of the signer whereas evidence authentication is based on the unforgeability of the signature. Moreover, the cryptographic technique employed in our protocol may be of independent interest: We show how ring signatures can be used for efficiently proving the knowledge of an element in a list without disclosing it. Outline. In Section 2, we introduce the system model of property-based attestation. In Section 3, we sketch different solutions on a high level. In Section 4, 3

4 we set up notation and explain some building blocks which will be used in our concrete PB scheme. In Section 5, we present and discuss a new PB scheme, and in Section 6 we define a formal security model and state theorems about the security of the scheme. In Section 7, we conclude the paper by mentioning some unsolved problems and future work. 2 System Model for PB The following system model for PB will serve as the basis for the security model in Section 6. Involved parties. PB protocol involves two participants: a prover P and a verifier V. The prover is a platform consisting of a host H and a trusted module TPM M (see Figure 1). To cover multiple executions of the protocol we consider multiple instances and use indices to distinguish among their participants, i.e., P i, V i. Each instance includes a single protocol execution with some unique session identity (SID) and two participants P i and V j are treated as communication partners (in the same instance) if they share the same SID. ssumptions. It is assumed that the communication between a host H i and its TPM M i is through a secure channel (private and authentic), and that M i and V i communicate via H i. We omit the indices i and j of the participants in an instance when no risk of confusion exists. Moreover, the TPM is trusted by all parties and possesses a secret (signing) key sk M which is unknown to the host. The corresponding public (verification) key is available to both P and V; see also trust relations in Section 6.1. Properties and configurations. Each prover P has a configuration value denoted cs P, which is an authenticated record about its platform s configuration. The value cs P is known to both the host H and TPM M, and it is computed by M from correctly measured configuration information, stored securely in specialpurpose registers the platform configuration registers (PCRs). s a result, H cannot modify this value without being detected. This is guaranteed by the properties of secure measurement and reporting based on the trusted computing technology [25]. It is assumed that before running the PB protocol, P and V have already agreed on a set of configuration values denoted CS = {cs 1,..., cs n } that satisfy the same property. So, we say that a configuration value cs satisfies a given property associated with CS, if and only if cs CS. Definition of PB. property-based attestation (PB) scheme consists of the following three polynomial-time algorithms: Setup: Given the security parameter 1 κ, this probabilistic algorithm selects a set of public parameters that are necessary to run the PB protocol, and produces a private/public key pair for each TPM. 4

5 Prover Host CS = {cs 1,...,cs n } cs P є CS Property-based attestation protocol Verifier CS = {cs 1,...,cs n } TPM PCRs: cs P Fig. 1. PB system model. PB-Sign: On input a configuration value cs P, a list of admissible configurations CS, and a nonce N v, this (distributed) randomized algorithm outputs a signature σ on cs P. PB-Verify: On input a candidate signature σ and CS, this deterministic algorithm outputs 1 (accept) if σ is a valid signature on a value from CS, or 0 (reject) otherwise. 3 Solutions In this section, we sketch two high-level solutions for PB without relying on trusted parties to certify the link between configurations and properties. Basically, P has to prove that its configuration value cs P belongs to the agreed set CS = {cs 1,..., cs n }. More precisely, V would accept a proof if and only if: (i) The proof is created by a valid TPM. If TPM anonymity is required, the D scheme [3] can be used to provide this feature. (ii) The proof is a fresh response to a specific challenge from V. (iii) The proof ensures that cs P = cs j for an index j {1, 2,..., n}, but does not reveal the value of j. Such a proof implements PB-Sign, whereas PB-Verify is the verification of the proof. In Setup, the keys for the TPM and system parameters are generated. Solution 1: TPM as single signer. The proof can be achieved by a new TPM command defined as follows: 1. TPM takes as input a list of configurations CS and a nonce N. The nonce is assumed to be chosen by the verifier V. 2. TPM checks for each cs j CS if cs P = cs j, until either a match is found, or the entire list has been checked. 3. If cs P is in the list, the TPM generates a signature on (1, N, CS); otherwise, the TPM generates a signature on (0, N, CS), which is then forwarded to V. The obvious drawbacks of this approach are: TPM operations depend on the size n of CS (O(n) in a straightforward implementation, and O(log n) if CS is a sorted list). s the TPM s memory is very limited, this would either impose a severe restriction on the size of CS, or the transfer of the list would have to be split up, causing further complexity of the TPM-command and slowing down the communication between host and TPM, due to the overhead. 5

6 Solution 2: TPM shares signer role with host. In this solution, the TPM signs a hidden version a commitment of the configuration cs P, and the host completes the proof that the hidden configuration is in the set CS. similar approach is used in the D protocol [3]. Our PB protocol proposed in Section 5 is an elegant and efficient example of this solution. It makes use of ring signatures in that the host computes n public keys for a ring signature scheme from the configurations in CS and the commitment to cs P (which was signed by the TPM), and determines the secret key that corresponds to cs P. The signer anonymity of the ring signature scheme ensures that the verifier does not learn which key has been used for signing, thus cs P is not disclosed. Our construction guarantees that the prover succeeds only if the hidden configuration cs P is indeed in CS. Current TPMs support all operations (random number generation, modular exponentiation, and signature generation) needed by our protocol. However, the TCG currently does not specify a command to create and sign a commitment to a configuration which is stored inside the TPM. To implement such a command, only firmware changes would be required. Other protocols for similar solutions could be developed, for instance based on existing zero-knowledge proofs (e.g., [8,13,7]) or zero-knowledge sets [15]. 4 Preliminaries 4.1 TPM Signatures The existing TCG technology defines two ways for a TPM to create own digital signature σ M. The first way is to use D [3]. With a D signature, a verifier is convinced that a TPM has signed a given message, but the verifier cannot learn the identity of the TPM. The message to be signed can be either an ttestation Identity Key (IK), or an arbitrary data string, The second way is to use an ordinary signature scheme. TPM generates a signature using an IK as signing key, which could either be certified by a Privacy-C, or it could be introduced by the TPM itself using a D signature. For simplicity, we do not distinguish these two cases, and denote by σ M := SignM(sk M ; m) the output of TPM s signing algorithm on input the TPM s signing key sk M and a message m, and by VerM(vk M ; σ M, m) the corresponding verification algorithm, which on input the TPM s verification key vk M outputs 1 if σ M is valid and 0 otherwise. 4.2 Commitment Scheme We apply the commitment scheme by Pedersen [18]: Let sk m com be the secret commitment key. commitment on a message m is computed as C m := g m h skm com mod P. P is a large prime, h is a generator of a cyclic subgroup G Q Z P of prime order Q and Q P 1. g is chosen randomly from h ; furthermore, log h (g) is unknown to the committing party. Both the message m and sk m com are taken from Z Q. The Pedersen commitment scheme as described above is perfectly hiding and computationally binding, assuming the hardness of the discrete logarithm problem in a subgroup of Z P of prime order (for P prime). 6

7 4.3 Ring Signatures The notion of a ring signature was first introduced by Rivest et al. [20]. It allows a signer to create a signature with respect to a set of public keys. Successful verification convinces a verifier that a private key corresponding to one of the public keys was used, without disclosing which one. In contrast to group signatures, no group manager is needed. For various security definitions for ring signatures see [2]. Recent efficient ring signature schemes which are provably secure in the standard model (i.e., without using random oracles) are proposed in [23,9], where in [9] a signature with size only O( n) is proposed. Dodis et al. [12] showed that ring signatures with constant size in the number of public keys can be achieved in the random oracle model. Unfortunately, none of these schemes can be used easily for our purposes: In our protocol, we employ a construction, where the public keys for the ring signature are computed from commitments formed by the TPM. We show how this can be done efficiently for Pedersen commitments (cf. Section 4.2) and public keys of the form y = g x mod P, where x is the corresponding secret key. However, the schemes above use keys of different types. In Figure 2, we recall an efficient ring signature scheme from [1], which we propose to use for our PB solution. The scheme is a generalization of the Schnorr signature scheme [22]: Intuitively, the product in step 2(b) corresponds to combined commitments for individual Schnorr signatures, in step 2(c) and 2(d), the challenges for the individual Schnorr signatures are derived from a single challenge, and in step 2(e), the secret key is used to compute s. The verification equation, where the sum of the challenges is compared to a hash value, ensures that a valid signature cannot be created without a secret key x j. The scheme is provably secure in the random oracle model, under the discrete logarithm assumption. We denote the generation of a ring signature σ r on message m with respect to the public key ring {y i } 1 i n and with private signing key x by σ r := SigRing(x; {y i }; m). Signature verification is denoted by VerRing({y i }; σ r, m). For simplicity, we omit the public parameters g, P, Q and the range of the index i in our notation. 5 Ring Signature-Based PB without TTP In this section, we propose a protocol for PB, which is based on ring signatures. The TPM generates a signature on a commitment to the configuration cs P. Then the host H creates a proof, using a ring signature, that cs P is in the agreed set CS of configurations with the given property. The verifier V verifies the TPM signature and the ring signature. Note that in our protocol, the TPM is trusted by all parties, but its resources are restricted, and it can execute only a very limited set of instructions. The host H is not trusted by the verifier V, hence the protocol has to protect evidence 7

8 1. Key generation. Let κ be a security parameter. On input 1 κ, create g, P and Q. signer S i (i = 1,..., n) chooses x i R {0, 1} l Q and compute y i = g x i mod P. Output its public key (g, P, Q, y i) and the corresponding secret key x i. 2. Signing algorithm SigRing(x j; {y i}; m). signer who owns secret key x j generates a ring signature on a message m with public key list (g, P, Q, y i) (i = 1,..., n), where j {1,..., n} as follows: (a) Choose α, c i R {0, 1} l Q for i = 1,..., n, i j. (b) Compute z = g α Q n i=1,i j yc i i mod P. (c) Compute c = Hash(g P Q y 1... y n m z). (d) Compute c j = c (c c j 1 + c j c n) mod Q. (e) Compute s = α c j x j mod Q. (f) Output the signature σ r = (s, c 1,..., c n). 3. Verification algorithm VerRing({y i}; σ r, m). To verify that the tuple σ r = (s, c 1,..., c n) is a ring signature on message m, check that P n i=1 ci Hash(g P Q y1... yn m gs y c ycn n mod P ). Fig. 2. Ring Signature Scheme [1] authentication against a malicious host. H cannot be prevented from disclosing its own configuration cs P, thus for configuration privacy, we have to assume that H is honest. 5.1 Security Parameters We suggest the following security parameters (values in parentheses indicate realistic values 4 for current TPMs): l cs (160): the size of the value of cs P. l (160): the security parameter for the anti-replay value (nonce). l P (1024): the size of the modulus P. l Q (160): the size of the order Q of the subgroup of Z P. The parameters l P and l Q should be chosen such that the discrete logarithm problem in the subgroup of Z P of order Q with P and Q being primes such that 2 l Q > Q > 2 lq 1 and 2 l P > P > 2 l P 1, is computationally hard. 5.2 Setup We assume that V can verify TPM signatures (including revocation verification) and that H and V have agreed on a set of configurations CS. Prior to the execution of the PB protocol, the parties have to agree on the following parameters, which can be used for several protocol runs (potentially 4 examples based on the use of SH-1 [16] as a hash function (like in current TPMs), and recommendations of the US National Institute of Standards and Technology (NIST) for similar applications (see, for instance, [17]); changes corresponding to stronger hash-functions, such as SH-256, can be made straightforwardly. 8

9 with different sets CS): primes P and Q, generators g and h of a subgroup of Z P of order Q (i.e., the discrete logarithm problem is hard in g = h ). The discrete logarithm log g (h) mod P must be unknown to H. 5.3 Signing and Verifying Protocol The attestation procedure executed between a TPM (M), its host (H), and a verifier (V) is described in Figure 3. s a result of the protocol, the host creates a ring signature σ r, which is based on a TPM signature σ M on the message C, which is a commitment to cs P. The TPM has to create and sign C, which it then opens towards H. To create the ring signature, the host uses the value r as the secret key (if cs P CS, this works, because y j = h r mod P for some j). From the ring signature, the verifier is convinced that the platform has been configured with one of the set of acceptable configuration specifications, CS = {cs 1,, cs n }, without knowing which one. TPM cs P, sk M H cs P, CS = {cs 1,..., cs n} V vk M,CS = {cs 1,..., cs n} N v N v N v R {0, 1} l r R Z Q C := g cs P h r mod P σ M := SignM(sk M; (C, N v)) C, r, σ M y j := C/g cs j mod P (for j = 1,... n) σ r := SigRing(r; {y j}; N v) C, σ M, σ r VerM(vk M; σ M, (C, N v)) y j := C/g cs j mod P (for j = 1,... n) VerRing({y j}; σ r, N v) OK OK OK Fig. 3. The protocol of the PB scheme. Common input: g, h, P, Q 5.4 Protocol Properties Our protocol has some interesting properties: First, no trusted third party is needed for this protocol. The only exception is the certification of TPM keys: The verifier may rely on a D issuer or a 9

10 Privacy-C to ensure that the TPM key belongs to a valid TPM, depending on the TPM signature scheme (see Section 4.1). However, this is completely independent from the PB protocol, and neither a D issuer nor a Privacy- C could breach the configuration privacy of our protocol. Second, the configuration set CS is created flexibly, dependent on the agreement between prover P and verifier V. One approach to negotiate the set of acceptable configurations could be analogous to the SSL/TLS handshake: The prover sends a proposal for CS to V, who can then select an appropriate subset. However, our protocol allows for different ways to agree on CS; the particular method can be chosen according to a concrete application scenario. Third, the size n of the set CS affects the configuration privacy. If n is small, V might have a high probability in guessing the configuration cs P. Therefore, to keep cs P private, P should execute the protocol only if CS is of acceptable size. Moreover, P has to ensure that V cannot learn cs P by running the PB protocol multiple times with different configuration sets, because in the case of several successful attestations, V would know that cs P is in the (possibly small) intersection of the sets used in the protocol executions. This example shows that P should install a privacy policy which prevents such abuses of the PB protocol. Fourth, note that the overhead of the TPM compared to binary attestation is small. dditionally, the TPM has to form the commitment C, which must be signed instead of cs P. So the overhead is just choosing a random number r and performing a modular multi-exponentiation modulo P (with two exponents). s with binary attestation, the TPM has to generate one digital signature (e.g., 2048 bit RS). The TPM s computation does not depend on the size of CS. 6 Security of our PB Scheme Here, we define a formal (game-based) security model based on the system model from Section 2, and state theorems about the security of our PB scheme. 6.1 Security Model dversary model. The adversary is a PPT algorithm and an active adversary that has full control over the communication channel between H and V. This is modeled by the query of the form send(e, m) which allows to address a message m to an entity E {H, V}. In response, receives a message which would be generated by E according to the protocol execution. In the definition of entity authentication, in which malicious hosts should also be considered, is also given access to another query sendtpm(m) by which it can communicate with M. We assume that m contains the identity of the sender (as chosen by ). Moreover, when considering evidence authentication, the adversary may corrupt the host via the query corrupt H, which returns the configuration cs P to (cs P is H s only secret). 10

11 We assume that cannot corrupt the TPM. In reality, a hardware attack would be necessary to corrupt a TPM, i.e., we limit the adversary to softwareonly attacks, which is the assumption of the TCG [25]. In case a real-world adversary succeeds in attacking the TPM, our protocol has to rely on the revocation mechanisms for TPM signatures. Evidence authentication. We formalize the intuitive security requirement that should not be able to pretend that P has a configuration cs P satisfying the property that has to be attested (i.e., cs P CS), when in fact the property is not fulfilled (i.e., cs P CS). Let Game ev-auth (1 κ ) be the following interaction between P, V, and. Before the interaction, chooses a platform with a valid TPM M and with a configuration cs P CS. Then is given access to send(e, m), sendtpm(m), and corrupt H queries to any P chosen by. Uncorrupted parties behave as specified by the protocol. wins, if it outputs a PB signature σ, such that PB-Verify accepts σ. We denote the success probability of by Succ cf-priv (1 κ ) := (1 κ ) = win], and its maximum over all PPT adversaries (running in time κ) as Succ cf-priv (1 κ ). PB protocol provides evidence authentication if Succ cf-priv (1 κ ) is negligible in κ. Pr[Game ev-auth Configuration privacy. The security requirement that the configuration cs P of P should be kept private is captured by the following game. For this requirement, host H and TPM M of P have to be honest because P could always send cs P to. Let Game cf-priv (1 κ ) be the following interaction between P, V and. is given access to send(e, m) queries. Moreover, may access sendtpm(m) and corrupt H queries for all but one prover P chosen adaptively by, which has to remain honest. t the end of the interaction, outputs an index i. wins if i is the index of P s configuration in the set CS = {cs 1,..., cs n }, i.e., if cs P = cs i. We denote the advantage of (over a random guess) with dv cf-priv (1 κ, n) := Pr[Game cf-priv (1 κ ) = win] 1/n, and its maximum over all PPT adversaries (running in time κ) as dv cf-priv (1 κ, n). PB protocol provides configuration privacy if dv cf-priv (1 κ, n) is negligible in κ. Security of PB. PB scheme is secure, if and only if it provides both evidence authentication and configuration privacy. Trust relations. The TPM is assumed to be trusted by both host and verifier. For evidence authentication, a PB protocol must ensure that a malicious host cannot cheat an honest verifier, whereas for configuration privacy, it must prevent a verifier controlled by from determining the configuration of an honest host. 11

12 6.2 Security nalysis The following theorems demonstrate the security of our PB scheme. For the proofs, see ppendix. Theorem 1 (Evidence uthentication). The PB protocol presented in Section 5 provides evidence authentication (in the random oracle model), assuming the security of the ring signature scheme, the security of TPM signatures, and the hardness of the discrete logarithm assumption. In more detail: Succ cf-priv (1 κ ) q 2 /2 l + ε TPM + ε ring + ε dlog, where q is the number of protocol runs, l is polynomial in the security parameter κ, ε TPM is the probability of an adversary to forge a TPM signature, ε ring is the probability to forge a ring signature, and ε dlog is the probability to solve the underlying discrete logarithm problem. Remark. Our proof does not directly use the random oracle model, however, it is required by the ring signature scheme we use. Theorem 2 (Configuration Privacy). The PB protocol presented in Section 5 provides configuration privacy against computationally unbounded adversaries, due to the unconditional signer anonymity of the ring signature scheme and perfect hiding of the commitment scheme. Remark. lthough our definition of configuration privacy assumes a PPT adversary (which would be reasonable for practical purposes), our protocol offers even unconditional security, because we use a perfectly hiding commitment scheme and an unconditionally signer-anonymous ring signature scheme. 7 Conclusion and Future Work The concept of property-based attestation (PB) has been proposed to overcome several deficiencies of the (binary) attestation scheme proposed by the Trusted Computing Group (TCG). mongst others, the TCG attestation reveals the system configuration to third parties that could misuse it for privacy violations and product discrimination. In this paper, we proposed the first cryptographic protocol for PB which, in contrast to the previous solutions, does not require a Trusted Third Party to certify properties. In our protocol, the TPM has to compute only one commitment and one signature. Furthermore, the cryptographic technique used here might be of independent interest: We demonstrate how a ring signature can be employed to prove membership in a list. Future work may include the investigation of how to determine meaningful properties. Moreover, a generic approach based on any ring signature scheme, an efficient scheme with a security proof in the standard model, and the design of a PB protocol with sub-linear communication and computation complexity in the size of the configuration set CS are still open problems. 12

13 References 1. M. be, M. Ohkubo, and K. Suzuki. 1-out-of-n signatures from a variety of keys. In SICRYPT 02, LNCS vol. 2501, pp Springer, Bender, J. Katz, R. Morselli. Ring Signatures: Stronger Definitions, and Constructions without Random Oracles. In TCC 06, LNCS vol. 3876, pp , Springer, E. Brickell, J. Camenisch, and L. Chen. Direct anonymous attestation. In B. Pfitzmann, and P. Liu, editor, Proceedings of CM CCS 04, pp , CM Press, Oct E. Brickell, L. Chen, and J. Li. new direct anonymous attestation scheme from bilinear maps. In Proceedings of the 1st International Conference on Trust (TRUST 2008), LNCS, Springer Verlag, March E. Brickell and J. Li. Enhanced Privacy ID: direct anonymous attestation scheme with enhanced revocation capabilities. In Proceedings of the 6th Workshop on Privacy in the Electronic Society (WPES 07), pp , CM Press, J. Camenisch. Better privacy for trusted computing platforms. In Proceedings of 9th European Symposium On Research in Computer Security (ESORICS 2004), LNCS vol. 3193, pp , Springer Verlag, J. Camenisch and M. Michels. Proving in Zero-Knowledge that a Number Is the Product of Two Safe Primes. In EUROCRYPT 99, LNCS vol. 1592, pp , Springer, J. Camenisch and M. Stadler. Proof Systems for General Statements about Discrete Logarithms. Technical Report TR 260, Dep. of Computer Science, ETH Zürich, March N. Chandran, J. Groth, and. Sahai. Ring Signatures of Sub-linear Size Without Random Oracles. In Proceedings of ICLP 07, LNCS vol. 4596, pp , Springer, D. Chaum and H. van ntwerpen. Undeniable signatures. In CRYPTO 89, LNCS vol. 435, pp , Springer, L. Chen, R. Landfermann, H. Löhr, M. Rohe,. Sadeghi and C. Stüble. Protocol for Property-Based ttestation. In Proceedings of CM STC 06, pp. 7 16, CM Press, Y. Dodis,. Kiayias,. Nicolosi, and V. Shoup. nonymous identification in ad hoc groups. In EUROCRYPT 04, LNCS vol. 3027, pp , Springer, E. Fujisaki and T. Okamoto. Statistical Zero Knowledge Protocols to Prove Modular Polynomial Relations. In CRYPTO 97, LNCS vol. 1294, pp , Springer, U. Kühn, M. Selhorst, and C. Stüble. Realizing Property-Based ttestation and Sealing on Commonly vailable Hard- and Software. In CM STC 07, pp , CM Press, S. Micali, M. O. Rabin, and J Kilian. Zero-Knowledge Sets. In Proceedings of the 44th Symposium on Foundations of Computer Science (FOCS 03), pp , IEEE Computer Society, National Institute of Standards and Technology (NIST). Secure Hash Standard (SHS). FIPS PUB 180-2, ugust National Institute of Standards and Technology (NIST). Digital Signature Standard (DSS). FIPS PUB (Draft), March T. P. Pedersen. Non-interactive and information-theoretic secure verifiable secret sharing. In J. Feigenbaum, editor, CRYPTO 91, LNCS vol. 576, pp Springer,

14 19. J. Poritz, M. Schunter, E. van Herreweghen, and M. Waidner. Property ttestation Scalable and Privacy-friendly Security ssessment of Peer Computers. IBM Research Report RZ 3548 (# 99559), Oct R. Rivest,. Shamir, and Y. Tauman. How to Leak a Secret. In C. Boyd, editor, SICRYPT 01, LNCS vol. 2248, pp , Springer, Sadeghi and C. Stüble. Property-based attestation for computing platforms: Caring about properties, not mechanisms. In Proceedings of NSPW 04, pp , CM Press, Sep C. P. Schnorr. Efficient Signature Generation by Smart Cards. J. Cryptology, 4(3): , Springer, H. Shacham and B. Waters. Efficient Ring Signatures without Random Oracles. In Proceedings of PKC 07, LNCS vol. 4450, pp , Springer, V. Shoup. Sequences of games: a tool for taming complexity in security proofs. Cryptology eprint rchive, Report 2004/ Trusted Computing Group. TCG TPM Specification, Version 1.2. vailable at Security Proofs Proof (Evidence uthentication). We structure the proof as a sequence of games [24], where a PPT adversary (see Section 2 for the adversary model) interacts with a simulator S. The first game is Game ev-auth. In each subsequent game, a new event is introduced. S aborts, whenever this event occurs. We show that each event can only happen with negligible probability for any PPT adversary, hence the probability for to win game G i+1, denoted by Pr[win i+1 ], differs only by a negligible amount from its probability Pr[win i ] to win game G i. G 0 G 1 G 2 The initial game is Game ev-auth, where S plays the game with by simulating the honest parties as specified by the protocol. chooses a platform with a configuration cs P CS of his choice (as specified in Section 6.1), and S simulates the honest TPM M of this platform. wins Game ev-auth, and hence G 0, if it manages to output σ = (C, σ M, σ r ) such that S (acting as an honest verifier) accepts σ as a proof that cs P CS, although actually cs P CS. Because G 0 is Game ev-auth, we have Pr[win 0 ] = Succ cf-priv (1 κ ). In the event that S, acting as a verifier, chooses a nonce N v that already occurred in a previous protocol run, S aborts the simulation. For this comparison, S records all nonces. s N v is chosen randomly by S, the probability ε 1 of this is q 2 /2 l (which is negligible in the security parameter), where q denotes the number of protocol runs. Hence, Succ cf-priv (1 κ ) Pr[win 1 ]+ε 1. S simulates protocol execution as before, with the difference that all TPM signatures are obtained from the corresponding signing oracle. In the event that S receives an output (C, σ M, σ r ) from, where σ M was not created previously by S, the simulation is aborted. In this case, provided S with a forgery of a TPM signature. The probability ε TPM of this event is the probability of a forgery of a TPM signature. Thus, Succ cf-priv (1 κ ) Pr[win 2 ]+ ε 1 + ε TPM. 14

15 G 1 covers replay attacks by estimating the probability that the same nonce occurs twice, and G 2 covers forgeries of TPM signatures. It remains to estimate the probability Pr[win 2 ]. We consider two cases: either wins in G 2 by forging the ring signature (with probability ε ring ), or without it. Since we are interested in the overall probability of winning in G 2, we do not require from S to detect which of these distinct cases occurs. If no forgery of the ring signature occurred, but wins G 2, must know a secret key r matching one of the public keys used to compute the ring signature. Hence, must know r, such that h r = C/g csj = g cs P cs j h r mod P for some j {1,..., n}. Because cs P cs j, we have r r, thus could compute the discrete logarithm log g (h) = (cs P cs j )/(r r) mod Q. The probability of the adversary to win the last game is Pr[win 2 ] = ε ring + (1 ε ring ) ε dlog ε ring + ε dlog, where ε dlog is the probability to solve the underlying discrete logarithm problem. Thus, in total, Succ cf-priv (1 κ ) ε 1 +ε TPM +ε ring +ε dlog, which is negligible in κ if the TPM signature and ring signature schemes are secure and the underlying discrete logarithm problem is hard. Note that although our proof is in the standard model, the ring signature scheme in [1] requires the random oracle model. Proof (Configuration Privacy). We demonstrate that dv cf-priv (1 κ, n), the maximum advantage over all in Game cf-priv, is negligible in κ, even if the adversary is computationally unbounded. For this, we construct a simulator S that plays Game cf-priv with some, simulating the honest parties. The goal of is to break the configuration privacy of the PB scheme, and the simulator s goal is to break either the perfect hiding property of the commitment scheme or the unconditional signer ambiguity property of the ring signature scheme. We play the game twice. In the first case, we assume that the ring signature is secure and show how S can break the commitment scheme. In the second case, we assume that the commitment scheme is secure, and hence, we show how S can break the ring signature scheme. Case 1. In this case, S is given a commitment C = g csp h r mod P with cs P CS, and plays Game cf-priv with. Once S receives a send query with a nonce N v from, it uses C in the PB protocol execution as the TPM s commitment (without knowing cs P and r), and creates a TPM signature σ M = SignM(sk M ; (C, N v )). The computationally unbounded simulator S can compute α, such that h = g α mod P, and k, such that C = g k = g cs P +αr mod P. lthough S knows neither cs P nor r, it can establish n equations k = cs j + α r j (for j = 1,..., n). Thus, S can compute n pairs (cs j, r j ), and create the ring signature σ r = SigRing(r j ; {y j }; N v ), where y j = g αrj = h rj mod P, with any of these r j as a signing key. Because of the signer ambiguity of the ring signature scheme, S can choose an arbitrary r j (for j R {1,..., n}). S sends C, σ M, and σ r to. t the end of the game, outputs an index i. S attacks the perfect hiding property of the commitment scheme by using the pairs (cs j, r j ) computed above, and opening the commitment to (cs i, r i ). 15

16 Because we assume that the ring signature is secure, the probability of S to break the commitment scheme successfully is the probability of to determine i with cs i = cs P. Thus, a non-negligible advantage dv cf-priv implies that S can break the perfect hiding property. Case 2. In this case, S is given public/private key pairs (y j, x j ) (j = 1,..., n) for the ring signature scheme, and access to a signature oracle for ring signatures under this key ring. S can use the oracle to query ring signatures on arbitrary messages. The unconditional signer ambiguity states that S should not be able to find out which private key was used for signing (although S knows all public and private keys). S chooses k R Z Q, and computes cs j = k x j mod Q for j = 1,..., n. Then, S starts to play Game cf-priv with. Once S receives a send query with a nonce N v from, it computes C := g k mod P and σ M := SignM(sk M ; (C, N v )). S uses the ring signature oracle to create a ring signature σ r on the message N v, and sends C, σ M, and σ r to. t the end of the game, outputs an index i. Since the commitment C was chosen randomly, the only possibility of to win Game cf-priv is to break the signer ambiguity of the ring signature. S also outputs i to indicate that x i was used to generate the signature, thus breaking the unconditional signer ambiguity of the ring signature scheme. 16