CN110879876A

CN110879876A - System and method for issuing certificates

Info

Publication number: CN110879876A
Application number: CN201811030447.8A
Authority: CN
Inventors: 程强
Original assignee: Individual
Current assignee: Shenzhen Hongzhuanfang Technology Co ltd
Priority date: 2018-09-05
Filing date: 2018-09-05
Publication date: 2020-03-13
Anticipated expiration: 2038-09-05
Also published as: CN110879876B; WO2020048290A1

Abstract

The embodiment of the application discloses a system and a method for issuing certificates. The system comprises an issuer device, a middleman device and a witness device, wherein the issuer device, the middleman device and the witness device are all provided with a trusted execution environment, and the trusted execution environment comprises the following steps: firstly, a digital asset issuer designates authorization certificate parameter information and first witness parameter information aiming at a target digital asset by using issuer equipment, then the issuer equipment generates a digital asset ciphertext, an authorization certificate ciphertext and a witness information ciphertext corresponding to the target digital asset and sends the digital asset ciphertext, the authorization certificate ciphertext and the witness information ciphertext to intermediary equipment, and then the intermediary equipment determines authorization content information aiming at the received digital asset ciphertext and generates an intermediary authorization certificate ciphertext. Therefore, the digital asset authorization certificate is issued by the intermediary, and the process of issuing the authorization certificate each time needs to be witnessed by the witness, so that the witness can know the authorization condition of the intermediary for the digital asset.

Description

System and method for issuing certificates

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a system and a method for issuing certificates.

Background

Digital Rights Management (DRM) is currently the main means for protecting the copyright of Digital works that are distributed in networks. However, DRM does not address how digital rights break down control rights in the manner of a universal asset and translate usage rights migration into a License issuance process.

For example, a music producer has authored a song, in the present case he can only commission intermediaries (e.g., record companies, cloud music operators, etc.) for sale. However, the music producer cannot know the sales mode and sales volume of the middleman, so the music producer cannot correlate the payment obtained by the music producer with the actual sales condition of the middleman.

Disclosure of Invention

The embodiment of the application provides a system and a method for issuing certificates.

In a first aspect, an embodiment of the present application provides a system for issuing a certificate, where the system includes: the issuer device, the facilitator device, and the witness device, all set up trusted execution environments, wherein: an issuer device configured to: in response to detecting a ciphertext generation request that includes the target digital asset, the authorization certificate parameter information, and the first witness information parameter information, wherein the authorization certificate parameter information and the first witness information parameter information each include: the first certificate-seeing information parameter information also comprises an encryption algorithm identifier, an encryption key, a decryption algorithm identifier and a decryption key: the witness passing condition, the digital asset description information and the witness information are integrated, the witness information comprises a witness user identifier, in a trusted execution environment of the issuer device, a ciphertext generation operation is executed to obtain a digital asset ciphertext, an authorization certificate ciphertext and a witness information ciphertext corresponding to the target digital asset, and the obtained digital asset ciphertext, the authorization certificate ciphertext and the witness information ciphertext are sent to an intermediary device indicated by an intermediary user identifier in the authorization certificate parameter information, wherein the ciphertext generation operation comprises: generating an authorization certificate, and setting the value of each parameter of the authorization certificate as the value of the corresponding parameter in the authorization certificate parameter information; encrypting the authorization certificate by using an authorization certificate key stored in a trusted execution environment of the issuer device to obtain an authorization certificate ciphertext corresponding to the target digital asset; generating first witness information, and setting values of various parameters of the first witness information as values of corresponding parameters in the first witness information parameter information; encrypting the first witness information by using a witness information key stored in a trusted execution environment of the issuer device to obtain a witness information ciphertext corresponding to the target digital asset; encrypting the target digital asset by using the algorithm indicated by the encryption algorithm identification in the authorization certificate parameter information and the encryption key to obtain a digital asset ciphertext corresponding to the target digital asset; a middleman device configured to: in response to receiving a digital asset ciphertext, an authorization certificate ciphertext and a witness information ciphertext sent by an issuer device, determining authorization content information for the received digital asset ciphertext, executing an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device, and obtaining an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authorization certificate generation operation includes: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediary device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the intermediary equipment to obtain an intermediary witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identification in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each first target witness device meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to the fact that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness information plaintext, and the decrypted authorization certificate plaintext and the decrypted middle merchant user identifier in the witness information plaintext are both the user identifiers of the middle merchant equipment, generating a middle merchant authorization certificate, setting the values of all the parameters in the middle merchant authorization certificate as the values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating the authorization content information in the middle merchant authorization certificate into the determined authorization content information; encrypting the intermediate merchant authorization certificate by using an authorization certificate key stored in a trusted execution environment of the intermediate merchant device to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext; a witness device configured to: in response to receiving the witness information ciphertext transmitted by the facilitator device, decrypting the received witness information ciphertext in the trusted execution environment of the witness device by using the witness information key stored in the trusted execution environment of the witness device to obtain a witness information plaintext; presenting the plaintext of the witness information obtained by decryption; in response to detecting a witness agreement operation entered by the user in the clear text of the presented witness information, generating witness passing information, and transmitting the generated witness passing information to the facilitator device that transmitted the received witness information ciphertext.

In a second aspect, an embodiment of the present application provides a method for issuing a credential, which is applied to a facilitator device in a system for issuing a credential, where the system for issuing a credential includes an issuer device, a facilitator device, and an authenticator device, and each of the issuer device, the facilitator device, and the authenticator device sets a trusted execution environment, and the method includes: in response to receiving a digital asset ciphertext, an authorization certificate ciphertext, and a witness message ciphertext transmitted by an issuer device, determining authorization content information for the received digital asset ciphertext; executing an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device to obtain an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authorization certificate generation operation comprises: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain an intermediate merchant witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identification in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each first target witness device meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to the fact that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness information plaintext, and the decrypted authorization certificate plaintext and the decrypted middle merchant user identifier in the witness information plaintext are both user identifiers of middle merchant equipment, generating a middle merchant authorization certificate, setting the value of each parameter in the middle merchant authorization certificate as the value of the corresponding parameter in the decrypted authorization certificate plaintext, and updating the authorization content information in the middle merchant authorization certificate into the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using the authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

In a third aspect, an embodiment of the present application provides an apparatus for issuing a credential, which is applied to a facilitator device in a system for issuing a credential, where the system for issuing a credential includes an issuer device, a facilitator device, and a witness device, and each of the issuer device, the facilitator device, and the witness device sets a trusted execution environment, and the apparatus includes: a determining unit configured to determine, in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness message ciphertext transmitted by the issuer device, authorization content information for the received digital asset ciphertext; a generating unit configured to execute an intermediary authority certificate generating operation in a trusted execution environment of the intermediary device to obtain an intermediary authority certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authority certificate generating operation includes: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain an intermediate merchant witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identification in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each first target witness device meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to the fact that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness information plaintext, and the decrypted authorization certificate plaintext and the decrypted middle merchant user identifier in the witness information plaintext are both user identifiers of middle merchant equipment, generating a middle merchant authorization certificate, setting the value of each parameter in the middle merchant authorization certificate as the value of the corresponding parameter in the decrypted authorization certificate plaintext, and updating the authorization content information in the middle merchant authorization certificate into the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using the authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; a storage device, on which one or more programs are stored, which, when executed by the one or more processors, cause the one or more processors to implement the method as described in any implementation manner of the second aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by one or more processors, implements the method as described in any implementation manner of the second aspect.

The system and method for issuing a certificate provided by the embodiment of the application, first, an issuer of a digital asset designates authorization certificate parameter information and first witness parameter information for a target digital asset by using an issuer device which is provided with a trusted execution environment, then, a digital asset ciphertext, an authorization certificate ciphertext and a witness message ciphertext which correspond to the target digital asset are generated in the trusted execution environment of the issuer device, the generated digital asset ciphertext, the authorization certificate ciphertext and the witness message ciphertext are sent to an intermediary device indicated by an intermediary user identifier in the authorization certificate parameter information, then, the intermediary device determines authorization content information for the received digital asset ciphertext, and executes an intermediary authorization certificate generation operation in the trusted execution environment of the intermediary device to obtain an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, therefore, the digital asset authorization certificate is issued by the facilitator, and in the process that the facilitator device generates the facilitator authorization certificate each time, the witness information ciphertext updated with the authorization content information needs to be sent to the witness device, and the facilitator authorization certificate is generated under the condition that the witness passing information received from each witness device meets the witness passing condition in the witness information plaintext, that is, the witness needs to pass the witness of the witness designated by the issuer each time the facilitator issues the certificate, so that the witness can know the digital asset authorization condition of the facilitator.

Drawings

Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:

FIG. 1 is an exemplary system architecture diagram in which one embodiment of the present application may be applied;

FIG. 2A is a timing diagram for one embodiment of a system for issuing certificates according to the present application;

FIG. 2B is a flow diagram for one embodiment of ciphertext generation operations in accordance with the present application;

FIG. 2C is a flow diagram for one embodiment of a broker authorization certificate generation operation in accordance with the present application;

FIGS. 3A and 3E are timing diagrams of another embodiment of a system for issuing certificates in accordance with the present application;

FIG. 3B is a flow diagram for one embodiment of a user identification generation operation, in accordance with the present application;

FIG. 3C is a flow diagram of another embodiment of ciphertext generation operations in accordance with the present application;

FIG. 3D is a flow diagram for one embodiment of witness pass information generation operations in accordance with the present application;

FIG. 3F is a flow diagram for one embodiment of a digital asset decryption operation, in accordance with the present application;

FIG. 3G is a flow diagram for one embodiment of witness generation and information encryption operations, according to the present application;

FIG. 3H is a flowchart of one embodiment of a multiparty witness message ciphertext decryption operation in accordance with the present application;

FIG. 4 is a flow diagram for one embodiment of a method for issuing certificates, according to the present application;

FIG. 5 is a block diagram illustrating an embodiment of an apparatus for issuing certificates in accordance with the present application;

FIG. 6 is a schematic block diagram of a computer system suitable for use in implementing an electronic device according to embodiments of the present application.

Detailed Description

The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.

It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.

Fig. 1 shows an exemplary system architecture 100 to which embodiments of the system for issuing certificates or the method for issuing certificates of the present application may be applied.

As shown in fig. 1, the system architecture 100 may include an issuer device 101, a facilitator device 102, a witness device 103, and a network 104. The network 104 is used to provide a medium for communication links between the issuer device 101, the facilitator device 102, and the witness device 103. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A publisher of a digital asset (e.g., video, audio, image, text, etc.) may interact with the facilitator device 102 over the network 104 using the publisher device 101 to receive or send messages, etc. The issuer device 101 may have installed thereon various communication client applications, such as applications for generating digital asset cryptograms, authorization credential cryptograms, and witness message cryptograms, web browser applications, shopping-like applications, search-like applications, instant messaging tools, mailbox clients, social platform software, and the like.

The issuer device 101, the facilitator device 102, and the witness device 103 may be hardware or software. When the issuer device 101, the facilitator device 102, and the witness device 103 are hardware, they may be various electronic devices having a display screen and setting a Trusted Execution Environment (TEE), including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like. When the issuer device 101, the facilitator device 102, and the witness device 103 are software, they may be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules, or as a single piece of software or software module. And is not particularly limited herein.

Here, the TEE is a runtime environment coexisting with the Rich OS (typically, Android or the like) on the device, and provides a security service to the Rich OS. The TEE has its own execution space. The hardware and software resources that are accessible to the TEE are separate from the Rich OS. The TEE provides a secure execution environment for Trusted Applications (TAs), while also protecting the confidentiality, integrity, and access rights of the Trusted applications' resources and data. To guarantee the trusted root of the TEE itself, the TEE is authenticated and isolated from the Rich OS during secure boot. In TEE, each trusted application is independent of each other and cannot access each other without authorization.

As an example, the TEE may take the following two forms:

(1) and constructing a trusted execution environment by means of the safety protection capability provided by a specific CPU chip, such as Intel SGX, ARM Trust Zone and the like.

In order to ensure the security strength, Trusted hardware support may be added to the bottom layer of the Trusted execution environment, for example, a security chip conforming to a Trusted Platform Module (TPM) standard or a security chip conforming to a Trusted Cryptography Module (TCM) standard is used.

(2) And a trusted execution environment is realized by adopting an encryption lock (commonly called a dongle).

A typical dongle is often packaged as a compact USB (Universal Serial Bus) device that provides both file storage and supports the running of customized programs. The dongle is not required to limit the device types of the issuer device, the facilitator device, and the witness device, and only needs to provide USB interfaces for the issuer device, the facilitator device, and the witness device, thereby reducing the device requirements for the issuer device, the facilitator device, and the witness device.

It should be noted that the method for issuing the certificate provided in the embodiment of the present application is generally performed by the facilitator apparatus 102, and accordingly, the apparatus for issuing the certificate is generally disposed in the facilitator apparatus 102.

It should be understood that the number of issuer devices, middleman devices, witness devices, and networks in fig. 1 is merely illustrative. There may be any number of issuer devices, facilitator devices, witness devices, and networks, as desired for the implementation.

With continued reference to fig. 2A, a timing sequence 200 for one embodiment of a system for issuing certificates in accordance with the present application is shown.

The system for issuing a certificate in an embodiment of the present application may include an issuer device, a facilitator device, and a witness device, each of which sets a trusted execution environment.

As shown in FIG. 2A, a sequence 200 according to one embodiment of a system for issuing certificates of the present application may include the steps of:

step 201, in response to detecting a ciphertext generation request including a target digital asset, authorization certificate parameter information, and first witness information parameter information, an issuer device executes a ciphertext generation operation in a trusted execution environment of the issuer device to obtain a digital asset ciphertext, an authorization certificate ciphertext, and a witness information ciphertext corresponding to the target digital asset, and sends the obtained digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext to a middleman device indicated by a middleman user identifier in the authorization certificate parameter information.

In this embodiment, the issuer device may, under the condition that a ciphertext generation request including the target digital asset, the authorization certificate parameter information, and the first witness information parameter information is detected, execute a ciphertext generation operation in a trusted execution environment of the issuer device to obtain a digital asset ciphertext, an authorization certificate ciphertext, and a witness information ciphertext corresponding to the target digital asset, and send the obtained digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext to the facilitator device indicated by the facilitator user identifier in the authorization certificate parameter information.

Here, the authorization certificate parameter information may include various parameter information in an authorization certificate to be generated for the target digital asset. The first witness information parameter information may include various parameter information in the first witness information to be generated for the target digital asset. The authorization certificate parameter information and the first witness information parameter information may each include: the first certificate information parameter information may further include an encryption algorithm identifier, an encryption key, a decryption algorithm identifier, and a decryption key: the witness pass condition, the digital asset description information, and the witness information set, where the witness information may include a witness user identification.

Here, the issuer user identification is used to uniquely identify the issuer, and the issuer user identification may include at least one of: numbers, characters, and words.

Here, the certificate identifier is used to uniquely identify each authorization certificate (also referred to as a digital certificate) issued by the same issuer, and may include at least one of the following: numbers, characters, and words. In practice, the certificate identification may be a number that is updated in increments for the same issuer user identification.

Here, the broker user identification is for uniquely identifying each broker that may sell the digital asset issued by the issuer, and the broker user identification may include at least one of: numbers, characters, and words.

Here, the encryption algorithm identification is used to indicate an encryption algorithm used to encrypt the target digital asset, and the encryption key is used to characterize a key used to encrypt the target digital asset. And the decryption algorithm identification is used for indicating a decryption algorithm used for decrypting the target digital asset ciphertext, and the decryption key is used for representing a key used for decrypting the digital asset ciphertext. It is to be understood that, when the encryption algorithm indicated by the encryption algorithm identifier is a symmetric encryption algorithm, the corresponding decryption algorithm identifier indicates a symmetric decryption algorithm corresponding to the symmetric encryption algorithm indicated by the encryption algorithm identifier, and the encryption key and the decryption key may be the same key. When the encryption algorithm indicated by the encryption algorithm identifier is an asymmetric encryption algorithm, the corresponding decryption algorithm identifier indicates an asymmetric decryption algorithm corresponding to the asymmetric encryption algorithm indicated by the encryption algorithm identifier, and the encryption key and the decryption key may be a public key for asymmetric encryption and a private key for asymmetric decryption, respectively.

Here, the witness passing condition may be used to represent a condition that needs to be satisfied by the witness passing information input by the issuer and received from each of the first target witness devices, and the facilitator device may decrypt the authorization certificate ciphertext only if the condition is satisfied. For example, the witness passing condition may be that witness passing information transmitted by each of the first target witness devices is received. For another example, the witness passing condition may be that a ratio of the number of first target witness devices that transmit the witness passing information to the number of all first target witness devices is equal to or greater than a preset ratio (e.g., 80%).

Here, the digital asset description information is information that the issuer has entered using the issuer device to describe the content of the target digital asset to be issued. The digital asset description information may be audio data, text data, or picture data. For example, the digital asset description information for a music genre may be information describing a word writer, a composition writer, an emotion expressed by the music, a music name, a music genre, a music duration, a suitable audience genre of the music, and the like of the music.

Here, the witness information is information describing the witness, and the witness information may include a witness user id. A witness is a user designated by the issuer that has witness to the target digital asset. In practice, the witness is generally a user having a profit relationship with the target digital asset, and of course the witness may also include the issuer itself, i.e., the witness user id in the witness information set may include the issuer user id. For example, for a music-type digital asset, the witness may be a word writer, song writer, singer, producer, investor, and so forth, of the music digital asset.

In practice, the authorization certificate parameter information may further include at least one of: the certificate type identifier, the check code, the certificate expiration time, and the number of bytes of the certificate fixed configuration information, and the first certificate discovery information parameter information may further include: the witness information type identification, the check code, the witness information failure time, the byte number of the witness information fixed configuration information, the number of witness persons, the byte number of authorized content and the byte number of the digital asset description information.

In practice, the issuer device may employ various implementations to detect the ciphertext generation request. For example, the issuer device may indicate that the issuer wishes to generate a digital asset ciphertext, an authorization credential ciphertext, and a witness information ciphertext corresponding to the input target digital asset in the case where it is detected that the user accesses, using the issuer device, a ciphertext generation request information page for the issuer to input the target digital asset, the authorization credential parameter information, and the first witness information parameter information, and in the ciphertext generation request page, the issuer user identifier, the credential identifier, and the facilitator user identifier in the target digital asset, the authorization credential parameter information, and the first witness information parameter information, the encryption algorithm identifier, the encryption key, the decryption algorithm identifier, and the decryption key in the authorization credential parameter information, and the witness passing condition, the digital asset description information, and the witness information set in the first witness information parameter information, and so forth, the issuer device may determine that a ciphertext generation request is detected. For another example, the issuer device may further indicate that the issuer wishes to generate a digital asset ciphertext, an authorization certificate ciphertext, and a witness information ciphertext corresponding to the input target digital asset when detecting that the user opens a ciphertext generation request interface for the user to input the target digital asset, the authorization certificate parameter information, and the first witness information parameter information in a ciphertext generation application installed on the issuer device, and that issuer user id, certificate id, and broker user id in the target digital asset, the authorization certificate parameter information, and the first witness information parameter information, an encryption algorithm id, an encryption key, a decryption algorithm id, and a decryption key in the authorization certificate parameter information, and a witness passing condition, a digital asset description information, and a witness information set, etc. in the ciphertext generation request interface are input by the user, at this time, the issuer device may determine that the ciphertext generation request is detected.

In the present embodiment, the ciphertext generation operation may include sub-steps 2011 to 2015 as shown in fig. 2B:

sub-step 2011, generating an authorization certificate, and setting the value of each parameter of the authorization certificate as the value of the corresponding parameter in the authorization certificate parameter information.

Here, the issuer device may generate an authorization certificate in a trusted execution environment of the issuer device, and set values of respective parameters of the authorization certificate as values of corresponding parameters in the authorization certificate parameter information. It is to be understood that the authorization certificate may include parameter information of various parameters included in the authorization certificate parameter information. For example, the authorization credential may include an issuer user identification, a credential identification, and a broker user identification, and may also include an encryption algorithm identification, an encryption key, a decryption algorithm identification, and a decryption key. It will be appreciated that, in addition to the authorization credentials including the parameters described above, in practice the authorization credentials may include at least one of: certificate type identification, check code, certificate failure time, byte number of certificate fixed configuration information and authorization content information.

And a substep 2012 for encrypting the authorization certificate by using the authorization certificate key stored in the trusted execution environment of the issuer device to obtain an authorization certificate ciphertext corresponding to the target digital asset.

Here, the trusted execution environment of the issuer device may have stored therein an authorization credential key, which may be stored within the trusted execution environment of the issuer device but not outside the trusted execution environment of the issuer device, and programs within the trusted execution environment of the issuer device may access the authorization credential key, but programs outside the trusted execution environment of the issuer device may not. Due to the above-described characteristics of the authorization credential key, the authorization credential plaintext may be stored within the trusted execution environment of the issuer device but not outside of the trusted execution environment of the issuer device, and programs within the trusted execution environment of the issuer device may access the authorization credential plaintext, but programs outside of the trusted execution environment of the issuer device may not access the authorization credential plaintext and programs outside of the trusted execution environment of the issuer device may access the authorization credential ciphertext.

Here, the authorization certificate is encrypted by using an authorization certificate key stored in the trusted execution environment of the issuer device, and various symmetric Encryption algorithms currently known or developed in the future, such as DES (Data Encryption Standard), 3DES/TDEA (Triple Data Encryption Algorithm), AES (Advanced Encryption Standard), Blowfish, RC2, RC4, RC5, and IDEA (International Data Encryption Algorithm), may be used.

And a substep 2013 of generating first witness information and setting the values of the parameters of the first witness information as the values of the corresponding parameters in the parameter information of the first witness information.

Here, the issuer device may generate the first witness information in a trusted execution environment of the issuer device, and set values of respective parameters of the first witness information to values of corresponding parameters in the first witness information parameter information. It is to be understood that the first witness information may include parameter information of respective parameters included in the first witness information parameter information. For example, the first witness information may include an issuer user identification, a credential identification, and a facilitator user identification, and the first witness information may further include witness passing conditions, digital asset description information, and a set of witness information. It is to be understood that the first witness information may comprise, in addition to the above parameters, in practice at least one of the following: the witness information type identification, the check code, the witness information failure time, the byte number of the witness information fixed configuration information, the number of witness persons, the byte number of authorized content and the byte number of the digital asset description information.

And a substep 2014 of encrypting the first witness information by using the witness information key stored in the trusted execution environment of the issuer device to obtain a witness information ciphertext corresponding to the target digital asset.

Here, the trusted execution environment of the issuer device may have stored therein a witness key, which may be stored within but not outside the trusted execution environment of the issuer device, and programs within but not outside the trusted execution environment of the issuer device may access the witness key, but programs outside the trusted execution environment of the issuer device may not. Due to the above-described characteristics of the witness key, the first witness information plaintext may be stored within the trusted execution environment of the issuer device but not outside of the trusted execution environment of the issuer device, and programs within the trusted execution environment of the issuer device may access the first witness information plaintext, but programs outside of the trusted execution environment of the issuer device may not access the first witness information plaintext and programs outside of the trusted execution environment of the issuer device may access the witness information ciphertext.

Here, the encrypting the first witness information with the witness key stored in the trusted execution environment of the issuer device may be by employing various now known or future developed symmetric encryption algorithms.

Sub-step 2015, encrypting the target digital asset by using the algorithm indicated by the encryption algorithm identification in the authorization certificate parameter information and the encryption key to obtain a digital asset cryptograph corresponding to the target digital asset.

In step 202, the facilitator device determines the authorization content information for the received digital asset ciphertext in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness message ciphertext transmitted by the issuer device.

Here, the facilitator device may employ various implementations to determine the authorization content information for the received digital asset ciphertext. For example, the facilitator device may, after determining the user identification of the authorized user of the received digital asset ciphertext, use the user identification of the authorized user determined for the received digital asset ciphertext as the authorization content information for the received digital asset ciphertext. For another example, the facilitator device may also use the first number as authorized content information after determining that the first number of users are authorized to be given the received digital asset cryptogram. For example, the facilitator device may also determine that a second number of the received digital asset ciphertexts are to be sold at a first price rate, and then use the first price rate and the second number as the authorization content information. Of course, it is understood that the facilitator device may also combine the user identification, the first number, the first unit price, and the second number of the authorized users as the authorized content information. In short, the authorization content information is information on the authorization status of the received digital asset cryptogram specified by the facilitator device according to the sales status of the facilitator device.

In step 203, the broker device executes a broker authorization certificate generation operation in the trusted execution environment of the broker device to obtain a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext.

Here, the broker authorization certificate generation operation may include sub-steps 2031 to 2037 as shown in fig. 2C:

substep 2031, decrypting the received witness message ciphertext using the witness message key stored in the trusted execution environment of the facilitator device to obtain a witness message plaintext.

Here, the witness key stored in the trusted execution environment of the facilitator device is the same as the witness key stored in the trusted execution environment of the issuer device, and the witness key may be stored within the trusted execution environment of the facilitator device but may not be stored outside of the trusted execution environment of the facilitator device, and a program within the trusted execution environment of the facilitator device may access the witness key but a program outside of the trusted execution environment of the facilitator device may not access the witness key. Due to the characteristics of the witness information key, the witness information ciphertext can be decrypted in the trusted execution environment of the facilitator device to obtain the witness information plaintext, but the witness information ciphertext cannot be decrypted outside the trusted execution environment of the facilitator device.

Substep 2032, updating the authorization content information in the witness information plaintext obtained by decryption to the determined authorization content information.

Here, the authorized content information in the witness information plaintext decrypted in sub-step 2031 may be updated to the authorized content information determined in step 202. That is, the authorized content information in the witness information plaintext decrypted in sub-step 2031 is the authorized content information in the first witness information parameter information detected by the issuer device, and the issuer delegates authorization to the digital asset ciphertext corresponding to the target digital asset to the broker, so that the authorized content information in the witness information plaintext decrypted in sub-step 2031 is specified by the broker, and therefore, the authorized content information in the witness information plaintext decrypted in sub-step 2031 needs to be updated to the authorized content information determined in step 202.

Substep 2033, encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the facilitator device, to obtain the facilitator witness information ciphertext.

Since the authorized content information in the witness information plaintext that has been decrypted in sub-step 2032 is updated, the updated witness information plaintext that has been decrypted may be encrypted using the witness information key stored in the trusted execution environment of the facilitator device to obtain a facilitator witness information ciphertext.

Sub-step 2034 of sending the facilitator witness message ciphertext to each of the first target witness devices.

Here, the first target witness device is the witness device indicated by the witness user identification in the witness information in the set of witness information in the witness information plaintext decrypted in sub-step 2031.

Sub-step 2035, in response to determining that the witness pass information received from each first target witness device satisfies the witness pass condition in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with the authorization certificate key stored in the trusted execution environment of the facilitator device to obtain the authorization certificate plaintext.

Here, the authorization credential key stored in the trusted execution environment of the facilitator device is the same as the authorization credential key stored in the trusted execution environment of the issuer device, and the authorization credential key may be stored within the trusted execution environment of the facilitator device but may not be stored outside of the trusted execution environment of the facilitator device, and programs within the trusted execution environment of the facilitator device may access the authorization credential key but programs outside of the trusted execution environment of the facilitator device may not access the authorization credential key. Due to the characteristics of the authorization certificate key, the authorization certificate ciphertext can be decrypted in the trusted execution environment of the facilitator device to obtain the authorization certificate plaintext, but the authorization certificate ciphertext cannot be decrypted outside the trusted execution environment of the facilitator device.

Substep 2036, in response to determining that the issuer user identifier and the certificate identifier in the decrypted authentication certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness mark information plaintext, and that the middleman user identifier in the decrypted witness mark information plaintext and the middleman user identifier in the decrypted witness mark information plaintext are both the user identifiers of the middleman device, generating a middleman authorization certificate, setting the values of the parameters in the middleman authorization certificate as the values of the corresponding parameters in the decrypted authentication certificate plaintext, and updating the authorization content information in the middleman authorization certificate to the determined authorization content information.

Here, if it is determined that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are the same as the corresponding parameters in the decrypted witness certificate plaintext, it indicates that the decrypted authorization certificate plaintext and the decrypted witness certificate plaintext correspond to the same digital asset issued by an issuer device indicated by an issuer user identifier. And if the middleman user identifier in the decrypted authorization certificate plaintext and the decrypted witness message plaintext is determined to be the user identifier of the middleman equipment, the middleman equipment is indicated to be the specified middleman equipment in the decrypted authorization certificate plaintext and the decrypted witness message plaintext. At this time, the broker authorization certificate may be generated, the values of the parameters in the broker authorization certificate may be set as the values of the corresponding parameters in the decrypted authorization certificate plain text, and the authorization content information in the broker authorization certificate may be updated to the authorization content information determined in step 202, so that the authorization content information in the generated broker authorization certificate plain text may be updated to the authorization content information specified by the broker. It is understood that the intermediary authority certificate includes various parameters included in the decrypted authority certificate specification.

Substep 2037, encrypting the broker authorization certificate with the authorization certificate key stored in the trusted execution environment of the broker device, to obtain a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext.

Since the authorization content information in the broker authorization certificate has been updated in sub-step 2036, here, the broker authorization certificate may be encrypted using an authorization certificate key stored in the trusted execution environment of the broker device to obtain a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext.

After step 203, the facilitator device may store the obtained facilitator authorization certificate ciphertext and the received digital asset ciphertext in correspondence, and provide the user authorized to obtain the received digital asset ciphertext with various implementation manners as needed. For example, the facilitator device may send the digital asset ciphertext to an email box designated by the user authorized to obtain the received digital asset ciphertext in an email manner, and then the user authorized to obtain the received digital asset ciphertext may obtain a facilitator authorization certificate ciphertext in a manner of receiving an email; or, the facilitator device may also provide a website link for downloading the cryptograph of the facilitator authorization certificate, and then the user may download the cryptograph of the facilitator authorization certificate by opening a browser using the user device and clicking the website link, or the user may directly copy the cryptograph of the facilitator authorization certificate from the facilitator device to the user device through the usb disk.

In step 204, in response to receiving the witness information ciphertext sent by the facilitator device, the witness device decrypts the received witness information ciphertext with the witness information key stored in the trusted execution environment of the witness device to obtain a witness information plaintext.

Here, the witness device may decrypt, in the trusted execution environment of the witness device, the received witness ciphertext using the witness key stored in the trusted execution environment of the witness device to obtain the witness plaintext, upon receiving the witness ciphertext transmitted by the facilitator device.

Wherein the witness information key stored in the trusted execution environment of the witness device, the witness information key stored in the trusted execution environment of the facilitator device, and the witness information key stored in the trusted execution environment of the issuer device are all the same, and the witness information key may be stored within the trusted execution environment of the witness device but may not be stored outside the trusted execution environment of the witness device, and programs within the trusted execution environment of the witness device may access the witness information key, but programs outside the trusted execution environment of the witness device may not access the witness information key. Due to the characteristics of the witness key, the witness message ciphertext may be decrypted within the trusted execution environment of the witness device to obtain the witness message plaintext, but may not be decrypted outside of the trusted execution environment of the witness device.

In step 205, the witness device presents the decrypted witness information in clear.

Here, the witness device may present the decrypted witness information in clear text in various implementations. For example, the presentation form may be to present the plaintext of the witness information in a text form on the screen of the witness device, or may be to play the text in the plaintext of the witness information with a speaker to obtain a voice after voice synthesis. In addition, when the decrypted witness information plaintext is presented, all the content in the witness information plaintext may be presented, or part of the content may be presented. In practice, issuer user identification, certificate identification, facilitator user identification, and digital asset description information in the witness message specification are typically presented.

In step 206, the witness device generates witness pass information in response to detecting a witness agreement operation entered by the user for the presented witness information plaintext, and transmits the generated witness pass information to the facilitator device that transmitted the received witness information ciphertext.

Since the decrypted witness information plaintext is presented in the witness device in step 205, the user can determine whether the witness passes through the witness information plaintext presented in the witness device. If the user passes the witness, a witness agreement operation may be input using the witness device (e.g., the user may input the witness agreement operation by clicking a button associated with the witness agreement operation), if the witness device detects a witness agreement operation input by the user in the clear text of the presented witness information, witness passing information may be generated, and the generated witness passing information may be transmitted to the facilitator device that transmitted the received witness information ciphertext.

Here, the witness pass information is used to characterize the user's approval of the witness information plaintext content presented by the witness device. It will be appreciated that if the user does not approve the plaintext content of the witness information presented by the witness device, the witness device may be used to input a witness-failure operation, and the witness device may generate witness-failure information upon detecting the witness-failure operation. As an example, the witness passing information may be a first preset value (e.g., may be generally 1), and the witness failing information may be a second preset value (e.g., may be generally 0). As yet another example, the witness passing information may be "true" and the witness failing information may be "false".

It is to be understood that steps 204 through 205 may be performed after step 2034 is performed in the course of performing the broker authorization credential generation operation in step 203. While the facilitator device is performing the facilitator authorization credential generation operation, sub-step 2035 may be performed in real time as the witness device performs steps 204 through 206, and it is not necessary to wait until all witness devices have performed steps 204 through 206 before performing sub-step 2035, since it is possible that the witness pass information received from some of the witness devices may satisfy the witness pass condition required by sub-step 2035.

In the present application, the issuer device may also serve as the facilitator device and/or the witness device, and similarly, the facilitator device may also serve as the issuer device and/or the witness device, and the witness device may also serve as the issuer device and/or the facilitator device.

The certificate issuing system provided in the above-mentioned embodiment of the present application specifies, by an issuer of a digital asset, authorization certificate parameter information and first witness parameter information for a target digital asset by using an issuer device that sets a trusted execution environment, then generates, in the trusted execution environment of the issuer device, a digital asset ciphertext, an authorization certificate ciphertext, and a witness message ciphertext corresponding to the target digital asset, and sends the generated digital asset ciphertext, authorization certificate ciphertext, and witness message ciphertext to an intermediary device indicated by an intermediary user identifier in the authorization certificate parameter information, then determines, by the intermediary device, authorization content information for the received digital asset ciphertext, and executes an intermediary authorization certificate generating operation in the trusted execution environment of the intermediary device, to obtain an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, therefore, the digital asset authorization certificate is issued by the facilitator, and in the process that the facilitator device generates the facilitator authorization certificate each time, the witness information ciphertext updated with the authorization content information needs to be sent to the witness device, and the facilitator authorization certificate is generated under the condition that the witness passing information received from each witness device meets the witness passing condition in the witness information plaintext, that is, the witness needs to pass the witness of the witness designated by the issuer each time the facilitator issues the certificate, so that the witness can know the digital asset authorization condition of the facilitator.

With further reference to fig. 3A, a timing sequence 300 of yet another embodiment of a system for issuing certificates in accordance with the present application is illustrated.

As shown in FIG. 3A, a sequence 300 of yet another embodiment of a system for issuing certificates in accordance with the present application may include the steps of:

in step 301, in response to detecting a first user identifier generation request including a first user identifier category identifier, an issuer device determines the first user identifier category identifier and a trusted execution environment of the issuer device as a target user identifier category identifier and a target trusted execution environment, respectively, in the determined target trusted execution environment, performs a user identifier generation operation to obtain a user identifier corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and adds the obtained user identifier to a user identifier set of the issuer device.

In practice, the issuer device may employ various implementations to detect the first user identification generation request. For example, the publisher device may determine that the first user identification generation request is detected when detecting that a user accesses a user identification generation page including a page element (e.g., a text box or a pull-down menu, etc.) for user input of a user identification category identification using the publisher device, and inputs the first user identification category identification in the page element for user input of the user identification category identification. For another example, the issuer device may further determine that the first user id generation request is detected when detecting that the user opens a user id generation interface in an application installed on the issuer device, inputs the first user id category id, and clicks a control (e.g., a button) associated with a user id generation operation.

Here, the first user identification category identification is used to indicate a category of user identifications in the user identification set of the issuer device. In practice, the user identifiers in the user identifier set may be classified in various ways, each classification corresponding to a different first user identifier category, and the first user identifier category identifier is used to indicate the different first user identifier category. As an example, the classification may be performed according to the belonging type of the application to which the generated user identifier is applied, for example, if the user wishes to generate the user identifier for the social application or the social website, the first user identifier generation request may be input or selected for the user identifier category identifier corresponding to the social application or the social website. For another example, if the user wishes to generate the user identifier of the shopping application or the shopping website, the user identifier category identifier corresponding to the shopping application or the shopping website may be input or selected to generate the first user identifier generation request. As an example, the first user identifier category identifier may also be determined in an incremental manner, that is, the issuer device may store a current first user identifier category identifier, and when an instruction that a user wants to generate a user identifier is detected, the issuer device may obtain the stored current first user identifier category identifier, perform incremental update on the obtained current first user identifier category identifier, and generate the first user identifier generation request using the current first user identifier category identifier after the incremental update.

Here, the user identification generation operation may be as in sub-step 3011 to sub-step 3013 shown in fig. 3B:

sub-step 3011, obtain an environment identification including a vendor identification and a product identification for indicating a target trusted execution environment.

Here, the environment identifier of the trusted execution environment is used for uniquely identifying the trusted execution environment, and the environment identifier of the trusted execution environment may include a vendor identifier and a product identifier, where the vendor identifier of the trusted execution environment is used for uniquely identifying vendors of different trusted execution environments, and the product identifier is used for uniquely identifying trusted execution environments produced by the same trusted execution environment vendor. In practice, a manufacturer identifier and a product identifier are already set in the trusted execution environment when the trusted execution environment leaves a factory, and cannot be modified, and the environment identifier of the trusted execution environment can only be stored in the trusted execution environment, a program in the trusted execution environment can access the environment identifier of the trusted execution environment, and a program outside the trusted execution environment cannot access the environment identifier of the trusted execution environment. The environment identification may include at least one of: numbers, characters, and words.

Sub-step 3012, randomly generating a random number.

Sub-step 3013, encrypt the extended user id with the user id key stored in the target trusted execution environment, and obtain the user id corresponding to the target user id category id and the target trusted execution environment.

Here, the extended user identity may include the environment identity acquired in sub-step 3011, the generated random number and the target user identity class identity.

Here, the user identification key may be stored in the target trusted execution environment and may be accessed by programs within the target trusted execution environment but not by programs outside the target trusted execution environment.

Here, the extended user id is encrypted by the user id key stored in the target trusted execution environment, and various symmetric encryption algorithms may be adopted.

The user identifier generated in step 301 is generated based on the environment identifier of the trusted execution environment of the issuer device, and the generated random number and the first user identifier category identifier are also added, so that for a program outside the trusted execution environment of the issuer device, only the generated user identifier can be obtained, but the environment identifier in the generated user identifier cannot be parsed, and the program inside the trusted execution environment of the issuer device can parse the generated user identifier to obtain the environment identifier in the user identifier, thereby protecting the user identifier in the user identifier set of the issuer device from being cracked by the program outside the trusted execution environment.

Step 302, in response to detecting a second user identifier generation request including a second user identifier category identifier, the facilitator device determines the second user identifier category identifier and the trusted execution environment of the facilitator device as a target user identifier category identifier and a target trusted execution environment, respectively, in the determined target trusted execution environment, performs a user identifier generation operation to obtain a user identifier corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and adds the obtained user identifier to a user identifier set of the facilitator device.

Here, the user identifier generation operation may refer to the related description in step 301 and will not be described herein again.

Step 303, in response to detecting the third user id generation request including the third user id class id, the witness device determines the third user id class id and the trusted execution environment of the witness device as a target user id class id and a target trusted execution environment, respectively, in the determined target trusted execution environment, performs a user id generation operation to obtain a user id corresponding to the determined target user id class id and the determined target trusted execution environment, and adds the obtained user id to the user id set of the witness device.

It will be appreciated that, through steps 301 to 303, the user identifications in the user identification sets of the issuer device, the facilitator device and the authenticator device are generated in the trusted execution environments of the issuer device, the facilitator device and the authenticator device, respectively, based on the environment identifications of the trusted execution environments, and for programs outside the trusted execution environments, only the generated user identifications can be obtained, but the environment identifications in the generated user identifications cannot be resolved, i.e., programs within the trusted execution environments can resolve the generated user identifications to obtain the environment identifications in the user identifications. Thus, the user identities in the set of user identities of the issuer device, the facilitator device, and the witness device may be protected from being hacked by programs outside of the trusted execution environment, steps 301 through 303.

Step 304, in response to detecting a ciphertext generation request including the target digital asset, the authorization certificate parameter information, and the first witness information parameter information, the issuer device executes a ciphertext generation operation in a trusted execution environment of the issuer device to obtain a digital asset ciphertext, an authorization certificate ciphertext, and a witness information ciphertext corresponding to the target digital asset, and sends the obtained digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext to the facilitator device indicated by the intermediary business user identifier in the authorization certificate parameter information.

Here, with respect to the authorization credential parameter information, the first witness information parameter information, the issuer user identifier, the credential identifier, the middleman user identifier, the encryption algorithm identifier, the encryption key, the decryption algorithm identifier, the decryption key, the witness passing condition, the digital asset description information, and the witness information, reference may be made to the related description in step 201 in the embodiment shown in fig. 2A, which is not described herein again.

Here, the issuer user identification in the authorization certificate parameter information and the first credential information parameter information may be a user identification in a user identification set of the issuer device. The issuer device may add the user identifier to the user identifier set of the issuer device by performing step 301, specifically please refer to the related description in step 301.

Here, the broker user identification in the authorization credential parameter information and the first credential information parameter information may be a user identification in a set of user identifications of the broker device. The facilitator device may add the user identifier to the user identifier set of the facilitator device by performing step 302, specifically referring to the relevant description in step 302.

Here, the witness user id in the witness information set in the first witness information parameter information is a user id in the user id set of the witness device. The witness device may add the user id to the set of user ids of the witness device by performing step 303, with reference to the relevant description in step 303.

Here, it should be noted that the user identification keys stored in the trusted execution environments of the different issuer devices, facilitator devices, and witness devices are the same.

In practice, the issuer device may employ various implementations to detect the ciphertext generation request.

In the present embodiment, the ciphertext generation operation may include substeps 3041 through 3049 as shown in fig. 3C:

sub-step 3041 of generating an authorization certificate and setting the values of the parameters of the authorization certificate as the values of the corresponding parameters in the authorization certificate parameter information.

In this embodiment, the specific operation of the sub-step 3041 is substantially the same as the specific operation of the sub-step 2011 in the embodiment shown in fig. 2A, and is not repeated here.

Substep 3042, decrypting the issuer user id and the broker user id in the authorization certificate parameter information and the first credential information parameter information respectively by using the user id key stored in the trusted execution environment of the issuer device, to obtain an issuer extended user id and a broker extended user id.

Here, since the issuer user id in the authorization credential parameter information and the first credential information parameter information is the user id in the user id set of the issuer device, the broker user id is the user id in the user id set of the broker device, and the user id in the user id set of the issuer device is encrypted by using the user id key stored in the trusted execution environment of the issuer device, the user id in the user id set of the broker device is encrypted by using the user id key stored in the trusted execution environment of the broker device, and the user id keys stored in the trusted execution environments of different issuer devices, broker devices, and witness devices are the same, here, the user id keys stored in the trusted execution environments of the issuer device are used to respectively encrypt the authorization credential parameter information and the issuer user id in the first credential information parameter information And decrypting the intermediate merchant user identifier to obtain the issuer extended user identifier and the intermediate merchant extended user identifier.

Sub-step 3043, updating the issuer user id and the broker user id in the authorization certificate to the environment id in the issuer extended user id and the environment id in the broker extended user id, respectively.

Here, the issuer user id and the broker user id in the authorization certificate generated in sub-step 3041 may be updated to the environment id in the issuer extended user id and the environment id in the broker extended user id decrypted in sub-step 3042, respectively. That is, the issuer user identifier and the broker user identifier in the generated authorization certificate actually store the environment identifier of the trusted execution environment in the issuer device and the environment identifier of the trusted execution environment in the broker device, respectively, instead of the user identifier in the user identifier set of the issuer device or the user identifier in the user identifier set of the broker device.

In sub-step 3044, the authorization certificate is encrypted by using the authorization certificate key stored in the trusted execution environment of the issuer device, so as to obtain an authorization certificate ciphertext corresponding to the target digital asset.

In this embodiment, the specific operation of the sub-step 3044 is substantially the same as the specific operation of the sub-step 2012 in the embodiment shown in fig. 2A, and is not described herein again.

Sub-step 3045, generating the first witness information, and setting the values of the parameters of the first witness information to the values of the corresponding parameters in the parameter information of the first witness information.

In this embodiment, the specific operation of the sub-step 3045 is substantially the same as the specific operation of the sub-step 2013 in the embodiment shown in fig. 2A, and is not described again here.

Sub-step 3046, updating the issuer user id and the broker user id in the first witness information to the environment id in the issuer extended user id and the environment id in the broker extended user id, respectively.

Here, the issuer user id and the broker user id in the first credential information generated in sub-step 3045 may be updated to the environment id in the issuer extended user id and the environment id in the broker extended user id decrypted in sub-step 3042, respectively. That is, the issuer user identifier and the broker user identifier in the generated first witness information actually store the environment identifier of the trusted execution environment in the issuer device and the environment identifier of the trusted execution environment in the broker device, respectively, instead of the user identifier in the user identifier set of the issuer device or the user identifier in the user identifier set of the broker device.

Sub-step 3047 of updating the witness user id in each of the witness information in the set of witness information in the first witness information to the witness environment id corresponding to the witness user id.

Here, the witness user id in each of the witness information sets in the first witness information generated in sub-step 3045 may be updated to the witness environment id corresponding to the witness user id. The prover environment id corresponding to the prover user id is an environment id in the extended user id obtained by decrypting the prover user id with a user id key stored in the trusted execution environment of the issuer device. That is, the witness user id in each of the witness information sets in the generated first witness information actually stores the environment id of the trusted execution environment in the witness device, rather than the user ids in the user id set of the witness device.

In sub-step 3048, the first witness information is encrypted by using the witness information key stored in the trusted execution environment of the issuer device to obtain a witness information ciphertext corresponding to the target digital asset.

In this embodiment, the specific operation of the sub-step 3048 is substantially the same as the specific operation of the sub-step 2014 in the embodiment shown in fig. 2A, and is not described again here.

In sub-step 3049, the target digital asset is encrypted by the algorithm indicated by the encryption algorithm identifier in the authorization certificate parameter information and the encryption key, so as to obtain a digital asset cryptograph corresponding to the target digital asset.

In this embodiment, the specific operation of the sub-step 3049 is substantially the same as the specific operation of the sub-step 2015 in the embodiment shown in fig. 2A, and is not described again here.

Step 305, the facilitator device determines the authorization content information for the received digital asset ciphertext in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness message ciphertext transmitted by the issuer device.

In this embodiment, the specific operation of step 305 is substantially the same as the specific operation of sub-step 202 in the embodiment shown in fig. 2A, and is not described herein again.

Step 306, the facilitator device executes a facilitator authorization certificate generation operation in the trusted execution environment of the facilitator device to obtain a facilitator authorization certificate ciphertext corresponding to the received digital asset ciphertext.

In this embodiment, the specific operation of step 306 is substantially the same as the specific operation of sub-step 203 in the embodiment shown in fig. 2A, and is not described herein again.

In step 307, in response to receiving the witness information ciphertext sent by the facilitator device, the witness device decrypts the received witness information ciphertext with the witness information key stored in the trusted execution environment of the witness device to obtain a witness information plaintext.

In this embodiment, the specific operation of step 307 is substantially the same as the specific operation of sub-step 204 in the embodiment shown in fig. 2A, and is not described herein again.

In step 308, the witness device presents the decrypted witness information in clear.

In this embodiment, the specific operation of step 308 is substantially the same as the specific operation of sub-step 205 in the embodiment shown in fig. 2A, and is not described herein again.

In step 309, the witness device generates witness pass information in response to detecting a witness agreement operation entered by the user for the presented witness information plaintext, and transmits the generated witness pass information to the facilitator device that transmitted the received witness information ciphertext.

In this embodiment, the specific operation of step 309 is substantially the same as the specific operation of sub-step 206 in the embodiment shown in fig. 2A, and is not described herein again.

In some implementations of this embodiment, the witness device generating witness pass information in step 309 may perform a witness pass information generating operation in the trusted execution environment of the witness device, resulting in witness pass information corresponding to the received witness information ciphertext, where the witness pass information generating operation may include sub-steps 3091 to 3092 as shown in fig. 3D:

and a substep 3091, in response to the integrity check of the decrypted plaintext of the witness information, generating a witness information key according to the environment identifier of the trusted execution environment of the witness device according to a preset algorithm.

Here, the integrity check of the plaintext of the witness information obtained by decryption in step 307 may be performed by calculating a message digest value of the content of the plaintext of the witness information other than the verification code, and then if the calculated message digest value is the same as the verification code of the plaintext of the witness information, it indicates that the integrity check of the plaintext of the witness information obtained by decryption passes.

Here, the preset algorithm may be various algorithms for generating a key according to the environment identification of the trusted execution environment. As an example, generating the witness information key from the context identity of the trusted execution environment of the witness device according to a preset algorithm may be performed as follows: the environment identification of the trusted execution environment of the witness device and a pre-provisioned key component identification (which may be, for example, a pre-provisioned constant) stored in the trusted execution environment of the witness device are combined to derive a witness information key.

For another example, generating the witness information key based on the context identifier of the trusted execution context of the witness device according to a predetermined algorithm may be performed as follows: and performing exclusive-or operation on the environment identifier of the trusted execution environment of the witness device and a preset mask stored in the trusted execution environment of the witness device to obtain a witness information key.

And a substep 3092 of encrypting the preset key information in the decrypted witness information plaintext by using the generated witness information key to obtain witness passing information corresponding to the received witness information ciphertext.

Here, the witness pass information corresponding to the received witness information ciphertext may be obtained by encrypting the preset key information in the witness information plaintext decrypted in step 307 with the witness information key generated in sub-step 3091. The preset key information may be parameter information of at least one preset parameter in the witness information declaration. In practice, the preset key information may include a verification code, an issuer user identification, and a certificate identification.

Based on the above optional implementation, the witness information may further include a witness weight, and the witness passing condition may include a sum of the witness weight and a preset weight or more and a threshold value. In this way, the determination that the witness pass information received from each of the first target witness devices satisfies the witness pass condition in the decrypted witness information plaintext in the broker-authorized-certificate generating operation may be performed as follows:

first, witness pass information received from each first target witness device within a preset time period may be determined as a set of target witness pass information.

That is, the facilitator device may not wait for all of the first target witness devices to return witness pass information, and therefore, witness pass information received from each of the first target witness devices within a preset period of time (e.g., within ten minutes from the point in time when the facilitator device transmits the facilitator witness information cipher text to each of the first target witness devices) may be determined to be a set of target witness pass information.

The witness sum may then be zeroed.

Next, the following witness weighting and updating operations may be performed for each target witness pass information in the set of target witness pass information:

the first step is to determine the witness information corresponding to the witness device which has transmitted the target witness passing information in the witness information set in the witness information plaintext obtained by decryption.

And secondly, generating a witness information key according to the determined witness user identifier in the witness information according to the preset algorithm.

Here, what the witness user id in the determined witness information actually stores is the environment id of the trusted execution environment in the witness device indicated by the witness user id. The predetermined algorithm used by the witness device to generate the witness information key in the trusted execution environment of the witness device based on the environment identification of the trusted execution environment of the witness device in sub-step 3091 is defined herein as the predetermined algorithm.

And thirdly, decrypting the target witness passing information by using the generated witness information key to obtain the key information of the witness information.

And fourthly, in response to the fact that the obtained witness information key information is the same as the preset key information in the witness information plaintext obtained through decryption, updating the witness weight sum into the sum of the witness weight sum and the witness weight in the determined witness information.

If the obtained witness information key information is the same as the preset key information in the decrypted witness information plaintext, which indicates that the obtained witness information key information really comes from the witness device indicated by the witness user identifier in the witness information set specified in the decrypted witness information plaintext, so that the witness device can be determined to really detect the witness agreement operation input by the user for the decrypted witness information plaintext, the witness weight sum can be updated to be the sum of the witness weight sum and the witness weight sum in the determined witness information.

Finally, in response to determining that the witness weight sum is greater than or equal to a preset weight sum threshold, it is determined that witness passing information received from each first target witness device satisfies witness passing conditions in the decrypted witness information plaintext.

Here, if it is determined that the witness weight sum is equal to or greater than the preset weight sum threshold, it indicates that the witness pass information received from each of the first target witness devices satisfies the witness pass condition in the witness information plaintext obtained by the decryption.

Here, the witness user identification and the witness weight in the witness information are received by the issuer device as user inputs. In general, a user of a publisher device (which may be referred to as a publisher) may set a prover weight in terms of a proportion of revenue to a target digital asset, the proportion of revenue of the prover to the target digital asset being positively correlated with the prover weight of the prover.

With continued reference to FIG. 3E due to page display limitations, it should be noted that the flow of FIG. 3E may include the steps shown in FIG. 3A in addition to the steps shown in FIG. 3E. In addition, it should be noted that the issuer device and the witness device shown in fig. 3E may perform the respective steps that the issuer device and the witness device shown in fig. 3A may perform, in addition to the respective steps shown in fig. 3E.

In some implementations of this embodiment, the authorization content information may include an authorization environment identifier set, and the system for issuing a certificate may further include a user equipment configured to set a trusted execution environment. Thus, the sequence 300 may further include the following steps 310 and 311:

in step 310, the ue determines an intermediary authorization certificate ciphertext corresponding to the digital asset ciphertext to be decrypted in response to detecting a decryption request for the digital asset ciphertext to be decrypted.

Here, the user equipment may employ various implementations to detect a decryption request for the digital asset ciphertext to be decrypted. For example, the user device may determine that a decryption request is detected when it is detected that a user accesses a digital asset decryption page including a page element (e.g., a file selection button) for the user to input a digital asset to be decrypted, and a file address where the digital asset to be decrypted is located is input in the page element for the user to input the digital asset to be decrypted. For another example, the issuer device may determine that the decryption request is detected when detecting that the user opens a digital asset decryption interface in an application installed on the user device, inputs a file address of the digital asset to be decrypted, and clicks a control (e.g., a button) associated with a digital asset decryption operation.

Here, the user equipment may determine the middleman authorization certificate ciphertext corresponding to the digital asset ciphertext to be decrypted in various implementations. For example, the user may use the user device to receive an intermediary authorization certificate ciphertext in an email sent by the intermediary device for the digital asset ciphertext to be decrypted, and store the intermediary authorization certificate ciphertext as the intermediary authorization certificate ciphertext corresponding to the digital asset ciphertext to be decrypted. For another example, the user may also use the user device to click a website link provided by the middleman device for downloading the ciphertext of the middleman authorization certificate to be decrypted, so as to download the ciphertext of the middleman authorization certificate. For another example, the user may also copy the authorization certificate ciphertext directly from the facilitator device to the user device via the usb disk.

After step 310 is executed, step 311 is continued.

Step 311, the user equipment performs a digital asset decryption operation in the trusted execution environment of the user equipment to obtain a digital asset plaintext corresponding to the digital asset ciphertext to be decrypted.

Here, the digital asset decryption operation may include sub-steps 3111 and 3112 as shown in fig. 3F:

substep 3111, in the trusted execution environment of the user equipment, decrypting the determined middleman authorization certificate ciphertext by using the authorization certificate key stored in the trusted execution environment of the user equipment to obtain a middleman authorization certificate plaintext.

Here, the authorization credential key stored in the trusted execution environment of the facilitator device, the authorization credential key stored in the trusted execution environment of the issuer device, and the authorization credential key stored in the trusted execution environment of the user device are all the same. Also, the authorization credential key may be stored within the trusted execution environment of the user device but not outside the trusted execution environment of the user device, and programs within the trusted execution environment of the user device may access the authorization credential key but programs outside the trusted execution environment of the user device may not. Due to the characteristics of the authorization certificate key, the intermediate merchant authorization certificate ciphertext can be decrypted in the trusted execution environment of the user equipment to obtain the intermediate merchant authorization certificate plaintext, but the intermediate merchant authorization certificate ciphertext cannot be decrypted outside the trusted execution environment of the user equipment.

Step 3112, in response to determining that the environment identifier of the trusted execution environment of the user equipment belongs to the set of authorized user identifiers in the authorized content information in the plaintext of the obtained decrypted intermediary authorization certificate, decrypting the ciphertext of the digital asset to be decrypted by using the algorithm indicated by the decryption algorithm identifier in the plaintext of the obtained decrypted authorization certificate and the decryption key, so as to obtain the plaintext of the digital asset corresponding to the ciphertext of the digital asset to be decrypted.

Here, if the environment identifier of the trusted execution environment of the user equipment belongs to the set of authorized user identifiers in the authorized content information in the decrypted middle-dealer authorized document plaintext, which indicates that the middle-dealer has authorized the user equipment to use the digital asset to be decrypted, the digital asset ciphertext to be decrypted, which is the request for decryption and is detected in step 310, may be decrypted by using the algorithm indicated by the decryption algorithm identifier in the authorized document plaintext obtained by decryption in sub-step 3111 and the decryption key, so as to obtain the digital asset plaintext corresponding to the digital asset ciphertext to be decrypted.

Through steps 310 and 311, the ue may decrypt the digital asset to be decrypted and obtain the plaintext of the corresponding digital asset.

In some implementations of the present embodiment, the timing sequence 300 may further include the following steps 312 to 316:

in step 312, the issuer device, in response to detecting the multiparty witness information encryption request, performs witness information generation and information encryption operations in a trusted execution environment of the issuer device to obtain an information ciphertext and a witness information ciphertext corresponding to the information to be encrypted.

Here, the multiparty witness information encryption request may include information to be encrypted and corresponding second witness information parameter information, and the second witness information parameter information may include issuer user identification, witness information set, encryption algorithm identification, encryption key, decryption algorithm identification, decryption key, witness passing condition, and encryption information description information.

Here, the encryption information description information may be information that the issuer inputs using the issuer device to describe the content of the information to be encrypted to be issued. The encryption information description information may be audio data, text data, or picture data. For example, the encryption information description information for a piece of the will content to be encrypted may be information describing a prospective person, a legacy beneficiary, etc. of the piece of the will.

In practice, the issuer device may employ various implementations to detect the multi-party witness encryption request. For example, the issuer device may indicate that the issuer wishes to generate an information ciphertext and a witness message ciphertext corresponding to the input information to be encrypted in the case where it is detected that the user accesses a multiparty witness message encryption request information page for the issuer to input information to be encrypted and second witness message parameter information using the issuer device, and an issuer user identifier, a witness message set, an encryption algorithm identifier, an encryption key, a decryption algorithm identifier, a decryption key, a witness pass condition, and encryption information description information, etc., in the multiparty witness message encryption request information page, at which point the issuer device may determine that the multiparty witness message encryption request is detected. For another example, the issuer device may further indicate that the issuer wishes to generate an information ciphertext and a witness information ciphertext corresponding to the input information to be encrypted when detecting that the user opens a multiparty witness information encryption request interface for the user to input information to be encrypted and second witness information parameter information in a multiparty witness information encryption application installed on the issuer device, and the issuer device may determine that the multiparty witness information encryption request is detected when the issuer user identifier, the witness information set, the encryption algorithm identifier, the encryption key, the decryption algorithm identifier, the decryption key, the witness passing condition, the encryption information description information, and the like in the information to be encrypted and the second witness information parameter information are input in the multiparty witness information encryption request interface.

Here, the witness generation and information encryption operation may include sub-steps 3121 to 3127 as shown in fig. 3G:

and a substep 3121, decrypting the issuer user identifier in the second witness information parameter information by using the user identifier key stored in the trusted execution environment of the issuer device, to obtain an issuer extended user identifier.

Here, since the issuer user id in the second witness information parameter information is the user id in the user id set of the issuer device, and the user id in the user id set of the issuer device is obtained by encrypting with the user id key stored in the trusted execution environment of the issuer device, and the user id keys stored in different issuer devices are the same, here, the issuer user id in the second witness information parameter information is decrypted by using the user id key stored in the trusted execution environment of the issuer device, so that the issuer extended user id can be obtained.

And a substep 3122 of generating second witness information.

Here, the second witness information may include parameter information of each parameter included in the second witness information parameter information. For example, the second witness information may include an issuer user identification, a set of witness information, an encryption algorithm identification, an encryption key, a decryption algorithm identification, a decryption key, witness pass conditions, and encryption information description information. It is to be understood that the second witness message may comprise, in addition to the above parameters, in practice at least one of the following: the witness information type identification, the check code, the witness information failure time, the byte number of the witness information fixed configuration information, the number of the witness and the byte number of the encryption information description information.

And a substep 3123 of setting the values of the parameters of the second witness message to the values of the corresponding parameters in the parameter information of the second witness message.

And a substep 3124 of updating the issuer user identifier in the second witness message to the environment identifier in the decrypted issuer extended user identifier.

Here, the issuer user id in the second witness information generated in sub-step 3122 may be updated to the environment id in the issuer extended user id decrypted in sub-step 3121. That is, the issuer user identification in the generated second witness information actually stores the environment identification of the trusted execution environment in the issuer device, rather than the user identification in the set of user identifications of the issuer device.

Sub-step 3125 updates the witness user id in each of the witness information sets in the second witness information to the witness environment id corresponding to the witness user id.

Here, the witness user id in each of the witness information sets in the second witness information generated in sub-step 3122 may be updated to the witness environment id corresponding to the witness user id. The prover environment id corresponding to the prover user id is an environment id in the extended user id obtained by decrypting the prover user id with a user id key stored in the trusted execution environment of the issuer device. That is, the witness user id in each of the witness information sets in the generated second witness information actually stores the environment id of the trusted execution environment in the witness device, rather than the user ids in the user id set of the witness device.

And a substep 3126 of encrypting the information to be encrypted by using the algorithm indicated by the encryption algorithm identifier in the second witness information parameter information and the encryption key to obtain an information ciphertext corresponding to the information to be encrypted and the second witness information.

And a substep 3127 of encrypting the second witness message with the witness message key stored in the trusted execution environment of the issuer device to obtain a witness message ciphertext corresponding to the message to be encrypted.

After step 312, the issuer device obtains the information ciphertext and the witness information ciphertext corresponding to the information to be encrypted, and then the issuer device may provide the information ciphertext and the witness information ciphertext to the user in various implementation manners, which may specifically refer to the description of the broker apparatus providing the broker authorization certificate ciphertext to the user in step 203 of the embodiment shown in fig. 2A, and is not described herein again.

Step 313, in response to detecting the multiparty witness information decryption request, the user equipment performs multiparty witness information ciphertext decryption operation in a trusted execution environment of the user equipment to obtain information plaintext corresponding to the information ciphertext to be decrypted.

Here, the user equipment may employ various implementations to detect the multi-party witness decryption request. For example, the user equipment may determine that an information ciphertext decryption request is detected when it is detected that the user accesses an information ciphertext decryption page including a page element (e.g., a file selection button) for inputting an information ciphertext to be decrypted by the user, and a file address where the information ciphertext to be decrypted and a corresponding witness information ciphertext are located is input in the page element for inputting the information ciphertext to be decrypted by the user. For another example, the issuer device may determine that the information ciphertext decryption request is detected when detecting that the user opens an information ciphertext decryption interface in an application installed on the user device, inputs a file address where the information ciphertext to be decrypted and the corresponding witness information ciphertext are located, and clicks a control (e.g., a button) associated with the information ciphertext operation.

Here, the multiparty witness information decryption request may include a to-be-decrypted information ciphertext and a corresponding witness information ciphertext.

Here, the multiparty witness message ciphertext decryption operation may include sub-step 3131 to sub-step 3133 as shown in fig. 3H:

sub-step 3131, decrypting the witness message ciphertext in the multiparty witness message decryption request with the witness message key stored in the trusted execution environment of the ue to obtain a witness message plaintext.

Here, the witness key stored in the trusted execution environment of the user device is the same as the witness key stored in the trusted execution environment of the issuer device, and the witness key may be stored within the trusted execution environment of the user device but may not be stored outside the trusted execution environment of the user device, and programs within the trusted execution environment of the user device may access the witness key but programs outside the trusted execution environment of the user device may not access the witness key. Due to the characteristics of the witness key, the witness ciphertext can be decrypted within the trusted execution environment of the user device to obtain the witness plaintext, but the witness ciphertext cannot be decrypted outside the trusted execution environment of the user device.

Sub-step 3132, sending the witness message ciphertext in the multiparty witness message decryption request to each second target witness device.

Here, the second target witness device is the witness device indicated by the witness user identification in the witness information in the set of witness information in the witness information plaintext decrypted in sub-step 3131.

Sub-step 3133, in response to determining that the witness pass information received from each second witness device satisfies the witness pass condition in the decrypted witness information plaintext, decrypting the to-be-decrypted information ciphertext using the algorithm indicated by the encryption algorithm identifier in the decrypted witness information plaintext and the encryption key to obtain an information plaintext corresponding to the to-be-decrypted information ciphertext.

So that the ue can use the plaintext information corresponding to the ciphertext of the information to be decrypted, via step 313.

In step 314, in response to receiving the witness information ciphertext sent by the user device, the witness device decrypts the received witness information ciphertext with the witness information key stored in the trusted execution environment of the witness device to obtain a witness information plaintext.

Here, the witness device may decrypt, in the trusted execution environment of the witness device, the received witness ciphertext using the witness key stored in the trusted execution environment of the witness device to obtain the witness plaintext, upon receiving the witness ciphertext transmitted by the user device.

In step 315, the witness device presents the decrypted witness information in clear.

Here, the witness device may present the plaintext of the witness information decrypted in step 314 in various implementations.

In step 316, the witness device generates witness pass information in response to detecting a witness agreement operation entered by the user in respect of the presented plaintext of witness information, and transmits the generated witness pass information to the user device that transmitted the received witness information ciphertext.

Since the witness information plaintext decrypted in step 314 is presented in the witness device in step 315, the user can thus determine whether the witness has passed through the witness information plaintext presented in the witness device. If the user passes the witness, a witness approval operation may be input using the witness device (e.g., the user may input the witness approval operation by clicking a button associated with the witness approval operation), if the witness device detects the witness approval operation input by the user in the clear text of the presented witness information, witness pass information may be generated, and the generated witness pass information may be transmitted to the user device that transmitted the received witness information ciphertext.

Here, how to generate the witness passing information may refer to the related description in step 206 in the embodiment shown in fig. 2A or may also refer to the related descriptions in sub-step 3091 to sub-step 3092 shown in fig. 3D, and is not described herein again.

It is understood that steps 314 through 316 may be performed after step 3132 is performed during the multiparty witness message ciphertext decryption operation performed by the user equipment in step 313. While the user device is performing the multi-party witness message ciphertext decryption operation, sub-step 3133 may be performed in real time as the witness device performs steps 314 through 316, and it is not necessary to wait until all witness devices have performed steps 314 through 316 to perform sub-step 3133, since it is possible that the witness pass information received from some of the witness devices may satisfy the witness pass condition required by sub-step 3133.

In some optional implementations of this embodiment, the authorization certificate parameter information and the authorization certificate may further include a certificate type identifier for indicating a certificate type.

In some optional implementation manners of this embodiment, the authorization certificate parameter information may further include certificate expiration time, and the first witness information parameter information, the second witness information parameter information, the first witness information, and the second witness information may further include witness information expiration time.

As can be seen from fig. 3, in comparison with the embodiment corresponding to fig. 2, in the timing sequence 300 of the system for issuing a certificate in the present embodiment, the issuer user id, the broker user id, and the witness user id used outside the trusted execution environments of the issuer device, the broker device, and the witness device are all user ids generated by the issuer device, the broker device, and the witness device in the respective trusted execution environments according to the environment ids of the trusted execution environments, and the issuer user id, the broker user id, and the witness user id used within the trusted execution environments of the issuer device, the broker device, and the witness device are all environment ids of the respective trusted execution environments of the issuer device, the broker device, and the witness device. Therefore, the scheme described by the embodiment can improve the security of the authorization certificate issuing process of the digital assets.

With further reference to fig. 4, a flow 400 of one embodiment of a method for issuing a credential as applied to a facilitator device in a system for issuing a credential, wherein the system issuer device, facilitator device, and witness device for issuing a credential each provide a trusted execution environment, is shown, the flow 400 of the method for issuing a credential comprising the steps of:

step 401, in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness message ciphertext sent by the issuer device, determining authorization content information for the received digital asset ciphertext.

In this embodiment, the specific operation of step 401 is substantially the same as the specific operation of step 202 in the embodiment shown in fig. 2A, and is not described herein again.

Step 402, executing a broker authorization certificate generation operation in a trusted execution environment of the broker device to obtain a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext.

In this embodiment, the specific operation of step 402 is substantially the same as the specific operation of step 203 in the embodiment shown in fig. 2A, and is not described herein again.

In some optional implementation manners of this embodiment, the user identifier of the facilitator device may be a user identifier in a user identifier set of the facilitator device, and the above-mentioned flow 400 may further include the following step 403:

step 403, in response to detecting a second user identifier generation request including a second user identifier category identifier, determining the second user identifier category identifier and the trusted execution environment of the intermediary device as a target user identifier category identifier and a target trusted execution environment, respectively, executing a user identifier generation operation in the determined target trusted execution environment, obtaining user identifiers corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and adding the obtained user identifiers to the user identifier set of the intermediary device.

Here, the specific operation of step 403 is substantially the same as the specific operation of step 302 in the embodiment shown in fig. 3A, and is not described again here.

In some optional implementations of this embodiment, the witness information may further include a witness weight, the witness passing condition may include a witness weight and a preset weight and a threshold value, and the determining that the witness passing information received from each first target witness device satisfies the witness passing condition in the decrypted witness information plaintext in the step 402 in the process of performing the broker-authorized-certificate generating operation may be performed as follows:

The witness sum may then be zeroed.

Next, for each target witness pass information in the set of target witness pass information, the following witness weighting and updating operations are performed: determining the witness information corresponding to the witness device which sends the target witness passing information in the witness information set in the witness information plaintext obtained by decryption; generating a witness information key according to the determined witness user identification in the witness information according to a preset algorithm; decrypting the target witness passing information by using the generated witness information key to obtain witness information key information; and in response to determining that the obtained witness information key information is the same as the preset key information in the witness information plaintext obtained through decryption, updating the witness weight sum as the sum of the witness weight sum and the witness weight in the determined witness information.

The method provided by the above embodiment of the present application determines the authorization content information for the digital asset ciphertext in the broker device, and then executes the broker authorization certificate generation operation in the trusted execution environment of the broker device to obtain the broker authorization certificate ciphertext corresponding to the digital asset ciphertext, thereby implementing the issue of the authorization certificate for the digital asset by the broker device.

With further reference to fig. 5, as an implementation of the method shown in the above-mentioned figures, the present application provides an embodiment of an apparatus for issuing a certificate, where the embodiment of the apparatus corresponds to the embodiment of the method shown in fig. 4, and the apparatus is particularly applicable to various electronic devices provided with trusted execution environments.

As shown in fig. 5, the apparatus 500 for issuing a certificate of the present embodiment includes: a determination unit 501 and a generation unit 502. The determining unit 501 is configured to determine, in response to receiving a digital asset ciphertext, an authorization certificate ciphertext and a witness message ciphertext transmitted by an issuer device, authorization content information for the received digital asset ciphertext; a generating unit 502, configured to execute a broker authorization certificate generating operation in a trusted execution environment of the broker device, to obtain a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext, where the broker authorization certificate generating operation includes: decrypting the received witness information ciphertext by using the witness information key stored in the trusted execution environment of the intermediary device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the facilitator device to obtain a witness information ciphertext of the facilitator; transmitting the facilitator witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identifier in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each of the first target witness devices meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to determining that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness certificate plaintext and that the broker user identifier in the decrypted witness certificate plaintext and the broker user identifier in the decrypted witness certificate plaintext are both user identifiers of the broker device, generating a broker authorization certificate, setting values of various parameters in the broker authorization certificate as values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating the authorization content information in the broker authorization certificate to the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using the authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

In this embodiment, specific processes of the determining unit 501 and the generating unit 502 of the apparatus 500 for issuing a certificate and technical effects brought by the specific processes may refer to related descriptions of step 401 and step 402 in the corresponding embodiment of fig. 4, which are not described herein again.

In some optional implementation manners of this embodiment, the user identifier of the facilitator device may be a user identifier in the user identifier set of the facilitator device; and the apparatus 500 may further include: an adding unit 403, configured to, in response to detecting a second user identifier generation request including a second user identifier category identifier, determine the second user identifier category identifier and the trusted execution environment of the intermediary device as a target user identifier category identifier and a target trusted execution environment, respectively, in the determined target trusted execution environment, perform a user identifier generation operation, obtain a user identifier corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and add the obtained user identifier to a user identifier set of the intermediary device, where the user identifier generation operation includes: acquiring an environment identifier which is used for indicating the target trusted execution environment and comprises a manufacturer identifier and a product identifier; randomly generating a random number; and encrypting an extended user identifier by using a user identifier key stored in the target trusted execution environment to obtain a user identifier corresponding to the target user identifier category identifier and the target trusted execution environment, wherein the extended user identifier comprises the acquired environment identifier, the generated random number and the target user identifier category identifier.

In some optional implementations of this embodiment, the witness information may further include a witness weight, and the witness passing condition may include the witness weight and a preset weight and a threshold value greater than or equal to each other; and the determining that the witness pass information received from each of the first target witness devices satisfies the witness pass condition in the decrypted witness information plaintext may include: determining witness passing information received from each first target witness device within a preset time period as a target witness passing information set; setting witness weight sum to zero; for each target witness pass information in the set of target witness pass information, performing the following witness weighting and updating operations: determining the witness information corresponding to the witness device which sends the target witness passing information in the witness information set in the witness information plaintext obtained by decryption; generating a witness information key according to the determined witness user identifier in the witness information according to the preset algorithm; decrypting the target witness passing information by using the generated witness information key to obtain witness information key information; in response to determining that the obtained witness key information is the same as the preset key information in the decrypted witness information plaintext, updating the witness weight sum to a sum of the witness weight sum and a witness weight in the determined witness information plaintext; in response to determining that the witness weight sum is equal to or greater than the preset weight sum threshold, determining that witness pass information received from each of the first target witness devices satisfies witness pass conditions in the decrypted witness information plaintext.

It should be noted that, for details of implementation and technical effects of each unit in the apparatus for issuing a certificate provided in the embodiment of the present application, reference may be made to descriptions of other embodiments in the present application, and details are not described herein again.

Referring now to FIG. 6, shown is a block diagram of a computer system 600 suitable for use in implementing the electronic device of an embodiment of the present application. The electronic device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM602, and RAM 603 are connected to each other via a bus 604. An Input/Output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output section 607 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN (Local area network) card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the method of the present application when executed by a Central Processing Unit (CPU) 601. It should be noted that the computer readable medium described herein can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, Python, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a determination unit and a generation unit. Where the names of these units do not in some cases constitute a limitation on the unit itself, for example, the determination unit may also be described as a "unit that determines authorized content information".

As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be present separately and not assembled into the device. The computer readable medium carries one or more programs which, when executed by the apparatus, cause the apparatus to: in response to receiving a digital asset ciphertext, an authorization certificate ciphertext, and a witness message ciphertext transmitted by an issuer device, determining authorization content information for the received digital asset ciphertext; executing an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device to obtain an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authorization certificate generation operation comprises: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using a witness information key stored in a trusted execution environment of the intermediate merchant device to obtain an intermediate merchant witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identification in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each first target witness device meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to the fact that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness information plaintext, and the decrypted authorization certificate plaintext and the decrypted middle merchant user identifier in the witness information plaintext are both user identifiers of middle merchant equipment, generating a middle merchant authorization certificate, setting the value of each parameter in the middle merchant authorization certificate as the value of the corresponding parameter in the decrypted authorization certificate plaintext, and updating the authorization content information in the middle merchant authorization certificate into the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using the authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims

1. A system for issuing a credential comprising an issuer device, a facilitator device, and a witness device, each of which sets a trusted execution environment, wherein:

an issuer device configured to: in response to detecting a ciphertext generation request that includes a target digital asset, authorization credential parameter information, and first credential information parameter information, wherein the authorization credential parameter information and the first credential information parameter information each include: the first certificate information parameter information further includes an encryption algorithm identifier, an encryption key, a decryption algorithm identifier and a decryption key: the witness passing condition, the digital asset description information and the witness information are collected, the witness information includes a witness user identifier, in a trusted execution environment of the issuer device, a ciphertext generation operation is executed to obtain a digital asset ciphertext, an authorization certificate ciphertext and a witness information ciphertext corresponding to the target digital asset, and the obtained digital asset ciphertext, the authorization certificate ciphertext and the witness information ciphertext are sent to an intermediary device indicated by an intermediary user identifier in the authorization certificate parameter information, wherein the ciphertext generation operation includes: generating an authorization certificate, and setting the value of each parameter of the authorization certificate as the value of the corresponding parameter in the authorization certificate parameter information; encrypting the authorization certificate by using an authorization certificate key stored in a trusted execution environment of the issuer device to obtain an authorization certificate ciphertext corresponding to the target digital asset; generating first witness information, and setting values of various parameters of the first witness information as values of corresponding parameters in the first witness information parameter information; encrypting the first witness information by using a witness information key stored in a trusted execution environment of the issuer device to obtain a witness information ciphertext corresponding to the target digital asset; encrypting the target digital asset by using the algorithm indicated by the encryption algorithm identification in the authorization certificate parameter information and an encryption key to obtain a digital asset ciphertext corresponding to the target digital asset;

a middleman device configured to: in response to receiving a digital asset ciphertext, an authorization certificate ciphertext and a witness information ciphertext sent by an issuer device, determining authorization content information for the received digital asset ciphertext, and executing an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device to obtain an intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authorization certificate generation operation includes: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediary device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the intermediary equipment to obtain an intermediary witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identifier in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each of the first target witness devices meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to determining that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness certificate plaintext and that the broker user identifier in the decrypted witness certificate plaintext and the broker user identifier in the decrypted witness certificate plaintext are both user identifiers of the broker device, generating a broker authorization certificate, setting values of various parameters in the broker authorization certificate as values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating authorization content information in the broker authorization certificate to the determined authorization content information; encrypting the intermediate merchant authorization certificate by using an authorization certificate key stored in a trusted execution environment of the intermediate merchant device to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext;

a witness device configured to: in response to receiving the witness information ciphertext transmitted by the facilitator device, decrypting the received witness information ciphertext in the trusted execution environment of the witness device by using the witness information key stored in the trusted execution environment of the witness device to obtain a witness information plaintext; presenting the plaintext of the witness information obtained by decryption; in response to detecting a witness agreement operation entered by the user in the clear text of the presented witness information, generating witness passing information, and transmitting the generated witness passing information to the facilitator device that transmitted the received witness information ciphertext.

2. The system of claim 1, wherein the issuer user identifications in the authorization credential parameter information and the first credential information parameter information are user identifications in a set of user identifications of issuer devices; and

an issuer device configured to: in response to detecting a first user identification generation request including a first user identification category identification, determining the first user identification category identification and the trusted execution environment of the issuer device as a target user identification category identification and a target trusted execution environment, respectively, in the determined target trusted execution environment, performing a user identification generation operation, obtaining user identifications corresponding to the determined target user identification category identification and the determined target trusted execution environment, and adding the obtained user identifications to a user identification set of the issuer device, wherein the user identification generation operation includes: acquiring an environment identifier which is used for indicating the target trusted execution environment and comprises a manufacturer identifier and a product identifier; randomly generating a random number; and encrypting an extended user identifier by using a user identifier key stored in the target trusted execution environment to obtain a user identifier corresponding to the target user identifier category identifier and the target trusted execution environment, wherein the extended user identifier comprises the acquired environment identifier, the generated random number and the target user identifier category identifier.

3. The system of claim 2, wherein the intermediary merchant user identification in the authorization credential parameter information and the first credential information parameter information is a user identification in a set of user identifications of intermediary devices; and

a middleman device configured to: in response to detecting a second user identifier generation request including a second user identifier category identifier, determining the second user identifier category identifier and the trusted execution environment of the intermediary device as a target user identifier category identifier and a target trusted execution environment, respectively, executing the user identifier generation operation in the determined target trusted execution environment, obtaining user identifiers corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and adding the obtained user identifiers to a user identifier set of the intermediary device.

4. The system of claim 3 wherein the witness user identities in the witness information in the first witness information parameter information set are user identities in a set of user identities of a witness device; and

a witness device configured to: in response to detecting a third user identity generation request comprising a third user identity class identity, determining the third user identity class identity and the trusted execution environment of the witness device as a target user identity class identity and a target trusted execution environment, respectively, performing the user identity generation operation in the determined target trusted execution environment, resulting in a user identity corresponding to the determined target user identity class identity and the determined target trusted execution environment, and adding the resulting user identity to the set of user identities of the witness device.

5. The system of claim 4, wherein after setting the values of the parameters of the authorization certificate as the values of the corresponding parameters in the authorization certificate parameter information, the ciphertext generation operation further comprises:

respectively decrypting an issuer user identifier and a middleman user identifier in the authorization certificate parameter information and the first witness information parameter information by using a user identifier key stored in a trusted execution environment of the issuer device to obtain an issuer extended user identifier and a middleman extended user identifier;

respectively updating an issuer user identifier and a middleman user identifier in the authorization certificate to an environment identifier in the issuer extended user identifier and an environment identifier in the middleman extended user identifier; and

after setting the values of the parameters of the first witness information to the values of the corresponding parameters in the first witness information parameter information, the ciphertext generation operation further comprises:

respectively updating the issuer user identification and the middleman user identification in the first witness information to an environment identification in the issuer extended user identification and an environment identification in the middleman extended user identification; and updating the witness user identifier in each witness information in the witness information set in the first witness information to a witness environment identifier corresponding to the witness user identifier, wherein the witness environment identifier corresponding to the witness user identifier is an environment identifier in the extended user identifiers obtained by decrypting the witness user identifier by using the user identifier key stored in the trusted execution environment of the issuer device.

6. The system of claim 5, wherein the witness device is configured to: generating witness passing information, comprising:

a witness device configured to: performing the following witness passing information generating operations in the trusted execution environment of the witness device to obtain witness passing information corresponding to the received witness information ciphertext, the witness passing information generating operations comprising: responding to the integrity check of the witness information plaintext obtained by decryption, and generating a witness information key according to the environment identifier of the trusted execution environment of the witness equipment and a preset algorithm; and encrypting the preset key information in the decrypted witness information plaintext by using the generated witness information key to obtain witness passing information corresponding to the received witness information ciphertext.

7. The system according to claim 6, wherein the witness information further includes a witness weight, the witness passing condition includes a sum of the witness weight and a preset weight and a threshold value; and

an intermediary device configured to determine that witness pass information received from each of the first target witness devices satisfies witness pass conditions in the decrypted witness information plaintext, comprising:

a middleman device configured to:

determining witness passing information received from each first target witness device within a preset time period as a target witness passing information set;

setting witness weight sum to zero;

for each target witness pass information in the set of target witness pass information, performing the following witness weighting and updating operations: determining the witness information corresponding to the witness device which sends the target witness passing information in the witness information set in the witness information plaintext obtained by decryption; generating a witness information key according to the determined witness user identifier in the witness information according to the preset algorithm; decrypting the target witness passing information by using the generated witness information key to obtain witness information key information; in response to determining that the obtained witness key information is the same as the preset key information in the decrypted witness plain text, updating the witness weight sum to be the sum of the witness weight sum and the witness weight in the determined witness information;

in response to determining that the witness weight sum is greater than or equal to the preset weight sum threshold, determining that witness pass information received from each of the first target witness devices satisfies witness pass conditions in the decrypted witness information plaintext.

8. The system of any one of claims 1-7, wherein the authorization content information includes a set of authorization context identifiers, the system further comprising a user device to set a trusted execution context; and

a user equipment configured to: in response to detecting a decryption request for a digital asset ciphertext to be decrypted, determining an intermediary authorization certificate ciphertext corresponding to the digital asset ciphertext to be decrypted; in a trusted execution environment of the user equipment, performing a digital asset decryption operation to obtain a digital asset plaintext corresponding to the digital asset ciphertext to be decrypted, wherein the digital asset decryption operation comprises: decrypting the determined intermediate merchant authorization certificate ciphertext by using an authorization certificate key stored in a trusted execution environment of the user equipment to obtain an intermediate merchant authorization certificate plaintext; and in response to determining that the environment identifier of the trusted execution environment of the user equipment belongs to the set of authorized user identifiers in the authorized content information in the decrypted middle merchant authorization document plaintext, decrypting the digital asset ciphertext to be decrypted by using the algorithm indicated by the decryption algorithm identifier in the decrypted authorization document plaintext and the decryption key to obtain the digital asset plaintext corresponding to the digital asset ciphertext to be decrypted.

9. The system of claim 8, wherein:

the issuer device is further configured to: in response to detecting a multi-party witness information encryption request, wherein the multi-party witness information encryption request comprises information to be encrypted and corresponding second witness information parameter information, the second witness information parameter information comprises issuer user identification, a witness information set, an encryption algorithm identification, an encryption key, a decryption algorithm identification, a decryption key, a witness passing condition and encryption information description information, in a trusted execution environment of the issuer device, witness information generation and information encryption operations are executed to obtain an information ciphertext and a witness information ciphertext corresponding to the information to be encrypted, and the witness information generation and information encryption operations comprise: decrypting the issuer user identifier in the second witness information parameter information by using a user identifier key stored in a trusted execution environment of the issuer device to obtain an issuer extended user identifier; generating second witness information; setting the values of all parameters of the second witness information as the values of corresponding parameters in the second witness information parameter information; updating the issuer user identifier in the second witness information into an environment identifier in the issuer extended user identifier obtained by decryption; updating the witness user identifier in each witness information in the witness information set in the second witness information to a witness environment identifier corresponding to the witness user identifier, wherein the witness environment identifier corresponding to the witness user identifier is an environment identifier in the extended user identifier obtained by decrypting the witness user identifier by using a user identifier key stored in the trusted execution environment of the issuer device; encrypting the information to be encrypted by using the algorithm indicated by the encryption algorithm identification in the second witness information parameter information and an encryption key to obtain an information ciphertext corresponding to the information to be encrypted; encrypting the second witness information by using a witness information key stored in a trusted execution environment of the issuer device to obtain a witness information ciphertext corresponding to the information to be encrypted;

a user equipment configured to: in response to detecting a multiparty witness information decryption request, wherein the multiparty witness information decryption request comprises a to-be-decrypted information ciphertext and a corresponding witness information ciphertext, executing multiparty witness information ciphertext decryption operation in a trusted execution environment of the user equipment to obtain an information plaintext corresponding to the to-be-decrypted information ciphertext, and the multiparty witness information ciphertext decryption operation comprises: decrypting the witness information ciphertext in the multiparty witness information decryption request by using the witness information key stored in the trusted execution environment of the user equipment to obtain a witness information plaintext; sending the witness information ciphertext in the multi-party witness information decryption request to each second target witness device, wherein the second target witness device is the witness device indicated by the witness user identifier in the witness information set in the witness information plaintext obtained through decryption; in response to determining that the witness passing information received from each of the second witness devices meets witness passing conditions in the decrypted witness information plaintext, decrypting the to-be-decrypted information ciphertext by using an algorithm and an encryption key indicated by the encryption algorithm identifier in the decrypted witness information plaintext to obtain an information plaintext corresponding to the to-be-decrypted information ciphertext;

a witness device configured to: in response to receiving the witness information ciphertext transmitted by the user equipment, decrypting the received witness information ciphertext in the trusted execution environment of the witness equipment by using a witness information key stored in the trusted execution environment of the witness equipment to obtain a witness information plaintext; presenting the plaintext of the witness information obtained by decryption; in response to detecting a witness agreement operation entered by the user in the clear text of the presented witness information, generating witness pass information, and transmitting the generated witness pass information to the user device that transmitted the received witness information ciphertext.

10. The system of claim 9, wherein the authorization credential parameter information and the authorization credential further comprise a credential type identifier.

11. The system of claim 10, wherein the authorization credential parameter information further includes a credential expiration time, the first witness parameter information, the second witness parameter information, the first witness information, and the second witness information further including the witness expiration time.

12. A method for issuing a credential for use with a facilitator device in a system for issuing credentials, the system for issuing credentials including an issuer device, a facilitator device, and a witness device, each of the issuer device, facilitator device, and witness device providing a trusted execution environment, the method comprising:

in response to receiving a digital asset ciphertext, an authorization certificate ciphertext, and a witness message ciphertext transmitted by an issuer device, determining authorization content information for the received digital asset ciphertext;

executing an intermediary authority certificate generation operation in a trusted execution environment of the intermediary device to obtain an intermediary authority certificate ciphertext corresponding to the received digital asset ciphertext, wherein the intermediary authority certificate generation operation comprises: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediary device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the intermediary equipment to obtain an intermediary witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identifier in the witness information set in the witness information plaintext obtained through decryption; in response to determining that witness passing information received from each of the first target witness devices meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to determining that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness certificate plaintext and that the broker user identifier in the decrypted witness certificate plaintext and the broker user identifier in the decrypted witness certificate plaintext are both user identifiers of the broker device, generating a broker authorization certificate, setting values of various parameters in the broker authorization certificate as values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating authorization content information in the broker authorization certificate to the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using an authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

13. The method of claim 12, wherein the user identification of the facilitator device is a user identification of a set of user identifications of the facilitator device; and

the method further comprises the following steps:

in response to detecting a second user identifier generation request including a second user identifier category identifier, respectively determining the second user identifier category identifier and a trusted execution environment of the intermediary device as a target user identifier category identifier and a target trusted execution environment, in the determined target trusted execution environment, performing a user identifier generation operation to obtain a user identifier corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and adding the obtained user identifier to a user identifier set of the intermediary device, wherein the user identifier generation operation includes: acquiring an environment identifier which is used for indicating the target trusted execution environment and comprises a manufacturer identifier and a product identifier; randomly generating a random number; and encrypting an extended user identifier by using a user identifier key stored in the target trusted execution environment to obtain a user identifier corresponding to the target user identifier category identifier and the target trusted execution environment, wherein the extended user identifier comprises the acquired environment identifier, the generated random number and the target user identifier category identifier.

14. The method of claim 13 wherein the witness information further includes witness weights, the witness passing condition including a sum of the witness weights being equal to or greater than a preset weight and a threshold; and

the determining that witness pass information received from each of the first target witness devices satisfies witness pass conditions in the decrypted witness information plaintext includes:

setting witness weight sum to zero;

15. An apparatus for issuing a credential for use with a facilitator device in a system for issuing credentials, the system for issuing credentials including an issuer device, a facilitator device, and a witness device, each of the issuer device, the facilitator device, and the witness device providing a trusted execution environment, the apparatus comprising:

a determining unit configured to determine, in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness message ciphertext transmitted by the issuer device, authorization content information for the received digital asset ciphertext;

a generating unit configured to execute a broker authorization certificate generation operation in a trusted execution environment of the broker device, resulting in a broker authorization certificate ciphertext corresponding to the received digital asset ciphertext, wherein the broker authorization certificate generation operation includes: decrypting the received witness information ciphertext by using a witness information key stored in a trusted execution environment of the intermediary device to obtain a witness information plaintext; updating the authorization content information in the witness information plaintext obtained by decryption into the determined authorization content information; encrypting the updated decrypted witness information plaintext by using the witness information key stored in the trusted execution environment of the intermediary equipment to obtain an intermediary witness information ciphertext; sending the intermediate quotient witness information ciphertext to each first target witness device, wherein the first target witness device is the witness device indicated by the witness user identifier in the witness information set in the witness information plaintext obtained through decryption; in response to determining that witness passing information received from each of the first target witness devices meets witness passing conditions in the decrypted witness information plaintext, decrypting the received authorization certificate ciphertext with an authorization certificate key stored in a trusted execution environment of the facilitator device to obtain an authorization certificate plaintext; in response to determining that the issuer user identifier and the certificate identifier in the decrypted authorization certificate plaintext are respectively the same as the corresponding parameters in the decrypted witness certificate plaintext and that the broker user identifier in the decrypted witness certificate plaintext and the broker user identifier in the decrypted witness certificate plaintext are both user identifiers of the broker device, generating a broker authorization certificate, setting values of various parameters in the broker authorization certificate as values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating authorization content information in the broker authorization certificate to the determined authorization content information; and encrypting the intermediate merchant authorization certificate by using an authorization certificate key stored in the trusted execution environment of the intermediate merchant equipment to obtain an intermediate merchant authorization certificate ciphertext corresponding to the received digital asset ciphertext.

16. The apparatus of claim 15, wherein the user identification of the facilitator device is a user identification of a set of user identifications of the facilitator device; and

the device further comprises:

an adding unit configured to, in response to detecting a second user identifier generation request including a second user identifier category identifier, determine the second user identifier category identifier and a trusted execution environment of the intermediary device as a target user identifier category identifier and a target trusted execution environment, respectively, execute, in the determined target trusted execution environment, a user identifier generation operation to obtain a user identifier corresponding to the determined target user identifier category identifier and the determined target trusted execution environment, and add the obtained user identifier to a user identifier set of the intermediary device, wherein the user identifier generation operation includes: acquiring an environment identifier which is used for indicating the target trusted execution environment and comprises a manufacturer identifier and a product identifier; randomly generating a random number; and encrypting an extended user identifier by using a user identifier key stored in the target trusted execution environment to obtain a user identifier corresponding to the target user identifier category identifier and the target trusted execution environment, wherein the extended user identifier comprises the acquired environment identifier, the generated random number and the target user identifier category identifier.

17. The apparatus of claim 16 wherein the witness information further comprises witness weights, the witness passing condition comprising a sum of the witness weights and a preset weight and threshold; and

setting witness weight sum to zero;

18. An electronic device, comprising:

one or more processors;

a storage device having one or more programs stored thereon,

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 12-14.

19. A computer-readable storage medium, having a computer program stored thereon, wherein the computer program, when executed by one or more processors, implements the method of any one of claims 12-14.