Patent Publication Number: US-8122245-B2

Title: Anonymity revocation

Description:
This application is a continuation of, and claims priority from, U.S. patent application Ser. No. 11/137,246, filed on May 25, 2005, now U.S. Pat. No. 7,581,107. U.S. Pat. No. 7,581,107 is a U.S. National Application of International Application No. EPO 04405331.2 (filed on May 28, 2004), of which the benefit of the priority filing date is claimed and which is hereby incorporated by reference in its entirety. 
    
    
     TECHNICAL FIELD 
     The present invention is related to a method and network for enabling a trusted entity to identify a user computer with a security module. Anonymity is revocable in predefined circumstances by the trusted entity within an otherwise anonymous system. 
     BACKGROUND OF THE INVENTION 
     Computers have evolved to tools for many applications and services. In today&#39;s world a trustworthy computing environment becomes more and more a desire. Comprehensive trust, security, and privacy functions are required to establish multi-party trust between devices, upon which content providers, application and service providers, consumers, enterprises and financial institutions, and particularly users can rely. 
     For that, a trusted platform module (TPM) has been established. The role of the module is to offer protected storage, platform authentication, protected cryptographic processes and attestable state capabilities to provide a level of trust for the computing platform. The foundation of this trust is the certification by a recognized authority that the platform can be trusted for an intended purpose. A so-called trusted computing group (TCG) will further develop and promote open industry standard specifications for trusted computing hardware building blocks and software interfaces across multiple platforms, including PC&#39;s, servers, PDA&#39;s, and digital phones. This will enable more secure data storage, online business practices, and online commerce transactions while protecting privacy and individual rights. Users will have more secure local data storage and a lower risk of identity theft from both external software attack and physical theft. 
     To realize the functionality of attestable states, an issuer issues a certificate to the trusted platform module, hereafter also abbreviated as TPM, as to allow the TPM to later prove that it is a genuine TPM and therefore a verifying party can have confidence stated attested by the TPM. To allow the TPM to prove it is genuine without that the verifying party can identify the TPM, a so-called direct anonymous attestation (DAA) protocol has been specified by the trusted computing group. The protocol allows the TPM to convince a verifying party that it obtained attestation by an issuer without revealing its identity. 
     Further, the TCG specified a protocol to provide attestation (with a certificate) to a platform&#39;s TPM such that the platform can later prove to any party that it preserved attestation without that the verifying party can identify the platform or link this proof of attestation with other proofs of attestation that the platform provided. 
     In many cases, complete anonymity is not appropriate, as it can be misused. Thus, a balance between privacy requirements of honest users and requirements of law enforcement should be found. This leads inevitably to a compromise that should be acceptable. 
     The attestation procedure however does not allow retrieving the identity of a TPM. 
     From the above it follows that there is still a need in the art for an improved protocol and system which allow a revocation of anonymity within an anonymous system. 
     GLOSSARY 
     The following are informal definitions to aid in the understanding of the description.
     TPM—trusted platform module or security module   ID TPM —identifying value   Nv, ID′ TPM —module-generated-identifier value   cert—attestation value with values A, e, v″   DAA′—user attestation-signature value   DAA[C]—first part of the user attestation-signature value   E—encryption   E′—encryption proof value   R—encryption random values   R′—encryption proof random values   C′—intermediate user attestation-signature value   C″—first verification value   PK UC —user public key   PK TPM —security module public key   PK AC —attester public key with values n,g,g′,h,S,Z,R 0 ,R 1 ,Γ,γ,ρ   PK J —trusted entity public key   SK J —trusted entity secret key   A—first part of attestation value cert   e—second part of attestation value cert, being a random prime   v″—third part of attestation value cert, being a random integer   m—decryption policy   U—part of public key of security module PK TPM      z—base value   C, sf 0 , sf 1 , sv—proof values   T 1 —part of user attestation-signature value DAA′   T′ 1 —first signature value, or first security module attestation value   T″ 1 —intermediary user attestation-signature value   T′″ 1 —intermediary user attestation-signature verification value   

     SUMMARY AND ADVANTAGES OF THE INVENTION 
     In the following are provided systems, apparatus and methods which allow a designated trusted party or trusted entity to reveal which computer with security module, also referred to as TPM, performed an anonymous proof of attestation. More precisely, the trusted entity can reveal an identifier that the TPM produced when the TPM got attestation. 
     In accordance with the present invention, there is provided a network for enabling identification of a user computer having a security module by a trusted entity. In other words, the network allows revoking of anonymity by the trusted entity within an otherwise anonymous system. The network comprises an attester computer that provides an attestation value cert from a security module public key PK TPM  and an identifying value ID TPM ; the security module of the user computer is adapted to provide the module public key PK TPM  and a security module attestation value DAA, the user computer providing a user public key PK UC , a user attestation-signature value DAA′ derived from the attestation value cert, and an encryption E computable under use of a trusted-entity public key PK J  and a module-generated-identifier value ID′ TPM , the module-generated-identifier value ID′ TPM  relating to the identifying value ID TPM ; a verification computer for verifying the validity of the received user attestation-signature value DAA′ and the encryption E; and a trusted entity having a trusted entity secret key SK J , wherein the trusted entity is able to derive the module-generated-identifier value ID′ TPM  from the encryption E, the module-generated-identifier value ID′ TPM  being usable to identify the user computer with the TPM. 
     In accordance with a further aspect of the present invention, there is provided a method enabling a trusted entity to identify a user computer having a security module within a system that usually is an anonymous system. That means, anonymity can be revoked by the trusted entity. 
     In accordance with another aspect of the present invention, there is provided a method for identifying a user computer with a security module by a trusted entity within a system. The system comprises further an attester computer and a verification computer. 
     In accordance with a yet a further aspect of the present invention, there is provided a method for verifying a user attestation-signature value DAA′ by a verification computer within a system in which an identity of a user computer having a security module is identifiable, i.e., revealable, by a trusted entity. The system comprises further an attester computer. 
     In accordance with yet another aspect of the present invention there is provided a method for enabling identification of a user computer with a security module by a trusted entity within a system which further comprises an attester computer and a verification computer. 
    
    
     
       DESCRIPTION OF THE DRAWINGS 
       Advantageous embodiments of the invention are described in detail below, by way of example only, with reference to the following schematic drawings. 
         FIG. 1  shows a schematic illustration of a scenario with an attester computer, a user computer having a trusted platform module, and a verification computer, and a trusted entity. 
         FIG. 2  shows a schematic flow between the trusted entity and the attester computer in order to identify the user computer with the respective identifying value. 
         FIG. 3  shows a schematic flow for the generation of an encryption E and a user attestation-signature value DAA′ and the verification of the encryption E and the user attestation-signature value DAA′ involving the trusted platform module, the user computer, and the verification computer. 
         FIG. 4  shows a schematic flow of a more detailed verification of the encryption E and the user attestation-signature value DAA′ by the verification computer. 
         FIG. 5  shows a schematic derivation by the trusted entity of the module-generated-identifier value from the encryption E by applying a trusted entity secret key. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     The present invention provides apparatus, systems and methods which allow a designated trusted party or trusted entity to reveal which computer with security module, also referred to as TPM, performed an anonymous proof of attestation. More precisely, the trusted entity can reveal an identifier that the TPM produced when the TPM got attestation. 
     The present invention provides an example of a network for enabling identification of a user computer having a security module by a trusted entity. In other words, the network allows revoking of anonymity by the trusted entity within an otherwise anonymous system. The network comprises an attester computer that provides an attestation value cert from a security module public key PK TPM  and an identifying value ID TPM ; the security module of the user computer is adapted to provide the module public key PK TPM  and a security module attestation value DAA, the user computer providing a user public key PK UC , a user attestation-signature value DAA′ derived from the attestation value cert, and an encryption E computable under use of a trusted-entity public key PK J  and a module-generated-identifier value ID′ TPM , the module-generated-identifier value ID′ TPM  relating to the identifying value ID TPM ; a verification computer for verifying the validity of the received user attestation-signature value DAA′ and the encryption E; and a trusted entity having a trusted entity secret key SK J , wherein the trusted entity is able to derive the module-generated-identifier value ID′ TPM  from the encryption E, the module-generated-identifier value ID′ TPM  being usable to identify the user computer with the TPM. 
     The present invention provides an example of a method enabling a trusted entity to identify a user computer having a security module within a system that usually is an anonymous system. That means, anonymity can be revoked by the trusted entity. The system further comprises an attester computer and a verification computer. The method performable by the user computer with the security module comprises the steps of (i) receiving from the attester computer an attestation value cert, the attestation value cert being derived from a security module public key PK TPM  and an identifying value ID TPM , (ii) deriving under use of the security module a user attestation-signature value DAA′ from the attestation value cert, (iii) computing an encryption E by the user computer under use of a trusted-entity public key PK J  and a module-generated-identifier value ID′ TPM , the module-generated-identifier value ID′ TPM  relating to the identifying value ID TPM , and (iv) providing the user attestation-signature value DAA′ and the encryption E to the verification computer for verification. The trusted entity having a trusted entity secret key SK J  is able to derive the module-generated-identifier value ID′ TPM  from the encryption E. The module-generated-identifier value ID′ TPM  is then usable to identify the user computer with the security module. This has the advantage that one can be sure that the attester computer knows the module-generated-identifier value ID′ TPM  and can thus identify the user computer with TPM from this value. 
     The step of deriving the user attestation-signature value DAA′ can further comprise receiving from the security module the module-generated-identifier value ID′ TPM  and deriving the encryption E and encryption random values R from the module-generated-identifier value ID′ TPM  under the use of the trusted-entity public key PK J . This is more secure as the security module can insure that a correct value of the module-generated-identifier value ID′ TPM  will be encrypted. 
     The step of deriving can further comprise receiving from the security module a second module-generated-identifier value ID′ TPM  and deriving an encryption proof value E′ and encryption proof random values R′ from the second module-generated-identifier value ID″ TPM  under the use of the trusted-entity public key PK J . This will allow the user computer to actually prove that the correct value of the module-generated-identifier value ID′ TPM  is encrypted in the encryption E. Thus, this is more secure for the verification computer which otherwise could not verify what the encryption E encrypts. 
     In addition, the step of deriving can further comprise deriving an intermediary user-attestation signature value C′ from the encryption E and the encryption proof value E′ under use of a hash function, providing the intermediate user attestation-signature value C′ to the security module; receiving from the security module a first part of the user attestation-signature value DAA′, and calculating by the user computer further parts of the user attestation-signature value DAA′ by using the received first part of the user attestation-signature value DAA′, the encryption random values R, the encryption proof random values R′, the attester public key PK AC  and the trusted-entity public key PK J . This allows the user computer to convince the verification computer that the value encrypted in the encryption E is the value that the attester computer, i.e., the issuer, has embedded into the attestation value cert that being a certificate. When providing a service the user computer with the security module can be billed or charged when the trusted entity derived or was requested to derive the module-generated-identifier value ID′ TPM  from the encryption E, because then the derived module-generated-identifier value ID′ TPM  identifies the user computer with the security module. 
     The present invention also provides an example of a method tbr identifying a user computer with a security module by a trusted entity within a system. The system comprises further an attester computer and a verification computer. The method performable by the trusted entity comprises step steps of (a) providing a trusted-entity public key PK J ; (b) receiving an encryption E computed by the user computer under use of the trusted-entity public key PK J , wherein the encryption comprises a module-generated-identifier value ID′ TPM  relating to an identifying value ID TPM . The identifying value ID TPM  was used together with a security module public key PK TPM  by the attester computer to generate an attestation value cert. The user computer under use of the security module derived a user attestation-signature value DAA′ from the attestation value cert. The method performable by the trusted entity further comprises the step (c) of deriving the module-generated-identifier value ID′ TPM  from the encryption E by applying a trusted entity secret key SK J , the derived module-generated-identifier value ID′ TPM  being usable to identify the user computer with the security module. 
     The method can further comprise sending the derived module-generated-identifier value ID′ TPM  to the attester computer and in response to the sent derived module-generated-identifier value ID′ TPM  receiving the related identifying value ID TPM  identifying the user computer with the security module. This will be advantageous in cases where the module-generated-identifier value ID′ TPM  allows not directly identifying the user computer with the TPM. As the attester computer knows which user computer with TPM has which value of the module-generated-identifier value ID′ TPM , the attester computer can help to identify the user computer with the respective TPM in such cases. 
     The present invention further provides an example of a method for verifying a user attestation-signature value DAA′ by a verification computer within a system in which an identity of a user computer having a security module is identifiable, i.e., revealable, by a trusted entity. The system comprises further an attester computer. This method performable by the verification computer comprises the steps of (I) receiving the user attestation-signature value DAA′ and an encryption E for verification, the encryption E having been computed by the user computer under use of a trusted-entity public key PK J  and a module-generated-identifier value ID′ TPM  that relates to an identifying value ID TPM  which together with a security module public key PK TPM  was used by the attester computer to generate an attestation value cert, wherein the user computer under use of the security module derived the user attestation-signature value DAA′ from the attestation value cert, wherein the trusted entity having a trusted entity secret key SK J  is able to derive the module-generated-identifier value ID′ TPM  from the encryption E, the derived module-generated-identifier value ID′ TPM  being usable to identify the user computer with the security module; and (II) verifying the validity of the received user attestation-signature value DAA′ and the encryption E. 
     The verification can comprise computing a first verification value C″ by using the user attestation-signature value DAA′, the attester public key PK AC , the trusted-entity public key PK J , the encryption E, and a hash-function, and checking whether or not the first verification value C″ is comprised in the user attestation-signature value DAA′. This has the advantage that the verification computer can convince itself, i.e. verify, that the encryption E is an encryption under the attester public key PK AC . 
     The present invention also provides an example of a method for enabling identification of a user computer with a security module by a trusted entity within a system which further comprises an attester computer and a verification computer. The method performable by the attester computer comprises the steps of (A) deriving an attestation value cert from a security module public key PK TPM  and an identifying value ID TPM ; (B) providing the attestation value cert to the user computer which under use of the security module is able to derive a user attestation-signature value DAA′ from the attestation value cert and to compute an encryption E under use of a trusted-entity public key PK J  and a module-generated-identifier value ID′ TPM , the module-generated-identifier value ID′ TPM  relating to the identifying value ID TPM , the user attestation-signature value DAA′ and the encryption E being verifiable by the verification computer, wherein the trusted entity having a trusted entity secret key SK J  is able to derive the module-generated-identifier value ID′ TPM  from the encryption E, the module-generated-identifier value ID′ TPM  being usable to identify the user computer with the security module. This has the advantage that the verification computer can convince itself or verify that the encryption E comprises one module-generated-identifier value ID′ TPM  that was embedded into the attestation value cert by the attester computer, i.e., thus the attester computer will know which user computer with TPM corresponds to the module-generated-identifier value ID′ TPM  that is comprised in the encryption E. 
     The user computer with the security module can be billed for the attestation value cert provided by the attester computer. The attestation value cert can relate to a particular service, such as a subscription or web service, and therefore be designed with a charge. 
     Further, the trusted entity can be billed for providing one identifying value ID TPM  upon request. The attester computer hosts or stores the module-generated-identifier value ID′ TPM  as well as the identifying value ID TPM  which relate to each other. Consequently, the attester computer can provide the real identity of the user computer with the security module to the trusted entity. 
     In accordance with the present invention, a direct anonymous attestation protocol involves an issuer, a trusted platform module (TPM), a host platform (host) with the TPM, and several verifiers. All communication of the TPM is performed via its host. The issuer issues an attestation to the host and the TPM together in such a way that
         when proving that attestation has been obtained, the host can only do so when involving the TPM,   proving possession of an attestation can be done anonymously (or pseudonymously), i.e., such that no verifier can not link two different proofs (or proves with different verifiers can not be linked).       

     Thus, the attestation scheme comprises four procedures:
         a “key generation” that allows the issuer to generate the public and secret keys of the attestation scheme;   a “join protocol” that is run between a host/TPM and the issuer and allows the host/TPM to obtain attestation;   a “sign procedure” that is run between a host and the TPM that allows them to anonymously prove that they got attestation and at the same time authenticating a message, the result of this prove is a signature that can be sent to a verifier; and   a “verify procedure” that allows a verifier to check whether or not a platform got attestation and whether this platform authenticated a given message.       

     The following figures and descriptions show how anonymity can be revoked from the otherwise anonymous system by a trusted entity. This should be performable in predefined circumstances, e.g., where a criminal act is involved, where the national security is jeopardized, or where a suspicious communication is detected. The predefined circumstances can be given by rules or a decryption policy. The trusted entity can be a judge or a government institution or any other entity with respective power or trust. 
       FIG. 1  shows a schematic illustration of a network or an anonymous system  10  with an attester computer  30 , also labeled with AC, a user computer  20  having a security module  22  which are labeled with UC and TPM, respectively, and a verification computer  40 , labeled with VC. In addition, a trusted entity  50 , labeled with TE, that is able to revoke anonymity is shown. The user computer  20  that represents the host platform (host) is connected to the attester computer  30 , i.e. the issuer, and the verification computer  40 , i.e. the verifier. The system allows to use a user attestation-signature value DAA′. 
     The TPM, i.e. the security module  22 , provides a security module public key PK TPM  while the user computer  20  further provides a user public key PK UC . The security module  22  further provides a security module attestation value DAA. The attester computer  30  provides an attester public key PK AC  and selects an identifying value ID TPM  that corresponds or maps to a module-generated-identifier value ID′ TPM . The verification computer  40  can verify the validity of the user attestation-signature value DAA′. The trusted entity  50  provides a trusted-entity public key PK J . 
     In operation, as indicated in the figure with arrow  1  and labeled with “ID′ TPM ”, the user computer  20  sends to the attester computer  30  its module-generated-identifier value ID′ TPM  as a request. The attester computer  30  chooses an identifying value ID TPM  that corresponds or maps to the received module-generated-identifier value ID′ TPM . From the security module public key PK TPM  and the identifying value ID TPM  is then an attestation value cert derived by the attester computer  30 . In return to the request the attester computer  30  sends back the attestation value cert, as indicated with arrow  2 , labeled with “cert”. The user computer  20  derives then the user attestation-signature value DAA′ from the attestation value cert under use of the security module  22 . The user computer  20  further computes an encryption E under use of a trusted-entity public key PK J  and the module-generated-identifier value ID′ TPM . It becomes clear from the above that the module-generated-identifier value ID′ TPM  relates to the identifying value ID TPM . The user computer  20  can then send the user attestation-signature value DAA′ together with the encryption E, as indicated with arrow  3  and labeled with “DAA′, E”, to the verification computer  40  that then can initiate the verification procedure. 
     Only the trusted entity  50  having a trusted entity secret key SK J  is able to derive the module-generated-identifier value ID′ TPM  from the encryption E. The module-generated-identifier value ID′ TPM  is usable to identify the user computer  20  with the security module  22 , as indicated with  FIG. 2 . 
       FIG. 2  shows a schematic flow between the trusted entity  50  and the attester computer  30  in order to identify the user computer  20  with the respective identifying value ID TPM . In a predefined case or circumstance, e.g., given by a policy, the trusted entity  50  derives from the encryption E under use of the trusted entity secret key SK J  the module-generated-identifier value ID′ TPM  and sends this derived module-generated-identifier value ID′ TPM  as a reveal request, as indicated with arrow  4 , to the attester computer  30 . The attester computer  30  tries to map the received module-generated-identifier value ID′ TPM  and when the received module-generated-identifier value ID′ TPM  corresponds to one identifying value ID TPM  the corresponding user computer  20  with security module  22  is identified. The reveal response indicating the respective user computer  20  with security module  22  is then returned to the trusted entity  50 , as indicated with arrow  5 , labeled with ID TPM . Further actions can then be taken, such as revealing the user of the user computer  20  and taking appropriate actions against the user. 
       FIG. 3  shows a schematic flow for the generation of an encryption E and a user attestation-signature value DAA′ and further the verification of the encryption E and the user attestation-signature value DAA′ involving the trusted platform or security module  22 , the user computer  20 , and the verification computer  40 . At first, in step  101  the user computer  20  generates from the attester public key PK AC  a base value z and provides it to the security module  22 . In step  102 , the security module  22  transforms the base value z to a module-generated-identifier value ID′ TPM  and provides the module-generated-identifier value ID′ TPM  to the user computer  20 . The user computer  20  computes then in step  103  an encryption E(ID′ TPM ) and encryption random values R from the module-generated-identifier value ID′ TPM  under the use of the trusted-entity public key PK J . 
     As further illustrated the security module  22  generates in step  104  a second module-generated-identifier value ID″ TPM  and provides the value to the user computer  20 . The user computer  20  derives then in step  105  an encryption proof value E′ and encryption proof random values R′ from the module-generated-identifier value ID′ TPM  under the use of the trusted-entity public key PK J . 
     Under use of a hash function, as indicated with step  106 , an intermediary user-attestation signature value C′ is derived from the encryption E(ID′ TPM ) and the encryption proof value E′. When the security module  22  has received the intermediate user attestation-signature value C′, a first part of the user attestation-signature value DAA[C] is generated and provided to the user computer  20 . The user computer  20  calculates then further parts of the user attestation-signature value DAA′ by using the received first part of the user attestation-signature value DAA[C], the encryption random values R, the encryption proof random values R′, the attester public key PK AC , and the trusted-entity public key PK J . 
     With the computed encryption E and the calculated user attestation-signature value DAA′, the user computer  20  can send a verification request, as also indicated with arrow  3  in  FIG. 1 , to the verification computer  40 . 
     When the user computer  20  provides the user attestation-signature value DAA′ and the encryption E to the verification computer  40 , the validity of the received user attestation-signature value DAA′ and the encryption E can be verified under use of the attester public key PK AC  and the trusted-entity public key PK J . The verification is described in more detail with reference to  FIG. 4 . As indicated with the output arrow from the verification step  109 , it turns out either “OK” or “not OK”, i.e., either the verification is valid or not. 
       FIG. 4  shows a schematic flow of a more detailed verification of the encryption E and the user attestation-signature value DAA′ by the verification computer  40 . The verification computer  40  computes under use of a hash function a first verification value C″ by using the user attestation-signature value DAA′, the encryption E, the attester public key PK AC , and the trusted-entity public key PK J , as indicated with step  109   a , and checks, as indicated with step  109   b , whether or not the first verification value C″ is comprised in the user attestation-signature value DAA′. It turns out either “OK” or “not OK”, i.e., either the verification is valid or not. 
       FIG. 5  indicates the derivation of the module-generated-identifier value ID′ TPM  by the trusted entity  50 . For that the trusted entity  50  derives by applying the trusted entity secret key SK J  the module-generated-identifier value ID′ TPM  in step  110  from the encryption E. The derived module-generated-identifier value ID′ TPM  is then usable to identify the user computer  20  with the security module  22 , as described above. 
     The above description is now supported by a more detailed implementation. More precisely, the attester public key PK AC  of the attester computer  30  comprises the values (n,g,g′,h,S,Z,R 0 ,R 1 ,Γ,γ,ρ). The trusted-entity public key PK J  and secret key SK J  pair could be one of the Cramer-Shoup encryption scheme, i.e., the public key consists of the values (η:=γ w  mod Γ, λ 1 :=γ x1 η x2  mod Γ, λ 2 :=γ x3 η x4  mod Γ, λ 3 :=γ x5  mod Γ) and the secret key of the values x1, x2, x3, x4, and x5. The Cramer-Shoup encryption scheme is described by R. Cramer and V. Shoup in “A Practical Public Key Cryptosystem Provably Secure Against Adaptive Chosen Ciphertext Attack”, Advances in Cryptology—CRYPTO &#39;98, vol. 1642, 1998, Springer Verlag, Berlin. 
     To obtain an attestation value cert from the attester computer  30 , the user computer  20 , hereafter also referred to as platform  20 , first sends a base value z to the security module  22 , hereafter referred to as TPM  22 , receives values U and Nv from it, and sends them to the attester computer  30 . Here Nv represents the module-generated-identifier value ID′ TPM . 
     The attester computer  30 , hereafter also referred to as attester  30 , stores Nv with the TPM/platform&#39;s identity. Then the attester computer  30  chooses a random prime e of suitable size and a random integer v″, and computes A=(Z/(U·S v″ )) l/e  mod n representing a first part of the attestation value cert. The attestation value cert comprises here the values A, e, v″. When the platform  20  intends to anonymously prove attestation to a verifier, that is the verification computer  40 , such that later on a trusted third party, that is the trusted entity  50 , will be able to revoke anonymity (i.e., to identify the TPM/platform), it proceeds as follows: Let m be a text or a value derived from such a text describing the condition under which anonymity is revocable. To m is also referred as decryption policy. 
     The platform  20  first sends the base value z and receives the value Nv from the TPM  22 . In  FIG. 3  is this illustrated by steps  101  and  102 , but ID′ TPM  is labeled for Nv. Then it chooses a random integer u and computes a part of the user attestation-signature value DAA′
 
 T   1   =A·h   u  mod  n.  
 
     Next, it chooses a random integer r between 0 and p and computes an encryption E with the following four values
 
δ1=γ τ  mod Γ, δ2=η τ  mod Γ, δ3=λ 3   τ   Nv  mod Γ, and δ4=λ 1   τ λ 2   τH(δ1,δ2,δ3,m) mod Γ.
 
     The platform  20  then sends T 1  and E=(δ1, δ2, δ3, δ4) to the verifier  40 . Then it receives a first signature value T′ 1  from the TPM  22  and computes an intermediary user attestation-signature value
 
 T″   1   =T′   1   ·A   re   ·h   reu  mod  n,  
 
where re and reu are random integers. Next, the platform  20  chooses a random integer rτ between 0 and ρ and computes an encryption proof value E′ with the following four values
 
δ1′=γ rτ  mod Γ, δ2′=η rτ  mod Γ, δ3′=λ 3   rτ   Nv  mod Γ, and δ4′=λ 1   rτ λ 2   rτH(δ1,δ2,δ3,m) mod Γ.
 
     The platform  20  then uses T″ 1  and E′=(δ1′, δ2′, δ3′, δ4′) as well as some other values as input to a hash function, e.g. SHA-1, to derive a value C′, herein also referred to as intermediate user attestation-signature value C′. The platform  20  sends C′ to the TPM  22  and receives the security module attestation value DAA comprising values (C,sf0,sf1,sv). The platform  20  augments these security module attestation with at least the values sτ=rτ+C·τ, se=re+C·e, and seu=reu+C·e·r and sends a resulting list of values DAA′, also referred to as user attestation-signature value DAA′, to the verifier  40 . 
     The received user attestation-signature value DAA′ can be verified by the verifier  40  by computing an intermediary user attestation-signature verification value
 
 T′″   1 =( T′   1 ( R   2   x   ·R   5   z )) −C   ·S   sv   ·R   0   sf0   ·R   1   sf1   ·T   1   se−CL   ·h   −seu   ·R   3   sy   ·R   4   sw  mod  n,  
 
where L is a security parameter, and computing encryption-proof verification values
 
δ1′″=δ1 −C γ sτ  mod Γ, δ2′″=δ2 −C η sτ  mod Γ, δ3′″=δ3 sτ   z   sf0+L′sf2  mod Γ, and δ4′″=δ3 −C λ 1   sτ λ 2   sτH(δ1,δ2,δ3,m) mod Γ,
 
where L′ is a further security parameter, using T′″ 1 , δ1′″, δ2′″, δ3′″, δ4′″ in the input to the hash function to derive the first verification value C″, and verifying whether C″ equals the value C comprised in the user attestation-signature value DAA′.
 
     When later anonymity is desired to be revoked, the verifier  40  can forward the encryption E with the encryption values (δ1, δ2, δ3, δ4) together with the decryption policy m. The trusted third party, i.e. the trusted entity  50 , verifies the decryption policy m, i.e., whether it is justified to revoke the anonymity. If this is the case, it next verifies the following congruencies:
 
δ1 x1+x3H(δ1,δ2,δ3,m) δ2 x2+x4H(δ1,δ2,δ3,m) =δ4 mod Γ and δ2=δ1 mod Γ.
 
     If they hold, the trusted third party  50  computes
 
 Nv=δ 3/δ1 x5  mod Γ.
 
     This value will then allow one to identify the TPM/platform as it is known to the issuer which TPM/platform corresponds to which value of Nv. 
     In a further embodiment, the trusted third party  50  could make available a public key of the Camenisch-Shoup encryption scheme, i.e., values (n, g, y1=g x1 , y2=g x2 , y3=g x3 ), where g, y1, y2, y3 are values from Zn 2  and are the secret key of the trusted third party  50 . The Camenisch-Shoup encryption scheme is described by J. Camenisch and V. Shoup in the article “Practical Verifiable Encryption and Decryption of Discrete Logarithms”, Advances in Cryptology—{CRYPTO 2003}, pp. 126-144, vol. 2729, 2003. Moreover, the issuer makes available besides the values (n, g, g′, h, S, Z, R 0 , R 1 , Γ, y, ρ) a further value R 2  in his public key. 
     In this setting, the issuer computes the attestation value cert or certificate as follows. The issuer first chooses a random prime e of suitable size and a random integer v″, and computes
 
 A =( Z /( U·R   2   IDtpm   ·S   v″ )) l/e  mod  n,  
 
where IDtpm is a value identifying the TPM/platform, i.e., the identifying value ID TPM  for the user computer  20  with security module  22 .
 
     When now the platform  20  wants to anonymously prove attestation to the verifier  40  such that later on one trusted third party  50  should be able to revoke anonymity (i.e., to identify the TPM/platform), it proceeds as follows: 
     Let m be a text or a value derived from such a text describing the condition under which anonymity maybe revoked. To m is also referred as decryption policy. 
     The platform  20  first receives value Nv from the TPM  22 , where here Nv represents the module-generated-identifier value ID′ TPM . Then it chooses a random integer u and computes
 
 T   1   =A·h   u  mod  n.  
 
     Next, it chooses a random integer τ between 0 and n/4 and computes encryption values
 
 u:=g   τ  mod  n   2   , e:=y 1 τ   h   IDtpm  mod  n   2 , and  v:=abs ( y 2 y 3 H .(u,e,,.m . . . ) ) τ  mod  n   2 ,
 
where abs( ) is a function that maps (a mod n 2 ) to (n 2 −a mod n 2 ) if a&gt;n 2 /2, and to (a mod n 2 ), otherwise, where 0&lt;a&lt;n 2 .
 
     The platform  20  then sends T 1  and encryption values (u,e,v) to the verifier  40 . Then it receives the first signature value T′, from the TPM  22  and computes
 
 T″   1   =T′   1   ·A   re   ·R   2   rt   ·h   reu  mod  n,  
 
where re, rt and reu are random integers. Next, the platform  20  chooses a random integer rτ between 0 and n/4 and computes
 
 u′:=g   2·r   τ  mod  n   2   , e′:=y 1 2·rτ   h   2·rτ  mod  n   2 , and  v′:=y 2 2   y 3 2·H     (u,e,     m     )     ·rτ  mod  n   2 .
 
     The platform  20  then uses T″ 1  and (u′,e′,v′) as well as some other values as input to the hash function to derive the intermediate user attestation-signature value C′. The platform  20  sends C′ to the TPM  22  and receives the security module attestation values DAA that comprises values (C,sf0,sf1,sv). The platform  20  augments these security module attestation with at least the values sτ=rτ+C·τ, st=rt+C·IDtpm, se=re+C·e, and seu=reu+C·e·u and sends the resulting list of values, that is the user attestation-signature value DAA′, to the verifier  40 . 
     The received user attestation-signature value DAA′ can be verified by the verifier  40  by computing
 
 T′″   1 =( T′   1 /( R   2   x   ·R   5   z )) −C   ·S   sv   ·R   0   sf0   ·R   1   sf1   ·R   2   st   ·T   1   se−CL   ·h   −seu   ·R   3   sy   ·R   4   sw  mod  n,  
 
where L is a security parameter, and computing values
 
 u′″:=g   2·sτ  mod  n   2   , e′″:=y 1 2·sτ   h   2·sτ  mod  n   2 , and  v′″=y 2 2   y 3 H     (u,e,     m     )     ·2·sτ  mod  n   2 .
 
using T′″ 1  and (u′″,e′″,v′″) in the input to the hash function to derive the first verification value C″, and verifying whether C″ equals the value C comprised in the user attestation-signature value DAA′.
 
     When later anonymity is intended to be revoked, the verifier  40  can forward the encryption values (u,e,v) together with the decryption policy m. The trusted third party  50  verifies the decryption policy, i.e., whether it is justified to revoke the anonymity. If this is the case, it next verifies the following congruencies:
 
 abs ( v )= v  and  u   2(x2+H(     u,e,     m)x3)   =v   2 ,
 
and, if they hold, computes t=2 −1  mod n, and compute ID′:=(e/u x1 ) 2t . If n divides ID′−1, then the trusted third party  50  outputs IDtpm=(ID′−1)/n. If any of the checks fail, it outputs “failure”. The value IDtpm, that is the identifying value IDtpm, will then allow one to identify the TPM/platform directly.
 
     Any disclosed embodiment may be combined with one or several of the other embodiments shown and/or described. This is also possible for one or more features of the embodiments. 
     The present invention can be realized in hardware, software, or a combination of hardware and software. Any kind of computer system—or other apparatus adapted for carrying out the method described herein—is suited. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. 
     Program code in the present context mean any expression, in any language, transcription or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or notation; b) reproduction in a different material form. 
     Variations described for the present invention can be realized in any combination desirable for each particular application. Thus particular limitations, and/or embodiment enhancements described herein, which may have particular advantages to a particular application need not be used for all applications. Also, not all limitations need be implemented in methods, systems and/or apparatus including one or more concepts of the present invention. 
     The present invention can be realized in hardware, software, or a combination of hardware and software. A visualization tool according to the present invention can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system—or other apparatus adapted for carrying out the methods and/or functions described herein—is suitable. A typical combination of hardware and software could be a general purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. The present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. 
     Computer program means or computer program in the present context include any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after conversion to another language, code or notation, and/or reproduction in a different material form. 
     Thus the invention includes an article of manufacture which comprises a computer usable medium having computer readable program code means embodied therein for causing a function described above. The computer readable program code means in the article of manufacture comprises computer readable program code means for causing a computer to effect the steps of a method of this invention. Similarly, the present invention may be implemented as a computer program product comprising a computer usable medium having computer readable program code means embodied therein for causing a function described above. The computer readable program code means in the computer program product comprising computer readable program code means for causing a computer to effect one or more functions of this invention. Furthermore, the present invention may be implemented as a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for causing one or more functions of this invention. 
     It is noted that the foregoing has outlined some of the more pertinent objects and embodiments of the present invention. This invention may be used for many applications. Thus, although the description is made for particular arrangements and methods, the intent and concept of the invention is suitable and applicable to other arrangements and applications. It will be clear to those skilled in the art that modifications to the disclosed embodiments can be effected without departing from the spirit and scope of the invention. The described embodiments ought to be construed to be merely illustrative of some of the more prominent features and applications of the invention. Other beneficial results can be realized by applying the disclosed invention in a different manner or modifying the invention in ways known to those familiar with the art.