Application verification method and apparatus
By verifying multiple trusted applications in groups and issuing unified identity credentials on the authentication server, the trust problem between multiple trusted applications is solved, and the establishment of secure channels and the compatible interconnection of heterogeneous TEE platforms are realized.
Patent Information
- Application Number
- PCT/CN2025/105951
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-01
- Filing Date
- 2025-06-30
- Publication Date
- 2026-01-08
AI Technical Summary
Existing TEE solutions' remote verification capabilities are limited to solving the trust problem of a single trusted application, and cannot effectively solve the mutual trust problem between multiple trusted applications.
By proving that the server uses trusted application grouping verification, multiple related trusted applications are grouped into the same group, and a unified format identity credential is issued to the trusted applications in the group for identity authentication and secure channel establishment.
It enables mutual trust between multiple trusted applications, supports compatibility and interoperability of heterogeneous TEE platforms, and ensures secure communication between applications.
Smart Images

Figure CN2025105951_08012026_PF_FP_ABST
Abstract
Description
Application verification method and device
[0001] The present application claims priority to the Chinese Patent Application No. 202410874061.4, filed on July 1, 2024, and entitled "Application Verification Method and Device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD
[0002] Embodiments of the present specification relate to the field of computer technology, in particular, to an application verification method and device. BACKGROUND
[0003] Remote attestation is a common way to verify the identity of a trusted application (TA), but the capabilities of remote attestation of various TEE (Trusted Execution Environment) schemes are currently limited to solving the trust problem of a specified application. However, in actual business scenarios, multiple trusted applications often need to cooperate to meet business needs.
[0004] Therefore, a reasonable and reliable solution is needed to solve the problem of mutual trust between multiple associated trusted applications. SUMMARY
[0005] Embodiments of the present specification provide an application verification method and device, so that the attestation server adopts a trusted application grouping verification manner, can group multiple associated trusted applications into the same group, and issue a uniform format of identity credentials for the trusted applications in the same group, for identity authentication when the trusted applications in the same group communicate, which can solve the problem of mutual trust between multiple associated trusted applications.
[0006] In a first aspect, the embodiments of the present specification provide an application verification method, executed by an attestation server, comprising: receiving a first acquisition request for an identity credential sent by a first application in a target group; wherein the target group includes multiple associated trusted applications, and the first acquisition request includes an application identity proof of the first application; using a pre-stored application verification rule of the first application in a group verification rule of the target group, verifying the application identity proof; in response to the application identity proof passing the verification, generating and returning a first identity credential, the first identity credential including at least part of the information in the group identifier of the target group and the application identity proof, for identity authentication when the first application communicates with other applications in the target group.
[0007] In some embodiments, before receiving the first obtaining request for the identity credential sent by any first application within the target group, the method further comprises: receiving a creation request of an administrator user for the target group, wherein the creation request comprises attribute information and application verification rules of each of a plurality of applications associated with the target group, and the plurality of applications comprise the plurality of trusted applications; assigning the group identifier to the target group; and generating and storing the group verification rules, wherein the group verification rules comprise the group identifier and the attribute information and application verification rules of each of the plurality of applications.
[0008] In some embodiments, the method further comprises: generating a first key for the target group, wherein the first key is used to establish a secure channel when the applications within the target group communicate with each other; and storing the first key in association with the group identifier.
[0009] In some embodiments, the method further comprises: for each developer of each application within the target group, generating a second key corresponding to the developer, wherein the second key is used to establish a secure channel when the applications developed by the developer within the target group communicate with each other; and storing the second key in association with the group identifier and the developer.
[0010] In some embodiments, the plurality of trusted applications are distributed in a plurality of trusted execution environment (TEE) platforms.
[0011] In some embodiments, the target group further comprises a plurality of untrusted applications associated with the plurality of trusted applications.
[0012] In some embodiments, when the first application is a trusted application, the application identity proof comprises a remote attestation report; and when the first application is an untrusted application, the application identity proof comprises a certificate in X.509 format.
[0013] In some embodiments, the first identity credential is in any one of the following formats: X.509 format, JWT format.
[0014] In some embodiments, the application verification rules of the first application comprise a real application fingerprint, and the application identity proof comprises an application fingerprint to be verified; and the verifying the application identity proof comprises: comparing the real application fingerprint with the application fingerprint to be verified.
[0015] In some embodiments, the application identity proof further comprises at least one of the following to be verified: an application version number, an application developer signature.
[0016] In some embodiments, the returning the first identity credential comprises: adding a signature to the first identity credential, and returning the first identity credential with the added signature.
[0017] In some embodiments, the first obtaining request and the first identity credential further comprise a first public key of the first application; the first public key in the first identity credential is used to establish a secure channel when the first application communicates with the other applications.
[0018] In some embodiments, the target group is configured with a first key; when the first identity credential is returned, the first key is also returned, which is used to establish a secure channel when the first application communicates with the other applications.
[0019] In some embodiments, the developers of the respective applications in the target group correspond to second keys; when the first identity credential is returned, the second key corresponding to the developer of the first application is also returned, which is used to establish a secure channel when the first application communicates with other applications developed by the developer in the target group.
[0020] In some embodiments, the method further comprises: receiving a second obtaining request for a group authentication report of the target group sent by a device of a challenging party; in response to the second obtaining request, obtaining identity information of respective applications in the target group, the identity information being determined based on the application identity proof of the corresponding application; generating and returning a group authentication report, which comprises the identity information of the respective applications, for verifying the respective applications.
[0021] In some embodiments, the group authentication report further comprises identity information of the proof server, for verifying the proof server.
[0022] In a second aspect, the embodiments of the present specification provide an application verification method, executed by any first application in a target group, the target group comprising a plurality of associated trusted applications, the method comprising: sending a first obtaining request for an identity credential to a proof server, wherein the first obtaining request comprises an application identity proof of the first application; receiving a first identity credential returned by the proof server, which is generated by the proof server after the application identity proof passes the application verification rule of the first application, the application verification rule being included in the group verification rule of the target group pre-stored in the proof server; the first identity credential comprises at least part of the information in the group identifier of the target group and the application identity proof, which is used for identity authentication when the first application communicates with other applications in the target group.
[0023] In some embodiments, the first obtaining request and the first identity credential further comprise a first public key of the first application; the method further comprises: sending an obtaining request for first data to a second application in the target group, wherein the first identity credential is comprised; receiving ciphertext first data returned by the second application and a second identity credential of the second application, the ciphertext first data being obtained by the second application from the first data by encryption using the first public key after passing the first identity credential verification; and decrypting the ciphertext first data using a first private key of the first application after passing the second identity credential verification.
[0024] In some embodiments, the method further comprises: receiving the first key of the target group returned by the attestation server; sending an obtaining request for first data to a second application in the target group, wherein the first identity credential is comprised; receiving ciphertext first data returned by the second application and a second identity credential of the second application, the ciphertext first data being obtained by the second application from the first data by encryption using the first key on the second application side after passing the first identity credential verification; and decrypting the ciphertext first data using the first key after passing the second identity credential verification.
[0025] In some embodiments, the method further comprises: receiving a second key corresponding to a developer of the first application returned by the attestation server; sending an obtaining request for second data to a third application developed by the developer in the target group, wherein the first identity credential is comprised; receiving ciphertext second data returned by the third application and a third identity credential of the third application, the ciphertext second data being obtained by the third application from the second data by encryption using the second key on the third application side after passing the first identity credential verification; and decrypting the ciphertext second data using the second key after passing the third identity credential verification.
[0026] In a third aspect, an embodiment of the present specification provides an application verification apparatus applied to a proof server, comprising: a receiving unit configured to receive a first acquisition request for an identity credential sent by any first application in a target group; wherein the target group comprises a plurality of trusted applications associated, and the first acquisition request comprises an application identity proof of the first application; a checking unit configured to check the application identity proof by using an application checking rule of the first application in a group checking rule of the target group stored in advance; and a generating unit configured to generate and return a first identity credential in response to the application identity proof passing the check, wherein the first identity credential comprises at least part of information in the application identity proof and a group identifier of the target group, and is used for identity authentication when the first application communicates with other applications in the target group.
[0027] In a fourth aspect, an embodiment of the present specification provides an application verification apparatus applied to any first application in a target group, wherein the target group comprises a plurality of trusted applications associated, and the apparatus comprises: a sending unit configured to send a first acquisition request for an identity credential to a proof server, wherein the first acquisition request comprises an application identity proof of the first application; and a receiving unit configured to receive a first identity credential returned by the proof server, wherein the first identity credential is generated by the proof server after the application identity proof passes the check by using an application checking rule of the first application, and the application checking rule is included in a group checking rule of the target group stored in advance by the proof server; and the first identity credential comprises at least part of information in the application identity proof and a group identifier of the target group, and is used for identity authentication when the first application communicates with other applications in the target group.
[0028] In a fifth aspect, an embodiment of the present specification provides a computer readable storage medium having a computer program stored thereon, wherein when the computer program is executed in a computer, the computer executes the method described in any implementation manner of the first aspect and the second aspect.
[0029] In a sixth aspect, an embodiment of the present specification provides a computing device comprising a memory and a processor, wherein the memory has executable code stored therein, and the processor executes the executable code to implement the method described in any implementation manner of the first aspect and the second aspect.
[0030] In a seventh aspect, an embodiment of the present specification provides a computer program product comprising computer programs / instructions, wherein the computer programs / instructions are executed by a processor to implement the method described in any implementation manner of the first aspect and the second aspect.
[0031] The above-mentioned embodiments of the present specification provide a scheme, wherein the attestation server receives a first obtaining request for an identity credential sent by any first application in a target group; wherein the target group comprises a plurality of trusted applications associated, and the first obtaining request comprises an application identity certificate of the first application. Then, the attestation server generates and returns a first identity credential after the application identity certificate is verified by using the application verification rule of the first application in the group verification rule of the target group stored in advance, the first identity credential comprising at least part of the information in the application identity certificate and the group identifier of the target group, for identity authentication when the first application communicates with other applications in the target group. Thus, the scheme enables the attestation server to use the trusted application group verification method to group the plurality of trusted applications associated into the same group, and issue identity credentials in a unified format for the trusted applications in the same group, for identity authentication when the trusted applications in the same group communicate with each other, thereby solving the problem of mutual trust among the plurality of trusted applications associated. BRIEF DESCRIPTION OF DRAWINGS
[0032] In order to more clearly illustrate the technical solutions of the multiple embodiments disclosed in the present specification, the drawings required to be used in the embodiment description will be briefly introduced below. Obviously, the drawings in the following description are only a part of the multiple embodiments disclosed in the present specification, and other drawings can also be obtained by those skilled in the art without creative effort on the basis of these drawings.
[0033] FIG. 1 is a schematic diagram of an application scenario to which the embodiments of the present specification can be applied;
[0034] FIG. 2 is a flowchart of a target group creation process in the embodiments of the present specification;
[0035] FIG. 3 is a timing diagram of an application verification method in the embodiments of the present specification;
[0036] FIG. 4 is a timing diagram of a group authentication report generation process of a target group in the embodiments of the present specification;
[0037] FIG. 5 is a structural schematic diagram of an application verification device in the embodiments of the present specification;
[0038] FIG. 6 is a structural schematic diagram of an application verification device in the embodiments of the present specification. DETAILED DESCRIPTION
[0039] The present specification will be further described in detail with reference to the drawings and embodiments. It can be understood that the specific embodiments described herein merely serve to explain the related application, and are not limitations on the application. The described embodiments are only a part of the embodiments of the present specification, and not all the embodiments. Based on the embodiments in the present specification, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.
[0040] It should be noted that, for the convenience of description, only the parts related to the application are shown in the drawings. The embodiments in the present specification and the features in the embodiments can be combined with each other without conflict. In addition, the words "first", "second", "third" and the like in the embodiments of the present specification are only for information distinction, and do not have any limiting effect.
[0041] As described above, remote attestation is a common way to verify the identity of trusted applications, but the capabilities of remote attestation of various TEE schemes are currently limited to solving the trust problem of specified applications. However, in actual business scenarios, multiple trusted applications often need to cooperate to meet business needs.
[0042] The application verification scheme provided by the embodiments of the present specification enables the attestation server to use trusted application group verification to group multiple associated trusted applications into the same group, issue identity credentials in a unified format for trusted applications in the same group, and use the identity credentials for identity authentication between trusted applications in the same group. This can solve the problem of mutual trust between multiple associated trusted applications.
[0043] FIG. 1 is a schematic diagram of an application scenario to which the embodiments of the present specification can be applied. The application scenario involves an attestation server 101, a device 102 used by an administrator user of the attestation server 101, multiple associated trusted applications (such as trusted applications TA1, TA2, … TAn shown in FIG. 1), and a device 103 used by a challenger. The attestation server 101 can be a third-party remote attestation agent service, which can be referred to as a unified attestation service (UAS). The multiple trusted applications correspond to the same business scenario, in which the multiple trusted applications need to cooperate to meet business needs. The same business scenario can be any scenario, for example, a data sharing or privacy computing scenario, which is not limited here. The challenger can be, for example, an institution (such as an enterprise) that has the business needs.
[0044] In practice, the plurality of trusted applications can be distributed in a plurality of TEE platforms. Specifically, any one of the plurality of TEE platforms can be deployed with one or more of the plurality of trusted applications. In addition, an SDK (Software Development Kit) of the attestation server 101 can be run on the plurality of TEE platforms, based on which the heterogeneous compatibility and interconnection of the plurality of TEE platforms can be achieved.
[0045] In order to enable the plurality of trusted applications to trust each other, an administrator user of the attestation server 101 can group the plurality of trusted applications into a target group, and send a creation request for the target group to the attestation server 101 through the device 102, which includes the attribute information and the application verification rule of each of the associated trusted applications TA1, TA2, …, TAn. Then, the attestation server 101 can generate and store the group verification rule of the target group according to the creation request.
[0046] Next, the specific creation process of the target group will be described in conjunction with FIG. 2. FIG. 2 is a flowchart of the creation process of the target group in an embodiment of the present specification. The creation process is performed by the attestation server 101, and includes the following steps S201-S205.
[0047] As shown in FIG. 2, in step S201, a creation request for a target group is received from an administrator user, which includes the attribute information and the application verification rule of each of the associated plurality of applications, including the plurality of trusted applications.
[0048] The attribute information of the application can include but is not limited to the application name. The application verification rule can include the real application fingerprint. Further, the application verification rule can also include the real application version number and / or the application developer signature, etc. It should be noted that the application fingerprint can uniquely indicate its corresponding application. In one example, the application fingerprint can be calculated according to the program code of its corresponding application.
[0049] In practice, as described above, the same business scenario can also involve a number of non-trusted applications, and the plurality of trusted applications and the number of non-trusted applications can be required to work together to meet the business requirements in the same business scenario. In such a case, the plurality of applications can also include the number of non-trusted applications. Thus, the group management can not only support the management of trusted applications, but also support the management of non-trusted applications.
[0050] Next, in step S203, a group identifier is assigned to the target group.
[0051] The identity generation algorithm can be deployed on the attestation server 101 to generate a unique identity for the target group.
[0052] It should be noted that by assigning the target group an identity by the attestation server 101 instead of by the administrator user, the administrator user is unable to create a malicious configuration group with the same identity.
[0053] Next, in step S205, the group verification rule of the target group is generated and stored, including the group identity of the target group and the attribute information and application verification rule of each of the plurality of applications.
[0054] In one example, the creation request can further include a group name of the target group. In this case, the group verification rule of the target group can further include the group name.
[0055] In practical applications, different trust dimensions can be supported for establishing secure channels between applications in the target group. A single trust dimension can be, for example, a group identity, an application name, or a developer, etc.
[0056] As an example, when secure channels are established between applications in the target group based on a group identity, the applications in the target group can share the same key. Specifically, the attestation server 101 can generate a first key for the target group and store the first key in association with the group identity of the target group. The first key is used to establish secure channels when the applications in the target group communicate with each other.
[0057] When secure channels are established between applications in the target group based on a developer, the applications in the target group developed by the same developer can share the same key. Specifically, for each developer of the applications in the target group, the attestation server 101 can generate a second key corresponding to the developer and store the second key in association with the group identity of the target group and the developer. The second key is used to establish secure channels when the applications in the target group developed by the developer communicate with each other.
[0058] When secure channels are established between applications in the target group based on an application name, any two applications in the target group that need to communicate can use the public key of the other party to establish a secure channel.
[0059] Figure 2 corresponds to the embodiments provided by the scheme, so that the administrator user can register the group verification rule of the target group to the attestation service 101 by creating the target group in the attestation service 101. Subsequently, the attestation service 101 can implement the trusted application group verification based on the group verification rule.
[0060] Continuing to refer to Figure 1, any application in the target group can provide the application identity attestation to the attestation service 101 to make the attestation service 101 issue the identity credential, as shown in Figure 1. Wherein, the attestation service 101 can generate and return the identity credential after verifying the application identity attestation by the application verification rule of the application in the group verification rule of the target group, so that the identity credential is used for identity authentication when the application communicates with other applications in the target group.
[0061] Next, the issuance process of the identity credential is introduced in combination with Figure 3. Figure 3 is a timing diagram of the application verification method in the embodiments of the present specification. The method includes the following steps S301-S307.
[0062] As shown in Figure 3, in step S301, any first application in the target group sends a first acquisition request for the identity credential to the attestation service 101; wherein the target group includes a plurality of associated trusted applications, and the first acquisition request includes the application identity attestation of the first application.
[0063] Wherein, the first acquisition request can further include the first public key of the first application. Further, the first acquisition request can include the public key certificate of the first application, and the first public key is contained in the public key certificate. The application identity attestation of the first application can include a plurality of application verification attributes. The application verification attribute can be understood as an attribute to be verified by the application. The plurality of application verification attributes can include the application fingerprint to be verified. Further, the plurality of application verification attributes can further include the application version number and / or the application developer signature to be verified, etc.
[0064] It should be noted that in the case where the target group further includes a plurality of non-trusted applications as described above, the first application is a trusted application or a non-trusted application. When the first application is a trusted application, the application identity attestation of the first application can include a remote attestation report (RAR). When the first application is a non-trusted application, the application identity attestation of the first application can include an X.509 format certificate. In practice, the remote attestation report is a report used to verify the security and trustworthiness of a remote system in a network environment. X.509 is a widely used digital certificate standard for verifying the identity of entities on the Internet. Since the remote attestation report and the X.509 certificate format are well-known techniques in the art, they will not be described in detail here.
[0065] Then, in step S303, the attestation service 101 checks the application identity attestation by using the application check rule of the first application applied in the pre-stored group check rule of the target group.
[0066] Specifically, the application check attributes in the application identity attestation of the first application can be checked by using the application check rule of the first application. It should be noted that, in order to facilitate the checking operation, the application identity attestation of the first application can be parsed to obtain a parsing result, and then the parsing result is checked by using the application check rule of the first application, such as checking the application check attributes in the parsing result.
[0067] In the process of checking the application identity attestation of the first application, when the application check rule of the first application includes a real application fingerprint, and the application identity attestation includes an application fingerprint to be checked, the real application fingerprint and the application fingerprint to be checked can be compared. Further, when the application check rule further includes a real application version number, and the application identity attestation further includes an application version number to be checked, the real application version number and the application version number to be checked can be compared; and / or, when the application check rule further includes a real application developer signature, and the application identity attestation further includes an application developer signature to be checked, the real application developer signature and the application developer signature to be checked can be compared.
[0068] After each application check attribute in the application identity attestation of the first application is checked, it can be determined that the application identity attestation is checked, and then step S305 is executed. If one or more of the application check attributes fail, it can be determined that the application identity attestation fails, and then a check failure message is returned to the first application.
[0069] Further, in order to facilitate the challenge party to collectively verify each application in the target group, after it is determined that the application identity attestation of the first application is checked, the application identity attestation or the parsing result of the application identity attestation can be stored as the identity information of the first application, to be used for generating a group authentication report of the target group. In this way, the challenge party can collectively verify each application according to the identity information of each application in the group authentication report.
[0070] In step S305, the attestation service 101 generates a first identity credential in response to the application identity attestation passing the check, the first identity credential including at least part of the information in the application identity attestation and the group identifier of the target group, for identity authentication when the first application communicates with other applications in the target group.
[0071] The at least part of the information can include a verification attribute of each application. The first identity credential can further include an application authentication time, etc. It should be noted that when the first obtaining request further includes a first public key of the first application, the first identity credential can further include the first public key. Further, when the first obtaining request includes a public key certificate including the first public key, the first identity credential can include the public key certificate. In one example, the first public key in the first identity credential can be used to establish a secure channel when the first application communicates with other applications in the target group. For example, when a secure channel is supported between applications in the target group based on an application name, the first public key in the first identity credential is used to establish a secure channel when the first application communicates with other applications in the target group. In addition, when a secure channel is supported between applications in the target group based on a developer, but a secure channel based on a group identifier is not supported, since applications developed by the same developer in the target group can share the same key, while applications developed by different developers do not share the same key, the first public key in the first identity credential can be used to establish a secure channel when the first application communicates with other applications in the target group having different developers from the first application.
[0072] The format of the first identity credential can be an X.509 format or a JWT (JSON Web Token) format, etc. The JWT is an open standard that defines a compact and self-contained manner for securely transmitting information between parties in the form of a JSON object. It should be noted that the identity credential format of each application in the target group is uniform, and by issuing the identity credential in a uniform format to each application, the applications can trust each other and securely communicate.
[0073] Next, in step S307, the attestation service 101 returns the first identity credential to the first application.
[0074] Specifically, the attestation server 101 can add a signature to the first identity credential, such as adding a signature to the first identity credential by using a private key of the attestation server 101, and then return the first identity credential with the added signature to the first application. After receiving the first identity credential with the added signature, the first application can verify the first identity credential. For example, the first application can verify the signature of the first identity credential, such as verifying the signature of the first identity credential by using a public key of the attestation server 101. In one example, the first application pre-stores the public key, and the first application can verify the signature of the first identity credential by using the pre-stored public key. In another example, the attestation server 101 can return the public key to the first application at the same time when the attestation server 101 returns the first identity credential to the first application, so that the first application verifies the signature of the first identity credential by using the public key. Further, the attestation server 101 can return a remote attestation report of the attestation server 101 to the first application at the same time when the attestation server 101 returns the first identity credential to the first application, and the public key is included in the remote attestation report. The first application can locally store a verification rule of the attestation server 101, and the first application can verify the signature of the first identity credential by using the public key in the remote attestation report after verifying the remote attestation report by using the verification rule. If the verification of the signature of the first identity credential is passed, the first application can know that the first identity credential is not tampered and is trusted, and thus the first application can use the first identity credential to communicate with other applications in the target group.
[0075] According to the foregoing description, the secure channel can be established between the applications in the target group based on the group identifier, the application name, or the developer. When the secure channel is established between the applications in the target group based on the group identifier, the attestation server 101 can return a first key of the target group to the first application at the same time when the attestation server 101 returns the first identity credential to the first application, so as to establish the secure channel when the first application communicates with other applications in the target group. When the secure channel is established between the applications in the target group based on the developer, the attestation server 101 can return a second key corresponding to the developer of the first application to the first application at the same time when the attestation server 101 returns the first identity credential to the first application, so as to establish the secure channel when the first application communicates with other applications in the target group developed by the developer.
[0076] Next, the establishment of the secure channel is illustrated by examples.
[0077] In one example, the first identity credential of the first application comprises a first public key of the first application. When the first application needs to acquire first data from a second application within the target group, the first application can send an acquisition request for the first data to the second application, which comprises but is not limited to the first identity credential. Then, the first application can receive the ciphertext first data returned by the second application and a second identity credential of the second application, the ciphertext first data being obtained by the second application from encrypting the first data using the first public key after passing the verification of the first identity credential. Wherein, the second application can verify the group identifier in the first identity credential when verifying the first identity credential, and / or verify the signature added in the first identity credential. Then, the first application can decrypt the ciphertext first data using its own first private key after passing the verification of the second identity credential.
[0078] It should be noted that, in the case where the second application generates a signature for the ciphertext first data, such as generating a signature for the ciphertext first data using the second private key of the second application, and returns the signature to the first application, the first application also needs to verify the signature, such as verifying the signature using the second public key of the second application included in the second identity credential. The first application can decrypt the ciphertext first data using its own first private key after passing the verification of both the second identity credential and the signature.
[0079] In another example, the first application receives the first identity credential returned by the attestation server 101 and a first key of the target group. When the first application needs to acquire first data from a second application within the target group, the first application can send an acquisition request for the first data to the second application, which comprises but is not limited to the first identity credential. Then, the first application can receive the ciphertext first data returned by the second application and a second identity credential of the second application, the ciphertext first data being obtained by the second application from encrypting the first data using the first key on the second application side after passing the verification of the first identity credential. Then, the first application can decrypt the ciphertext first data using the first key after passing the verification of the second identity credential.
[0080] In yet another example, the first application receives the first identity credential returned by the attestation server 101 and a second key corresponding to the developer of the first application. When the first application needs to acquire second data from a third application developed by the developer within the target group, the first application can send an acquisition request for the second data to the third application, which comprises but is not limited to the first identity credential. Then, the first application can receive the ciphertext second data returned by the third application and a third identity credential of the third application, the ciphertext second data being obtained by the third application from encrypting the second data using the second key on the third application side after passing the verification of the first identity credential. Then, the first application can decrypt the ciphertext second data using the second key after passing the verification of the third identity credential.
[0081] It should be noted that the first data and the second data mentioned above can be any data required by the first application in the same service scenario as described above, and the content of the first data and the second data is not limited here.
[0082] The scheme provided by the embodiment corresponding to FIG. 3 enables the attestation server 101 to group the associated multiple trusted applications into the same group by using the trusted application group verification manner, and issue identity credentials in a unified format for the trusted applications in the same group, so as to be used for identity authentication when the trusted applications in the same group communicate with each other, thereby solving the problem of mutual trust among the associated multiple trusted applications.
[0083] In addition, as described above, the multiple trusted applications can be distributed in multiple TEE platforms, and the SDK of the attestation server 101 can be run on the multiple TEE platforms. In this case, the scheme provided by the embodiment corresponding to FIG. 3 can realize heterogeneous compatibility and interconnection and intercommunication of the multiple TEE platforms based on the SDK, and also enable the attestation server 101 to verify the application identity proofs (such as remote attestation reports) of the trusted applications running on different TEE platforms.
[0084] Referring back to FIG. 1, it is shown that the challenge party can collectively verify the applications in the target group. Specifically, as shown in FIG. 1, the challenge party can send, through the device 103, a second acquisition request for a group authentication report of the target group to the attestation server 101. Then, the attestation server 101 can generate and return the group authentication report of the target group, which includes the identity information of each application in the target group. Thus, on the side of the challenge party, the applications in the target group can be collectively verified according to the group authentication report.
[0085] Next, the generation process of the group authentication report will be further described in combination with FIG. 4. FIG. 4 is a timing diagram of the generation process of the group authentication report of the target group in the embodiment of the present specification. The generation process includes steps S401-S407 as shown below.
[0086] As shown in FIG. 4, in step S401, the device 103 of the challenge party sends a second acquisition request for a group authentication report of the target group to the attestation server 101.
[0087] The second acquisition request includes but is not limited to the group identifier of the target group.
[0088] Next, in step S403, the attestation server 101 acquires the identity information of each application in the target group in response to the second acquisition request, which is determined based on the application identity proof of the corresponding application.
[0089] According to the foregoing description, for any application in the target group, the identity information of the application can be the application identity certificate of the application or a resolution result of the application identity certificate, and the attestation server 101 can store the identity information after verifying the application identity certificate. Based on this, the attestation server 101 can obtain the identity information of each application in the target group stored locally.
[0090] Then, in step S405, a group attestation report is generated, which includes the identity information of each application in the target group, for verifying the applications.
[0091] In practice, the challenger can also verify the attestation server 101. Based on this, the group attestation report can also include the identity information of the attestation server 101. The identity information can be a remote attestation report of the attestation server 101, or a resolution result of the remote attestation report. Further, the group attestation report can also include other to-be-verified information (such as group shared key and certificate information, authorized user identity information, etc.) bound by the target group. In addition, the group attestation report can be obtained based on the way proposed by the RATS (Remote ATtestation procedureS) Composite device model.
[0092] Then, in step S407, the attestation server 101 returns the group attestation report to the device 103.
[0093] After the device 103 receives the group attestation report of the target group, the challenger can use the device 103 to collectively verify the applications in the target group according to the group attestation report. As an example, the device 103 can store verification rules negotiated by the challenger and the authorities to which the applications in the target group belong, and can use the verification rules to verify the identity information of the applications in the group attestation report. Further, the device 103 can also store verification rules negotiated by the challenger and the authorities to which the attestation server 101 belongs, and when the group attestation report also includes the identity information of the attestation server 101, the verification rules can be used to verify the identity information.
[0094] The challenger can comprehensively cover the applications in the target group by verifying the group attestation report of the target group. After the challenger verifies the attestation server 101 and the applications in the target group, the challenger can trust the attestation server 101 and the applications in the target group. The attestation server 101 that passes the verification can verify the applications according to the application verification rules of the applications that have been verified, so as to realize the transmission of the trust chain from the attestation server 101 to the applications in the target group.
[0095] FIG. 5 is a structural schematic diagram of an application verification device in the embodiments of the present specification. The device can be applied to a proof server. The device comprises: a receiving unit 501 configured to receive a first obtaining request for an identity credential sent by any first application in a target group; wherein the target group comprises a plurality of trusted applications associated therewith, and the first obtaining request comprises an application identity proof of the first application; a checking unit 502 configured to check the application identity proof by using an application checking rule of the first application in a group checking rule of the target group stored in advance; and a generating unit 503 configured to generate and return a first identity credential in response to the application identity proof passing the check, the first identity credential comprising at least part of information in the application identity proof and a group identifier of the target group, for identity authentication when the first application communicates with other applications in the target group.
[0096] In an embodiment, the receiving unit 501 can be further configured to receive a creation request of the target group by an administrator user, wherein the creation request comprises attribute information and the application checking rule of each of the plurality of applications, and the plurality of applications comprise the plurality of trusted applications; and the generating unit 503 can be further configured to assign the group identifier to the target group, and generate and store the group checking rule comprising the group identifier and the attribute information and the application checking rule of each of the plurality of applications.
[0097] In an embodiment, the generating unit 503 can be further configured to generate a first key for the target group, the first key being used to establish a secure channel when the applications in the target group communicate with each other; and store the first key in association with the group identifier.
[0098] In an embodiment, the generating unit 503 can be further configured to generate, for each developer of each application in the target group, a second key corresponding to the developer, the second key being used to establish a secure channel when the applications developed by the developer in the target group communicate with each other; and store the second key in association with the group identifier and the developer.
[0099] In an embodiment, the plurality of trusted applications are distributed in a plurality of TEE platforms.
[0100] In an embodiment, the target group further comprises a plurality of non-trusted applications associated with the plurality of trusted applications.
[0101] In an embodiment, when the first application is a trusted application, the application identity proof comprises a remote attestation report; and when the first application is a non-trusted application, the application identity proof comprises a certificate in X.509 format.
[0102] In an implementation, the first identity credential is in any of the following formats: X.509 format, JWT format, and the like.
[0103] In an implementation, the application verification rule of the first application includes a real application fingerprint, and the application identity certificate includes an application fingerprint to be verified; the verification unit 502 can be further configured to: compare the real application fingerprint with the application fingerprint to be verified.
[0104] In an implementation, the application identity certificate further includes at least one of the following to be verified: application version number, application developer signature, and the like.
[0105] In an implementation, the generation unit 503 can be further configured to: add a signature to the first identity credential, and return the first identity credential with the added signature.
[0106] In an implementation, the first obtaining request and the first identity credential further include a first public key of the first application; the first public key in the first identity credential is used to establish a secure channel when the first application communicates with the other applications.
[0107] In an implementation, the target group is configured with a first key; the generation unit 503 can be further configured to: return the first key for establishing a secure channel when the first application communicates with the other applications, while returning the first identity credential.
[0108] In an implementation, the developers of the respective applications in the target group correspond to a second key; the generation unit 503 can be further configured to: return the second key corresponding to the developer of the first application for establishing a secure channel when the first application communicates with other applications developed by the developer in the target group, while returning the first identity credential.
[0109] In an implementation, the receiving unit 501 can be further configured to: receive a second obtaining request for a group authentication report of the target group sent by a device of a challenger; the generation unit 503 can be further configured to: in response to the second obtaining request, obtain identity information of the respective applications in the target group, which is determined based on the application identity certificate of the corresponding application; generate and return the group authentication report, which includes the identity information of the respective applications, for verifying the respective applications.
[0110] In an implementation, the group authentication report further includes identity information of the attestation server for verifying the attestation server.
[0111] Figure 6 is a structural schematic diagram of an application verification device in the embodiments of the present specification. The device can be applied to any first application in a target group, the target group comprising a plurality of trusted applications associated therewith, and the device comprises: a sending unit 601 configured to send a first acquisition request for an identity credential to a proof service end, wherein the first acquisition request comprises an application identity proof of the first application; a receiving unit 602 configured to receive a first identity credential returned by the proof service end, the first identity credential being generated by the proof service end after the application identity proof is verified by using an application verification rule of the first application, the application verification rule being included in group verification rules of the target group pre-stored in the proof service end; the first identity credential comprises at least part of information in the application identity proof and a group identifier of the target group, and is used for identity authentication when the first application communicates with other applications in the target group.
[0112] In an implementation, the first acquisition request and the first identity credential further comprise a first public key of the first application; the sending unit 601 can be further configured to send an acquisition request for first data to a second application in the target group, wherein the acquisition request comprises the first identity credential; the receiving unit 602 can be further configured to receive ciphertext first data and a second identity credential of the second application returned by the second application, the ciphertext first data being obtained by the second application by encrypting the first data by using the first public key after verifying the first identity credential; the device can further comprise a decryption unit (not shown in the figure) configured to decrypt the ciphertext first data by using a first private key of the first application after verifying the second identity credential.
[0113] In an implementation, the receiving unit 602 can be further configured to receive a first key of the target group returned by the proof service end; the sending unit 601 can be further configured to send an acquisition request for first data to a second application in the target group, wherein the acquisition request comprises the first identity credential; the receiving unit 602 can be further configured to receive ciphertext first data and a second identity credential of the second application returned by the second application, the ciphertext first data being obtained by the second application by encrypting the first data by using the first key on the second application side after verifying the first identity credential; the device can further comprise a decryption unit (not shown in the figure) configured to decrypt the ciphertext first data by using the first key after verifying the second identity credential.
[0114] In an implementation, the receiving unit 602 can be further configured to receive the second key corresponding to the first application developer returned by the attestation service; the sending unit 601 can be further configured to send, to a third application developed by the developer in the target group, a request for obtaining the second data, wherein the first identity credential is included; the receiving unit 602 can be further configured to receive the second data encrypted by the third application using the second key on the third application side after the first identity credential is verified, and a third identity credential of the third application; and the apparatus can further include a decrypting unit (not shown in the figure) configured to decrypt the encrypted second data using the second key after the third identity credential is verified.
[0115] The embodiments of the present specification further provide a computer readable storage medium, having stored thereon a computer program, wherein the computer program causes a computer to execute the method described in FIGS. 2 to 4 when the computer program is executed in the computer.
[0116] The embodiments of the present specification further provide a computing device, including a memory and a processor, wherein the memory has stored executable code, and the processor executes the executable code to implement the method described in FIGS. 2 to 4.
[0117] The embodiments of the present specification further provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the method described in FIGS. 2 to 4.
[0118] Those skilled in the art should be aware that, in one or more examples described above, the functions described in the embodiments disclosed in the present specification can be implemented in hardware, software, firmware or any combination thereof. When implemented in software, the functions can be stored in a computer readable medium or transmitted as one or more instructions or codes on a computer readable medium.
[0119] In some cases, the actions or steps recited in the claims can be performed in a different order than the order described in the embodiments and still achieve the desired result. In addition, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.
[0120] The above detailed description sets forth numerous specific details for the purpose of providing a thorough understanding of the various embodiments of the present disclosure. However, it will be understood that the various embodiments of the present disclosure can be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the various embodiments of the present disclosure. It can be understood that the various embodiments of the present disclosure while including numerous specific details are given by way of example and for purpose of illustration only. The various embodiments of the present disclosure can be practiced without these specific details. In other instances, specific instrumentation and details have not been described in detail since they would be apparent to those skilled in the art.
Claims
1. A method for application verification, performed by a proving server, comprising: receiving a first obtaining request for an identity credential sent by a first application in a target group; wherein the target group comprises a plurality of trusted applications associated therewith, and the first obtaining request comprises an application identity proof of the first application; verifying the application identity proof using an application verification rule of the first application in a group verification rule of the target group stored in advance; in response to the application identity proof passing the verification, generating and returning a first identity credential, the first identity credential comprising at least part of information in the application identity proof and a group identifier of the target group, for identity authentication when the first application communicates with other applications in the target group.
2. The method of claim 1, wherein, Before receiving the first obtaining request for an identity credential sent by a first application in a target group, further comprising: receiving a creation request for the target group from an administrator user, wherein the creation request comprises attribute information and an application verification rule of each of a plurality of applications associated therewith, and the plurality of applications comprise the plurality of trusted applications; allocating the group identifier to the target group; generating and storing the group verification rule, wherein the group verification rule comprises the group identifier and the attribute information and the application verification rule of each of the plurality of applications.
3. The method of claim 2, further comprising: generating a first key for the target group, the first key being used to establish a secure channel when applications in the target group communicate with each other; storing the first key in association with the group identifier.
4. The method of claim 2, further comprising: generating a second key corresponding to a developer of each of the applications in the target group, the second key being used to establish a secure channel when applications developed by the developer in the target group communicate with each other; storing the second key in association with the group identifier and the developer.
5. The method of claim 1, wherein, The plurality of trusted applications are distributed in a plurality of trusted execution environment (TEE) platforms.
6. The method of claim 1, wherein, The target group further comprises a plurality of untrusted applications associated with the plurality of trusted applications.
7. The method of claim 6, wherein, When the first application is a trusted application, the application identity proof comprises a remote attestation report; when the first application is an untrusted application, the application identity proof comprises an X.509 format certificate.
8. The method of claim 1, wherein, The first identity credential is in any one of the following formats: X.509 format, JWT format.
9. The method of claim 1, wherein, The application verification rule of the first application comprises a real application fingerprint, and the application identity proof comprises an application fingerprint to be verified. The verifying the application identity proof comprises: comparing the real application fingerprint with the application fingerprint to be verified.
10. The method of claim 9, wherein, The application identity proof further comprises at least one of the following to be verified: an application version number, an application developer signature.
11. The method of claim 1, wherein, The returning the first identity credential comprises: adding a signature to the first identity credential, and returning the first identity credential with the added signature.
12. The method of claim 1, wherein, The first obtaining request and the first identity credential further comprise a first public key of the first application; the first public key in the first identity credential is used to establish a secure channel when the first application communicates with the other applications.
13. The method of claim 1, wherein, The target group is configured with a first key; The first identity credential is returned, and further comprises: The first key is returned to be used to establish a secure channel when the first application communicates with the other applications.
14. The method of claim 1, wherein, Developers of respective applications in the target group correspond to a second key; The first identity credential is returned, and further comprises: The second key corresponding to the developer of the first application is returned to be used to establish a secure channel when the first application communicates with other applications developed by the developer in the target group.
15. The method of claim 1, further comprising: receiving a second obtaining request of a group authentication report of the target group sent by a device of a challenging party; in response to the second obtaining request, obtaining identity information of respective applications in the target group, the identity information being determined based on application identity proofs of the respective applications; generating and returning a group authentication report comprising the identity information of the respective applications to be used to verify the respective applications.
16. The method of claim 15, wherein, The group authentication report further comprises identity information of the proof server to be used to verify the proof server.
17. An application verification method performed by any first application in a target group, the target group comprising a plurality of associated trusted applications, the method comprising: sending a first obtaining request of an identity credential to a proof server, the first obtaining request comprising an application identity proof of the first application; receiving a first identity credential returned by the proof server, the first identity credential being generated by the proof server after the application identity proof is verified by using application verification rules of the first application, the application verification rules being included in group verification rules of the target group pre-stored in the proof server; the first identity credential comprising at least part of information in the group identification of the target group and the application identity proof, to be used for identity authentication when the first application communicates with other applications in the target group.
18. The method of claim 17, wherein, The first obtaining request and the first identity credential further comprise a first public key of the first application; The method further comprises: sending an obtaining request of first data to a second application in the target group, the obtaining request comprising the first identity credential; receiving ciphertext first data returned by the second application and a second identity credential of the second application, the ciphertext first data being obtained by the second application by encrypting the first data using the first public key after verifying the first identity credential; decrypting the ciphertext first data using a first private key of the first application after verifying the second identity credential.
19. The method of claim 17, further comprising: receiving a first key of the target group returned by the proof server; sending an obtaining request of first data to a second application in the target group, the obtaining request comprising the first identity credential; receive, from the second application, first encrypted data and a second identity credential of the second application, the first encrypted data being encrypted by the second application using the first key on the second application side after the first identity credential is verified to be valid; decrypt the first encrypted data using the first key after the second identity credential is verified to be valid.
20. The method of claim 17, further comprising: receive, from the attestation server, a second key corresponding to a developer of the first application; send, to a third application developed by the developer within the target group, a request for second data, wherein the request includes the first identity credential; receive, from the third application, second encrypted data and a third identity credential of the third application, the second encrypted data being encrypted by the third application using the second key on the third application side after the first identity credential is verified to be valid; decrypt the second encrypted data using the second key after the third identity credential is verified to be valid.
21. An application verification apparatus applied to an attestation server, comprising: a receiving unit configured to receive a first request for an identity credential sent by a first application within a target group, wherein the target group includes a plurality of trusted applications associated with each other, and the first request includes an application identity credential of the first application; a verification unit configured to verify the application identity credential using an application verification rule of the first application included in a group verification rule of the target group stored in advance; a generating unit configured to generate and return a first identity credential in response to the application identity credential being verified to be valid, wherein the first identity credential includes at least part of information in the application identity credential and a group identifier of the target group, and is used for identity authentication when the first application communicates with other applications within the target group.
22. An application verification apparatus applied to a first application within a target group, wherein the target group includes a plurality of trusted applications associated with each other, and the apparatus comprises: a sending unit configured to send a first request for an identity credential to an attestation server, wherein the request includes an application identity credential of the first application; a receiving unit configured to receive a first identity credential returned by the attestation server, wherein the first identity credential is generated by the attestation server after the application identity credential is verified to be valid using an application verification rule of the first application, and the application verification rule is included in a group verification rule of the target group stored in advance by the attestation server; the first identity credential includes at least part of information in the application identity credential and a group identifier of the target group, and is used for identity authentication when the first application communicates with other applications within the target group.
23. A computer readable storage medium having stored thereon a computer program, wherein, the computer program, when executed in a computer, causes the computer to perform the method of any one of claims 1-20.
24. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and the processor executes the executable code to implement the method in any one of claims 1-20. The memory stores executable code, and the processor executes the executable code to implement the method in any one of claims 1-20. The memory stores executable code, and the processor executes the executable code to implement the method in any one of claims 1-20. The memory stores
Citation Information
Patent Citations
Service certificate management method, terminal, and server
CN111066284A
Identity credential application method, identity authentication method, equipment and device
CN113872765A
User data sharing method and device
CN115664759A
Application verification method and device
CN118410469A
Electronic Identity and Credentialing System
US20150095999A1