CN103856477B

CN103856477B - A kind of credible accounting system and corresponding authentication method and equipment

Info

Publication number: CN103856477B
Application number: CN201310050808.6A
Authority: CN
Inventors: 付颖芳
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2012-12-06
Filing date: 2013-02-08
Publication date: 2018-01-02
Anticipated expiration: 2033-02-08
Also published as: CN103856478B; CN103856477A; CN103856478A

Abstract

A kind of credible accounting system and corresponding authentication method and equipment, the credible accounting system include management domain and multiple inter-trust domain, and the member of the inter-trust domain, which includes domain trusted party (DT) and domain terminal, methods described, to be included：For DT using its platform identity certificate to prove to management domain to register, management domain certification authorizes the DT by rear, by management domain to the signing certificate of the DT；Domain terminal is registered by the DT proved to place inter-trust domain of its platform identity certificate, the DT certifications pass through rear, by domain terminal described in terminal identity Credentialing, the terminal identity certificate includes signature of the management domain to the signature of the DT with the DT to the domain terminal；Between the domain terminal of different inter-trust domain during interaction, the terminal identity certificate based on remote port realizes the remote authentication to remote port identity.The application is easy to extension to tackle the integrated of different scales inter-trust domain, reduces network traffics, computational load and memory space, improves the efficiency of cross-domain certification.

Description

Trusted computing system and corresponding authentication method and equipment

Technical Field

The present application relates to trusted computing, and more particularly, to a trusted computing system having a distributed network topology and corresponding authentication method and apparatus.

Background

With the continuous development of the Internet, the distributed computing power is continuously enhanced, so that the wide-range resource sharing becomes a trend. However, due to the openness and uncontrollable property of the distributed network environment and the autonomy of the resources thereof, and the incompleteness, inconsistency, uncertainty and the like of the resource aggregation and collaboration environment, the traditional security mechanism based on centralized management is no longer applicable. People put forward a new idea to ensure the security of the terminal, namely a trusted computing technology. The core idea of the Trusted computing technology is that in various devices including desktop computers, notebook computers, smart phones and the like, an embedded Trusted Platform Module (TPM) is used as a core to provide security guarantee for users and platforms (including TPMs and hosts). The TPM has the remote certification capability and can respond to the request of a remote authenticator and certify the identity, integrity and other credible attributes of the platform. Trusted Computing Group (TCG) requires that privacy of platform identity information is effectively protected during remote attestation, that is, identity information cannot be exposed when TPM remotely attests to an authenticator.

In order to solve the problem of protecting the privacy information of the platform during remote certification, the TCG adopts a PCA method and a DAA method in sequence.

The TCG proposes a Privacy certificate authority (Privacy ca) anonymous authentication system in its TPM v1.1b specification, which adopts Privacy ca as a trusted third party to issue an alias certificate for an EK certificate of a client platform to ensure anonymity, and ensures the irrelevability among multiple authentications of the platform by a one-time pad method.

For different uses of keys, TCG defines seven types of keys, among which the main keys related to platform identity authentication are:

signing Key (EK, Endorsement Key): the key used to uniquely identify the platform identity is typically generated by the TPM manufacturer at the time of manufacture of the TPM. The EK affects the security of the whole system, it is used for only two operations: firstly, when determining the owner of the platform, decrypting the authorization data of the owner; the second is to generate the AIK key and create an alias certificate for the platform identity.

Identification Identity Key (AIK), attention Identity Key: the method is specially used for signing data (such as PCRs values and the like) generated by the TPM, and proving the legality of the identity of the platform and the credibility of the environment of the platform.

To enable trusted attestation of the application, management, and platform of keys, TCGs define five classes of certificates, each class being used to provide the necessary information for a particular operation, including:

signing certificate (Endorsement Credential): the EK certificate is issued by EK manufacturer, and contains information such as TPM manufacturer name, TPM model number, TPM version number and EK public key. The EK public key, although public, is the only proof of authenticating the identity of the TPM and therefore is also confidential and sensitive.

Identification Credential (AIK creditial): also known as AIK certificates, are used to authenticate the AIK private key that signs the PCR value, including the AIK public key and other information deemed useful by the issuer. The AIK certificate is issued by a trusted service capable of verifying various certificates and protecting the privacy of the user. By issuing a certificate, the service may prove that the TPM providing the TPM information is authentic.

Other certificates are a consistency certificate (consistency certificate), a platform certificate (platform enterprise certificate), and a Validation certificate (Validation certificate).

The Privacy CA system is simple and easy to implement, and can realize anonymous authentication of a platform, but the Privacy CA needs to issue a new AIK certificate for each authentication of the platform, and the AIK certificate is required to be highly available, so that the Privacy CA can become a performance bottleneck of the whole authentication system, and can suffer from DoS attack to cause single-point failure of the system.

In 12 months in 2007, the code administration of China issued "trusted computing password support platform function and interface specifications", which describes the functional principle and requirements of the trusted computing password support platform and defines the interface specifications of the trusted computing password support platform for providing services for the application layer, so as to guide the development and application of related trusted computing products in China. In order to protect the anonymity of the platform identity in the remote certification process, the standard defines a platform identity authentication system taking a Trusted third party as a center, a Trusted Cryptography Module (TCM) replaces TPM to be used as a Trusted root, the working principle and the protocol flow of issuing the certificate are basically the same as those of a TCG privacyCA system, but a double-certificate system and different Cryptographic algorithms are adopted to adapt to the national conditions of China. The dual certificate includes a Platform Identity certificate and a Platform encryption certificate, where the Platform Identity certificate is a certificate issued for a public Key of a Platform Identity Key (PIK), and is also referred to as a PIK certificate. The PIK is an SM2 key pair generated in the TCM and used for signing information in the TCM to realize platform identity authentication and integrity report; the platform encryption certificate is a certificate issued for a public Key of a Platform Encryption Key (PEK), also referred to as a PEK certificate, which is a data encryption certificate associated with a PIK certificate in the TCM. The authentication system defined by the specification suffers from the same drawbacks as the PrivacyCA system.

To overcome the drawbacks of the PrivacyCA system, TCG proposes a Direct Anonymous Authentication (DAA) system in TPM v1.2 standard. The DAA certification system is based on the C-L signature scheme and discrete logarithm based zero knowledge proof and converts the knowledge proof into a non-interactive knowledge signature using Fiat-Shamir heuristic. DAThe main participants of the a-authentication system are a signing party (Signer), a trusted issuing party (Issuer), and an authenticating party (Verifier). When the system works, firstly, the TPM applies to a trusted issuer to obtain secret data based on the EK public key (f)₀,f₁) Of (C-L), i.e. obtaining a signature on (f)₀,f₁) After each authentication, the TPM, together with the platform host to which it is bound, proves zero knowledge to the authenticator that it possesses secret data (f)₀,f₁) And the associated DAA certificate (A, e, v), in combination with (f)₀,f₁) Calculate the pseudonym N_vAnd if the verification is passed, the identity of the corresponding platform of the TPM is credible. Since the authentication uses zero knowledge proof, the authenticator cannot know (f)₀,f₁) And the certificate (A, e, v) thereof, the true identity of the certification platform cannot be judged, and the anonymity of the certification is realized. The DAA authentication system realizes identity validity authentication and simultaneously signs the AIK public key, so that the AIK becomes an alias of EK.

The DAA uses the DAA certificate to replace the original AIK certificate, only needs to apply for once and can be used for multiple times to ensure the anonymity of the trusted platform, and does not need the help of Privacy-CA. However, the DAA certification system is mainly oriented to a network environment with a small range and a definite boundary, is particularly suitable for an internal network, and is only suitable for a trusted issuer where the TPM and the authenticator trust the same, and cannot provide identity certification between the TPM and the authenticator or between the TPM and the TPM belonging to different DAA domains (applying for DAA certification to different issuers), that is, the current DAA certification system is only suitable for a single trust domain, and cannot provide a trust relationship for cross-domain certification. Although it is contemplated that different sets of TPM trust relationships may be constructed in a manner that allows one TPM to apply different DAA attestations to a plurality of different DAA issuers, this approach of exhaustively enumerating all trust relationships is overly complicated and redundant, and the information that a TPM can hold is very limited, and thus, this approach may not be truly usable in an Internet environment.

For the limitations of such cross-domain authentication, the prior art proposes some solutions.

In "dynamic trust value-based DAA cross-domain authentication mechanism" published in "computer engineering" volume 36, paragraph 11 (month 6 2010), "a scheme for implementing TPM user cross-domain authentication by establishing an inter-domain trust relationship is proposed, in which an inter-domain trust value is quantized to a real number between [0,1], and compared with a trust threshold, if the inter-domain trust relationship is greater than or equal to the trust threshold, a temporary trust relationship is established between two domains, and a TPM user authenticated by a local domain is approved to access resources in a remote domain according to an access control policy. The existing DAA scheme cannot provide identity authentication for TPMs belonging to different DAA domains, and for this purpose, a trust value center (TA) is introduced to calculate and store trust values between domains. When the cross-domain authentication is carried out, the TPM submits an access request to a remote domain B to an authentication server of a local domain (domain A), the authentication of the authentication server of the local domain is passed and then the cross-domain access request is sent to the authentication server of the remote domain (domain B), after the authentication of the authentication server of the domain B is passed, a trust value to the TPM is calculated and a trust value to the domain A is requested to be calculated by a TA, if the trust value is larger than a threshold value, an allowance message is returned to the authentication server of the domain A, when the authentication of the authentication server of the domain A is allowed, a Ticket (Ticket) is sent to the TPM, and the TPM holds the Ticket to access the resources of the remote domain.

In the cross-domain anonymous authentication mechanism under distributed network environment, named Zhouyama, published in book 30, No. 8 (8 2010), the proposed cross-domain authentication framework includes a trusted third party Certificate Arbitration Center (CAC) and a plurality of trusted domains, each including TCP and DAA Certificate Issuers (IS), the CAC vouches for the authenticity of AIK certificates issued by DAA Certificate issuers of different manufacturers. Trusted domain DO_ATrusted computing platform TCP_ATowards another trusted domain DO_BWhen the service provider applies for the service, TCP_AFirst, through the local domain DAA certificate issuer IS_AObtains its issued AIK certificate, and then sends a cross-domain certificate request, TCP, to CAC_AUsing local domain AIK certificates and its own integrity metrics to prove its identity to the CAC, which passes through the IS_AInter-message mutual authentication TCP_AAuthenticity ofAnd integrity, for platform-complete TCP with legitimate AIK certificates_AIssuing Cross-Domain authentication certificates, TCP_AUsing cross-domain authentication certificates to trusted domain DO_BThe service provider in (1) verifies the authenticity of its identity and the integrity of the platform.

In the "direct anonymous proving scheme in multiple trust domains", which is written by cheng xiao feng et al published in volume 31, stage 7 (month 7 2008), the "computer science newspaper" proposes a cross-domain DAA scheme, which adds two participating parties in each trust domain on the basis of the DAA scheme: passport issuers and visa issuers. The basic idea of the cross-domain method is as follows: if the trust domain DO_AHT (trusted computing platform)_A(Host/TPM A) to trust domain DO_BAuthenticator V of_BTo prove its identity without revealing its privacy, then HT first_AApplying a passport certificate to a local domain passport issuer, the passport certificate proving HT_AIn a trust domain DO_AOf (1), then HT_AUsing the passport certificate to the trust domain DO_BThe visa issuer of (a) applies for a visa certificate, and finally, HT_AUsing the passport certificate and visa certificate to the trust domain DO_BAuthenticator V in_BAnonymously proving its identity.

In the improved cross-domain direct anonymous authentication scheme, which is written in the computer application, 30, 12 th (2010 12) and published by the minister of plum and the like, DAA issuers in different trust domains are taken as proxy members of the domain, the proxy members firstly authenticate the identity of a trusted platform of the domain, issue direct anonymous certificates in the trust domains under the condition of legal confirmation, and bind the identity, the valid dates of the certificates and the direct anonymous certificates.

All of the above cross-domain authentication schemes require a certificate issuer of each trusted domain or a trusted third party (such as a third-party certificate arbitration center, a trust value center) to participate in issuing the certificate required by cross-domain authentication, and the process is still too complicated, and better schemes are yet to be researched.

Content of application

In view of the above, the present application provides a trusted computing system, and a corresponding authentication method and device.

In order to solve the above technical problem, the present application proposes an authentication method of a trusted computing system, the trusted computing system including an administrative domain and a plurality of trusted domains, members of the trusted domain including a domain trusted party (DT) and a domain terminal, the method including:

the DT registers in the management domain by taking the platform identity certificate thereof as a certificate, and after the management domain passes the authentication, the DT is granted with the signature certificate of the DT by the management domain;

the domain terminal registers in a DT (trusted domain) which is proved by a platform identity certificate of the domain terminal, and after the DT passes authentication, a terminal identity certificate is granted to the domain terminal, wherein the terminal identity certificate comprises a signature of a management domain to the DT and a signature of the DT to the domain terminal;

when the domain terminal of one trusted domain interacts with the domain terminal of another trusted domain, the domain terminal of the trusted domain realizes remote authentication of the domain terminal identity of the other trusted domain based on the terminal identity certificate of the domain terminal of the other trusted domain.

Preferably, in the above-mentioned authentication method,

members of the administrative domain include a privacy certificate authority (PrivacyCA);

after the management domain passes the authentication, the step of granting the DT with the signature certificate of the management domain to the DT comprises the following steps: and after the PrivacyCA passes the authentication, a DT identity certificate is granted to the DT, and the DT identity certificate contains the signature of the DT by the PrivacyCA.

Preferably, in the above-mentioned authentication method,

the members of the administrative domain include a privacy certificate authority (PrivacyCA) and a plurality of virtual CA members, and the authentication method further includes the following virtual CA establishment procedures:

the Privacy CA generates a pair of system public private keys, publishes public parameters required by threshold signature and verification, and distributes the system private keys to virtual CA members in a secret way;

each virtual CA member secretly shares the system private key based on a (t, n) threshold system to form a virtual CA, and each virtual CA member stores a system sub private key;

the DT takes the platform identity certificate as the certificate to register to the management domain, namely registers to t virtual CA members respectively; after the management domain passes the authentication, the step of granting the DT with the signature certificate of the management domain to the DT comprises the following steps: and after the t virtual CA members respectively pass the authentication, signing the DT by using the respectively stored system sub-private keys according to a threshold signature algorithm to obtain t sub-DT identity sub-certificates, and granting the DT to the DT, after the DT passes the validity authentication of the signature of the DT by the system sub-private keys in the t DT identity sub-certificates, synthesizing a DT identity certificate according to the t DT identity sub-certificates, wherein the DT identity certificate comprises the signature of the DT by using the virtual CA synthesized by the threshold signature algorithm.

Preferably, in the above-mentioned authentication method,

when the t virtual CA members sign the DT with the system sub-private keys stored in the T virtual CA members to obtain t DT identity sub-certificates and grant the DT, the T virtual CA members also provide the DT with the CA member identity certificates of the T virtual CA members as identity certificates;

and after receiving the DT identity sub-certificate and the CA member identity certificate, the DT firstly authenticates the identity of the corresponding virtual CA member based on the CA member identity certificate, and after the authentication is passed, the DT authenticates the signature in the identity sub-certificate legally.

Preferably, in the above-mentioned authentication method,

the CA membership certificate is obtained by a virtual CA member through the following processes:

a virtual CA member registers to other t or t-1 virtual CA members by taking a platform identity certificate thereof as a certificate, after the other t or t-1 virtual CA members pass the verification, the virtual CA member is signed by using a system sub-private key stored by the virtual CA member, the obtained t or t-1 CA member sub-identity certificates are granted to the virtual CA member, the virtual CA member legally authenticates the signature of the virtual CA member by the system sub-private key in the t or t-1 CA member identity sub-certificates, synthesizes a CA member t identity certificate, and the CA member identity certificate comprises the signature of the DT by the virtual CA synthesized by a threshold signature algorithm;

the main body part of the signature in the CA membership certificate comprises the platform identification of the virtual CA member, or comprises the platform identification of the virtual CA member and the system administrator identification at the same time.

Preferably, in the above-mentioned authentication method,

when the DT grants the terminal identity certificate to the domain terminal, the DT also provides the own DT identity certificate as an identity certificate to the domain terminal;

and after receiving the terminal identity certificate and the DT identity certificate, the domain terminal authenticates the DT on the basis of the DT identity certificate, and after the DT passes the authentication, the domain terminal stores the terminal identity certificate.

Preferably, in the above-mentioned authentication method,

the body part of the signature in the DT identity certificate comprises the domain administrator identification and the platform identification of the DT.

Preferably, in the above-mentioned authentication method,

the members of the administrative domain include PrivacyCA, to which the other members of the trusted computing system, except PrivacyCA, register to obtain a platform identity certificate by:

the other members register in the privacyCA by taking the signed certificate of the trusted module in the trusted computing platform as the certificate, and store the platform identity certificate granted by the privacyCA;

and after the authentication of the Privacy CA is passed, granting a platform identity certificate to the other members, wherein the platform identity certificate contains the signatures of the other members by the Privacy CA.

Preferably, in the above-mentioned authentication method,

the process of registering the other member with the PrivacyCA is performed before the other member joins the trusted computing system;

in the process, after the PrivacyCA passes the authentication, a unique platform identifier in the system is also distributed to the other members, and the main part of the signature in the platform identity certificate granted to the other members by the PrivacyCA contains the platform identifier.

Preferably, in the above-mentioned authentication method,

and the main part of the signature of the DT on the domain terminal in the terminal identity certificate comprises the terminal user identifier and the platform identifier of the domain terminal.

Accordingly, the present application also provides a trusted computing system based on a distributed network environment, the trusted computing system comprising an administrative domain and a trusted domain, members of the trusted domain comprising a domain trusted party (DT) and a domain terminal, characterized in that:

the management domain is used for accepting the registration of the DT, and after the DT is authenticated, the signature certificate of the DT by the management domain is granted to the DT;

the domain terminal includes:

the terminal certificate application module is used for registering the DT which proves that the terminal is located in the trusted domain by taking the platform identity certificate of the terminal in the domain as a certificate and storing the terminal identity certificate granted by the DT;

the remote authentication module is used for providing terminal identity certificates for the domain terminals of other trusted domains when interacting with the domain terminals of other trusted domains, and performing identity authentication on the domain terminals of other trusted domains based on the terminal identity certificates of the domain terminals of other trusted domains;

the DT includes:

the DT certificate application module is used for registering in the management domain by taking the platform identity certificate of the DT as a certificate and storing a signature certificate granted by the management domain;

and the terminal certificate issuing module is used for receiving the registration of the domain terminal, and after the domain terminal passes the authentication, issuing a terminal identity certificate to the domain terminal, wherein the terminal identity certificate comprises the signature of the management domain on the DT and the signature of the management domain on the domain terminal by the DT.

Preferably, in the above-described trusted computing system,

the PrivacyCA includes:

and the DT certificate issuing module is used for accepting the registration of the DT, and after the DT is authenticated, granting a DT identity certificate to the DT, wherein the DT identity certificate contains the signature of the DT by the PrivacyCA.

Preferably, in the above-described trusted computing system,

the members of the administrative domain include PrivacyCA and a plurality of virtual CA members, wherein:

the PrivacyCA includes:

the system key management module is used for generating a pair of system public and private keys, publishing a threshold signature and public parameters required by verification, and distributing the system private key to the virtual CA members in a secret way;

the plurality of virtual CA members secretly share the system private key based on a (t, n) threshold system to jointly form a virtual CA, wherein each virtual CA member comprises:

the DT certificate issuing module is used for receiving the registration of the DT, signing the DT by using a system sub-private key stored by the virtual CA member according to a threshold signature algorithm after the DT passes the authentication, and granting the DT with an obtained DT identity sub-certificate;

the DT certificate application module of the DT registers to t virtual CA members respectively to obtain t DT identity sub-certificates, and synthesizes the DT identity certificates according to the t DT identity sub-certificates after the legality of the signature of the DT by a system sub-private key in the t DT identity sub-certificates is authenticated, wherein the DT identity certificates comprise the signature of the DT by the virtual CA synthesized by a threshold signature algorithm.

Preferably, in the above-described trusted computing system,

when the DT certificate issuing module of the virtual CA member grants the DT with the DT identity sub-certificate, the DT further provides the own CA member identity certificate as an identity certificate to the DT;

and after receiving the t DT identity sub-certificates and the corresponding CA member identity certificates, the DT certificate application module of the DT firstly authenticates the identities of the corresponding virtual CA members based on the CA member identity certificates, and then performs legality authentication on the signatures in the DT identity sub-certificates after the identities pass the authentication.

Preferably, in the above-described trusted computing system,

each virtual CA member further comprises:

the CA member certificate application module is used for registering to other t or t-1 virtual CA members by taking the platform identity certificate thereof as a certificate, legally authenticating the signature of the virtual CA member by the system sub private key after receiving the granted t or t-1 CA member sub certificates, and synthesizing the CA member identity certificate after the authentication is passed, wherein the CA member identity certificate comprises the signature of the DT by the virtual CA synthesized by a threshold signature algorithm, and the main part of the signature comprises the platform identification of the virtual CA member or comprises the platform identification of the virtual CA member and the system administrator identification at the same time;

and the CA member certificate issuing module is used for receiving the registration of another virtual CA member, signing the other virtual CA member by using a self-stored system sub private key after the other virtual CA member passes the authentication, and granting the other virtual CA member with the obtained CA member identity sub certificate.

Preferably, in the above-described trusted computing system,

when the terminal certificate issuing module of the DT grants the terminal identity certificate to the domain terminal, the terminal certificate issuing module of the DT also provides the own DT identity certificate as an identity certificate to the domain terminal;

and after receiving the terminal identity certificate and the DT identity certificate, the terminal certificate application module of the domain terminal authenticates the DT on the basis of the DT identity certificate, and stores the terminal identity certificate after the DT passes the authentication.

Preferably, in the above-described trusted computing system,

and the main part of the signature in the DT identity certificate synthesized by the DT certificate application module of the DT comprises the domain administrator identification and the platform identification of the DT.

Preferably, in the above-described trusted computing system,

the PrivacyCA includes:

the platform certificate issuing module is used for receiving registration of other members of the system, and after the registration is passed, a platform identity certificate is issued to the other members, wherein the platform identity certificate contains the signatures of the other members of the Privacy CA;

the other members of the trusted computing system further include:

and the platform certificate application module is used for registering to the Privacy CA by taking the signing certificate of the trusted module in the trusted computing platform as a certificate and storing the platform identity certificate granted by the Privacy CA.

Preferably, in the above-described trusted computing system,

the platform certificate application modules of other members of the system register with the PrivacyCA before joining the trusted computing system;

after the platform certificate issuing module of the PrivacyCA passes the authentication, a unique platform identifier in the system is also distributed to the other members, and the main part of the signature in the platform identity certificate issued by the PrivacyCA to the other members comprises the platform identifier.

Preferably, in the above-described trusted computing system,

the main part of the signature of the DT on the domain terminal in the terminal identity certificate granted to the domain terminal by the terminal certificate issuing module of the DT comprises a terminal user identifier and a platform identifier of the domain terminal.

Accordingly, the present application also provides a privacy certificate authority (PrivacyCA) in the trusted computing system, wherein: the PrivacyCA includes:

and the system key management module is used for generating a pair of system public and private keys, publishing threshold signatures and public parameters required by verification, and distributing the system private keys to the virtual CA members in a secret manner.

Preferably, after the platform certificate issuing module passes the authentication, the platform certificate issuing module further allocates a unique platform identifier in the system to the other member, and a main part of a signature in the platform identity certificate issued by the PrivacyCA to the other member includes the platform identifier.

Accordingly, the present application further provides a virtual Certificate Authority (CA) member in the trusted computing system, wherein:

the method comprises the following steps that a plurality of virtual CA members secret a private key of a sharing system based on a (t, n) threshold system to jointly form a virtual CA, wherein each virtual CA member comprises:

the platform certificate application module is used for registering to the Privacy CA by taking a signed certificate of a trusted module in a trusted computing platform as a certificate, and storing a platform identity certificate granted by the Privacy CA;

and the DT certificate issuing module is used for receiving the registration of the DT, signing the DT by using a system sub-private key stored by the virtual CA member according to a threshold signature algorithm after the DT passes the authentication, and granting the DT with the obtained DT identity sub-certificate.

Preferably, the virtual certificate CA member further includes:

And when the DT certificate issuing module grants the DT with the DT identity sub-certificate, the DT also provides the CA membership certificate of the DT as an identity certificate to the DT.

Accordingly, the present application also provides a domain trusted party (DT) in the above trusted computing system, the DT comprising:

and the terminal certificate issuing module is used for accepting the registration of the domain terminal, issuing a terminal identity certificate to the domain terminal after the domain terminal passes the authentication, and simultaneously providing the DT identity certificate of the terminal to the domain terminal as an identity certificate, wherein the terminal identity certificate comprises the signature of the management domain on the DT and the signature of the DT on the domain terminal.

Preferably, the DT certificate application module registers to t virtual CA members respectively to obtain t DT identity sub-certificates, and after the validity of the signature of the DT by the system sub-private key in the t DT identity sub-certificates is authenticated, synthesizes a DT identity certificate according to the t DT identity sub-certificates, where the DT identity certificate includes the signature of the DT by the virtual CA synthesized by the threshold signature algorithm.

Preferably, the DT certificate application module further receives the corresponding CA member identity certificate when receiving the t DT identity sub-certificates, performs identity authentication on the corresponding virtual CA members based on the CA member identity certificate, and performs validity authentication on the signature in the DT identity sub-certificate after the authentication is passed.

Preferably, the main part of the signature of the DT on the domain terminal in the terminal identity certificate granted to the domain terminal by the terminal certificate issuing module includes the terminal user identifier and the platform identifier of the domain terminal.

Preferably, the body part of the signature in the DT identity certificate synthesized by the DT certificate application module includes the domain administrator identity and the platform identity of the DT.

Accordingly, the present application further provides a domain terminal in the above trusted computing system, where the domain terminal includes:

preferably, after the terminal certificate application module receives the DT identification certificate and the terminal identification certificate, the DT is authenticated based on the DT identification certificate, and the terminal identification certificate is stored after the DT identification certificate passes the authentication.

In the implementation mode of the application, the authentication method of the trusted computing system and the corresponding system adopt the distributed network topology based on the trusted domain, so that the integration of the trusted domains with different scales is conveniently dealt with by expansion.

In the implementation mode of the application, the domain terminal can realize cross-domain authentication by obtaining the terminal identity certificate from the DT of the trusted domain, and does not need to apply for the certificate for each trusted domain, so that network flow, calculation load and storage space are reduced, and the efficiency of the cross-domain authentication of the distributed network is improved.

In the implementation mode of the application, the DT identity certificate is issued to the DT by adopting the virtual CA instead of the Privacy CA, a plurality of virtual CA members share the system private key according to a (t, n) threshold system, so that the false attack, the single-point DOS attack and the invalidation can be avoided, the Privacy CA can grant the member platform identity certificates only when other members of the system register, the Privacy CA does not need to participate in the subsequent authentication process, the Privacy CA can be effectively protected, and the confidentiality of the system is improved.

In the implementation mode of the application, the user identification and the platform identification of the member are bound in the certificate granted to the system member, so that the platform replacement attack can be effectively prevented.

Drawings

FIG. 1 is a block diagram of a trusted computing system according to an embodiment of the present application;

FIG. 2 is a block diagram of system components in accordance with an embodiment of the present application;

FIG. 3 is a general flowchart of an authentication method according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating a method for authenticating a platform identity certificate by registering a member of a trusted domain with privacyCA;

fig. 5 is a flowchart of a process of establishing a virtual CA in the authentication method according to the embodiment of the present application;

fig. 6 is a flowchart of DT registration to a management domain virtual CA in an authentication method according to an embodiment of the present application;

fig. 7 is a flowchart illustrating DT registration of a domain terminal to a trusted domain in an authentication method according to an embodiment of the present application;

fig. 8 is a flowchart illustrating registration of a virtual CA member with other virtual CA members in the authentication method according to the embodiment of the present application;

fig. 9 is a schematic diagram illustrating an architecture and a flow of an exemplary application of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.

As shown in fig. 1, the trusted computing system of the present embodiment includes a management domain and a plurality of trusted domains, and each of the management domain and the trusted domains includes several members. As members of a trusted computing system, trusted computing platforms of all members have trusted modules (such as TPM, TCM, etc.) embedded in a hardware platform, and each trusted module stores a pair of signing keys (EK) and corresponding EK certificates, which can uniquely identify itself.

The management domain is used for receiving the registration of a domain trusted party (DT), and after the DT is authenticated, the DT is granted with a signature certificate of the DT by the management domain.

Members of the trusted domain include a domain trusted party (DT), which may also be referred to as a trusted domain server, and a domain terminal, the user of which is referred to as a domain administrator. The domain terminal is a common member in the trusted domain, and the user of the domain terminal is called an end user. The DT is used for obtaining a signature certificate granted by the management domain from the management domain by taking the platform identity certificate thereof as a certificate, accepting the registration of the domain terminal, and granting the terminal identity certificate to the domain terminal passing the authentication, wherein the terminal identity certificate comprises the signature of the DT by the management domain and the signature of the DT to the domain terminal. The domain terminal is used for registering the DT which is proved to be in the trusted domain by taking the platform identity certificate thereof as the certificate, acquiring the terminal identity certificate granted by the DT, and realizing remote identity authentication of the remote terminal based on the terminal identity certificate of the remote terminal when interacting with the domain terminals of other trusted domains.

In this embodiment, the members of the administrative domain include a privacy certificate authority (PrivacyCA)10 and a plurality of virtual CA members 20, wherein the virtual CA members may also be referred to as administrative domain servers, and users thereof are referred to as system administrators. Please refer to fig. 2 (only one trusted domain a is shown as an example), in which:

privacy CA 10 includes:

and the system key management module 102 is used for generating a pair of system public and private keys, publishing threshold signatures and public parameters required for verification, and distributing the system private key secret to the virtual CA members.

And the platform certificate issuing module 104 is configured to accept registration of other members of the system, and after the authentication is passed, issue a platform identity certificate to the other members, where the platform identity certificate includes a signature of the PrivacyCA on the other members. Other members herein include all members of the trusted domain such as DT, domain termination, and other members of the administrative domain than Privacy CA such as virtual CA members.

The plurality of virtual CA members secret and share the system private key based on the (t, n) threshold system to jointly form virtual CA, and the virtual CA members can be designated by Privacy CA or applied by a terminal in the system and become virtual CA members after being approved by Privacy CA.

Wherein each virtual CA member 20 comprises:

and the DT certificate issuing module 202 is used for receiving the registration of the DT, signing the DT by using a system sub-private key stored by the virtual CA member according to a threshold signature algorithm after the DT passes the authentication, and granting the DT with the obtained DT identity sub-certificate. In addition, when the DT certificate issuing module grants the DT with the DT identity sub-certificate, the DT can also provide the CA membership certificate of the DT as an identity certificate.

The CA member certificate application module 204 is configured to register to t or t-1 virtual CA members with their platform identity certificates as a certificate, and after receiving the granted t or t-1 CA member sub-certificates, perform validity authentication on the signature of the virtual CA member by the system sub-private key, and synthesize a CA member identity certificate of its own after the authentication is passed, where the CA member identity certificate includes a signature of the DT by a virtual CA synthesized by a threshold signature algorithm, and a main part of the signature may include a platform identifier of the virtual CA member, or may include both the platform identifier of the virtual CA member and a system administrator identifier, so that a verifier, such as the DT, can simultaneously authenticate the platform identity and the user identity of the virtual CA member.

And the CA member certificate issuing module 206 is configured to receive registration of another virtual CA member, sign the another virtual CA member with a system sub-private key stored in the CA member after the another virtual CA member passes authentication based on a key exchange protocol, and grant the obtained CA member sub-certificate to the another virtual CA member.

The platform certificate application module 208 is configured to register with the PrivacyCA by using the signed certificate of the trusted module in the trusted computing platform as a certificate, and store the platform identity certificate granted by the PrivacyCA.

The management domain may further include corresponding databases, such as a user information and platform identity card library managed by PrivacyCA, a DT identity card library and a CA member identity card library managed by virtual CA, and the like. In one example, system members may access the respective databases through a Web server as shown in FIG. 1.

Among the members of the trusted domain, the domain trusted party 30 includes:

the platform certificate application module 302 is configured to register in the PrivacyCA using a signed certificate of a trusted module in a trusted computing platform of the platform as a certificate, and store the platform identity certificate granted by the PrivacyCA.

And the DT certificate application module 304 is configured to register in the management domain as evidenced by the platform identity certificate of the DT, and store a signature certificate granted by the management domain. In this embodiment, the DT certificate application module registers to t virtual CA members respectively to obtain t DT identity sub-certificates, and after the legitimacy of the signature of the DT by the system sub-private key in the t DT identity sub-certificates is authenticated, synthesizes a DT identity certificate according to the t DT identity sub-certificates, where the DT identity certificate includes a signature of the DT by the virtual CA synthesized by a threshold signature algorithm, and a main part of the signature may include the domain administrator identifier and the platform identifier of the DT at the same time, so that a verifier, such as a domain terminal, realizes simultaneous authentication of the platform identity and the user identity of the DT. When the virtual CA member provides the CA member identity certificate of the virtual CA member, the DT certificate application module receives the t DT identity sub-certificates and the corresponding CA member identity certificates, authenticates the corresponding virtual CA member based on the CA member identity certificate, and authenticates the legality of the signature of the DT after the authentication is passed.

A terminal certificate issuing module 306, configured to accept registration of a domain terminal, and after the domain terminal passes authentication, grant a terminal identity certificate to the domain terminal, where the terminal identity certificate includes a signature of a management domain to the DT and a signature of the DT to the domain terminal, where a main part of the signature of the DT to the domain terminal may include a terminal user identifier and a platform identifier of the domain terminal at the same time, so that a verifier, such as another domain terminal, may implement simultaneous authentication of the platform identity and the user identity of the domain terminal. When the terminal certificate issuing module of this embodiment grants the terminal identity certificate to the domain terminal, the DT identity certificate of the terminal can also be provided to the domain terminal as an identity certificate.

The domain terminal 40 includes:

a platform certificate application module 402, configured to register with the PrivacyCA by using a signed certificate of a trusted module in a trusted computing platform of the platform as a certificate, and store the platform identity certificate granted by the PrivacyCA.

And the terminal certificate application module 404 is configured to register the DT in the trusted domain by using the platform identity certificate of the terminal in the domain as a certificate, and store the terminal identity certificate granted by the DT. And when the DT provides the DT identity certificate at the same time, the DT is authenticated based on the DT identity certificate, and the terminal identity certificate is stored after the DT identity certificate passes the authentication.

And the remote authentication module 406 is configured to provide the terminal identity certificate to the remote end when interacting with a domain terminal of another trusted domain, and perform identity authentication on the remote end based on the terminal identity certificate of the remote end.

The authentication method of the present embodiment is shown in fig. 3, and the general flow thereof includes:

step 1, a DT registers in a management domain by taking a platform identity certificate as a certificate, and after the management domain passes authentication, a DT identity certificate is granted to the DT and contains a signature of the management domain on the DT;

the various certificates of this embodiment may conform to, but are not limited to, the x.509 standard, and include a body part (tbsccertificate), a signature algorithm identification part (signatureealgorithm), and a signature value part (signatureValue), which is a value signed by the subject part of the tbsccertificate using the signature algorithm specified in the signatureealgorithm part. The body part and the signature value part in the certificate are collectively referred to herein as a signature. The main part comprises fields such as a certificate version number, a certificate serial number, a certificate main body name, a certificate public key, a certificate issuer name, a certificate validity period and the like, and also comprises fields such as a certificate issuer ID, a certificate main body ID and a certificate extension segment, wherein the certificate public key can be used for encryption and/or identity certification and is not described in detail.

Preferably, the signed body part in the DT ID certificate of the present embodiment includes, in addition to the platform ID of the trusted computing platform of the DT, an ID of a legitimate user of the DT, i.e., a domain administrator ID. That is, the platform ID of the DT and the domain administrator ID are bound together in the DT identity certificate granted to the DT, and when a verifying party, such as a domain terminal, authenticates the DT based on the DT identity certificate, simultaneous authentication of the DT platform and a user can be achieved, thereby avoiding platform replacement attack by an illegal user using a legitimate DT platform.

Step 2, the domain terminal registers the DT which proves that the domain terminal is located in the trusted domain by taking the platform identity certificate of the domain terminal as the certificate, and after the DT passes the authentication, the domain terminal is granted with a terminal identity certificate which comprises the signature of the management domain to the DT and the signature of the DT to the domain terminal;

in this step, when the DT grants the terminal identity certificate to the domain terminal, the DT identity certificate itself can be provided to the domain terminal as an identity certificate; and after receiving the granted terminal identity certificate and the DT identity certificate of the DT, the domain terminal authenticates the DT on the basis of the DT identity certificate, and after the DT identity certificate passes the authentication, the domain terminal stores the terminal identity certificate.

Preferably, the body part of the signature of the DT on the domain terminal in the terminal identity certificate includes the platform identifier and the terminal user identifier of the domain terminal. The user ID and the platform ID of the domain terminal are bound together. Therefore, the platform replacement attack by an illegal user by using a legal platform can be avoided.

And 3, when the domain terminals of different trusted domains interact with each other, realizing the identity authentication of the remote end based on the terminal identity certificate of the remote end.

For example, when the domain terminal a of the trusted domain a interacts with the domain terminal B of the trusted domain B, the domain terminal a implements remote authentication of the identity of the domain terminal B based on the terminal identity certificate of the domain terminal B, and the domain terminal B implements remote authentication of the identity of the domain terminal a based on the terminal identity certificate of the domain terminal a.

Since the DT identity certificate contains the management domain's signature on the DT, a chain of trust is passed to the DT by the management domain. And the terminal identity certificate contains the signature of the management domain on the DT and the signature of the DT on the domain terminal, and the trust chain is transmitted to the domain terminal by the management domain. After the domain terminals of other trusted domains obtain the terminal identity card granted by the DT in the trusted domain, the domain terminals can be trusted through the verification of DT signatures by the management domain and the verification of DT signatures by the domain terminals, cross-domain authentication is realized, and each trusted domain does not need to apply for a certificate, so that the independence of trusted domain management is facilitated, the network flow, the calculation load and the storage space are reduced, and the efficiency of the cross-domain authentication of the distributed network is improved.

The authentication method of this embodiment may include the following process in which other members of the trusted computing system except PrivacyCA register with PrivacyCA to apply for the platform identity certificate, and this process may be completed before the other members join the trusted computing system, as shown in fig. 4, and this process includes:

110, under the authorization of the owner, the trusted computing platforms of the other members generate a pair of platform identity public and private keys by the internal trusted module, and the platform identity private keys are stored in the trusted module;

the trusted module can be a trusted module with different standards, such as TPM or TCM, and is embedded in the trusted computing platform.

Step 120, the trusted computing platform of the other member applies for registration to PrivacyCA by taking the EK certificate as an identity certificate, and carries the EK certificate and the generated platform identity public key;

step 130, after the PrivacyCA passes the authentication, a platform identity certificate is granted to the other members, and the platform identity certificate contains the signatures of the PrivacyCA to the other members.

Preferably, after the PrivacyCA authentication is passed, a platform identifier unique in the system is further allocated to the other member to identify the trusted computing platform of the member, and the body part of the signature of the PrivacyCA on the other member includes the platform identifier. Unified identification in the system is established for members of different trusted domains, and the realization of unified management and cross-domain authentication of a trusted computing platform of the system is facilitated.

The above process of applying for the platform identity certificate may adopt a mode that the TPM in the PCA system acquires the AIK certificate or the TPM in the china specification acquires the PIK certificate, but is not limited thereto, and is not described herein again. The platform identity certificate issued by Privacy-CA is used as an alias certificate of EK in the system, and the validity of the platform identity can be proved to other members of the system.

Secret sharing is a very important branch in the field of modern cryptography and is also an important research content in the direction of information security. The first secret sharing scheme is the (t, n) threshold system scheme, which was proposed by Shamir [1] and Blakley [2] in 1979 based on Lagrange's interpolation and the properties of multidimensional space points, respectively, and after the secret sharing concept was proposed, many researchers made extensive studies and achieved many results. The (t, n) threshold system is that the secret s is divided into n shares, each participant stores one secret share, and at least t participants need to cooperate to reconstruct the secret s.

The method applies the (t, n) threshold system to the establishment of the virtual CA of the trusted computing system, the Privacy CA is used as a secret distributor, a system private key generated by the Privacy CA is used as a secret s, n virtual CA members are used as participants, and each virtual CA member stores a secret share (called as a system sub private key). The reconstructor needs to obtain the system sub-private keys stored by at least t virtual CA members or the pseudo shares calculated by the system sub-private keys, so as to recover the system private keys.

In this embodiment, the process of establishing the virtual CA is shown in fig. 5, and includes:

step 210, the PrivacyCA generates a pair of system public private keys, publishes public parameters required by threshold signature and verification, and distributes the system private key to virtual CA members;

Privacy-CA may use a key generation algorithm such as RSA algorithm, SM2, etc. to generate the above-mentioned system public and private keys. The generated pair of system public and private keys can be stored in a key pool of the system.

Step 220, each virtual CA member secretly shares the system private key based on the (t, n) threshold system.

The constructed virtual CA may issue a DT identity certificate for the DT of the trusted domain instead of PrivacyCA. After the trusted domain member obtains the platform identity certificate from the Pravacy CA, the subsequent certificate obtaining and authentication processes do not need to be participated by the Pravacy CA, the problems of single-point DOS attack and invalidation caused when one node of the Pravacy CA issues the identity certificate are avoided, and a plurality of virtual CA members issue the DT identity certificate together, so that the privacy is also improved.

In this embodiment, a process of DT to management domain registration is shown in fig. 6, and includes:

step 310, the DT uses the platform identity certificate as the identity certificate, submits registration application to t virtual CA members, and simultaneously carries the platform ID of the DT;

the DT of the trusted domain may be specified by the Privacy CA, or may be applied by the domain terminal of the trusted domain, and is approved by the Privacy CA to become the DT.

Step 320, each virtual CA member authenticates the DT, and after the authentication is passed, a DT identity sub-certificate is respectively granted to the DT, and each DT identity sub-certificate contains a signature of the corresponding virtual CA member on the DT by using a system sub-private key stored by the corresponding virtual CA member;

and 330, synthesizing a DT identity certificate by the DT according to the obtained t DT identity sub-certificates, wherein the DT identity certificate comprises a signature of the DT on a virtual CA synthesized by a threshold signature algorithm.

Many signature and verification schemes based on a threshold system have been proposed at present, such as documents [1] R Gennaro, SJ arecki, HKwarwczyk, TRabin. Robust threshold DSS signatures. in: Eurocrypt' 96, LNCS1070.Berlin: Springer-Verlag, 1996.354-371; document [2] Ronald Cramer, Ivan Damgard, Ulel Maurer, general secure multi-level calculation from linear secure sharing scheme in: procceeeds of Eurocrypt' 2000, LNCS 1807.Berlin, Springer-Verlag, 2000.316-334; document [3] spring fragrance, Dongqing widow, Xiao nationality town, secret sharing of vector space-multiple signature scheme. electronic newspaper, 2003,31(1): 48-50. Document [4] Zhang Xinglan. threshold signature scheme with fault tolerance. proceedings of graduate institute of Chinese academy of sciences, Vol 21, No. 3, No. 2004, No. 7, No. 398-401. Among them, in the threshold signature schemes disclosed in documents [1] and [2], a secret share (secret share) holder first needs to make its own sub-signature. Document [2] presents a threshold signature scheme, where the signature made by each sub-secret holder can be verified. The document [4] is an improved scheme aiming at the document [3], and an effective threshold signature and verification scheme with fault tolerance is provided by utilizing the principle of multi-party calculation.

In this example, reference [4] is used]The application is not limited to this, and Privacy CA in this example is cited as document [4]]The system comprises a trusted center for selecting and calculating public parameters, n virtual CA members form a set of n participants, any t virtual CA members form an authorization subset, a system private key is used as a secret to be shared, a system sub private key is used as a sub secret, and a main part of a DT identity sub-certificate containing DT identity information, related public keys and other information is used as a message m. Sub-signature algorithm (calculating sig) according to threshold signature algorithm_i(m)), each dummyThe sub-signature of the CA member on the message m is the signature of the DT on the DT identity sub-certificate by the system sub-private key, and the DT can verify the signature in the DT identity sub-certificate according to the verification algorithm on the sub-signature. And DT receives t identity sub-cards and then performs a synthesis algorithm according to the threshold signature algorithm (document [4]]The algorithm for calculating the threshold signature (R, S) can be synthesized to obtain the signature of the management domain on DT in the DT identity certificate. And the verification algorithm of the synthesized signature in the domain terminal threshold signature algorithm can verify the signature in the DT identity certificate by using corresponding public parameters.

Preferably, the body part of the DT identity certificate that manages the domain signature on the DT includes both the DT's platform ID and the domain administrator ID, which can uniquely identify the domain administrator in the system, which may include the domain ID. The domain administrator ID may be distributed by the Privacy CA when registering to the Privacy CA to obtain the platform identity certificate, or may be generated according to a predetermined rule, for example, when the existing DT of the trusted domain is added into the system, the domain identifier is added on the basis of the original identifier to obtain the domain administrator ID. The same is true of the system administrator identification of the virtual CA member and the end user identification of the domain terminal below.

In this step, t virtual CA members can provide their own CA member identity certificate as an identity certificate when granting the DT identity sub-certificate to the DT. The DT can authenticate the identity of the corresponding virtual CA member based on the CA member identity certificate, and after all the t virtual CA certificates pass, the DT authenticates the signatures in the t DT identity sub-certificates. The process of registering the virtual CA member with the virtual CA to obtain the CA member identity certificate will be described in detail below, but in other embodiments, the DT may authenticate the identity of the virtual CA member according to the public key of the virtual CA member or the platform identity certificate provided by the virtual CA member, and the process of obtaining the CA member identity certificate by the virtual CA member is optional.

In this embodiment, a process of DT registration of a domain terminal to a trusted domain is shown in fig. 7, and includes:

step 410, a Trusted Computing Platform (TCP) of the domain terminal registers to a DT of a trusted domain with a platform identity certificate as an identity certificate and carries a TCP ID;

step 420, after the DT passes the domain terminal authentication, generating a terminal identity certificate of the domain terminal, where the terminal identity certificate includes a signature of the DT on the domain terminal;

the terminal identity certificate may conform to the x.509 standard, and the signed body part of the terminal identity certificate includes information about the domain terminal, such as a platform ID and an end user ID of the domain terminal, which may uniquely identify the end user in the system, and may include the domain ID. In this embodiment, the terminal identity certificate further includes information related to a certificate issuer DT, such as a platform ID and a domain administrator ID of the DT. The signature value part comprises the signature value of the management domain to the related information of the DT and the signature value of the DT to the related information of the domain terminal. In this way, the terminal identity certificate of the domain terminal can be used for remote authentication of the domain terminal by another trusted domain.

Step 430, the DT sends the terminal identity certificate to the domain terminal.

The process that the domain terminal applies for the terminal identity certificate from the DT based on the platform identity certificate can be realized by adopting a mode that an attestation party in a PCA system applies for an AIK certificate from a Privacy CA based on an EK certificate, at the moment, the domain terminal in the application is equivalent to the attestation party in the PCA system, the DT is equivalent to the Privacy CA in the PCA system, and the terminal identity certificate in the application is opposite to the AIK certificate, so that the signature of the management domain on the DT is increased. In another embodiment, the above process of the domain terminal applying for the terminal identity certificate from the DT based on the platform identity certificate may also use the proving party in the DAA system to apply for obtaining the secret data from the trusted issuing party based on the EK public key (f)₀,f₁) The C-L signature of (a) is implemented in the form of a DAA certificate (a, e, v), in which case, the domain terminal in the present application is equivalent to the proving party in the DAA system, and the DT is equivalent to the trusted issuing party in the DAA system, and the terminal identity certificate in the present application increases the signature of the management domain on the DT as compared with the DAA certificate.

The terminal identity certificate and the corresponding user information can be stored in a database corresponding to the trusted domain.

In this embodiment, a process of registering a virtual CA member with a virtual CA to obtain a CA member identity certificate may be included, as shown in fig. 8, the process is similar to the process of registering a DT with a virtual CA to obtain a DT identity certificate, and includes:

step 510, a virtual CA member registers application CA member identity certificates to other t or t-1 virtual CA members by taking the platform identity certificates as certificates;

because the virtual CA member is a participant sharing the secret in the (t, n) threshold system, the secret can be recovered as long as the secret shares or the pseudo shares of other t-1 virtual CA members are acquired, but when the virtual CA member registers to the virtual CA to acquire the CA member identity certificate, the registered virtual CA member can be specified to be excluded from the t virtual CA members, and at the moment, the virtual CA member is registered to the t virtual CA members.

Step 520, after the other t or t-1 virtual CA members pass the authentication of the virtual CA member, signing the virtual CA member by using the respectively stored system sub-private keys according to a threshold signature algorithm, and granting the obtained t or t-1 CA member identity sub-certificates to the virtual CA member;

step 530, after the validity of the signature of the virtual CA member by the system sub private key in the other t or t-1 virtual CA member identity sub-certificates is verified, synthesizing the CA member identity certificate of the virtual CA member according to the t or t-1 CA member identity sub-certificates, wherein the CA member identity certificate comprises the signature of the management domain (here, virtual CA) synthesized by a threshold signature algorithm on the virtual CA member.

The body part of the signature in the CA membership certificate may include the platform id of the virtual CA member, or both the platform id and the system administrator id of the virtual CA member.

The above embodiments mainly describe the process of implementing identity authentication through a certificate, and for authentication of integrity of a platform and the like, reference may be made to relevant standards, which are not described herein again.

In the above embodiment, the authentication method of the trusted computing system and the corresponding system adopt a distributed network topology based on the trusted domain, which is convenient for expansion to cope with integration of trusted domains of different scales.

In the above embodiment, the domain terminal obtains the terminal identity certificate from the DT of the trusted domain, and thus cross-domain authentication can be achieved without applying for a certificate for each trusted domain, which reduces network traffic, computational load, and storage space, and improves the efficiency of cross-domain authentication in the distributed network.

In the above embodiment, a virtual CA is used to replace a PrivacyCA to issue a DT identity sub-certificate to a DT, and a plurality of virtual CA members share a system private key according to a (t, n) threshold system, so that a false attack, a single-point DOS attack, and a failure can be avoided, and the PrivacyCA is allowed to grant the member platform identity certificates only when other members of the system register, and the following authentication process does not need the participation of the PrivacyCA, so that the PrivacyCA can be effectively protected, and the confidentiality of the system can be improved.

In the above embodiment, the user identifier of the member and the platform identifier can be bound in the certificate granted to the system member, so that the platform replacement attack can be effectively prevented.

There may be some variations to the above-described embodiments. In one variant, the management domain is constituted by PrivacyCA, excluding virtual CA. The establishment process of the virtual CA is not included in the corresponding certificate. The process that other members except PrivacyCA of the trusted computing system register to PrivacyCA to apply for the platform identity certificate can be reserved or cancelled. In the DT-to-PrivacyCA registration process, the DT may prove its identity with the EK certificate of its trusted module or its alias certificate as a platform identity certificate. Correspondingly, after the certification of the Privacy CA is passed, a DT identity certificate is directly granted to the DT, wherein the DT identity certificate contains the signature of the DT by the Privacy CA, and the private key in a pair of keys used by the Privacy CA for signing at the position can be the same as or different from that used by the signature in the platform identity certificate.

Members and their modules associated with the virtual CA may be eliminated from the trusted computing system. Accordingly, PrivacyCA includes:

And the DT certificate application module in the DT only needs to register in the management domain by taking the platform identity certificate of the DT as a certificate, and stores the DT identity certificate granted by PrivacyCA, and the DT identity certificate does not need to be synthesized according to the DT identity sub-certificate any more.

Because the domain terminal of the trusted domain can interact with other trusted domains only by applying for a terminal identity certificate from the DT of the domain, the method can also avoid that the Privacy CA becomes the performance bottleneck of the whole authentication system and is attacked by DoS to cause single-point failure of the system; and a certificate is not required to be applied for each trusted domain, so that network flow, calculation load and storage space are reduced, and the cross-domain authentication efficiency of the distributed network is improved. The structures of the DT identification certificate and the terminal identification certificate of this variation may be the same as those of the above-described embodiment.

The above embodiment is explained below using an application example. Referring to fig. 1, the distributed trusted computing system of the present application example includes 1 management domain and 2 trusted domains (trusted domain a and trusted domain B), where the management domain includes 6 virtual CA members (1 virtual CA member corresponds to one server) and 1 Privacy-CA, and 1 Web server may also be set in the management domain. The 6 virtual CA members form a virtual CA according to a (3,6) threshold system. Each trusted domain has 1 domain trusted party (DT) and a plurality of domain terminals, and the domain terminals may be mobile terminals such as PDAs, mobile phones, and notebook computers, and fixed terminals such as desktop computers, and the like.

Referring to fig. 9, the corresponding authentication method includes:

firstly, Privacy-CA generates a pair of public and private keys of the privately distributed system for platform identity certificate signature and a pair of system public and private keys for secret distribution, and discloses corresponding system parameters;

the two pairs of keys may be generated by RSA algorithm, but are not limited thereto, and the generated keys may be stored in a key pool.

secondly, a trusted module in a trusted computing platform of other members of the system generates a pair of platform identity keys, registers in Privacy-CA and carries an EK certificate and a platform identity public key;

step ③, after receiving the registration application and authenticating the legality of the other member platforms, the Privacy-CA grants the ID and the platform identity certificate of the other member platforms.

in the processes of the second step and the third step, the system members except the Privacy-CA, such as the domain terminal, DT and virtual CA members, acquire the platform identity certificate from the Privacy-CA application by using the EK certificate of the members as the certificate, and use the platform identity certificate as the identity certificate of the trusted computing platform in the system.

step four, secret sharing system private keys by a plurality of virtual CA members according to a threshold system (t, n) to form virtual CA, and secret distributing system private keys in the virtual CA members by the Privacy CA;

on an entity, Privacy CA may include one or two entities, such as one entity for issuing a platform identity certificate and one entity for generating and secretly distributing a system private key. The virtual CA member may be designated by Privacy CA, or may be selected by Privacy CA, which is a terminal application. The system key adopts a distributed management mode, so that the security of system key storage can be improved.

there are many ways to share secret and distribute secret based on (t, n) threshold system, an example is given below but not limited to the present application, in the above step ④, the virtual CA composed of n virtual CA members is used as B_iRepresents the ith virtual CA member, s_iDenotes the system sub-private key, i ═ 1, …, n, assigned by the ith virtual CA member.

Privacy CA obtains S according to the following formula_iAnd distributed to the respective virtual CA members:

h(x)＝α_t-1x^t-1+…+α₁x+α₀modφ (4-1)

S_i＝h(x_i)modφx_i＝i,i＝1,...,n (4-2)

wherein the prime phi is greater than the maximum possible system private key S and the total number of virtual CA members n, and α₀modф＝h(0)＝S，α_t-1,...,α₁Random coefficients and these coefficients are kept secret; x is the number of_iIs the ith sub-private key S_iCorresponding variable, in this example, x_iIs equal to i.

Let A be any subset of n virtual CA members and include t virtual CA members in A ≧ t, mark the system sub-private key of the r-th virtual CA member in subset A as ≧ tr＝1…t，

According to the formula (4-2), there are:

t virtual CA membersSaved system sub-private keyAnd the system private key S satisfies the following conditions:

wherein,

is the r-th variable in the subset consisting of t variables in the variable set corresponding to the n sub-private keys;is the jth variable in the subset consisting of t variables in the variable set corresponding to the n sub-private keys.

step five, the DT takes the platform identity certificate as the proof, and registers to t members of the n virtual CA members at least to obtain DT identity sub-certificates;

assuming that n-6 and t-3, taking domain trusted party John as an example, John submits applications to at least 3 of 6 trusted virtual CA members.

after t virtual CA members authenticate that the DT platform is legal, a DT identity sub-certificate is respectively granted to the DT, each DT identity sub-certificate comprises a signature of the DT by a system sub-private key stored by the virtual CA member based on a threshold signature algorithm, after the validity verification of the signature in the DT identity sub-certificate by the DT is passed, a DT identity certificate is synthesized according to the t DT identity sub-certificates, and the DT identity certificate comprises a signature of the DT by the virtual CA synthesized by the threshold signature algorithm.

The virtual CA member can register with other virtual CA members in a similar way to obtain a CA member identity certificate and provides the CA member identity certificate for the DT in the DT registration process, at the moment, the DT authenticates the identity of the virtual CA member based on the CA member identity certificate, and then carries out validity verification on the signature in the DT identity sub-certificate after the identity certificate passes. The credibility of the virtual CA membership authentication can be improved by using the CA membership certificate authentication.

seventhly, the domain terminal wants to access the network resource of the trusted domain, registers and applies for a terminal identity certificate to DT of the trusted domain, the domain terminal and the DT mutually authenticate the legality of the certificate of the other party, the DT grants the terminal identity certificate to the domain terminal, and the domain terminal stores the terminal identity certificate;

the body part of the signature in the terminal identity certificate may include both the platform identification and the end user identification of the domain terminal.

and step ⑧, when the domain terminal accesses another domain terminal of the non-local trusted domain, submitting the terminal identity certificate, and after the remote terminal (namely, another domain terminal) is authenticated to be legal, also submitting the terminal identity certificate of the remote terminal, and after the domain terminal is authenticated to be legal, accessing the trusted domain network to obtain resource service.

The domain terminals may negotiate an authorization key together in the above-described authentication process to encrypt the interacted data.

When the existing distributed network user accesses different trusted domains, access authentication needs to be carried out again, and the process not only requires strong expansibility, trusted authentication and small delay. The distributed network cross-domain authentication method can effectively prevent unauthorized users from entering the network, and enables authorized users to be quickly authenticated so as to obtain resource services in different regions.

It will be understood by those skilled in the art that all or part of the steps of the above methods may be implemented by instructing the relevant hardware through a program, and the program may be stored in a computer readable storage medium, such as a read-only memory, a magnetic or optical disk, and the like. Alternatively, all or part of the steps of the foregoing embodiments may also be implemented by using one or more integrated circuits, and accordingly, each module/unit in the foregoing embodiments may be implemented in the form of hardware, and may also be implemented in the form of a software functional module. The present application is not limited to any specific form of hardware or software combination.

The above description is only a preferred embodiment of the present application and is not intended to limit the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method of authentication of a trusted computing system, the trusted computing system comprising an administrative domain and a plurality of trusted domains, members of the trusted domains comprising a domain trusted party (DT) and a domain terminal, the method comprising:

2. The authentication method of claim 1, wherein:

3. The authentication method of claim 1, wherein:

4. The authentication method of claim 3, wherein:

5. The authentication method of claim 4, wherein:

6. An authentication method according to claim 2 or 3 or 4 or 5, characterized in that:

7. The authentication method of claim 3, wherein:

8. The authentication method according to claim 1 or 2 or 3 or 4 or 5 or 7, characterized in that:

9. The authentication method of claim 8, wherein:

10. An authentication method according to any one of claims 1-5, 7, 9, characterized by:

11. A trusted computing system based on a distributed network environment, the trusted computing system comprising an administrative domain and a trusted domain, members of the trusted domain comprising a domain trusted party (DT) and a domain terminal, characterized by:

the domain terminal includes:

the DT includes:

12. The trusted computing system of claim 11, wherein:

the PrivacyCA includes:

13. The trusted computing system of claim 11, wherein:

the PrivacyCA includes:

14. The trusted computing system of claim 13, wherein:

15. The trusted computing system of claim 14, wherein:

each virtual CA member further comprises:

16. A trusted computing system as claimed in claim 12, 13, 14 or 15, wherein:

17. The trusted computing system of claim 13, wherein:

18. A trusted computing system as claimed in any one of claims 11 to 15 and 17, wherein:

the PrivacyCA includes:

the other members of the trusted computing system further include:

19. The trusted computing system of claim 18, wherein:

20. A trusted computing system as claimed in any one of claims 11 to 15, 17, and 19, wherein:

21. A virtual Certificate Authority (CA) member in a trusted computing system based on a distributed network environment, characterized by:

22. The virtual certificate CA member of claim 21, further comprising:

the CA member certificate issuing module is used for receiving the registration of another virtual CA member, signing the other virtual CA member by using a self-stored system sub-private key after the other virtual CA member passes the authentication, and granting the obtained CA member identity sub-certificate to the other virtual CA member;

23. A domain trusted party (DT) in a trusted computing system based on a distributed network environment, the DT comprising:

24. The domain trusted party of claim 23, wherein:

the DT certificate application module registers to t virtual CA members respectively to obtain t DT identity sub-certificates, and synthesizes a DT identity certificate according to the t DT identity sub-certificates after the legality of the signature of the DT by a system sub-private key in the t DT identity sub-certificates is authenticated, wherein the DT identity certificate comprises the signature of the DT by the virtual CA synthesized by a threshold signature algorithm.

25. The domain trusted party of claim 24, wherein:

and the DT certificate application module receives the corresponding CA member identity certificate when receiving the t DT identity sub-certificates, firstly performs identity authentication on the corresponding virtual CA members based on the CA member identity certificate, and then performs validity authentication on the signature in the DT identity sub-certificates after the authentication is passed.

26. The domain trusted party of claim 23, 24 or 25, wherein:

the main part of the signature of the DT on the domain terminal in the terminal identity certificate granted to the domain terminal by the terminal certificate issuing module comprises the terminal user identification and the platform identification of the domain terminal.

27. The domain trusted party of claim 24 or 25, wherein:

and the main body part of the signature in the DT identity certificate synthesized by the DT certificate application module comprises the domain administrator identification and the platform identification of the DT.

28. A domain terminal in a trusted computing system based on a distributed network environment, characterized in that: the domain terminal includes:

the terminal certificate application module is used for registering a DT (trusted domain) which is certified by a platform identity certificate of a terminal in the domain, and storing a terminal identity certificate granted by the DT, wherein the terminal identity certificate comprises a signature of a management domain on the DT and a signature of the DT on the domain terminal;

and the remote authentication module is used for providing terminal identity certificates for the domain terminals of other trusted domains when interacting with the domain terminals of other trusted domains, and performing identity authentication on the domain terminals of other trusted domains based on the terminal identity certificates of the domain terminals of other trusted domains.

29. The domain terminal of claim 28, wherein:

and after the terminal certificate application module receives the DT identity certificate and the DT identity certificate, the DT identity certificate is authenticated based on the DT identity certificate, and the terminal identity certificate is stored after the DT identity certificate passes the authentication.