WO2020048290A1 - 用于发行证书的系统和方法 - Google Patents

用于发行证书的系统和方法 Download PDF

Info

Publication number
WO2020048290A1
WO2020048290A1 PCT/CN2019/099944 CN2019099944W WO2020048290A1 WO 2020048290 A1 WO2020048290 A1 WO 2020048290A1 CN 2019099944 W CN2019099944 W CN 2019099944W WO 2020048290 A1 WO2020048290 A1 WO 2020048290A1
Authority
WO
WIPO (PCT)
Prior art keywords
witness
information
user
ciphertext
execution environment
Prior art date
Application number
PCT/CN2019/099944
Other languages
English (en)
French (fr)
Inventor
程强
Original Assignee
深圳市红砖坊技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳市红砖坊技术有限公司 filed Critical 深圳市红砖坊技术有限公司
Publication of WO2020048290A1 publication Critical patent/WO2020048290A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/16Program or content traceability, e.g. by watermarking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities

Definitions

  • the embodiments of the present application relate to the field of computer technology, and in particular, to a system and method for issuing a certificate.
  • Digital rights protection (Digital Rights Management, DRM) is the main method of copyright protection of digital works spreading on the Internet. However, DRM does not address the process of how digital rights decompose control rights in the manner of common assets, and transform the transfer of use rights into a license (authorization certificate) issue process.
  • a music producer creates a song.
  • he can only commission an intermediary (for example, a record company, a cloud music operator, etc.) to sell.
  • intermediary for example, a record company, a cloud music operator, etc.
  • music producers cannot understand the sales methods and sales volume of middlemen, so music producers cannot correlate their remuneration with the actual sales of middlemen.
  • the embodiments of the present application propose a system and method for issuing a certificate.
  • an embodiment of the present application provides a system for issuing a certificate.
  • the system includes: an issuer device, an intermediary device, and a witness device.
  • the issuer device, the intermediary device, and the witness device are all trusted.
  • the execution environment, wherein the issuer device is configured to respond to detecting a ciphertext generation request including 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
  • the parameter information includes: certificate type, issuer user ID, certificate ID, and broker user ID.
  • the authorization certificate parameter information also includes the encryption algorithm ID, encryption key, decryption algorithm ID, and decryption key.
  • the first witness information parameter information also Including: Witness pass conditions, digital asset description information, and witness information collection.
  • witness information includes the witness user ID.
  • the ciphertext generation operation is performed to obtain the corresponding digital asset.
  • Digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext and Send the obtained digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext to the intermediary device indicated by the intermediary user ID in the authorization certificate parameter information, where the ciphertext generation operation includes generating an authorization certificate, and Set the value of each parameter of the authorization certificate to the value of the corresponding parameter in the parameter information of the authorization certificate; use the authorization certificate key stored in the trusted execution environment of the issuer's device to encrypt the authorization certificate to obtain the corresponding digital asset Ciphertext of the authorization certificate; 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; using the issuer device's trusted execution environment to store Encrypts the first witness information to obtain the ciphertext of the witness information
  • the middleware authorization certificate is generated, and the middleware authorization certificate is The value of each parameter is set to the value of the corresponding parameter in the clear text of the authorized certificate obtained by decryption, and the authorized content information in the middleman authorization certificate is updated to the determined authorized content information; using the trusted execution environment of the middleman device Stored authorization certificate key encrypts the middleman authorization certificate Obtain the ciphertext of the intermediary authorization certificate corresponding to the received digital asset ciphertext; the witness device is configured to: in response to receiving the ciphertext of the witness information sent by the intermediary device, perform credible execution on the witness device The environment uses the witness information key stored in the trusted execution environment of the witness device to decrypt the received witness information ciphertext to obtain the plaintext of the witness information; present the decrypted plaintext of the witness information; in response to detecting the user's The presented witness information is entered in plain text to agree to the operation, generate witness pass information, and send the generated witness pass information to the intermediary device that sends the received cipher text of the witness information.
  • an embodiment of the present application provides a method for issuing a certificate, which is applied to an intermediary device in a system for issuing a certificate.
  • the system for issuing a certificate includes an issuer device, an intermediary device, and a witness.
  • the publisher device, the publisher device, the broker device, and the witness device all set a trusted execution environment.
  • the method includes: in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness information ciphertext sent by the publisher device, determining Authorized content information for the received digital asset ciphertext; perform the middleman authorization certificate generation operation in the trusted execution environment of the middleman device to obtain the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext Among them, the middleman authorized certificate generation operation includes: using the witness information key stored in the trusted execution environment of the middleman device to decrypt the received witness information ciphertext to obtain the plaintext of the witness information; decrypting the plaintext of the witness information The authorized content information in the update to the determined authorized content information; using the trusted execution environment of the middleman device The stored witness information key encrypts the updated plaintext of the decrypted witness information to obtain the middleman witness information ciphertext; sends the middleman witness information ciphertext to each first target witness device, where the first target witness The witness device is the witness device indicated by the witness user ID in the witness information set in the
  • the authorization certificate key stored in the environment encrypts the middleman authorization certificate to obtain the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • an embodiment of the present application provides a device for issuing a certificate, which is applied to an intermediary device in a system for issuing a certificate.
  • the system for issuing a certificate includes an issuer device, an intermediary device, and a witness
  • the device, the issuer device, the intermediary device, and the witness device all set a trusted execution environment.
  • the device includes a determination unit configured to respond to receiving the digital asset ciphertext, authorization certificate ciphertext, and witness sent by the issuer device.
  • the generation unit is configured to perform the middleman authorized certificate generation operation in the trusted execution environment of the middleman device, and obtain the same number as the received number
  • the ciphertext of the intermediary authorization certificate corresponding to the asset ciphertext wherein the operation of generating the intermediary authorization certificate includes: using the witness information key stored in the trusted execution environment of the intermediary device to decrypt the received witness information ciphertext
  • the plaintext of the witness information the authorized content information in the plaintext of the decrypted witness information is updated to the determined authorized content
  • the middleman user identification in the clear text of the message is used by the middleman device Identification, generating a middleman authorization certificate, setting the values of various parameters in the middleman authorization certificate to the values of the corresponding parameters in the decrypted authorization certificate plaintext, and updating the authorization content information in the middleman authorization certificate to the determined authorization Content information; the authorization certificate key stored in the trusted execution environment of the middleman device is used to encrypt the middleman authorization certificate to obtain the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • an embodiment of the present application provides an electronic device including: one or more processors; a storage device storing one or more programs thereon; and when the one or more programs are replaced by the one or more programs, When the processor executes, the one or more processors are caused to implement the method as described in any implementation manner of the second aspect.
  • an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, wherein when the computer program is executed by one or more processors, the computer program is implemented as described in any implementation manner in the second aspect.
  • the issuer of a digital asset uses the issuer device that sets up a trusted execution environment to specify authorization certificate parameter information and first witness parameter information for a target digital asset. Then generate the digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext corresponding to the target digital asset in the trusted execution environment of the issuer device, and generate the generated digital asset ciphertext, authorization certificate ciphertext, and witness information
  • the ciphertext is sent to the intermediary device indicated by the intermediary user ID in the authorization certificate parameter information, and then, the intermediary device determines the authorized content information for the received ciphertext of the digital asset, and In the letter execution environment, the middleman authorization certificate generation operation is performed, and the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext is obtained, so that the authorization certificate for digital assets is issued through the middleman, and the middleman
  • the middleman authorization certificate generation operation is performed, and the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext is obtained, so that
  • the ciphertext of the updated witness information of the right content information and determine that the witness pass information received from each witness device meets the witness pass conditions in the clear text of the witness information, that is, each time the intermediary issues a certificate All must be witnessed by the witness designated by the issuer, so that the witness can understand the authorization of the intermediary for digital assets.
  • FIG. 1 is an exemplary system architecture diagram to which an embodiment of the present application can be applied;
  • FIG. 1 is an exemplary system architecture diagram to which an embodiment of the present application can be applied;
  • FIG. 2A is a sequence diagram of an embodiment of a system for issuing a certificate according to the present application
  • 2B is a flowchart of an embodiment of a ciphertext generating operation according to the present application
  • 2C is a flowchart of an embodiment of an intermediary authorization certificate generation operation according to the present application.
  • 3A and 3E are timing diagrams of another embodiment of a system for issuing a certificate according to the present application.
  • 3B is a flowchart of an embodiment of a user identification generating operation according to the present application.
  • 3C is a flowchart of another embodiment of a ciphertext generating operation according to the present application.
  • FIG. 3D is a flowchart of one embodiment of a witness passing information generating operation according to the present application.
  • 3F is a flowchart of an embodiment of a digital asset decryption operation according to the present application.
  • 3G is a flowchart of an embodiment of witness information generation and information encryption operations according to the present application.
  • 3H is a flowchart of an embodiment of a multi-party witness information ciphertext decryption operation according to the present application
  • FIG. 4 is a flowchart of an embodiment of a method for issuing a certificate according to the present application
  • FIG. 5 is a schematic structural diagram of an embodiment of a device for issuing a certificate according to the present application.
  • FIG. 6 is a schematic structural diagram of a computer system suitable for implementing an electronic device according to an embodiment of the present application.
  • FIG. 1 illustrates an exemplary system architecture 100 of an embodiment of a system for issuing certificates or a method for issuing certificates to which the present application can be applied.
  • the system architecture 100 may include a publisher device 101, a broker device 102, a witness device 103, and a network 104.
  • the network 104 is used to provide a medium for a communication link between the issuer device 101, the broker device 102, and the witness device 103.
  • the network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, and so on.
  • Issuers of digital assets can use the issuer device 101 to interact with the intermediary device 102 through the network 104 to receive or send messages and the like.
  • Various communication client applications can be installed on the publisher device 101, such as applications for generating digital asset ciphertext, authorization certificate ciphertext and witness information ciphertext, web browser application, shopping application, search application, instant Communication tools, email clients, social platform software, etc.
  • the issuer device 101, the broker device 102, and the witness device 103 may be hardware or software.
  • the issuer device 101, the middleman device 102, and the witness device 103 are hardware, they can be various electronic devices with a display screen and a Trusted Execution Environment (TEE), including but not limited to smart phones, Tablets, laptops, and desktop computers.
  • TEE Trusted Execution Environment
  • the publisher device 101, the middleman device 102, and the witness device 103 are software, they can be installed in the electronic devices listed above. It can be implemented as multiple software or software modules or as a single software or software module. It is not specifically limited here.
  • TEE is an operating environment coexisting with Rich OS (usually Android, etc.) on the device, and provides security services for Rich OS.
  • Rich OS usually Android, etc.
  • TEE has its own execution space.
  • the software and hardware resources that TEE can access are separated from Rich OS.
  • TEE provides a secure execution environment for Trusted Applications (TA), while also protecting the confidentiality, integrity, and access rights of resources and data of trusted applications.
  • TA Trusted Applications
  • TEE In order to ensure the trusted root of TEE itself, TEE must be verified and isolated from RichOS during the secure boot process.
  • each trusted application is independent of each other and cannot be accessed without authorization.
  • TEE can use the following two methods:
  • TPM Trusted Platform Module
  • TCM Trusted Cryptographic Module
  • a cryptographic lock (commonly known as a software dog) is used to implement a trusted execution environment.
  • USB Universal Serial Bus
  • the software dogs not only provide file storage, but also support running customized programs.
  • SoftDog it is not necessary to limit the device types of the publisher device, middleman device and witness device, as long as the publisher device, middleman device and witness device have USB interfaces, which reduces the issue of publisher devices and middleman devices And witness equipment requirements.
  • the SoftDog can be directly connected to the server using USB, or it can use TCP / IP communication to pull USB devices remotely and access them as remote logical devices by using technologies such as USB Over Network. It can also be understood that there can be multiple, even thousands of such remote logical devices, forming a device pool service mode.
  • the method for issuing a certificate provided by the embodiment of the present application is generally executed by the intermediary device 102, and accordingly, a device for issuing a certificate is generally disposed in the intermediary device 102.
  • FIG. 1 the number of issuer devices, intermediary devices, witness devices, and networks in FIG. 1 is merely exemplary. Depending on the implementation needs, there can be any number of publisher devices, intermediary devices, witness devices, and networks.
  • timing diagram 200 of one embodiment of a system for issuing certificates according to the present application is shown.
  • the system for issuing a certificate in the embodiment of the present application may include a publisher device, an intermediary device, and a witness device, and the issuer device, the intermediary device, and the witness device all set a trusted execution environment.
  • sequence 200 of an embodiment of a system for issuing a certificate according to the present application may include the following steps:
  • 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, the issuer device performs a ciphertext generation operation in a trusted execution environment of the issuer device. Obtain the digital asset ciphertext, authorization certificate ciphertext, and 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 intermediate in the authorization certificate parameter information Intermediary equipment indicated by merchant user identification.
  • the issuer device may detect the ciphertext generation request including the target digital asset, the authorization certificate parameter information, and the first witness information parameter information in a trusted execution environment of the issuer device. Perform the ciphertext generation operation to obtain the digital asset ciphertext, authorization certificate ciphertext, and 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 authorization The broker device indicated by the broker user ID in the certificate parameter information.
  • the ciphertext of the authorization certificate will be decrypted into a plaintext in the trusted execution environment of the middleman device, and this plaintext will be used as a template to generate the target authorization certificate.
  • the cipher text or clear text of the authorization certificate can also be referred to as the authorization certificate template.
  • the ciphertext of the witness information will be decrypted into a plaintext in the trusted execution environment of the middleman device.
  • This plaintext will be used to control how the target authorization certificate is generated.
  • the plaintext integrates various control parameters and supports the middle of generating the target authorization certificate. Process control.
  • the cipher text or plain text of the witness information may also be referred to as a witness control block.
  • the authorization certificate parameter information may include various parameter information in the 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 include: certificate type, issuer user identification, certificate identification, and middleman user identification.
  • the authorization certificate parameter information may also include encryption algorithm identification, encryption key, decryption algorithm identification, and To decrypt the key, the first witness information parameter information may further include: witness pass conditions, digital asset description information, and witness information set, and the witness information may include a witness user identification.
  • the certificate category is used to express the purpose of the target certificate to be issued, for example, for decryption or encryption, or for decryption or encryption under the condition of multiple witnesses.
  • issuer user identification is used to uniquely identify the issuer, and the issuer user identification may include at least one of the following: numbers, characters, and text.
  • the certificate identifier is used to uniquely identify each authorization certificate (also called a digital certificate) issued by the same issuer, and the certificate identifier may include at least one of the following: numbers, characters, and text.
  • the certificate identifier may be a number that is updated in increments of the same issuer user identifier.
  • the middleman user ID is used to uniquely identify each middleman who can sell digital assets issued by the issuer, and the middleman user ID may include at least one of the following: numbers, characters, and text.
  • the encryption algorithm identifier is used to indicate the encryption algorithm used to encrypt the target digital asset
  • the encryption key is used to characterize the key used to encrypt the target digital asset.
  • the decryption algorithm identifier is used to indicate the decryption algorithm used to decrypt the target digital asset ciphertext
  • the decryption key is used to characterize the key used to decrypt the digital asset ciphertext. It can 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 can be the same key.
  • the corresponding decryption algorithm ID indicates an asymmetric decryption algorithm corresponding to the asymmetric encryption algorithm indicated by the encryption algorithm ID
  • the encryption key and decryption key The key can be a public key for asymmetric encryption and a private key for asymmetric decryption, respectively.
  • the witness pass condition can be used to characterize the conditions that the issuer needs to meet the witness pass information received from each of the first target witness devices.
  • the intermediary device can only encrypt the authorization certificate when this condition is met. Decrypt.
  • the witness pass condition may be that the witness pass information sent by each first target witness device is received.
  • the witness pass condition may also be a ratio of the number of the first target witness devices sending the witness pass information to the number of all the first target witness devices is greater than or equal to a preset ratio (for example, 80%).
  • the digital asset description information is information that the issuer uses the issuer device to describe the content of the target digital asset to be issued.
  • Digital asset description information can be audio data, text data, or picture data.
  • the digital asset description information for a music type may be information describing the lyricist, composer, emotion expressed by the music, music name, music type, music duration, type of audience suitable for the music, and the like.
  • the witness information is information describing the witness, and the witness information may include a witness user identification.
  • witnesses are users designated by the issuer who have the right to witness the target digital asset. In practice, witnesses are generally users who have an interest relationship with the target digital asset.
  • the witness can also include the issuer itself, that is, the witness user ID in the witness information in the witness information collection can include the issuer.
  • User ID For example, for music-type digital assets, the witness may be a songwriter, songwriter, singer, producer, investor, etc. of the music digital asset.
  • the authorization certificate parameter information may further include at least one of the following: certificate type identification, check code, certificate expiration time, and number of bytes of the certificate fixed configuration information
  • the first witness information parameter information may further include: witness information type Identification, check code, expiration time of witness information, number of bytes of witness information fixed configuration information, number of witnesses, number of authorized content bytes, number of bytes of digital asset description information.
  • the publisher device can detect the ciphertext generation request in various implementations.
  • the issuer device may detect that the user has used the issuer device to access the ciphertext generation request information page for the issuer to enter the target digital asset, authorization certificate parameter information, and first witness information parameter information, and generate a request in the ciphertext
  • the page enters the target digital asset, the certificate certificate parameter information and the first witness information parameter information in the certificate category, the issuer user ID, the certificate ID and the broker user ID, the encryption algorithm ID and the encryption key in the authorization certificate parameter information ,
  • the decryption algorithm identification and decryption key, and the witness pass conditions in the first witness information parameter information, the digital asset description information, and the witness information collection, etc., it indicates that the issuer wishes to generate a corresponding digital target asset input Digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext, at this time, the issuer device can determine that a ciphertext generation request is detected.
  • the issuer device may also detect the user's opening of the ciphertext generation application installed on the issuer device for the user to enter a ciphertext generation request interface for the target digital asset, authorization certificate parameter information, and first witness information parameter information. And in the ciphertext generation request interface, the target digital asset, the certificate type of the authorized certificate parameter information and the first witness information parameter information are entered, the issuer user ID, the certificate ID and the middleman user ID, and the authorization certificate parameter information Encryption algorithm identification, encryption key, decryption algorithm identification and decryption key, and witness pass conditions in the first witness information parameter information, digital asset description information, and witness information collection, etc., indicate that the issuer wishes to generate and The digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext corresponding to the input target digital asset. At this time, the issuer device may determine that a ciphertext generation request is detected.
  • the ciphertext generating operation may include sub-steps 2011 to 2015 as shown in FIG. 2B:
  • an authorization certificate is generated, and the values of various parameters of the authorization certificate are set to the values of corresponding parameters in the parameter information of the authorization certificate.
  • the issuer device may generate an authorization certificate in the trusted execution environment of the issuer device, and set the values of various parameters of the authorization certificate to the values of the corresponding parameters in the authorization certificate parameter information.
  • the authorization certificate may include parameter information of each parameter included in the authorization certificate parameter information.
  • the authorization certificate may include a certificate type, an issuer user identification, a certificate identification, and an intermediary user identification.
  • the authorization certificate may further include an encryption algorithm identification, an encryption key, a decryption algorithm identification, and a decryption key.
  • the authorization certificate may include at least one of the following: the certificate type identification, the check code, the certificate expiration time, the number of bytes of the certificate fixed configuration information, and the authorization content information. .
  • the authorization certificate is encrypted by using the authorization certificate key stored in the trusted execution environment of the issuer device to obtain the authorization certificate ciphertext corresponding to the target digital asset.
  • an authorized certificate key may be stored in the trusted execution environment of the issuer device, and the authorized certificate key may be stored in the trusted execution environment of the issuer device, but not in the trusted execution environment of the issuer device.
  • programs within the trusted execution environment of the issuer device can access the authorization certificate key, but programs outside the trusted execution environment of the issuer device cannot access the authorization certificate key.
  • the clear text of the authorization certificate can be stored within the trusted execution environment of the issuer device, but cannot be stored outside the trusted execution environment of the issuer device, and the trusted execution environment of the issuer device Programs inside can access the clear text of the authorization certificate, but programs outside the trusted execution environment of the issuer device cannot access the clear text of the authorization certificate, and programs outside the trusted execution environment of the issuer device can access the cipher text of the authorization certificate.
  • the authorization certificate is encrypted by using the authorization certificate key stored in the trusted execution environment of the publisher ’s device.
  • the authorization certificate may be DES (Data Encrytion Standard) algorithm, 3DES / TDEA (triple data encryption algorithm, Triple Data Encryption Algorithm, AES (Advanced Encryption Standard) algorithm, Blowfish algorithm, RC2 algorithm, RC4 algorithm, RC5 algorithm, IDEA algorithm (International Data Encryption Algorithm) Or a symmetric encryption algorithm developed in the future.
  • first witness information is generated, and values of parameters of the first witness information are set to values of corresponding parameters in the first witness information parameter information.
  • the issuer device may generate the first witness information in the trusted execution environment of the issuer device, and set the values of various parameters of the first witness information to the values of the corresponding parameters in the first witness information parameter information.
  • the first witness information may include parameter information of each parameter included in the first witness information parameter information.
  • the first witness information may include a certificate type, an issuer user identification, a certificate identification, and an intermediary user identification.
  • the first witness information may further include a witness passing condition, digital asset description information, and witness information collection.
  • the first witness information may include at least one of the following types: witness type identification, check code, witness information expiration time, and witness information fixed configuration information. The number of bytes, the number of witnesses, the number of authorized content bytes, the number of bytes of digital asset description information.
  • Sub-step 2014 Use the witness information key stored in the trusted execution environment of the publisher device to encrypt the first witness information to obtain the ciphertext of the witness information corresponding to the target digital asset.
  • a witness information key may be stored in the trusted execution environment of the issuer device, and the witness information key may be stored in the trusted execution environment of the issuer device, but not in the trusted execution environment of the issuer device.
  • programs within the trusted execution environment of the publisher device can access the witness information key, but programs outside the trusted execution environment of the publisher device cannot access the witness information key.
  • the first witness information in plain text can be stored within the trusted execution environment of the issuer device, but cannot be stored outside the trusted execution environment of the issuer device, and Programs in the execution environment can access the plaintext of the first witness information, but programs outside the trusted execution environment of the publisher's device cannot access the plaintext of the first witness information, and programs outside the trusted execution environment of the publisher's device can access the witness information ciphertext .
  • using the witness information key stored in the trusted execution environment of the issuer device to encrypt the first witness information may use various symmetric encryption algorithms now known or developed in the future.
  • Sub-step 2015 Encrypt the target digital asset by using the algorithm and encryption key indicated by the encryption algorithm identifier in the parameter information of the authorization certificate to obtain the digital asset ciphertext corresponding to the target digital asset.
  • Step 202 The intermediary device determines the authorized content information for the received digital asset ciphertext in response to receiving the digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext sent by the issuer device.
  • the intermediary device may adopt various implementation manners to determine the authorized content information for the received digital asset ciphertext. For example, after determining the user ID of the authorized user of the received digital asset ciphertext, the intermediary device may use the user ID of the authorized user determined for the received digital asset ciphertext as the received digital asset. Authorized content information in cipher text. As another example, after determining that the first number of users grant the received digital asset ciphertext authorization to the middleman device, the first number is used as the authorized content information. For another example, after determining that the second number of received digital asset ciphertexts are sold at the first unit price, the intermediary device may use the first unit price and the second number as authorized content information.
  • the intermediary device may also combine the user ID, the first number, the first unit price, and the second number of the authorized user as the authorized content information.
  • the authorized content information is information about the authorization status of the received digital asset ciphertext as specified by the intermediary device according to its own sales situation. It can be understood that the above authorization content will be finally saved in the authorization certificate to be generated.
  • the authorization certificate still uses the trusted execution environment to implement various authorization authority controls, such as when the first unit price and the second number are used as the authorization basis.
  • the trusted execution environment will record how many points are consumed for each decrypted target data, and the program in the trusted execution environment will implement the operation of deducting the corresponding amount from the total purchase points.
  • Step 203 The intermediary device performs an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device, and obtains the intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • the middleman authorization certificate generation operation may include sub-steps 2031 to 2037 as shown in FIG. 2C:
  • Sub-step 2031 decrypting the received ciphertext of the witness information by using the witness information key stored in the trusted execution environment of the broker device to obtain the plaintext of the witness information.
  • the witness information key stored in the trusted execution environment of the intermediary device is the same as the witness information key stored in the trusted execution environment of the issuer device, and the witness information key may be stored in the trusted device's trusted execution environment. Within the execution environment, but cannot be stored outside the trusted execution environment of the middleman device, and the programs in the trusted execution environment of the middleman device can access the witness information key, but the outside of the trusted execution environment of the middleman device The program cannot access the witness information key. Due to the characteristics of the witness information key described above, the ciphertext of the witness information can be decrypted within the trusted execution environment of the intermediary device to obtain the plaintext of the witness information, but the witness information cannot be encrypted outside the trusted execution environment of the intermediary device. The text is decrypted.
  • Sub-step 2032 Update the authorized content information in the plaintext of the decrypted witness information to the determined authorized content information.
  • the authorized content information in the plaintext of the witness information 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 plaintext of the witness information decrypted in sub-step 2031 is the authorized content information in the first witness information parameter information detected by the issuer's device, and the issuer will secretly identify the digital asset corresponding to the target digital asset. Authorization of the text is entrusted to the middleman, then the authorized content information for the digital asset ciphertext corresponding to the target digital asset is specified by the middleman. Therefore, the authorized content in the plaintext of the witness information decrypted in substep 2031 needs to be The information is updated to the authorized content information determined in step 202.
  • Sub-step 2033 Use the witness information key stored in the trusted execution environment of the intermediary device to encrypt the updated plaintext of the decrypted witness information to obtain the intermediary witness information ciphertext.
  • the witness information obtained after decryption can be updated by using the witness information key stored in the trusted execution environment of the broker device
  • the information is encrypted in plain text to obtain the cipher text of the middleman witness information.
  • Sub-step 2034 Send the cipher text of the middleman witness information to each first target witness device.
  • the first target witness device is the witness device indicated by the witness user identifier in the witness information in the witness information set in the plaintext of the witness information obtained in the 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 conditions in the plaintext of the witness information obtained by decryption, using the authorization certificate secret stored in the trusted execution environment of the broker device The key decrypts the received cipher text of the authorization certificate to obtain the clear text of the authorization certificate.
  • the above-mentioned witness pass information is a ciphertext encrypted using the witness information key. Before judging whether the witness pass condition is satisfied in the above steps, the witness pass information should be decrypted with the witness information key. Passing testimonials in ciphertext prevents the information from being forged. It is also understandable that the middlemen's equipment has not received the witness pass information of the first target witness after the expiration date, and it will be regarded as receiving the witness failure pass information.
  • the authorization certificate key stored in the trusted execution environment of the intermediary device is the same as the authorization certificate key stored in the trusted execution environment of the issuer device, and the authorization certificate key can be stored in the trusted device's trusted execution environment. Within the execution environment, but cannot be stored outside the trusted execution environment of the middleman device, and the programs in the trusted execution environment of the middleman device can access the authorization certificate key, but the outside of the trusted execution environment of the middleman device The program cannot access the authorization certificate key. Due to the characteristics of the authorization certificate key described above, the ciphertext of the authorization certificate can be decrypted within the trusted execution environment of the middleman device to obtain the clear text of the authorization certificate, but the authorization certificate cannot be encrypted outside the trusted execution environment of the middleman device. The text is decrypted.
  • Sub-step 2036 in response to determining that the issuer user ID and certificate ID in the decrypted plaintext of the authorization certificate are the same as the corresponding parameters in the decrypted witness information plaintext and the decrypted authorization certificate plaintext and decrypted witness information plaintext are
  • the middleman user ID is the user ID of the middleman device, generates the middleman authorization certificate, sets the values of the parameters in the middleman authorization certificate to the corresponding parameters in the clear text of the decrypted authorization certificate, and sets the middleman
  • the authorized content information in the authorization certificate is updated to the determined authorized content information.
  • the issuer user ID and the certificate ID in the plaintext of the decrypted authorization certificate are the same as the corresponding parameters in the plaintext of the decrypted witness information, it means that the plaintext of the decrypted authorization certificate and the plaintext of the decrypted witness information correspond The same digital asset issued by the issuer device indicated by the issuer user ID.
  • the clear text of the authorization certificate obtained by decryption and the clear text of the witness information obtained by decryption are both user IDs of the middleware device, it indicates that the middleware device is the clear text of the authorization certificate obtained by decryption and the clear text of the witness information obtained by decryption. Broker device specified in.
  • an intermediary authorization certificate can be generated, and then the values of various parameters in the intermediary authorization certificate are set to the values of the corresponding parameters in the decrypted authorization certificate plain text, and the authorized content information in the intermediary authorization certificate is updated to steps.
  • the authorized content information determined in 202 so that the generated authorized content information in the clear text of the generated middleman authorization certificate has been updated to the authorized content information specified by the middleman.
  • the intermediary authorization certificate includes various parameters included in the clear text of the authorization certificate obtained by decryption.
  • the intermediary authorization certificate updated in the sub-step 2036 is an authorization certificate to be generated and sent to the authorized person (the purchaser of the digital asset).
  • the certificate essentially consists of three parts.
  • the first part is the certificate header of the authorization certificate, which records the inherent attributes of the certificate, including: certificate type, issuer user ID, certificate ID, middleman user ID, etc .; the second part is the fixed configuration of the certificate.
  • Selectable values include: encryption algorithm identification, encryption key, decryption algorithm identification, decryption key, encryption algorithm identification, encryption key, etc.
  • This part is highly confidential and is used during the certificate generation process and after the certificate is issued. The process does not reveal a trusted execution environment (for example, when presenting the information to be witnessed to the witness, this part is not included).
  • the third part is the authorization content of the certificate, which is mainly used to limit the scope of use. Possible values include: user identification that can enjoy the benefits, the amount of decryption or re-encryption.
  • Sub-step 2037 Use the authorization certificate key stored in the trusted execution environment of the middleman device to encrypt the middleman authorization certificate to obtain the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • the authorization certificate key stored in the trusted execution environment of the middleman device can be used to encrypt the middleman authorization certificate to obtain The middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • the intermediary device may store the obtained ciphertext of the intermediary authorization certificate corresponding to the received digital asset ciphertext, and provide the received digital asset secret with various implementation methods when needed.
  • Authorized user For example, the intermediary device can send the digital asset ciphertext in an email to the designated email address of the user who obtained the authorization of the received digital asset ciphertext, and then the user who obtained the authorization of the received digital asset ciphertext can pass Receive the email to get the ciphertext of the middleman authorization certificate; or, the middleman device can also provide a URL link to download the ciphertext of the middleman authorization certificate, and then the user can download the middleware by opening the browser using the user device and clicking the above URL link
  • the cipher text of the vendor authorization certificate or alternatively, the user can also copy the cipher text of the intermediary authorization certificate from the intermediary device directly to the user device via a USB flash drive.
  • Step 204 In response to receiving the witness information ciphertext sent by the broker device, the witness device utilizes the witness information key stored in the trusted execution environment of the witness device in the trusted execution environment of the witness device. The ciphertext of the received witness information is decrypted to obtain the plaintext of the witness information.
  • the witness device may use the witness information key stored in the trusted execution environment of the witness device in the trusted execution environment of the witness device when the witness information ciphertext sent by the broker device is received. Decrypt the received witness information ciphertext to obtain the plaintext of the witness information.
  • the witness information key stored in the trusted execution environment of the witness device is both The same, and the witness information key can be stored in the trusted execution environment of the witness device, but cannot be stored outside the trusted execution environment of the witness device, and the program in the trusted execution environment of the witness device can be The witness information key is accessed, but programs outside the trusted execution environment of the witness device cannot access the witness information key. Due to the characteristics of the witness information key described above, the ciphertext of the witness information can be decrypted within the trusted execution environment of the witness device to obtain the plaintext of the witness information, but the witness information cannot be encrypted outside the trusted execution environment of the witness device. The text is decrypted.
  • Step 205 The witness device presents the plaintext of the decrypted witness information.
  • the witness device may use various implementation manners to present the plaintext of the decrypted witness information.
  • the presentation form may be the plain text of the testimonial information on the screen of the witness device, or the voice obtained by synthesizing the text in the plain text of the testimonial information through a speaker.
  • all or part of the plaintext of the witness information may be presented.
  • usually only the certificate type, issuer user ID, certificate ID, broker user ID, and digital asset description information in the plaintext of the witness information are presented.
  • Step 206 The witness device responds to detecting the witness consent operation that the user has entered in plain text for the presented witness information, generates witness pass information, and sends the generated witness pass to the intermediary device that sends the received cipher text of the witness information. information.
  • the user can determine whether the witness passes through the plaintext of the witness information presented in the witness device. If the user's testimony passes, the witness device can be used to enter the witness consent operation (for example, the user can enter the witness consent operation by clicking the button associated with the witness consent operation). If the witness device detects that the user has entered the plaintext of the presented witness information The witness consent operation can generate witness pass information and send the generated witness pass information to the intermediary device that sends the received cipher text of the witness information.
  • the link between the middleman and the witness requesting the witness can also adopt the following methods.
  • This method allows witnesses to give testimony passing information without relying on a trusted execution environment.
  • the witness user ID in the witness information set contained in the plaintext of the witness information is expressed by the public key, and the witness result is signed with the private key corresponding to the public key to express whether the witness passes. Because the signature is unforgeable, the conclusion that the signature passed or failed by the witness is credible.
  • the verification signature is verified with the corresponding public key in the trusted broker execution environment.
  • the specific sub-steps can be performed as follows:
  • the trusted execution environment of the intermediary device extracts the key information to be witnessed (certificate category, issuer user identification, certificate identification, intermediary user identification, and digital asset description information, etc.), Encrypt with the second witness information key that the middleman has preset to the trusted execution environment to obtain the middleman witness information ciphertext.
  • the trusted execution environment of the intermediary device decrypts the ciphertext witness information received from each first target witness device, decrypts it with the second witness information key, obtains the plaintext, and then verifies the plaintext. A summary of the key information to be witnessed, and then verify the signature with the corresponding public key. After the verification is passed, combined with the testimony results given by each witness, a comprehensive judgment is made as to whether the test pass conditions are met.
  • the identity of the witness is identified by the public key mentioned above, and the witness has a private key that matches this public key. The following steps have been changed for the witness:
  • step 204 after receiving the ciphertext of the witness information, the witness device decrypts it with the second witness information key to obtain the plaintext of the witness information.
  • Step 206 After the witness agrees, generate witness confirmation information representing the passing of the witness.
  • the witness confirmation information includes two parts, one is the signed information, including the witness result (whether passed), and a summary of key information to be witnessed (for example, MD5 verification). Code or hash digest value), and the second is signature. After that, the witness confirmation information is encrypted with the second witness information key to obtain the cipher text witness pass information.
  • the witness pass information is used to represent the user's approval of the plain text content of the witness information presented by the witness device. It is understandable that if the user does not approve the plain text content of the witness information presented by the witness device, the witness device can be used to enter the witness failure operation, and the witness device can generate a witness failure after detecting the witness failure operation.
  • the witness pass information and the witness fail information both include the witness result.
  • the witness result can be a first preset value (for example, it can usually be 1, which indicates that the witness passed), or a second preset value (for example, usually It can be 0, which means that the witness fails.)
  • witness pass information and witness fail information also include a clear text summary of the witness information (eg, MD5 checksum or hash digest value).
  • the witness pass information and the witness fail information also need to be encrypted with the witness information key and transmitted to the middlemen's device, because this step of encryption is made in a trusted execution environment, and the ciphertext as a whole cannot be tampered with. So there is no need to add additional signature measures.
  • the witness can choose whether to pass or not to pass the test. It can also be automatically determined by the program to automatically drive the witness device to generate test pass information or test pass information and feed it back to the intermediary device.
  • steps 204 to 205 may be performed after performing sub-step 2034 in the process of performing an intermediary authorized certificate generation operation in step 203.
  • the middleman device can perform the sub-step 2035 in real time during the process of performing the steps 204 to 206 by the witness device, without waiting for all the witness devices to perform steps 204 to step Sub-step 2035 is performed only at 206, because it is possible that the witness pass information received from some of the witness devices can meet the witness pass conditions required by sub-step 2035.
  • the issuer device can also be used as the intermediary device and / or witness device.
  • the intermediary device can also be used as the issuer device and / or witness device.
  • the device can also function as both a publisher device and / or a middleman device.
  • the certificate issuing system specifies that the issuer of the digital asset first uses the issuer device that sets up a trusted execution environment to specify the authorization certificate parameter information and the first witness parameter information for the target digital asset, and then issues the Generate the digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext corresponding to the target digital asset in the trusted execution environment of the consumer device, and send the generated digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext
  • the intermediary device indicated by the intermediary user identification in the authorization certificate parameter information is then determined by the intermediary device for the authorized content information for the received digital asset ciphertext, and in the trusted execution environment of the intermediary device
  • the middleman authorization certificate generation operation is performed in the middle, and the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext is obtained, thereby realizing the issue of the authorization certificate for digital assets through the middleman, and In the process of generating the middleman authorization certificate, it is necessary to send the The
  • FIG. 3A illustrates a timing sequence 300 of still another embodiment of a system for issuing certificates according to the present application.
  • the system for issuing a certificate in the embodiment of the present application may include a publisher device, an intermediary device, and a witness device, and the issuer device, the intermediary device, and the witness device all set a trusted execution environment.
  • the timing sequence 300 may include the following steps:
  • Step 301 In response to detecting a first user ID generation request including a first user ID category ID, the publisher device determines the first user ID category ID and the trusted execution environment of the issuer device as target user ID category IDs, respectively. And the target trusted execution environment, in the determined target trusted execution environment, performing a user ID generation operation to obtain a user ID corresponding to the determined target user ID category ID and the determined target trusted execution environment, and The obtained user ID is added to the user ID set of the publisher device.
  • the publisher device may detect the first user identity generation request in various implementation manners. For example, the publisher device may detect that the user uses the publisher device to access a user ID generation page including a page element (for example, a text box or a drop-down menu, etc.) for the user to input a user ID category ID, and the user is inputted by the user in the above.
  • a page element for example, a text box or a drop-down menu, etc.
  • the publisher device may also detect that the user has opened the user ID generation interface in the application installed on the publisher device, entered the first user ID category ID, and clicked on a control associated with the user ID generation operation (for example, , Button), it is determined that the first user ID generation request is detected.
  • a control associated with the user ID generation operation for example, , Button
  • the first user identity category identifier is used to indicate the category of the user identity in the user identity set of the issuer device.
  • user identifiers in a user identifier set can 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 a different first user identifier category.
  • the classification may be performed according to the type of the application to which the generated user ID is applied. For example, if the user wishes to generate a user ID for a social application or a social website, then the user may enter or select a social application or a social website.
  • the corresponding user identifier category identifier generates a first user identifier generation request.
  • a user identification category identifier corresponding to the shopping application or a shopping website may be input or selected to generate a first user identification generating request.
  • the first user identifier category identifier may also be determined in an incremental manner, that is, the issuer device may store the current first user identifier category identifier.
  • the issuer device may store the current first user identifier category identifier.
  • the issuer device The current first user identification category identifier stored above may be obtained, the acquired current first user identification category identifier may be incrementally updated, and the first user identification generation request may be generated using the current first user identification category identifier after the incremental update.
  • the user ID generating operation may be performed from sub-step 3011 to sub-step 3013 shown in FIG. 3B:
  • Sub-step 3011 Obtain an environment identifier including a manufacturer identifier and a product identifier, which is used to indicate the target trusted execution environment.
  • the environment identification of the trusted execution environment is used to uniquely identify the trusted execution environment.
  • the environment identification of the trusted execution environment may include a manufacturer identification and a product identification.
  • the manufacturer identification of the trusted execution environment is used to uniquely identify different trusted execution environments.
  • the manufacturer of the execution environment, and the product identification is used to uniquely identify the trusted execution environment produced by the same trusted execution environment manufacturer.
  • the trusted execution environment usually has a manufacturer's logo and a product logo set at the factory, and cannot be modified.
  • the environment logo of the trusted execution environment can only be stored in the trusted execution environment and within the trusted execution environment.
  • the program of the trusted execution environment can access the environment identification of the trusted execution environment, while the program of the trusted execution environment cannot access the environment identification of the trusted execution environment.
  • the environmental identification can include at least one of the following: numbers, characters, and text.
  • step 3012 a random number is generated randomly.
  • Sub-step 3013 The extended user identification is encrypted with the user identification key stored in the target trusted execution environment to obtain a user identification corresponding to the target user identification category identification and the target trusted execution environment.
  • the extended user identifier may include the environment identifier obtained in the sub-step 3011, the generated random number, and the target user identifier category identifier.
  • the user identification key can be stored in the target trusted execution environment and can be accessed by programs within the target trusted execution environment, but cannot be accessed by programs outside the target trusted execution environment.
  • the user identification key stored in the target trusted execution environment is used to encrypt the extended user identification, and various symmetric encryption algorithms can be used.
  • 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 identification category identifier are also added.
  • the trusted execution environment of the issuer device For other programs, only the generated user ID can be obtained, but the environment ID in the generated user ID cannot be parsed.
  • Programs in the trusted execution environment of the publisher device can parse the generated user ID to obtain the user ID. Environment ID in the user ID set of the publisher device can therefore be protected from being cracked by programs outside the trusted execution environment.
  • Step 302 In response to detecting a second user ID generation request including a second user ID category ID, the middleman device determines the second user ID category ID and the trusted execution environment of the middleman device as the target user ID category ID, respectively. And the target trusted execution environment, in the determined target trusted execution environment, performing a user ID generation operation to obtain a user ID corresponding to the determined target user ID category ID and the determined target trusted execution environment, and The obtained user identification is added to the user identification set of the broker device.
  • step 301 For the operation of generating the user identifier, reference may be made to the related description in step 301, and details are not described herein again.
  • Step 303 The witness device responds to detecting a third user ID generation request including a third user ID category ID, and determines the third user ID category ID and the trusted execution environment of the witness device as the target user ID category ID, respectively. And the target trusted execution environment, in the determined target trusted execution environment, performing a user ID generation operation to obtain a user ID corresponding to the determined target user ID category ID and the determined target trusted execution environment, and The obtained user identity is added to the user identity set of the witness device.
  • step 301 For the operation of generating the user identifier, reference may be made to the related description in step 301, and details are not described herein again.
  • the user IDs in the user ID set of the issuer device, the middleman device, and the witness device are trusted executions in the issuer device, the middleman device, and the witness device, respectively. Generated in the environment based on the environment identifier of the trusted execution environment. For programs outside the trusted execution environment, only the generated user ID can be obtained, but the environment ID in the generated user ID cannot be parsed. A program in the letter execution environment can parse the generated user ID to obtain the environment ID in the user ID. Therefore, steps 301 to 303 can protect the user ID in the user ID set of the issuer device, the middleman device, and the witness device from being cracked by programs outside the trusted execution environment.
  • 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 performs a ciphertext generation operation in a trusted execution environment of the issuer device. Obtain the digital asset ciphertext, authorization certificate ciphertext, and 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 intermediate in the authorization certificate parameter information Intermediary equipment indicated by merchant user identification.
  • the issuer device may detect the ciphertext generation request including the target digital asset, the authorization certificate parameter information, and the first witness information parameter information in a trusted execution environment of the issuer device. Perform the ciphertext generation operation to obtain the digital asset ciphertext, authorization certificate ciphertext, and 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 authorization The broker device indicated by the broker user ID in the certificate parameter information.
  • the authorization certificate parameter information, first witness information parameter information, certificate type, issuer user ID, certificate ID, broker user ID, encryption algorithm ID, encryption key, decryption algorithm ID, decryption key, and witness pass conditions For digital asset description information and witness information, reference may be made to the related description in step 201 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • the issuer user identity in the authorization certificate parameter information and the first witness information parameter information may be a user identity in a user identity set of the issuer device.
  • the publisher device may add a user identifier to the user identifier set of the publisher device by executing step 301. For details, refer to the related description in step 301.
  • the broker user identifier in the authorization certificate parameter information and the first witness information parameter information may be a user identifier in a user identifier set of the broker device.
  • the middleman device may add a user ID to the user ID set of the middleman device by executing step 302. For details, refer to the related description in step 302.
  • the witness user identity in the witness information set in the witness information set in the first witness information parameter information is the user identity in the user identity set of the witness device.
  • the witness device may add a user identifier to the user identifier set of the witness device by performing step 303. For details, refer to the related description in step 303.
  • the publisher device can detect the ciphertext generation request in various implementations.
  • the ciphertext generating operation may include sub-steps 3041 to 3049 as shown in FIG. 3C:
  • Sub-step 3041 generating an authorization certificate, and setting values of various parameters of the authorization certificate to the values of corresponding parameters in the parameter information of the authorization certificate.
  • sub-step 3041 is basically the same as the specific operation of sub-step 2011 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Sub-step 3042 using the user identification key stored in the trusted execution environment of the issuer device to decrypt the issuer user ID and the broker user ID in the authorization certificate parameter information and the first witness information parameter information, respectively, to obtain the issue User extension user ID and middleman extension user ID.
  • the issuer user ID in the authorization certificate parameter information and the first witness 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
  • 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 publisher device, and the user ID in the user ID set of the broker device is using the intermediate
  • the user identification key stored in the trusted execution environment of the commercial device is encrypted, and the user identification key stored in the trusted execution environment of different issuer devices, middlemen devices, and witness devices is the same.
  • the user identification key stored in the trusted execution environment of the issuer device is used to decrypt the issuer user ID and the intermediary user ID in the authorization certificate parameter information and the first witness information parameter information, and the issuer extension can be obtained.
  • User ID and broker extension user ID are used to decrypt the issuer user ID and the intermediary user ID in the authorization certificate parameter information and the first witness information parameter information, and the issuer extension can be obtained.
  • Sub-step 3043 Update the issuer user ID and the middleman user ID in the authorization certificate to the environment ID in the issuer extended user ID and the middleman extended user ID respectively.
  • the issuer user ID and the intermediary user ID in the authorization certificate generated in the sub-step 3041 may be respectively updated to the environment ID in the issuer extended user ID and the intermediary extended user ID decrypted in the sub-step 3042.
  • Environmental identification That is, the issuer user ID and the broker user ID in the generated authorization certificate actually store the environment ID of the trusted execution environment in the issuer device and the environment ID of the trusted execution environment in the broker device, instead of issuing The user ID in the user ID set of the user device or the user ID in the user ID set of the broker device.
  • Sub-step 3044 using the authorization certificate key stored in the trusted execution environment of the issuer device to encrypt the authorization certificate to obtain the authorization certificate ciphertext corresponding to the target digital asset.
  • sub-step 3044 is basically the same as the specific operation of sub-step 2012 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Sub-step 3045 Generate first witness information, and set values of parameters of the first witness information to values of corresponding parameters in the first witness information parameter information.
  • sub-step 3045 is basically the same as the specific operation of sub-step 2013 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Sub-step 3046 Update the issuer user ID and the broker user ID in the first witness information to the environment ID in the publisher extended user ID and the environment ID in the broker extended user ID, respectively.
  • the issuer user ID and the broker user ID in the first witness information generated in the sub-step 3045 may be respectively updated to the environment ID and the broker extension user ID in the issuer extended user ID decrypted in the sub step 3042.
  • Sub-step 3047 Update 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.
  • the witness user identifier in each of the witness information sets in the witness information set in the first witness information generated in the sub-step 3045 may be updated to a witness environment identifier corresponding to the witness user identifier.
  • the witness environment ID corresponding to the witness user ID is the environment ID in the extended user ID obtained by decrypting the witness user ID using the 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 set actually stores the environment ID of the trusted execution environment in the witness device, not the witness device's The user ID in the user ID collection.
  • Sub-step 3048 Use the witness information key stored in the trusted execution environment of the publisher device to encrypt the first witness information to obtain the ciphertext of the witness information corresponding to the target digital asset.
  • sub-step 3048 is basically the same as the specific operation of sub-step 2014 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Sub-step 3049 Encrypt the target digital asset by using the algorithm and encryption key indicated by the encryption algorithm identifier in the authorization certificate parameter information to obtain the digital asset ciphertext corresponding to the target digital asset.
  • sub-step 3049 is basically the same as the specific operation of sub-step 2015 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 305 The intermediary device determines the authorized content information for the received digital asset ciphertext in response to receiving the digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext sent by the issuer device.
  • step 305 is basically the same as the specific operation of sub-step 202 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 306 The intermediary device performs an intermediary authorization certificate generation operation in a trusted execution environment of the intermediary device, and obtains the intermediary authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • step 306 is basically the same as the specific operation of sub-step 203 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 307 In response to receiving the ciphertext of the witness information sent by the broker device, the witness device utilizes the witness information key stored in the trusted execution environment of the witness device in the trusted execution environment of the witness device. The ciphertext of the received witness information is decrypted to obtain the plaintext of the witness information.
  • step 307 is basically the same as the specific operation of sub-step 204 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 308 The witness device presents the plaintext of the decrypted witness information.
  • step 308 is basically the same as the specific operation of sub-step 205 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 309 The witness device responds to detecting the witness consent operation that the user has entered in plain text for the presented witness information, generates witness pass information, and sends the generated witness pass to the intermediary device that sends the received cipher text of the witness information. information.
  • step 309 is basically the same as the specific operation of sub-step 206 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • the witness device in step 309, the witness device generates the witness pass information.
  • the witness pass information generation operation can be performed in the trusted execution environment of the witness device to obtain a ciphertext with the received witness information.
  • Corresponding witness pass information, wherein the witness pass information generating operation may include sub-steps 3091 to 3092 as shown in FIG. 3D:
  • Sub-step 3091 in response to the integrity verification of the plaintext of the decrypted witness information being passed, generating a witness information key according to a preset algorithm according to an environment identifier of a trusted execution environment of the witness device.
  • the integrity check of the plaintext of the witness information obtained in step 307 may be performed by calculating the message digest value of the content other than the verification code in the plaintext of the witness information, and then if the calculated message digest value is in the plaintext of the witness information
  • the verification code is the same, indicating that the integrity verification of the plaintext of the witness information obtained through decryption passes.
  • the preset algorithm may be various algorithms that generate a key according to an environment identifier of a trusted execution environment.
  • generating a witness information key according to an environment identifier of a trusted execution environment of the witness device may be performed as follows: The environment identifier of the trusted execution environment of the witness device and an available identifier of the witness device are combined.
  • the identification of the preset key component stored in the letter execution environment (for example, it may be a preset constant) to obtain the witness information key.
  • generating a witness information key according to the environment identifier of the trusted execution environment of the witness device may also be performed as follows: the environment identifier of the witness device's trusted execution environment and the witness device The XOR operation is performed on the preset mask stored in the trusted execution environment to obtain the witness information key.
  • Sub-step 3092 encrypts the preset key information in the plaintext of the witness information obtained by decryption using the generated witness information key to obtain witness pass information corresponding to the received ciphertext of the witness information.
  • the key information in the plaintext of the witness information decrypted in step 307 may be encrypted by using the witness information key generated in sub-step 3091 to obtain witness pass information corresponding to the received ciphertext of the witness information.
  • the preset key information may be parameter information of at least one preset parameter in the plaintext of the witness information.
  • the preset key information may include a verification code, a certificate type, an issuer user identification, and a certificate identification.
  • 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.
  • the witness pass information received from each first target witness device within a preset time period may be determined as a target witness pass information set.
  • a middleman device it is impossible for a middleman device to wait for all the first target witness devices to return witness pass information. Therefore, a preset time period (for example, the middleman witness information ciphertext is sent to each first target from the middleman device)
  • the witness pass information received from each first target witness device within ten minutes from the time of the witness device is determined as the target witness pass information set.
  • witness weight and update operations can be performed:
  • the first step is to determine the witness information corresponding to the witness device in the plaintext of the decrypted witness information and the witness device that sent the target witness pass information.
  • a witness information key is generated according to the witness user ID in the determined witness information.
  • the witness user identification in the determined witness information actually stores the environment identification of the trusted execution environment in the witness device indicated by the witness user identification.
  • the preset algorithm here is the sub-step 3091, which is used by the witness device in generating the witness information key in the trusted execution environment of the witness device according to the environment identification of the trusted execution environment of the witness device Preset algorithm.
  • the third step is to decrypt the target witness pass information using the generated witness information key to obtain key information of the witness information.
  • the witness weight is updated and updated to the witness weight and the witness weight in the determined witness information Sum.
  • the key information of the obtained witness information is the same as the preset key information in the plaintext of the decrypted witness information, it means that the key information of the obtained witness information is indeed from the witness in the set of witness information specified in the plaintext of the decrypted witness information
  • the witness device indicated by the witness user ID in the witness information so that it can be determined that the witness device has indeed detected the witness consent operation that the user entered in plain text for the decrypted witness information, and then the witness weight can be updated to the witness weight Sum with the weight of the witnesses in the identified witness information.
  • the witness pass information received from each first target witness device satisfies the witness pass condition in the plaintext of the witness information obtained by decryption.
  • the witness user identification and witness weight in the witness information are received by the issuer device and input by the user.
  • a user of an issuer device (which may be referred to as an issuer) can set a witness weight according to the return ratio of the target digital asset, and the return ratio of the witness to the target digital asset is positively related to the witness weight of the witness.
  • FIG. 3E Due to the limitation of page display, the following reference is continued to FIG. 3E. It should be noted that the process of FIG. 3E may include various steps shown in FIG. 3A in addition to the steps shown in FIG. 3E. In addition, it should be noted that, in addition to the issuer device and witness device shown in FIG. 3E, the publisher device and witness device shown in FIG. 3E can also execute the issuer device and witness device shown in FIG. 3A. Perform the appropriate steps.
  • the authorized content information may include an authorized environment identifier set
  • the system for issuing a certificate may further include a user device that sets a trusted execution environment.
  • the above sequence 300 may further include the following steps 310 and 311:
  • Step 310 In response to detecting a decryption request for the ciphertext of the digital asset to be decrypted, the user equipment determines an intermediary authorization certificate ciphertext corresponding to the ciphertext of the digital asset to be decrypted.
  • the user equipment may detect the decryption request for the ciphertext of the digital asset to be decrypted in various implementation manners. For example, the user equipment may detect that the user has accessed the digital asset decryption page including a page element (for example, a file selection button) for the user to input the digital asset to be decrypted using the user equipment, and input the digital asset to be decrypted by the user on the user equipment.
  • a page element for example, a file selection button
  • the publisher device may also detect that the user has opened the digital asset decryption interface in the application installed on the user device, entered the address of the file where the digital asset to be decrypted is located, and clicked the control associated with the digital asset decryption operation ( For example, button), it is determined that a decryption request is detected.
  • the control associated with the digital asset decryption operation For example, button
  • the user equipment may adopt various implementation manners to determine the cipher text of the intermediary authorization certificate corresponding to the cipher text of the digital asset to be decrypted.
  • the user can use the user device to collect the cipher text of the intermediary authorization certificate in the email sent by the intermediary device for the ciphertext of the digital asset to be decrypted, and save the cipher text of the intermediary authorization certificate as the ciphertext of the digital asset to be decrypted.
  • the corresponding middleman authorization certificate ciphertext The corresponding middleman authorization certificate ciphertext.
  • the user can also use the user device to download the cipher text of the intermediary authorization certificate provided by the intermediary device for downloading the cipher text of the intermediary authorization certificate provided by the intermediary device for the digital asset to be decrypted.
  • the user can also copy the cipher text of the authorization certificate from the middleman device directly to the user device through a USB flash drive.
  • step 310 After performing step 310, proceed to step 311.
  • Step 311 The user equipment performs a digital asset decryption operation in a trusted execution environment of the user equipment to obtain a digital asset plaintext corresponding to the digital asset ciphertext to be decrypted.
  • the digital asset decryption operation may include sub-step 3111 and sub-step 3112 as shown in FIG. 3F:
  • Sub-step 3111 In the trusted execution environment of the user equipment, use the authorization certificate key stored in the trusted execution environment of the user equipment to decrypt the determined middleman authorization certificate ciphertext to obtain the middleman authorization
  • the certificate is in plain text.
  • the authorization certificate key stored in the trusted execution environment of the broker device is all the same.
  • the authorization certificate key can be stored in the trusted execution environment of the user device, but cannot be stored outside the trusted execution environment of the user device, and the program in the trusted execution environment of the user device can access the authorization Certificate key, but programs outside the trusted execution environment of the consumer device cannot access the authorized certificate key.
  • the cipher text of the intermediary authorization certificate can be decrypted within the trusted execution environment of the user device to obtain the clear text of the intermediary authorization certificate, but it cannot be outside the trusted execution environment of the user device Decrypt the cipher text of the middleman authorization certificate.
  • Step 3112 In response to determining that the environment identifier of the trusted execution environment of the user equipment belongs to the authorized user identification set in the authorized content information in the clear text of the middleman authorization certificate obtained by decryption, use the decryption algorithm in the clear text of the authorized certificate obtained by decryption The algorithm and decryption key indicated by the identifier are used to decrypt the ciphertext of the digital asset to be decrypted to obtain the plaintext of the digital asset corresponding to the ciphertext of the digital asset to be decrypted.
  • the environment identifier of the trusted execution environment of the user equipment belongs to the authorized user identifier set in the authorized content information in the clear text of the intermediary authorization certificate obtained by decryption, it indicates that the intermediary has authorized the user equipment to use the digital asset to be decrypted .
  • the algorithm and decryption key indicated by the decryption algorithm ID in the clear text of the authorization certificate decrypted in sub-step 3111 can be used to decrypt the ciphertext of the digital asset to be decrypted for the decryption request detected in step 310, and obtain The plaintext of the digital asset corresponding to the ciphertext of the digital asset to be decrypted.
  • the user equipment can implement decryption of the digital asset to be decrypted and obtain the corresponding plaintext of the digital asset.
  • the foregoing sequence 300 may further include the following steps 312 to 316:
  • the publisher device responds to detecting a multi-party witness information encryption request, and performs witness information generation and information encryption operations in the trusted execution environment of the publisher device to obtain the information ciphertext and witness information corresponding to the information to be encrypted Ciphertext.
  • the multi-party witness information encryption request may include information to be encrypted and corresponding second witness information parameter information
  • the second witness information parameter information may include certificate type, issuer user identification, witness information set, encryption algorithm identification, and encryption secret.
  • Key, decryption algorithm identification, decryption key, witness pass condition and encryption information describe information.
  • the encrypted information description information may be information entered by the issuer using the issuer device to describe the content of the information to be encrypted to be issued.
  • the encrypted information description information can be audio data, text data, or picture data.
  • the encrypted information description information about the content of a will to be encrypted may be information describing the testator, beneficiary, etc. of the will.
  • the issuer device can detect the multi-party witness information encryption request in various implementations.
  • the issuer device may detect that the user has used the issuer device to access the multi-party witness information encryption request information page for the issuer to enter the information to be encrypted and the second witness information parameter information, and enter in the multi-party witness information encryption request page Describes the certificate type, issuer user identification, witness information collection, encryption algorithm identification, encryption key, decryption algorithm identification, decryption key, witness pass condition, and encryption information description information in the information to be encrypted and the second witness information parameter information In the case of waiting, it indicates that the publisher wishes to generate the information ciphertext and witness information ciphertext corresponding to the input information to be encrypted.
  • the publisher device may determine that a multi-party witness information encryption request is detected.
  • the issuer device may also detect a multi-party witness information encryption request interface installed on the issuer device for the user to input the multi-party witness information encryption request interface for the information to be encrypted and the second witness information parameter information.
  • the certificate type, issuer user ID, witness information set, encryption algorithm ID, encryption key, decryption algorithm ID, decryption key In the case of witness passing conditions, description information of encrypted information, etc., it indicates that the publisher wishes to generate the information ciphertext and witness information ciphertext corresponding to the input information to be encrypted.
  • the issuer device can determine that multi-party witness information is detected Encryption request.
  • witness information generation and information encryption operations may include sub-steps 3121 to 3127 shown in FIG. 3G:
  • Sub-step 3121 using the user identification key stored in the trusted execution environment of the issuer device to decrypt the issuer user identification in the second witness information parameter information to obtain the issuer extended user identification.
  • the issuer user identification in the second witness information parameter information is the user identification in the user identification set of the issuer device, and the user identification in the user identification set of the issuer device is a credibility using the issuer device
  • the user identification key stored in the execution environment is encrypted and the user identification key stored in different publisher devices is the same. Therefore, the user identification key stored in the trusted execution environment of the publisher device is used here. Decrypting the issuer user ID in the second witness information parameter information can obtain the issuer extended user ID.
  • Sub-step 3122 generating second witness information.
  • the second witness information may include parameter information of each parameter included in the second witness information parameter information.
  • the second witness information may include certificate category, issuer user identification, witness information set, encryption algorithm identification, encryption key, decryption algorithm identification, decryption key, witness pass condition, and encryption information description information.
  • the second witness information may include at least one of the following: in practice, the witness information type identifier, check code, witness information expiration time, and witness information fixed configuration information. The number of bytes, the number of witnesses, and the number of bytes describing the encrypted message.
  • the values of the parameters of the second witness information are set to the values of the corresponding parameters in the parameter information of the second witness information.
  • Sub-step 3124 Update the issuer user ID in the second witness information to the environment ID in the issuer extended user ID obtained by decryption.
  • the issuer user identifier in the second witness information generated in the sub-step 3122 may be updated to the environment identifier in the issuer extended user identifier decrypted in the 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 user identification set of the issuer device.
  • Sub-step 3125 Update 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.
  • the witness user identifier in each of the witness information sets in the witness information set in the second witness information generated in the sub-step 3122 may be updated to a witness environment identifier corresponding to the witness user identifier.
  • the witness environment ID corresponding to the witness user ID is the environment ID in the extended user ID obtained by decrypting the witness user ID using the 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 set actually stores the environmental identity of the trusted execution environment in the witness device, not the witness device's The user ID in the user ID collection.
  • Sub-step 3126 Use the algorithm and encryption key indicated by the encryption algorithm identifier in the second witness information parameter information to encrypt the encrypted information to obtain the information ciphertext corresponding to the information to be encrypted and the second witness information.
  • Sub-step 3127 Encrypt the second witness information by using the witness information key stored in the trusted execution environment of the publisher device to obtain the ciphertext of the witness information corresponding to the information to be encrypted.
  • the issuer device obtains the information ciphertext and witness information ciphertext corresponding to the information to be encrypted. After that, the issuer device can provide the information ciphertext and witness information ciphertext to the user by various implementation methods. Reference may be made to step 203 of the embodiment shown in FIG. 2A for the description about the intermediary device to provide the cipher text of the intermediary authorization certificate to the user, which is not repeated here.
  • step 313 the user equipment, in response to detecting the multi-party witness information decryption request, executes the multi-party witness information ciphertext decryption operation in the trusted execution environment of the user equipment to obtain the plaintext of the information corresponding to the ciphertext of the information to be decrypted.
  • the user equipment may detect the multi-party witness information decryption request in various implementation manners. For example, the user equipment may detect that the user uses the user equipment to access an information ciphertext decryption page including a page element (for example, a file selection button) for the user to input the ciphertext of the information to be decrypted, and in the above for the user to input the to-be-decrypted When a page address of the information ciphertext to be decrypted and the corresponding witness information ciphertext are input into the page element of the information ciphertext, it is determined that the information ciphertext decryption request is detected.
  • a page element for example, a file selection button
  • the publisher device may also detect that the user has opened the information ciphertext decryption interface in the application installed on the user device, enter the address of the file to be decrypted and the corresponding witness information ciphertext, and click
  • a control for example, a button
  • the multi-party witness information decryption request may include the ciphertext of the information to be decrypted and the corresponding witness information ciphertext.
  • the multi-party witness information ciphertext decryption operation may include sub-steps 3131 to 3133 as shown in FIG. 3H:
  • Sub-step 3131 Decrypt the witness information ciphertext in the multi-party witness information decryption request by using the witness information key stored in the trusted execution environment of the user equipment to obtain the plaintext of the witness information.
  • the witness information key stored in the trusted execution environment of the user device is the same as the witness information key stored in the trusted execution environment of the issuer device, and the witness information key may be stored in the trusted device of the user device.
  • the program in the trusted execution environment of the user device can access the witness information key, but the outside of the trusted execution environment of the user device The program cannot access the witness information key.
  • the ciphertext of the witness information can be decrypted within the trusted execution environment of the user equipment to obtain the plaintext of the witness information, but the witness information cannot be encrypted outside the trusted execution environment of the user equipment. The text is decrypted.
  • Sub-step 3132 Send the witness information ciphertext in the multi-party witness information decryption request to each second target witness device.
  • the second target witness device is the witness device indicated by the witness user identifier in the witness information in the witness information set in the plaintext of the witness information obtained in the 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 plaintext of the witness information obtained by decryption, and uses the algorithm and encryption indicated by the encryption algorithm identifier in the plaintext of the decrypted witness information The key decrypts the ciphertext of the information to be decrypted to obtain the plaintext of the information corresponding to the ciphertext of the information to be decrypted.
  • the user equipment can use the plaintext of the information corresponding to the ciphertext of the information to be decrypted.
  • Step 314 The witness device responds to receiving the ciphertext of the witness information sent by the user device, and uses the witness information key stored in the trusted execution environment of the witness device in the trusted execution environment of the witness device.
  • the ciphertext of the received witness information is decrypted to obtain the plaintext of the witness information.
  • the witness device may use the witness information key stored in the trusted execution environment of the witness device in the trusted execution environment of the witness device when the witness information ciphertext sent by the user device is received. Decrypt the received witness information ciphertext to obtain the plaintext of the witness information.
  • Step 315 The witness device presents the plaintext of the decrypted witness information.
  • the witness device may use various implementation manners to present the plaintext of the witness information obtained in step 314.
  • Step 316 The witness device responds to detecting the witness consent operation that the user entered in plain text for the presented witness information, generates witness pass information, and sends the generated witness pass information to the use of the received cipher text of the witness information. Person equipment.
  • the witness device can be used to enter the witness consent operation (for example, the user can enter the witness consent operation by clicking the button associated with the witness consent operation). If the witness device detects that the user has entered the plaintext of the presented witness information The witness consent operation can generate witness pass information and send the generated witness pass information to the user device that sends the ciphertext of the received witness information.
  • witness pass information please refer to the related description in step 206 in the embodiment shown in FIG. 2A or the related description in sub-step 3091 to sub-step 3092 shown in FIG. 3D, which will not be repeated here. .
  • steps 314 to 316 may be performed after performing the sub-step 3132 in the process of performing the multi-party witness information ciphertext decryption operation by the user equipment in step 313.
  • the user equipment can perform sub-step 3133 in real time during the process of performing steps 314 to 316 by the witness device, without waiting for all witness devices to perform steps 314 to Step 316 only executes sub-step 3133, because it is possible that the witness pass information received from some of the witness devices can satisfy the witness pass conditions required by sub-step 3133.
  • the authorization certificate parameter information and the authorization certificate may further include a certificate type identifier for indicating a certificate type.
  • the authorization certificate parameter information may further include a certificate expiration time
  • 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
  • the trusted execution environment of the issuer device, the middleman device, and the witness device Issuer user IDs, broker user IDs, and witness user IDs used outside of this are generated by the issuer device, broker device, and witness device in their respective trusted execution environments based on the environment ID of the trusted execution environment User ID, and the issuer user ID, middleman user ID, and witness user ID used within the trusted execution environment of the issuer device, middleman device, and witness device are all issuer device, middleman device, and witness The environment identification of each trusted execution environment of the user device. Therefore, the solution described in this embodiment can improve the security of the issuing process of the digital asset's authorization certificate.
  • FIG. 4 it illustrates a process 400 of an embodiment of a method for issuing a certificate, which is applied to a middleman device in a system for issuing a certificate, wherein the system issuer device for issuing a certificate , Middleman device and witness device, issuer device, middleman device and witness device all set a trusted execution environment.
  • the process 400 of the method for issuing a certificate includes the following steps:
  • step 401 in response to receiving the digital asset ciphertext, authorization certificate ciphertext, and witness information ciphertext sent by the issuer device, determining authorized content information for the received digital asset ciphertext.
  • step 401 is basically the same as the specific operation of step 202 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • Step 402 Perform the middleman authorization certificate generation operation in the trusted execution environment of the middleman device to obtain the middleman authorization certificate ciphertext corresponding to the received digital asset ciphertext.
  • step 402 is basically the same as the specific operation of step 203 in the embodiment shown in FIG. 2A, and details are not described herein again.
  • the user identity of the middleman device may be the user identity in the user identity set of the middleman device, and the above process 400 may further include the following step 403:
  • Step 403 In response to detecting a second user ID generation request including the second user ID category ID, determine the second user ID category ID and the trusted execution environment of the middleman device as the target user ID category ID and the target trusted, respectively. An execution environment, in the determined target trusted execution environment, performing a user ID generation operation to obtain a user ID corresponding to the determined target user ID category ID and the determined target trusted execution environment, and the obtained user The identity is added to the user identity collection of the middleman device.
  • step 403 is basically the same as the specific operation of step 302 in the embodiment shown in FIG. 3A, and details are not described herein again.
  • the witness information may further include a witness weight
  • the witness passing conditions may include the witness weight and a preset weight and threshold value or more
  • the middleman authorization certificate is executed.
  • the witness pass information received from each first target witness device within a preset time period may be determined as a target witness pass information set.
  • each target witness pass information in the target witness pass information set perform the following witness weighting and update operations: determine the decrypted witness information in the clear text of the witness information set and the witness who sent the target witness pass information Trust information corresponding to the device; according to a preset algorithm, a witness information key is generated according to the witness user ID in the determined witness information; the target witness pass information is decrypted using the generated witness information key to obtain Key information of witness information; in response to determining that the key information obtained by the witness information is the same as the preset key information in the plaintext of the witness information obtained by decryption, the witness weight is updated and updated to the witness weight and the witness in the determined witness information Sum of weights.
  • the method provided by the above embodiments of the present application determines the authorized content information for the ciphertext of digital assets in the intermediary device, and then executes the intermediary authorized certificate generation operation in the trusted execution environment of the intermediary device to obtain the confidentiality The cipher text of the intermediary authorization certificate corresponding to the text, so that the intermediary device issues an authorization certificate for digital assets.
  • this application provides an embodiment of a device for issuing a certificate.
  • the device embodiment corresponds to the method embodiment shown in FIG. 4.
  • the device can be specifically applied to various electronic devices provided with a trusted execution environment.
  • the apparatus 500 for issuing a certificate in this embodiment includes a determining unit 501 and a generating unit 502.
  • the determining unit 501 is configured to determine the authorized content information for the received digital asset ciphertext in response to receiving the digital asset ciphertext, the authorization certificate ciphertext, and the witness information ciphertext sent by the issuer device; the generating unit 502.
  • the generation operation includes: using the witness information key stored in the trusted execution environment of the middleman device to decrypt the received witness information ciphertext to obtain the plaintext of the witness information; and updating the authorized content information in the plaintext of the decrypted witness information Is the determined authorized content information; using the witness information key stored in the trusted execution environment of the above-mentioned intermediary device to encrypt the updated plaintext of the witness information obtained by decryption to obtain the ciphertext of the intermediary witness information;
  • the ciphertext of the witness information is sent to each first target witness device, where the first target is The witness device is the witness device indicated by the witness user ID in the witness information set in the witness information set in the plaintext of the decrypted witness information; in response to determining that the witness received from each of the first target witness devices passes
  • the received authorization certificate ciphertext is decrypted with the authorization certificate key stored in the trusted execution environment of the above-mentioned broker device to obtain the clear text of the authorization certificate; It is determined that the issuer user ID and the certificate ID in the decrypted plaintext of the authorization certificate are the same as the corresponding parameters in the decrypted witness information plaintext, and that the decrypted authorization certificate plaintext and the decrypted witness information plaintext are both the intermediate user ID Generate a middleman authorization certificate for the user ID of the middleman device, set the values of the parameters in the middleman authorization certificate to the corresponding parameters in the clear text of the decrypted authorization certificate, and set the values in the middleman authorization certificate.
  • Authorized content information is updated to the determined authorized content information ; Brokers trusted execution environment using the above device key stored in the above-described broker authorization certificate authority certificate is encrypted, the ciphertext to obtain the corresponding digital asset broker authorization certificate received ciphertext.
  • the user identifier of the middleman device may be a user identifier in the user ID set of the middleman device; and the apparatus 500 may further include: an adding unit 403 configured to In response to detecting a second user identification generation request including a second user identification category identification, the above-mentioned second user identification category identification and the trusted execution environment of the middleman device are respectively determined as the target user identification category identification and the target trusted execution Environment, in the determined target trusted execution environment, performing a user ID generation operation to obtain a user ID corresponding to the determined target user ID category ID and the determined target trusted execution environment, and the obtained user ID Added to the user ID collection of the above-mentioned middleman device, wherein the user ID generating operation includes: obtaining an environmental ID including a vendor ID and a product ID for indicating the trusted execution environment of the target; randomly generating a random number; using the above User identification key stored in the target trusted execution environment The extended user ID is encrypted to obtain a user ID corresponding to the target user ID category ID and
  • the witness information may further include a witness weight
  • the witness pass condition may include a witness weight and a preset weight and a threshold greater than or equal to each other;
  • the witness pass information received by the tester device satisfies the witness pass conditions in the plaintext of the decrypted witness information, which may include: determining the test pass information received from each of the first target witness devices within a preset time period as the target test pass Information collection; set witness weight and zero; for each target witness pass information in the above target witness pass information set, perform the following witness weight and update operations: determine the decrypted witness information in the clear text of the witness information set and Send the witness information corresponding to the witness device that sent the target witness pass information; according to the above-mentioned preset algorithm, generate the witness information key according to the witness user ID in the determined witness information; use the generated witness information key Decrypt the target witness through information to obtain witness information Key information; in response to determining that the obtained witness information key information is the same as the above-mentioned preset
  • FIG. 6 illustrates a schematic structural diagram of a computer system 600 suitable for implementing an electronic device according to an embodiment of the present application.
  • the electronic device shown in FIG. 6 is only an example, and should not impose any limitation on the functions and scope of use of the embodiments of the present application.
  • the computer system 600 includes a central processing unit (CPU, Central Processing Unit) 601, which can be loaded into random access according to a program stored in a read-only memory (ROM, Read Only Memory) 602 or from a storage portion 608
  • ROM Read Only Memory
  • RAM Random Access Memory
  • a program in a memory (RAM, Random Access Memory) 603 performs various appropriate actions and processes.
  • RAM Random Access Memory
  • various programs and data required for the operation of the system 600 are also stored.
  • the CPU 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604.
  • An input / output (I / O, Input / Output) interface 605 is also connected to the 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 portion 607 including a cathode ray tube (CRT, Cathode Ray Tube), a liquid crystal display (LCD, Liquid Crystal Display), and a speaker, etc.
  • 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, and 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 necessary.
  • a removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.
  • the process described above with reference to the flowchart may be implemented as a computer software program.
  • embodiments of the present disclosure include a computer program product including a computer program carried on a computer-readable medium, the computer program containing program code for performing a method shown in a flowchart.
  • the computer program may be downloaded and installed from a network through the communication portion 609, and / or installed from a removable medium 611.
  • CPU central processing unit
  • the computer-readable medium described in this application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the foregoing.
  • the 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 thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable Programming read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.
  • a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in combination with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium may include a data signal that is included in baseband or propagated as part of a carrier wave, and which carries computer-readable program code. Such a propagated data signal may take many forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing.
  • the computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, and the computer-readable medium may send, propagate, or transmit 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, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
  • Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including programming languages such as Java, Smalltalk, C ++, Python, and also object-oriented. Includes regular procedural programming languages—such as "C” or similar programming languages.
  • the program code can be executed entirely on the user's computer, partly on the user's computer, as an independent software package, partly on the user's computer, partly on a remote computer, or entirely on a remote computer or server.
  • the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (such as through an Internet service provider) Internet connection).
  • LAN local area network
  • WAN wide area network
  • Internet service provider Internet service provider
  • each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, which contains one or more functions to implement a specified logical function Executable instructions.
  • the functions noted in the blocks may also occur in a different order than those marked in the drawings. For example, two successively represented boxes may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved.
  • each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts can be implemented by a dedicated hardware-based system that performs the specified function or operation , Or it can be implemented with a combination of dedicated hardware and computer instructions.
  • the units described in the embodiments of the present application can be implemented by software or hardware.
  • the described unit may also be provided in a processor, for example, it may be described as: a processor includes a determining unit and a generating unit. Among them, the names of these units do not constitute a limitation on the unit itself in some cases.
  • the determining unit may also be described as a “unit for determining authorized content information”.
  • the present application also provides a computer-readable medium, which may be included in the device described in the foregoing embodiments; or may exist alone without being assembled into the device.
  • the above computer-readable medium carries one or more programs, and when the one or more programs are executed by the device, the device causes the device to: in response to receiving the digital asset ciphertext, authorization certificate ciphertext, and witness sent by the issuer device Information ciphertext to determine the authorized content information for the received digital asset ciphertext; perform the middleman authorized certificate generation operation in the trusted execution environment of the middleman device to obtain the intermediate corresponding to the received digital asset ciphertext
  • the cipher text of the vendor authorization certificate, wherein the operation of generating the broker authorization certificate includes: using the witness information key stored in the trusted execution environment of the broker's device to decrypt the received witness information cipher text to obtain the plain text of the witness information; decrypting The authorized content information in the plaintext of the obtained witness information is updated to the determined authorized content information; the witness information obtained in the decrypted
  • the authorized certificate key stored in the trusted execution environment of the intermediary device is used to decrypt the received authorization certificate ciphertext to obtain authorization.
  • the plaintext of the certificate in response to determining that the issuer's user ID and certificate ID in the plaintext of the authorization certificate obtained by decryption are the same as the corresponding parameters in the plaintext of the witness information obtained by decryption, and
  • the middleman user ID is the user ID of the middleman device, generates the middleman authorization certificate, sets the values of the parameters in the middleman authorization certificate to the corresponding parameters in the clear text of the decrypted authorization certificate, and sets the middleman authorization certificate.
  • Authorized content information in is updated to the determined authorized content Information; storing device using a trusted execution environment brokers authorization certificate key pair encrypted authorization certificate intermediaries, to give the corresponding ciphertext digital asset received ciphertext broker authorization certificate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例公开了用于发行证书的系统和方法。该系统包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,其中:首先,数字资产发行者利用发行者设备指定针对目标数字资产的授权证书参数信息和第一见证参数信息,然后发行者设备生成与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,并发送给中间商设备,接着,由中间商设备确定针对所收到的数字资产密文的授权内容信息,并生成中间商授权证书密文。从而实现了通过中间商发行针对数字资产的授权证书,并且每次发行授权证书的过程都需经过见证者的见证,使得见证者可以了解中间商针对数字资产的授权情况。

Description

用于发行证书的系统和方法
相关申请的交叉引用
本申请要求于2018年9月5日递交于中国国家知识产权局(CNIPA)的、申请号为201811030447.8、发明名称为“用于发行证书的系统和方法”的中国发明专利申请的优先权和权益,该中国发明专利申请通过引用整体并入本文。
技术领域
本申请实施例涉及计算机技术领域,具体涉及用于发行证书的系统和方法。
背景技术
数字版权保护(Digital Rights Management,DRM)是目前对网络中传播的数字作品进行版权保护的主要手段。然而,DRM并未解决数字版权如何按通用资产的方式分解控制权,并将使用权迁移转化为License(授权证书)发行的过程。
举例来说,某音乐制作人创作了一首歌,在当前情况下,他只能委托中间商(例如,唱片公司、云音乐运营商等)进行销售。然而,音乐制作人却无法了解中间商的销售方式和销售量,所以音乐制作人无法将自己获得的报酬与中间商的实际销售情况建立关联。
发明内容
本申请实施例提出了用于发行证书的系统和方法。
第一方面,本申请实施例提供了一种用于发行证书的系统,该系统包括:发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,其中:发行者设备,被配置成:响应于检测到包括目标数字资产、授权证书参数信息和第一见 证信息参数信息的密文生成请求,其中,授权证书参数信息和第一见证信息参数信息均包括:证书类别、发行者用户标识、证书标识和中间商用户标识,授权证书参数信息还包括加密算法标识、加密密钥、解密算法标识和解密密钥,第一见证信息参数信息还包括:见证通过条件、数字资产描述信息和见证者信息集合,见证者信息包括见证者用户标识,在该发行者设备的可信执行环境中,执行密文生成操作,得到与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,以及将所得到的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备,其中,密文生成操作包括:生成授权证书,以及将授权证书的各项参数的值设置为授权证书参数信息中相应参数的值;利用该发行者设备的可信执行环境中存储的授权证书密钥对授权证书进行加密,得到与目标数字资产对应的授权证书密文;生成第一见证信息,以及将第一见证信息的各项参数的值设置为第一见证信息参数信息中相应参数的值;利用该发行者设备的可信执行环境中存储的见证信息密钥对第一见证信息进行加密,得到与目标数字资产对应的见证信息密文;利用授权证书参数信息中的加密算法标识所指示的算法和加密密钥对目标数字资产进行加密,得到与目标数字资产对应的数字资产密文;中间商设备,被配置成:响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息,在该中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,其中,中间商授权证书生成操作包括:利用该中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;利用该中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;将中间商见证信息密文发送给各第一目标见证者设备,其中,第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备; 响应于确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用该中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为该中间商设备的用户标识,生成中间商授权证书,将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为所确定的授权内容信息;利用该中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文;见证者设备,被配置成:响应于接收到中间商设备发送的见证信息密文,在该见证者设备的可信执行环境中利用该见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;呈现解密得到的见证信息明文;响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息,以及向发送所收到的见证信息密文的中间商设备发送所生成的见证通过信息。
第二方面,本申请实施例提供了一种用于发行证书的方法,应用于用于发行证书的系统中的中间商设备,该用于发行证书的系统包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,该方法包括:响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;在中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,其中,中间商授权证书生成操作包括:利用中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明 文进行加密,得到中间商见证信息密文;将中间商见证信息密文发送给各第一目标见证者设备,其中,第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;响应于确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为中间商设备的用户标识,生成中间商授权证书,将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
第三方面,本申请实施例提供了一种用于发行证书的装置,应用于用于发行证书的系统中的中间商设备,用于发行证书的系统包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,该装置包括:确定单元,被配置成响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;生成单元,被配置成在中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,其中,中间商授权证书生成操作包括:利用中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;将中间商见证信息密文发送给各第一目标见证者设备,其中,第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合 中见证者信息中的见证者用户标识所指示的见证者设备;响应于确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为中间商设备的用户标识,生成中间商授权证书,将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
第三方面,本申请实施例提供了一种电子设备,包括:一个或多个处理器;存储装置,其上存储有一个或多个程序,当上述一个或多个程序被上述一个或多个处理器执行时,使得上述一个或多个处理器实现如第二方面中任一实现方式描述的方法。
第四方面,本申请实施例提供了一种计算机可读存储介质,其上存储有计算机程序,其中,该计算机程序被一个或多个处理器执行时实现如第二方面中任一实现方式描述的方法。
本申请实施例提供的用于发行证书的系统和方法,首先,由数字资产的发行者利用设置可信执行环境的发行者设备指定针对目标数字资产的授权证书参数信息和第一见证参数信息,然后在发行者设备的可信执行环境中生成与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,并将所生成的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备,接着,由中间商设备确定针对所收到的数字资产密文的授权内容信息,并在该中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,从而实现了通过中间商来发行针对数字资产的授权证书,并且在中间商设备每次生成中间商授权证书的过程中,都需要向见证者设 备发送对授权内容信息更新后的见证信息密文并在确定从各见证者设备接收到的见证通过信息满足见证信息明文中的见证通过条件的情况下生成中间商授权证书,即,每次中间商发行证书都需经过发行者指定的见证者的见证,从而见证者可以了解中间商针对数字资产的授权情况。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显:
图1是本申请的一个实施例可以应用于其中的示例性系统架构图;
图2A是根据本申请的用于发行证书的系统的一个实施例的时序图;
图2B是根据本申请的密文生成操作的一个实施例的流程图;
图2C是根据本申请的中间商授权证书生成操作的一个实施例的流程图;
图3A和图3E是根据本申请的用于发行证书的系统的另一个实施例的时序图;
图3B是根据本申请的用户标识生成操作的一个实施例的流程图;
图3C是根据本申请的密文生成操作的另一个实施例的流程图;
图3D是根据本申请的见证通过信息生成操作的一个实施例的流程图;
图3F是根据本申请的数字资产解密操作的一个实施例的流程图;
图3G是根据本申请的见证信息生成及信息加密操作的一个实施例的流程图;
图3H是根据本申请的多方见证信息密文解密操作的一个实施例的流程图;
图4是根据本申请的用于发行证书的方法的一个实施例的流程图;
图5是根据本申请的用于发行证书的装置的一个实施例的结构示 意图;
图6是适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
图1示出了可以应用本申请的用于发行证书的系统或用于发行证书的方法的实施例的示例性系统架构100。
如图1所示,系统架构100可以包括发行者设备101、中间商设备102、见证者设备103和网络104。网络104用以在发行者设备101、中间商设备102和见证者设备103之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
数字资产(例如,视频、音频、图像、文本等)的发行者可以使用发行者设备101通过网络104与中间商设备102交互,以接收或发送消息等。发行者设备101上可以安装有各种通讯客户端应用,例如用于生成数字资产密文、授权证书密文和见证信息密文的应用、网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。
发行者设备101、中间商设备102和见证者设备103可以是硬件,也可以是软件。当发行者设备101、中间商设备102和见证者设备103为硬件时,可以是具有显示屏且设置可信执行环境(TEE,Trusted Execution Environment)的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。当发行者设备101、中间商设备102和见证者设备103为软件时,可以安装在上述所列举 的电子设备中。其可以实现成多个软件或软件模块,也可以实现成单个软件或软件模块。在此不做具体限定。
这里,TEE是与设备上的Rich OS(通常是Android等)并存的运行环境,并且给Rich OS提供安全服务。TEE具有其自身的执行空间。TEE所能访问的软硬件资源是与Rich OS分离的。TEE提供了可信应用(Trusted Application,TA)的安全执行环境,同时也保护可信应用的资源和数据的保密性,完整性和访问权限。为了保证TEE本身的可信根,TEE在安全启动过程中是要通过验证并且与Rich OS隔离的。在TEE中,每个可信应用是相互独立的,而且不能在未授权的情况下不能互相访问。
作为示例,TEE可以采用如下两种方式:
(1)、借助特定CPU芯片提供的安全防护能力,比如Intel SGX、ARM Trust Zone等,构造一个可信执行环境。
为了保障安全强度,还可以在可信执行环境底层增加可信硬件支持,比如采用符合可信平台模块(TPM,Trusted Platform Module)标准的安全芯片,或采用符合可信密码模块(TCM,Trusted Cryptography Module)标准的安全芯片。
(2)采用加密锁(俗称软件狗)实现可信执行环境。
常见的软件狗常包装成一个小巧的USB(Universal Serial Bus,通用串行总线)设备,软件狗内既提供文件存贮,也支持运行经过定制的程序。采用软件狗,可以不必限定发行者设备、中间商设备和见证者设备的设备类型,只要发行者设备、中间商设备和见证者设备有USB接口即可,降低了对发行者设备、中间商设备和见证者设备的设备要求。
应该理解,软件狗既可以用USB直接连接到服务器,还可以借助类似USB Over Network之类的技术利用TCP/IP通信将USB设备拉远,以远程的逻辑设备方式接入。同样可以理解,这种远程的逻辑设备可以有多个,甚至有成千上万个,形成一种设备池服务方式。
需要说明的是,本申请实施例所提供的用于发行证书的方法一般由中间商设备102执行,相应地,用于发行证书的装置一般设置于中 间商设备102中。
应该理解,图1中的发行者设备、中间商设备、见证者设备和网络的数目仅仅是示意性的。根据实现需要,可以具有任意数目的发行者设备、中间商设备、见证者设备和网络。
继续参考图2A,其示出了根据本申请的用于发行证书的系统的一个实施例的时序200。
本申请实施例中的用于发行证书的系统可以包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境。
如图2A所示,根据本申请的用于发行证书的系统的一个实施例的时序200可以包括以下步骤:
步骤201,发行者设备响应于检测到包括目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求,在该发行者设备的可信执行环境中,执行密文生成操作,得到与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,以及将所得到的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备。
在本实施例中,发行者设备可以在检测到包括目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求的情况下,在该发行者设备的可信执行环境中,执行密文生成操作,得到与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,以及将所得到的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备。
这里,授权证书密文将在中间商设备的可信执行环境中解密成明文,该明文将用作模板以便生成目标授权证书。为方便理解,授权证书密文或明文,也可称为授权证书模板。
这里,见证信息密文将在中间商设备的可信执行环境中解密成明文,该明文将用于控制目标授权证书如何生成,该明文集合了各种控制参数,支持在生成目标授权证书的中间过程实施控制。为方便理解, 见证信息密文或明文,也可称为见证控制块。
这里,授权证书参数信息可以包括针对目标数字资产所要生成的授权证书中的各种参数信息。第一见证信息参数信息可以包括针对目标数字资产所要生成的第一见证信息中的各种参数信息。授权证书参数信息和第一见证信息参数信息均可以包括:证书类别、发行者用户标识、证书标识和中间商用户标识,授权证书参数信息还可以包括加密算法标识、加密密钥、解密算法标识和解密密钥,第一见证信息参数信息还可以包括:见证通过条件、数字资产描述信息和见证者信息集合,而其中,见证者信息可以包括见证者用户标识。
这里,证书类别用于表达目标待颁发证书的目的用途,比如用于解密,或者转密,或者用于多方见证条件下的解密或转密。
这里,发行者用户标识用于唯一标识发行者,发行者用户标识可以包括以下至少一项:数字、字符和文字。
这里,证书标识用于唯一标识同一个发行者发行的各个授权证书(也称为数字证书),证书标识可以包括以下至少一项:数字、字符和文字。实践中,证书标识可以是对于同一个发行者用户标识按照每次递增的方式进行更新的数字。
这里,中间商用户标识用于唯一标识可以对发行者发行的数字资产进行销售的各个中间商,中间商用户标识可以包括以下至少一项:数字、字符和文字。
这里,加密算法标识用于指示对目标数字资产进行加密所使用的加密算法,加密密钥用于表征对目标数字资产进行加密所使用的密钥。而解密算法标识用于指示对目标数字资产密文进行解密所使用的解密算法,解密密钥用于表征对数字资产密文进行解密时所使用的密钥。可以理解的是,当加密算法标识所指示的加密算法为对称加密算法时,相应的解密算法标识所指示的是与加密算法标识所指示的对称加密算法对应的对称解密算法,而且加密密钥和解密密钥可以是相同的密钥。当加密算法标识所指示的加密算法为非对称加密算法时,相应的解密算法标识所指示的是与加密算法标识所指示的非对称加密算法对应的非对称解密算法,而且加密密钥和解密密钥可以是分别是用于非对称 加密的公钥和用于非对称解密的私钥。
这里,见证通过条件可以用于表征发行者输入的从各第一目标见证者设备接收到的见证通过信息所需满足的条件,中间商设备只有在满足该条件时,才可以对授权证书密文进行解密。例如,见证通过条件可以是接收到每个第一目标见证者设备发送的见证通过信息。又例如,见证通过条件也可以是发送见证通过信息的第一目标见证者设备的数目与所有第一目标见证者设备的数目的比值大于等于预设比值(例如,80%)。
这里,数字资产描述信息是发行者使用发行者设备输入的对所要发行的目标数字资产的内容进行描述的信息。数字资产描述信息可以是音频数据,也可以是文本数据,还可以是图片数据。例如,针对音乐类型的数字资产描述信息可以是对该音乐的作词作者、作曲作者、音乐所表达的情感、音乐名称、音乐类型、音乐时长、音乐适合的听众类型等等进行描述的信息。
这里,见证者信息是对见证者进行描述的信息,见证者信息可以包括见证者用户标识。见证者是由发行者指定的、对目标数字资产具有见证权的用户。实践中,见证者一般都是与目标数字资产之间具有利益关系的用户,当然见证者也可以包括发行者自己,即见证者信息集合中的见证者信息中的见证者用户标识可以包括发行者用户标识。例如,对于音乐类型的数字资产而言,见证者可以是音乐数字资产的词作者、曲作者、演唱者、制作者、投资者等等。
实践中,授权证书参数信息还可以包括以下至少一项:证书类型标识、校验码、证书失效时间、证书固定配置信息的字节数,而第一见证信息参数信息还可以包括:见证信息类型标识、校验码、见证信息失效时间、见证信息固定配置信息的字节数,见证者数目、授权内容字节数、数字资产描述信息的字节数。
实践中,发行者设备可以采用各种实现方式检测密文生成请求。例如,发行者设备可以在检测到用户使用发行者设备访问了供发行者输入目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求信息页面,且在该密文生成请求页面中输入了目标数字资 产、授权证书参数信息和第一见证信息参数信息中的证书类别、发行者用户标识、证书标识和中间商用户标识,授权证书参数信息中的加密算法标识、加密密钥、解密算法标识和解密密钥,以及第一见证信息参数信息中的见证通过条件、数字资产描述信息和见证者信息集合等等的情况下,表明发行者希望生成与所输入的目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,这时,发行者设备可以确定检测到密文生成请求。又例如,发行者设备还可以在检测到用户打开了发行者设备上安装的密文生成应用中供用户输入目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求界面,且在该密文生成请求界面中输入了目标数字资产、授权证书参数信息和第一见证信息参数信息中的证书类别、发行者用户标识、证书标识和中间商用户标识,授权证书参数信息中的加密算法标识、加密密钥、解密算法标识和解密密钥,以及第一见证信息参数信息中的见证通过条件、数字资产描述信息和见证者信息集合等等的情况下,表明发行者希望生成与所输入的目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,这时,发行者设备可以确定检测到密文生成请求。
在本实施例中,密文生成操作可以包括如图2B所示的子步骤2011到子步骤2015:
子步骤2011,生成授权证书,以及将授权证书的各项参数的值设置为授权证书参数信息中相应参数的值。
这里,发行者设备可以在该发行者设备的可信执行环境中生成授权证书,以及将授权证书的各项参数的值设置为授权证书参数信息中相应参数的值。可以理解的是,授权证书可以包括授权证书参数信息中所包括的各个参数的参数信息。例如,授权证书可以包括证书类别、发行者用户标识、证书标识和中间商用户标识,授权证书还可以包括加密算法标识、加密密钥、解密算法标识和解密密钥。可以理解的是,授权证书除了包括上述各项参数,实践中授权证书还可以包括以下至少一项:证书类型标识、校验码、证书失效时间、证书固定配置信息的字节数和授权内容信息。
子步骤2012,利用该发行者设备的可信执行环境中存储的授权证书密钥对授权证书进行加密,得到与目标数字资产对应的授权证书密文。
这里,发行者设备的可信执行环境中可以存储有授权证书密钥,授权证书密钥可以存储在发行者设备的可信执行环境之内,但不能存储在发行者设备的可信执行环境之外,并且发行者设备的可信执行环境内的程序可以访问授权证书密钥,但发行者设备的可信执行环境外的程序不能访问授权证书密钥。由于上述授权证书密钥的特性,授权证书明文可以存储在发行者设备的可信执行环境之内,但不能存储在发行者设备的可信执行环境之外,并且发行者设备的可信执行环境内的程序可以访问授权证书明文,但发行者设备的可信执行环境外的程序不能访问授权证书明文,发行者设备的可信执行环境外的程序可以访问授权证书密文。
这里,利用该发行者设备的可信执行环境中存储的授权证书密钥对授权证书进行加密,可以是采用DES(Data Encrytion Standard,美国数据加密标准)算法,3DES/TDEA(三重数据加密算法,Triple Data Encryption Algorithm)算法,AES(Advanced Encryption Standard,高级加密标准)算法、Blowfish算法,RC2算法,RC4算法,RC5算法,IDEA算法(International Data Encryption Algorithm,国际数据加密算法)等各种现在已知或者未来开发的对称加密算法。
子步骤2013,生成第一见证信息,以及将第一见证信息的各项参数的值设置为第一见证信息参数信息中相应参数的值。
这里,发行者设备可以在该发行者设备的可信执行环境中生成第一见证信息,以及将第一见证信息的各项参数的值设置为第一见证信息参数信息中相应参数的值。可以理解的是,第一见证信息可以包括第一见证信息参数信息中所包括的各个参数的参数信息。例如,第一见证信息可以包括证书类别、发行者用户标识、证书标识和中间商用户标识,第一见证信息还可以包括见证通过条件、数字资产描述信息和见证者信息集合。可以理解的是,第一见证信息除了可以包括上述各项参数,实践中第一见证信息还可以包括以下至少一项:见证信息 类型标识、校验码、见证信息失效时间、见证信息固定配置信息的字节数,见证者数目、授权内容字节数、数字资产描述信息的字节数。
子步骤2014,利用该发行者设备的可信执行环境中存储的见证信息密钥对第一见证信息进行加密,得到与目标数字资产对应的见证信息密文。
这里,发行者设备的可信执行环境中可以存储有见证信息密钥,见证信息密钥可以存储在发行者设备的可信执行环境之内,但不能存储在发行者设备的可信执行环境之外,并且发行者设备的可信执行环境内的程序可以访问见证信息密钥,但发行者设备的可信执行环境外的程序不能访问见证信息密钥。由于上述见证信息密钥的特性,第一见证信息明文可以存储在发行者设备的可信执行环境之内,但不能存储在发行者设备的可信执行环境之外,并且发行者设备的可信执行环境内的程序可以访问第一见证信息明文,但发行者设备的可信执行环境外的程序不能访问第一见证信息明文,发行者设备的可信执行环境外的程序可以访问见证信息密文。
这里,利用该发行者设备的可信执行环境中存储的见证信息密钥对第一见证信息进行加密,可以是采用各种现在已知或者未来开发的对称加密算法。
子步骤2015,利用授权证书参数信息中的加密算法标识所指示的算法和加密密钥对目标数字资产进行加密,得到与目标数字资产对应的数字资产密文。
步骤202,中间商设备响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息。
这里,中间商设备可以采用各种实现方式确定针对所收到的数字资产密文的授权内容信息。例如,中间商设备可以在确定所收到的数字资产密文的授权用户的用户标识后,将针对所收到的数字资产密文所确定的授权用户的用户标识作为针对所收到的数字资产密文的授权内容信息。又例如,中间商设备也可以在确定对第一数目个用户给予所收到的数字资产密文的授权后,将第一数目作为授权内容信息。还 例如,中间商设备还可以在确定以第一单价销售第二数目个所收到的数字资产密文后,将第一单价和第二数目作为授权内容信息。当然,可以理解的是,中间商设备还可以组合上述授权用户的用户标识、第一数目、第一单价和第二数目作为授权内容信息。总之,授权内容信息是中间商设备根据自己的销售情况而指定的针对所收到的数字资产密文的授权情况的信息。可以理解的是,上述授权内容最后将保存到请求待生成的授权证书中,授权证书仍借助可信执行环境来实施各种授权的权限控制,比如以第一单价和第二数目作为授权依据时,可信执行环境将记录每解密多少目标数据耗用了多少点数,由可信执行环境中的程序实施从总购买点数中扣除相应用量的操作。
步骤203,中间商设备在该中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文。
这里,中间商授权证书生成操作可以包括如图2C所示的子步骤2031到子步骤2037:
子步骤2031,利用该中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
这里,中间商设备的可信执行环境中存储的见证信息密钥与发行者设备的可信执行环境中存储的见证信息密钥相同,且,见证信息密钥可以存储在中间商设备的可信执行环境之内,但不能存储在中间商设备的可信执行环境之外,并且中间商设备的可信执行环境内的程序可以访问见证信息密钥,但中间商设备的可信执行环境外的程序不能访问见证信息密钥。由于上述见证信息密钥的特性,可以在中间商设备的可信执行环境之内对见证信息密文进行解密得到见证信息明文,但不能在中间商设备的可信执行环境之外对见证信息密文进行解密。
子步骤2032,将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息。
这里,可以将子步骤2031中解密得到的见证信息明文中的授权内容信息更新为步骤202中所确定的授权内容信息。即,子步骤2031中解密得到的见证信息明文中的授权内容信息是发行者设备所检测到 的第一见证信息参数信息中的授权内容信息,而发行者将对目标数字资产对应的数字资产密文的授权委托给中间商进行,那么针对目标数字资产对应的数字资产密文的授权内容信息则是由中间商指定的,因此,需要将子步骤2031中解密得到的见证信息明文中的授权内容信息更新为步骤202中所确定的授权内容信息。
子步骤2033,利用该中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文。
由于已经在子步骤2032中解密得到的见证信息明文中的授权内容信息进行了更新,那么,可以利用该中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文。
子步骤2034,将中间商见证信息密文发送给各第一目标见证者设备。
这里,第一目标见证者设备为子步骤2031中解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备。
子步骤2035,响应于确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用该中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文。
可以理解的是,上述见证通过信息是使用见证信息密钥加密过的密文,上述步骤中判断见证通过条件是否满足之前,应先用见证信息密钥将见证通过信息解密。以密文方式传递见证通过信息可预防此信息被伪造。同样可以理解的是,中间商设备超期未收到第一目标见证者的见证通过信息,将视作收到见证不通过信息。
这里,中间商设备的可信执行环境中存储的授权证书密钥与发行者设备的可信执行环境中存储的授权证书密钥相同,且,授权证书密钥可以存储在中间商设备的可信执行环境之内,但不能存储在中间商设备的可信执行环境之外,并且中间商设备的可信执行环境内的程序 可以访问授权证书密钥,但中间商设备的可信执行环境外的程序不能访问授权证书密钥。由于上述授权证书密钥的特性,可以在中间商设备的可信执行环境之内对授权证书密文进行解密得到授权证书明文,但不能在中间商设备的可信执行环境之外对授权证书密文进行解密。
子步骤2036,响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为该中间商设备的用户标识,生成中间商授权证书,将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为所确定的授权内容信息。
这里,如果确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同,表明解密得到的授权证书明文与解密得到的见证信息明文是对应一个发行者用户标识所指示的发行者设备发行的同一个数字资产的。如果确定解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为该中间商设备的用户标识,表明该中间商设备是解密得到的授权证书明文和解密得到的见证信息明文中所指定的中间商设备。这时,可以生成中间商授权证书,再将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为步骤202中所确定的授权内容信息,从而所生成的中间商授权证书明文中的授权内容信息已经更新为中间商所指定的授权内容信息。可以理解的是,中间商授权证书中包括解密得到的授权证书明文中所包括的各项参数。
可以理解的是,子步骤2036中更新的中间商授权证书是即将生成要发送给被授权者(数字资产的购买者)的授权证书。该证书实质包含三部分内容,第一部分是授权证书的证书头,记录证书的固有属性,包括:证书类别、发行者用户标识、证书标识、中间商用户标识等;第二部分是证书固定配置,可选取值包括:加密算法标识、加密密钥、解密算法标识、解密密钥、转密算法标识、转密密钥等,这部分内容 高度机密,在证书的生成过程以及证书发行后的使用过程均不会泄露出可信执行环境(例如,在将待见证信息呈现给见证者时,不包含这部分内容),这几项密钥均在证书颁发给终端用户后,在购买者的可信执行环境中起作用,以特定解密或转密服务体现购买者享受的权益。第三部分是证书的授权内容,主要用来限定使用范围,可能取值包括:可享受权益的用户标识、解密或转密的用量等,这部分内容就是步骤202中所确定的授权内容信息。
子步骤2037,利用该中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
由于已经在子步骤2036中对中间商授权证书中的授权内容信息进行了更新,这里,可以利用该中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
经过步骤203之后,中间商设备可以将所得到的中间商授权证书密文与所收到的数字资产密文对应存储,并在需要时采用各种实现方式提供给获得所收到的数字资产密文授权的用户。例如,中间商设备可以将数字资产密文以电子邮件的方式发送给获得所收到的数字资产密文授权的用户指定的电子邮箱,然后获得所收到的数字资产密文授权的用户可以通过收取电子邮件的方式获取中间商授权证书密文;或者,中间商设备也可以提供下载中间商授权证书密文的网址链接,然后用户可以通过使用使用者设备打开浏览器点击上述网址链接来下载中间商授权证书密文,又或者,用户还可以通过U盘直接从中间商设备拷贝中间商授权证书密文到使用者设备中。
步骤204,见证者设备响应于接收到中间商设备发送的见证信息密文,在该见证者设备的可信执行环境中利用该见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
这里,见证者设备可以在接收到中间商设备发送的见证信息密文的情况下,在该见证者设备的可信执行环境中利用该见证者设备的可 信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
其中,见证者设备的可信执行环境中存储的见证信息密钥、中间商设备的可信执行环境中存储的见证信息密钥与发行者设备的可信执行环境中存储的见证信息密钥均相同,且,见证信息密钥可以存储在见证者设备的可信执行环境之内,但不能存储在见证者设备的可信执行环境之外,并且见证者设备的可信执行环境内的程序可以访问见证信息密钥,但见证者设备的可信执行环境外的程序不能访问见证信息密钥。由于上述见证信息密钥的特性,可以在见证者设备的可信执行环境之内对见证信息密文进行解密得到见证信息明文,但不能在见证者设备的可信执行环境之外对见证信息密文进行解密。
步骤205,见证者设备呈现解密得到的见证信息明文。
这里,见证者设备可以采用各种实现方式呈现解密得到的见证信息明文。例如,呈现形式可以是在见证者设备的屏幕上以文字形式呈现见证信息明文,也可以以扬声器播放见证信息明文中的文字以语音合成后得到的语音。另外,在呈现解密得到的见证信息明文时,可以将见证信息明文中的全部内容进行呈现,也可呈现部分内容。实践中,通常只呈现见证信息明文中的证书类别、发行者用户标识、证书标识、中间商用户标识和数字资产描述信息。
步骤206,见证者设备响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息,以及向发送所收到的见证信息密文的中间商设备发送所生成的见证通过信息。
由于步骤205中在见证者设备中呈现了解密得到的见证信息明文,这样,用户可以通过见证者设备中呈现的见证信息明文,确定是否见证通过。如果用户见证通过,可以使用见证者设备输入见证同意操作(例如,用户可以通过点击关联有见证同意操作的按钮来输入见证同意操作),如果见证者设备检测到用户针对所呈现的见证信息明文输入的见证同意操作,可以生成见证通过信息,以及向发送所收到的见证信息密文的中间商设备发送所生成的见证通过信息。
中间商向见证人请求见证的环节还可采用以下方式。该方式允许 见证人不依赖可信执行环境也能给出见证通过信息。这种情形要求见证信息明文中的见证者信息集合所包含的见证者信息中的见证者用户标识以公钥表达,而见证结果用与该公钥对应的私钥进行签名来表达见证是否通过。因签名具有不可伪造性,所以由见证者作出的签名通过或不通过的结论是可信的。验证签名则在中间商可信执行环境中,用对应的公钥做验证。在这样的实施例中,具体子步骤可按照以下方式进行:
子步骤2033中,中间商设备的可信执行环境在获得见证信息明文后,从中提取待见证关键信息(证书类别、发行者用户标识、证书标识、中间商用户标识和数字资产描述信息等),以中间商已预设到可信执行环境的第二见证信息密钥加密,得到中间商见证信息密文。
子步骤2035中,中间商设备的可信执行环境对从各第一目标见证者设备接收到的密文态的见证通过信息,先用第二见证信息密钥解密,得到明文,然后核实明文中的待见证关键信息的摘要,然后用对应的公钥验证签名。验证通过后,再结合各位见证者给出的见证结果,综合判断见证通过条件是否满足。
见证者的身份由上述公钥标识,并且见证者拥有与此公钥匹配的私钥,如下涉及见证者的操作步骤有改动:
步骤204中,见证者设备收到见证信息密文后,用第二见证信息密钥解密,得到见证信息明文。
步骤206,见证同意后,生成表征见证通过的见证确认信息,见证确认信息包含两部分,其一为被签名信息,包括见证结果(是否通过)、待见证关键信息的摘要(例如,MD5校验码或哈希摘要值),其二是签名。之后见证确认信息用第二见证信息密钥加密,得到密文态的见证通过信息。
这里,见证通过信息用于表征用户对于见证者设备所呈现的见证信息明文内容的认可。可以理解的是,如果用户对于见证者设备所呈现的见证信息明文内容不认可,可以使用见证者设备输入见证不通过操作,而见证者设备在检测到上述见证不通过操作后,可以生成见证不通过信息。作为示例,见证通过信息与见证不通过信息均包含见证结果,见证结果可以是第一预设数值(例如,通常可以为1,表征见 证通过),还可以是第二预设数值(例如,通常可以为0,表征见证不通过)。见证通过信息与见证不通过信息还包含见证信息明文的摘要(例如,MD5校验码或哈希摘要值)。为防止见证结果被伪造,见证通过信息及见证不通过信息还需用见证信息密钥加密后传送给中间商设备,因为这一步加密在可信执行环境中做出,密文整体难被篡改,所以不必额外增加签名措施。
可以理解的是,见证者做出见证通过或者见证不通过选择,还可以由程序自动判断,自动驱动见证者设备生成见证通过信息或见证不通过信息,并反馈给中间商设备。
可以理解的是,步骤204到步骤205可以是在步骤203中执行中间商授权证书生成操作的过程中执行完子步骤2034之后执行的。而中间商设备在执行中间商授权证书生成操作的过程中,则可以在见证者设备执行步骤204到步骤206的过程中实时执行子步骤2035,不必等到全部见证者设备都执行完步骤204到步骤206才执行子步骤2035,因为有可能从部分见证者设备接收到的见证通过信息可以满足子步骤2035所要求的见证通过条件。
需要说明的是,在本申请中,发行者设备也可以同时作为中间商设备和/或见证者设备,同理,中间商设备也可以同时作为发行者设备和/或见证者设备,而见证者设备也可以同时作为发行者设备和/或中间商设备。
本申请的上述实施例提供的证书发行系统,通过首先由数字资产的发行者利用设置可信执行环境的发行者设备指定针对目标数字资产的授权证书参数信息和第一见证参数信息,然后在发行者设备的可信执行环境中生成与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,并将所生成的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备,接着,由中间商设备确定针对所收到的数字资产密文的授权内容信息,并在该中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,从而实现了通过中间商来发行针对数字资产的授权证书,并且在中间 商设备每次生成中间商授权证书的过程中,都需要向见证者设备发送对授权内容信息更新后的见证信息密文并在确定从各见证者设备接收到的见证通过信息满足见证信息明文中的见证通过条件的情况下生成中间商授权证书,即,每次中间商发行证书都需经过发行者指定的见证者的见证,从而见证者可以了解中间商针对数字资产的授权情况。
进一步参考图3A,其示出了根据本申请的用于发行证书的系统的又一个实施例的时序300。
本申请实施例中的用于发行证书的系统可以包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境。
如图3A所示,根据本申请的用于发行证书的系统的又一个实施例的时序300可以包括以下步骤:
步骤301,发行者设备响应于检测到包括第一用户标识类别标识的第一用户标识生成请求,分别将第一用户标识类别标识和该发行者设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到该发行者设备的用户标识集合中。
实践中,发行者设备可以采用各种实现方式检测第一用户标识生成请求。例如,发行者设备可以在检测到用户使用发行者设备访问了包括供用户输入用户标识类别标识的页面元素(例如,文本框或者下拉菜单等)的用户标识生成页面,并在上述供用户输入用户标识类别标识的页面元素中输入了第一用户标识类别标识时,确定检测到第一用户标识生成请求。又例如,发行者设备还可以在检测到用户打开了发行者设备上安装的应用中的用户标识生成界面,输入了第一用户标识类别标识,并点击了关联有用户标识生成操作的控件(例如,按钮)时,确定检测到第一用户标识生成请求。
这里,第一用户标识类别标识用于指示发行者设备的用户标识集 合中用户标识的类别。实践中,可以按照各种方式对用户标识集合中的用户标识进行分类,每个分类对应不同的第一用户标识类别,而第一用户标识类别标识用于指示不同的第一用户标识类别。作为示例,可以按照所生成的用户标识所应用于的应用的所属类型来进行分类,比如,如果用户希望生成用于社交应用或者社交网站的用户标识,那么,可以输入或者选择社交应用或者社交网站对应的用户标识类别标识生成第一用户标识生成请求。又比如,如果用户希望生成购物应用或者购物网站的用户标识,那么,可以输入或者选择购物应用或者购物网站对应的用户标识类别标识生成第一用户标识生成请求。作为示例,还可以按照递增的方式确定第一用户标识类别标识,即,发行者设备可以存储有当前第一用户标识类别标识,当检测到用户输入的希望生成用户标识的指令时,发行者设备可以获取上述存储的当前第一用户标识类别标识,并将所获取的当前第一用户标识类别标识进行递增更新,用递增更新之后的当前第一用户标识类别标识生成第一用户标识生成请求。
这里,用户标识生成操作可以如图3B所示的子步骤3011到子步骤3013:
子步骤3011,获取用于指示目标可信执行环境的、包括厂商标识和产品标识的环境标识。
这里,可信执行环境的环境标识用于唯一标识可信执行环境,可信执行环境的环境标识可以包括厂商标识和产品标识,其中,可信执行环境的厂商标识用于唯一标识不同的可信执行环境的厂商,而产品标识用于唯一标识同一可信执行环境厂商所生产的可信执行环境。实践中,通常可信执行环境在出厂时已经设置好厂商标识和产品标识,不能进行修改,而且,可信执行环境的环境标识只能存储在可信执行环境之内,可信执行环境之内的程序可以访问可信执行环境的环境标识,而可信执行环境之外的程序不能访问可信执行环境的环境标识。环境标识可以包括以下至少一项:数字、字符和文字。
子步骤3012,随机生成随机数。
子步骤3013,用目标可信执行环境中存储的用户标识密钥对扩展 用户标识进行加密,得到与目标用户标识类别标识和目标可信执行环境对应的用户标识。
这里,扩展用户标识可以包括子步骤3011中所获取的环境标识、所生成的随机数和目标用户标识类别标识。
这里,用户标识密钥可以存储在目标可信执行环境中,且可以被目标可信执行环境之内的程序访问,但不能被目标可信执行环境之外的程序访问。
这里,用目标可信执行环境中存储的用户标识密钥对扩展用户标识进行加密,可以采用各种对称加密算法。
步骤301中所生成的用户标识是基于发行者设备的可信执行环境的环境标识生成的,而且还加入了所生成的随机数和第一用户标识类别标识,对于发行者设备的可信执行环境之外的程序而言,仅仅可以得到所生成的用户标识,但不能解析所生成的用户标识中的环境标识,发行者设备的可信执行环境内的程序可以解析所生成的用户标识得到用户标识中的环境标识,因此,可以保护发行者设备的用户标识集合中的用户标识不被可信执行环境之外的程序破解。
步骤302,中间商设备响应于检测到包括第二用户标识类别标识的第二用户标识生成请求,分别将第二用户标识类别标识和该中间商设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到该中间商设备的用户标识集合中。
这里,关于用户标识生成操作可参考步骤301中的相关描述在此不再赘述。
步骤303,见证者设备响应于检测到包括第三用户标识类别标识的第三用户标识生成请求,分别将第三用户标识类别标识和该见证者设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应 的用户标识,以及将所得到的用户标识添加到该见证者设备的用户标识集合中。
这里,关于用户标识生成操作可参考步骤301中的相关描述在此不再赘述。
可以理解的是,经过步骤301到步骤303,发行者设备、中间商设备和见证者设备的用户标识集合中的用户标识分别为在发行者设备、中间商设备和见证者设备中的可信执行环境中基于该可信执行环境的环境标识生成的,对于可信执行环境之外的程序而言,仅仅可以得到所生成的用户标识,但不能解析所生成的用户标识中的环境标识,即可信执行环境内的程序可以解析所生成的用户标识得到用户标识中的环境标识。因此,步骤301到步骤303,可以保护发行者设备、中间商设备和见证者设备的用户标识集合中的用户标识不被可信执行环境之外的程序破解。
步骤304,发行者设备响应于检测到包括目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求,在该发行者设备的可信执行环境中,执行密文生成操作,得到与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,以及将所得到的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备。
在本实施例中,发行者设备可以在检测到包括目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求的情况下,在该发行者设备的可信执行环境中,执行密文生成操作,得到与目标数字资产对应的数字资产密文、授权证书密文和见证信息密文,以及将所得到的数字资产密文、授权证书密文和见证信息密文发送给授权证书参数信息中的中间商用户标识所指示的中间商设备。
这里,关于授权证书参数信息、第一见证信息参数信息、证书类别、发行者用户标识、证书标识、中间商用户标识、加密算法标识、加密密钥、解密算法标识、解密密钥、见证通过条件、数字资产描述信息和见证者信息,可以参考图2A所示的实施例中步骤201中的相关描述,在此不再赘述。
这里,授权证书参数信息和第一见证信息参数信息中的发行者用户标识可以是发行者设备的用户标识集合中的用户标识。而发行者设备可以通过执行步骤301来向该发行者设备的用户标识集合中添加用户标识,具体请参考步骤301中的相关描述。
这里,授权证书参数信息和第一见证信息参数信息中的中间商用户标识可以是中间商设备的用户标识集合中的用户标识。而中间商设备可以通过执行步骤302来向该中间商设备的用户标识集合中添加用户标识,具体请参考步骤302中的相关描述。
这里,第一见证信息参数信息中的见证者信息集合中的见证者信息中的见证者用户标识是见证者设备的用户标识集合中的用户标识。而见证者设备可以通过执行步骤303来向该见证者设备的用户标识集合中添加用户标识,具体请参考步骤303中的相关描述。
这里,需要说明的是,不同的发行者设备、中间商设备以及见证者设备的可信执行环境中存储的用户标识密钥是相同的。
实践中,发行者设备可以采用各种实现方式检测密文生成请求。
在本实施例中,密文生成操作可以包括如图3C所示的子步骤3041到子步骤3049:
子步骤3041,生成授权证书,以及将授权证书的各项参数的值设置为授权证书参数信息中相应参数的值。
在本实施例中,子步骤3041的具体操作与图2A所示的实施例中子步骤2011的具体操作基本相同,在此不再赘述。
子步骤3042,利用该发行者设备的可信执行环境中存储的用户标识密钥分别对授权证书参数信息和第一见证信息参数信息中的发行者用户标识和中间商用户标识进行解密,得到发行者扩展用户标识和中间商扩展用户标识。
这里,由于授权证书参数信息和第一见证信息参数信息中的发行者用户标识是发行者设备的用户标识集合中的用户标识,中间商用户标识是中间商设备的用户标识集合中的用户标识,而且,发行者设备的用户标识集合中的用户标识是采用该发行者设备的可信执行环境中存储的用户标识密钥加密得到的,中间商设备的用户标识集合中的用 户标识是采用该中间商设备的可信执行环境中存储的用户标识密钥加密得到的,以及不同的发行者设备、中间商设备以及见证者设备的可信执行环境中存储的用户标识密钥是相同的,因此,这里利用该发行者设备的可信执行环境中存储的用户标识密钥分别对授权证书参数信息和第一见证信息参数信息中的发行者用户标识和中间商用户标识进行解密,可以得到发行者扩展用户标识和中间商扩展用户标识。
子步骤3043,将授权证书中的发行者用户标识和中间商用户标识分别更新为发行者扩展用户标识中的环境标识和中间商扩展用户标识中的环境标识。
这里,可以将子步骤3041中生成的授权证书中的发行者用户标识和中间商用户标识分别更新为子步骤3042中解密得到的发行者扩展用户标识中的环境标识和中间商扩展用户标识中的环境标识。即,所生成的授权证书中的发行者用户标识和中间商用户标识分别实际存储的是发行者设备中可信执行环境的环境标识和中间商设备中可信执行环境的环境标识,而不是发行者设备的用户标识集合中的用户标识或者中间商设备的用户标识集合中的用户标识。
子步骤3044,利用该发行者设备的可信执行环境中存储的授权证书密钥对授权证书进行加密,得到与目标数字资产对应的授权证书密文。
在本实施例中,子步骤3044的具体操作与图2A所示的实施例中子步骤2012的具体操作基本相同,在此不再赘述。
子步骤3045,生成第一见证信息,以及将第一见证信息的各项参数的值设置为第一见证信息参数信息中相应参数的值。
在本实施例中,子步骤3045的具体操作与图2A所示的实施例中子步骤2013的具体操作基本相同,在此不再赘述。
子步骤3046,将第一见证信息中的发行者用户标识和中间商用户标识分别更新为发行者扩展用户标识中的环境标识和中间商扩展用户标识中的环境标识。
这里,可以将子步骤3045中生成的第一见证信息中的发行者用户标识和中间商用户标识分别更新为子步骤3042中解密得到的发行者 扩展用户标识中的环境标识和中间商扩展用户标识中的环境标识。即,所生成的第一见证信息中的发行者用户标识和中间商用户标识分别实际存储的是发行者设备中可信执行环境的环境标识和中间商设备中可信执行环境的环境标识,而不是发行者设备的用户标识集合中的用户标识或者中间商设备的用户标识集合中的用户标识。
子步骤3047,将第一见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与该见证者用户标识对应的见证者环境标识。
这里,可以将子步骤3045中生成的第一见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与该见证者用户标识对应的见证者环境标识。其中,与该见证者用户标识对应的见证者环境标识是利用该发行者设备的可信执行环境中存储的用户标识密钥对该见证者用户标识进行解密所得到的扩展用户标识中的环境标识。即,所生成的第一见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识实际存储的是见证者设备中可信执行环境的环境标识,而不是见证者设备的用户标识集合中的用户标识。
子步骤3048,利用该发行者设备的可信执行环境中存储的见证信息密钥对第一见证信息进行加密,得到与目标数字资产对应的见证信息密文。
在本实施例中,子步骤3048的具体操作与图2A所示的实施例中子步骤2014的具体操作基本相同,在此不再赘述。
子步骤3049,利用授权证书参数信息中的加密算法标识所指示的算法和加密密钥对目标数字资产进行加密,得到与目标数字资产对应的数字资产密文。
在本实施例中,子步骤3049的具体操作与图2A所示的实施例中子步骤2015的具体操作基本相同,在此不再赘述。
步骤305,中间商设备响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息。
在本实施例中,步骤305的具体操作与图2A所示的实施例中子 步骤202的具体操作基本相同,在此不再赘述。
步骤306,中间商设备在该中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文。
在本实施例中,步骤306的具体操作与图2A所示的实施例中子步骤203的具体操作基本相同,在此不再赘述。
步骤307,见证者设备响应于接收到中间商设备发送的见证信息密文,在该见证者设备的可信执行环境中利用该见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
在本实施例中,步骤307的具体操作与图2A所示的实施例中子步骤204的具体操作基本相同,在此不再赘述。
步骤308,见证者设备呈现解密得到的见证信息明文。
在本实施例中,步骤308的具体操作与图2A所示的实施例中子步骤205的具体操作基本相同,在此不再赘述。
步骤309,见证者设备响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息,以及向发送所收到的见证信息密文的中间商设备发送所生成的见证通过信息。
在本实施例中,步骤309的具体操作与图2A所示的实施例中子步骤206的具体操作基本相同,在此不再赘述。
在本实施例的一些的实现方式中,步骤309中见证者设备生成见证通过信息可以在该见证者设备的可信执行环境中执行见证通过信息生成操作,得到与所收到的见证信息密文对应的见证通过信息,其中,见证通过信息生成操作可以包括如图3D所示的子步骤3091到子步骤3092:
子步骤3091,响应于对解密得到的见证信息明文进行完整性校验通过,按照预设算法,根据该见证者设备的可信执行环境的环境标识生成见证信息密钥。
这里,对步骤307中解密得到的见证信息明文进行完整性校验,可以通过计算见证信息明文中除验证码以外的其他内容的消息摘要 值,然后如果计算所得的消息摘要值与见证信息明文中的验证码相同,表明对解密得到的见证信息明文进行完整性校验通过。
这里,预设算法可以是各种根据可信执行环境的环境标识生成密钥的算法。作为示例,按照预设算法,根据该见证者设备的可信执行环境的环境标识生成见证信息密钥可以如下进行:组合该见证者设备的可信执行环境的环境标识和该见证者设备的可信执行环境中存储的预设密钥分量标识(例如,可以是预设常数)得到见证信息密钥。
又例如,按照预设算法,根据该见证者设备的可信执行环境的环境标识生成见证信息密钥也可以如下进行:将根据该见证者设备的可信执行环境的环境标识与该见证者设备的可信执行环境中存储的预设掩码做异或运算,得到见证信息密钥。
子步骤3092,用所生成的见证信息密钥对解密得到的见证信息明文中的预设关键信息进行加密,得到与所收到的见证信息密文对应的见证通过信息。
这里,可以用子步骤3091中所生成的见证信息密钥对步骤307中解密得到的见证信息明文中的预设关键信息进行加密,得到与所收到的见证信息密文对应的见证通过信息。其中,预设关键信息可以是见证信息明文中的至少一种预设参数的参数信息。实践中,预设关键信息可以包括验证码、证书类别、发行者用户标识和证书标识。
基于上述可选实现方式,见证者信息还可以包括见证者权重,见证通过条件可以包括见证者权重和大于等于预设权重和阈值。这样,中间商授权证书生成操作中确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,可以如下进行:
首先,可以将预设时间段内从各第一目标见证者设备接收到的见证通过信息确定为目标见证通过信息集合。
即,中间商设备不可能一直等待所有的第一目标见证者设备返回见证通过信息,因此,可以将预设时间段(例如,从中间商设备将中间商见证信息密文发送给各第一目标见证者设备的时间点开始十分钟之内)内从各第一目标见证者设备接收到的见证通过信息确定为目标 见证通过信息集合。
然后,可以将见证权重和置零。
接着,可以对于目标见证通过信息集合中的每个目标见证通过信息,执行以下见证者权重和更新操作:
第一步,确定解密得到的见证信息明文中的见证者信息集合中与发送该目标见证通过信息的见证者设备对应的见证者信息。
第二步,按照上述预设算法,根据所确定的见证者信息中的见证者用户标识,生成见证信息密钥。
这里,所确定的见证者信息中的见证者用户标识实际存储的是见证者用户标识所指示的见证者设备中的可信执行环境的环境标识。而且,这里的预设算法即为子步骤3091中,见证者设备在该见证者设备的可信执行环境中根据该见证者设备的可信执行环境的环境标识生成见证信息密钥时所使用的预设算法。
第三步,用所生成的见证信息密钥对该目标见证通过信息进行解密,得到见证信息关键信息。
第四步,响应于确定所得到的见证信息关键信息与解密得到的见证信息明文中的预设关键信息相同,将见证权重和更新为见证权重和与所确定的见证者信息中的见证者权重之和。
如果所得到的见证信息关键信息与解密得到的见证信息明文中的预设关键信息相同,表明所得到的见证信息关键信息确实来自解密得到的见证信息明文中所指定的见证者信息集合中的见证者信息中的见证者用户标识所指示的见证者设备,从而可以确定该见证者设备确实检测到用户针对解密得到的见证信息明文输入的见证同意操作,那么就可以将见证权重和更新为见证权重和与所确定的见证者信息中的见证者权重之和。
最后,响应于确定见证者权重和大于等于预设权重和阈值,确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件。
这里,如果确定见证者权重和大于等于预设权重和阈值,表明从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信 息明文中的见证通过条件。
这里,见证者信息中的见证者用户标识和见证者权重是由发行者设备接收用户输入的。通常,发行者设备的用户(可以称为发行者)可以按照对目标数字资产的收益比例来设置见证者权重,见证者对目标数字资产的收益比例与该见证者的见证者权重正相关。
由于页面显示限制,下面继续参考图3E,需要说明的是,图3E的流程除了包括图3E中所示的各个步骤外,还可以包括图3A中所示的各个步骤。另外,需要说明的是,图3E中所示的发行者设备和见证者设备除了可以执行图3E中所示的相应步骤外,还可以执行图3A中所示的发行者设备和见证者设备可以执行的相应步骤。
在本实施例的一些的实现方式中,授权内容信息可以包括授权环境标识集合,上述用于发行证书的系统还可以包括设置可信执行环境的使用者设备。这样,上述时序300还可以包括以下步骤310和步骤311:
步骤310,使用者设备响应于检测到针对待解密数字资产密文的解密请求,确定与待解密数字资产密文对应的中间商授权证书密文。
这里,使用者设备可以采用各种实现方式检测针对待解密数字资产密文的解密请求。例如,使用者设备可以在检测到用户使用使用者设备访问了包括供用户输入待解密数字资产的页面元素(例如,文件选择按钮)的数字资产解密页面,并在上述供用户输入待解密数字资产的页面元素中输入了待解密数字资产所在的文件地址时,确定检测到解密请求。又例如,发行者设备还可以在检测到用户打开了使用者设备上安装的应用中的数字资产解密界面,输入了待解密数字资产所在文件地址,并点击了关联有数字资产解密操作的控件(例如,按钮)时,确定检测到解密请求。
这里,使用者设备可以采用各种实现方式确定与待解密数字资产密文对应的中间商授权证书密文。例如,用户可以使用使用者设备收取中间商设备针对待解密数字资产密文发送的电子邮件中的中间商授权证书密文,并将中间商授权证书密文保存下来作为与待解密数字资产密文对应的中间商授权证书密文。又例如,用户也可以使用使用者 设备点击中间商设备为待解密数字资产提供的下载中间商授权证书密文的网址链接,来下载中间商授权证书密文。再例如,用户还可以通过U盘直接从中间商设备拷贝授权证书密文到使用者设备中。
执行完步骤310后,继续执行步骤311。
步骤311,使用者设备在该使用者设备的可信执行环境中,执行数字资产解密操作得到与待解密数字资产密文对应的数字资产明文。
这里,数字资产解密操作可以包括如图3F所示的子步骤3111和子步骤3112:
子步骤3111,在该使用者设备的可信执行环境中,利用该使用者设备的可信执行环境中存储的授权证书密钥对所确定的中间商授权证书密文进行解密,得到中间商授权证书明文。
这里,中间商设备的可信执行环境中存储的授权证书密钥、发行者设备的可信执行环境中存储的授权证书密钥和使用者设备的可信执行环境中存储的授权证书密钥均相同。而且,授权证书密钥可以存储在使用者设备的可信执行环境之内,但不能存储在使用者设备的可信执行环境之外,并且使用者设备的可信执行环境内的程序可以访问授权证书密钥,但使用者设备的可信执行环境外的程序不能访问授权证书密钥。由于上述授权证书密钥的特性,可以在使用者设备的可信执行环境之内对中间商授权证书密文进行解密得到中间商授权证书明文,但不能在使用者设备的可信执行环境之外对中间商授权证书密文进行解密。
步骤3112,响应于确定该使用者设备的可信执行环境的环境标识属于解密得到的中间商授权证书明文中的授权内容信息中的授权用户标识集合,利用解密得到的授权证书明文中的解密算法标识所指示的算法和解密密钥对待解密数字资产密文进行解密,得到与待解密数字资产密文对应的数字资产明文。
这里,如果该使用者设备的可信执行环境的环境标识属于解密得到的中间商授权证书明文中的授权内容信息中的授权用户标识集合,表明中间商已经授权该使用者设备使用待解密数字资产,那么可以利用子步骤3111中解密得到的授权证书明文中的解密算法标识所指示 的算法和解密密钥对步骤310中检测到的解密请求所针对的待解密数字资产密文进行解密,得到与待解密数字资产密文对应的数字资产明文。
经过步骤310和步骤311,使用者设备可以实现对待解密数字资产进行解密并获得对应的数字资产明文。
在本实施例的一些的实现方式中,上述时序300还可以包括以下步骤312到步骤316:
步骤312,发行者设备响应于检测到多方见证信息加密请求,在该发行者设备的可信执行环境中,执行见证信息生成及信息加密操作,得到与待加密信息对应的信息密文和见证信息密文。
这里,多方见证信息加密请求可以包括待加密信息和对应的第二见证信息参数信息,而第二见证信息参数信息可以包括证书类别、发行者用户标识、见证者信息集合、加密算法标识、加密密钥、解密算法标识、解密密钥、见证通过条件和加密信息描述信息。
这里,加密信息描述信息可以是发行者使用发行者设备输入的对所要发行的待加密信息的内容进行描述的信息。加密信息描述信息可以是音频数据,也可以是文本数据,还可以是图片数据。例如,针对一份待加密的遗嘱内容的加密信息描述信息可以是对该份遗嘱的立遗嘱人、遗产受益人等进行描述的信息。
实践中,发行者设备可以采用各种实现方式检测多方见证信息加密请求。例如,发行者设备可以在检测到用户使用发行者设备访问了供发行者输入待加密信息和第二见证信息参数信息的多方见证信息加密请求信息页面,且在该多方见证信息加密请求页面中输入了待加密信息和第二见证信息参数信息中的证书类别、发行者用户标识、见证者信息集合、加密算法标识、加密密钥、解密算法标识、解密密钥、见证通过条件和加密信息描述信息等等的情况下,表明发行者希望生成与所输入的待加密信息对应的信息密文和见证信息密文,这时,发行者设备可以确定检测到多方见证信息加密请求。又例如,发行者设备还可以在检测到用户打开了发行者设备上安装的多方见证信息加密应用中供用户输入待加密信息和第二见证信息参数信息的多方见证信 息加密请求界面,且在该多方见证信息加密请求界面中输入了待加密信息和第二见证信息参数信息中的证书类别、发行者用户标识、见证者信息集合、加密算法标识、加密密钥、解密算法标识、解密密钥、见证通过条件和加密信息描述信息等等的情况下,表明发行者希望生成与所输入的待加密信息对应的信息密文和见证信息密文,这时,发行者设备可以确定检测到多方见证信息加密请求。
这里,见证信息生成及信息加密操作可以包括如图3G所示的子步骤3121到子步骤3127:
子步骤3121,利用该发行者设备的可信执行环境中存储的用户标识密钥对第二见证信息参数信息中的发行者用户标识进行解密,得到发行者扩展用户标识。
这里,由于第二见证信息参数信息中的发行者用户标识是发行者设备的用户标识集合中的用户标识,而且,发行者设备的用户标识集合中的用户标识是采用该发行者设备的可信执行环境中存储的用户标识密钥加密得到的,以及不同的发行者设备中存储的用户标识密钥是相同的,因此,这里利用该发行者设备的可信执行环境中存储的用户标识密钥分别对第二见证信息参数信息中的发行者用户标识进行解密,可以得到发行者扩展用户标识。
子步骤3122,生成第二见证信息。
这里,第二见证信息可以包括第二见证信息参数信息中所包括的各个参数的参数信息。例如,第二见证信息可以包括证书类别、发行者用户标识、见证者信息集合、加密算法标识、加密密钥、解密算法标识、解密密钥、见证通过条件和加密信息描述信息。可以理解的是,第二见证信息除了包括上述各项参数,实践中第二见证信息还可以包括以下至少一项:见证信息类型标识、校验码、见证信息失效时间、见证信息固定配置信息的字节数,见证者数目和加密信息描述信息的字节数。
子步骤3123,将第二见证信息的各项参数的值设置为第二见证信息参数信息中相应参数的值。
子步骤3124,将第二见证信息中的发行者用户标识更新为解密得 到的发行者扩展用户标识中的环境标识。
这里,可以将子步骤3122中生成的第二见证信息中的发行者用户标识更新为子步骤3121中解密得到的发行者扩展用户标识中的环境标识。即,所生成的第二见证信息中的发行者用户标识实际存储的是发行者设备中可信执行环境的环境标识,而不是发行者设备的用户标识集合中的用户标识。
子步骤3125,将第二见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与该见证者用户标识对应的见证者环境标识。
这里,可以将子步骤3122中生成的第二见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与该见证者用户标识对应的见证者环境标识。其中,与该见证者用户标识对应的见证者环境标识是利用该发行者设备的可信执行环境中存储的用户标识密钥对该见证者用户标识进行解密所得到的扩展用户标识中的环境标识。即,所生成的第二见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识实际存储的是见证者设备中可信执行环境的环境标识,而不是见证者设备的用户标识集合中的用户标识。
子步骤3126,利用第二见证信息参数信息中的加密算法标识所指示的算法和加密密钥对待加密信息进行加密,得到与待加密信息和第二见证信息对应的信息密文。
子步骤3127,用该发行者设备的可信执行环境中存储的见证信息密钥对第二见证信息进行加密,得到与待加密信息对应的见证信息密文。
经过步骤312,发行者设备得到了与待加密信息对应的信息密文和见证信息密文,这之后,发行者设备可以采用各种实现方式将信息密文和见证信息密文提供给用户,具体可参考图2A所示的实施例的步骤203中关于中间商设备将中间商授权证书密文提供给用户的相关描述,在此不再赘述。
步骤313,使用者设备响应于检测到多方见证信息解密请求,在该使用者设备的可信执行环境中执行多方见证信息密文解密操作,得 到与待解密信息密文对应的信息明文。
这里,使用者设备可以采用各种实现方式检测多方见证信息解密请求。例如,使用者设备可以在检测到用户使用使用者设备访问了包括供用户输入待解密信息密文的页面元素(例如,文件选择按钮)的信息密文解密页面,并在上述供用户输入待解密信息密文的页面元素中输入了待解密信息密文和对应的见证信息密文所在的文件地址时,确定检测到信息密文解密请求。又例如,发行者设备还可以在检测到用户打开了使用者设备上安装的应用中的信息密文解密界面,输入了待解密信息密文和对应的见证信息密文所在的文件地址,并点击了关联有信息密文操作的控件(例如,按钮)时,确定检测到信息密文解密请求。
这里,多方见证信息解密请求可以包括待解密信息密文和对应的见证信息密文。
这里,多方见证信息密文解密操作可以包括如图3H所示的子步骤3131到子步骤3133:
子步骤3131,利用该使用者设备的可信执行环境中存储的见证信息密钥对多方见证信息解密请求中的见证信息密文进行解密得到见证信息明文。
这里,使用者设备的可信执行环境中存储的见证信息密钥与发行者设备的可信执行环境中存储的见证信息密钥相同,且,见证信息密钥可以存储在使用者设备的可信执行环境之内,但不能存储在使用者设备的可信执行环境之外,并且使用者设备的可信执行环境内的程序可以访问见证信息密钥,但使用者设备的可信执行环境外的程序不能访问见证信息密钥。由于上述见证信息密钥的特性,可以在使用者设备的可信执行环境之内对见证信息密文进行解密得到见证信息明文,但不能在使用者设备的可信执行环境之外对见证信息密文进行解密。
子步骤3132,将多方见证信息解密请求中的见证信息密文发送给各个第二目标见证者设备。
这里,第二目标见证者设备为子步骤3131中解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的 见证者设备。
子步骤3133,响应于确定从各第二见证者设备接收的见证通过信息满足解密得到的见证信息明文中的见证通过条件,利用解密得到的见证信息明文中的加密算法标识所指示的算法和加密密钥对待解密信息密文进行解密得到与待解密信息密文对应的信息明文。
从而经过步骤313,使用者设备可以使用与待解密信息密文对应的信息明文。
步骤314,见证者设备响应于接收到使用者设备发送的见证信息密文,在该见证者设备的可信执行环境中利用该见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
这里,见证者设备可以在接收到使用者设备发送的见证信息密文的情况下,在该见证者设备的可信执行环境中利用该见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文。
步骤315,见证者设备呈现解密得到的见证信息明文。
这里,见证者设备可以采用各种实现方式呈现步骤314中解密得到的见证信息明文。
步骤316,见证者设备响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息,以及将所生成的见证通过信息发送给发送所收到的见证信息密文的使用者设备。
由于步骤315中在见证者设备中呈现了步骤314中解密得到的见证信息明文,这样,用户可以通过见证者设备中呈现的见证信息明文,确定是否见证通过。如果用户见证通过,可以使用见证者设备输入见证同意操作(例如,用户可以通过点击关联有见证同意操作的按钮来输入见证同意操作),如果见证者设备检测到用户针对所呈现的见证信息明文输入的见证同意操作,可以生成见证通过信息,以及将所生成的见证通过信息发送给发送所收到的见证信息密文的使用者设备。
这里,关于如何生成见证通过信息可以参考图2A所示是实施例中步骤206中的相关描述或者也可以参考图3D所示的子步骤3091到 子步骤3092中的相关描述,在此不再赘述。
可以理解的是,步骤314到步骤316可以是在步骤313中使用者设备执行多方见证信息密文解密操作的过程中执行完子步骤3132之后执行的。而使用者设备在执行多方见证信息密文解密操作的过程中,则可以在见证者设备执行步骤314到步骤316的过程中实时执行子步骤3133,不必等到全部见证者设备都执行完步骤314到步骤316才执行子步骤3133,因为有可能从部分见证者设备接收到的见证通过信息可以满足子步骤3133所要求的见证通过条件。
在本实施例的一些可选的实现方式中,授权证书参数信息和授权证书还可以包括用于指示证书类型的证书类型标识。
在本实施例的一些可选的实现方式中,授权证书参数信息还可以包括证书失效时间,第一见证信息参数信息、第二见证信息参数信息、第一见证信息和第二见证信息还可以包括见证信息失效时间。
从图3中可以看出,与图2对应的实施例相比,本实施例中的用于发行证书的系统的时序300中,发行者设备、中间商设备和见证者设备的可信执行环境之外使用的发行者用户标识、中间商用户标识和见证者用户标识均为发行者设备、中间商设备和见证者设备在各自的可信执行环境中根据可信执行环境的环境标识所生成的用户标识,而在发行者设备、中间商设备和见证者设备的可信执行环境之内使用的发行者用户标识、中间商用户标识和见证者用户标识均为发行者设备、中间商设备和见证者设备的各自的可信执行环境的环境标识。由此,本实施例描述的方案可以提高数字资产的授权证书发行过程的安全性。
进一步参考图4,其示出了一种用于发行证书的方法的一个实施例的流程400,应用于用于发行证书的系统中的中间商设备,其中,用于发行证书的系统发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,该用于发行证书的方法的流程400,包括以下步骤:
步骤401,响应于接收到发行者设备发送的数字资产密文、授权 证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息。
在本实施例中,步骤401的具体操作与图2A所示的实施例中步骤202的具体操作基本相同,在此不再赘述。
步骤402,在中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文。
在本实施例中,步骤402的具体操作与图2A所示的实施例中步骤203的具体操作基本相同,在此不再赘述。
在本实施例的一些可选的实现方式中,中间商设备的用户标识可以是中间商设备的用户标识集合中的用户标识,以及上述流程400还可以包括以下步骤403:
步骤403,响应于检测到包括第二用户标识类别标识的第二用户标识生成请求,分别将第二用户标识类别标识和中间商设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到中间商设备的用户标识集合中。
这里,步骤403的具体操作与图3A所示的实施例中步骤302的具体操作基本相同,在此不再赘述。
在本实施例的一些可选的实现方式中,见证者信息还可以包括见证者权重,见证通过条件可以包括见证者权重和大于等于预设权重和阈值,以及步骤402中在执行中间商授权证书生成操作的过程中确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,可以如下进行:
首先,可以将预设时间段内从各第一目标见证者设备接收到的见证通过信息确定为目标见证通过信息集合。
然后,可以将见证权重和置零。
接着,对于目标见证通过信息集合中的每个目标见证通过信息,执行以下见证者权重和更新操作:确定解密得到的见证信息明文中的见证者信息集合中与发送该目标见证通过信息的见证者设备对应的见 证者信息;按照预设算法,根据所确定的见证者信息中的见证者用户标识,生成见证信息密钥;用所生成的见证信息密钥对该目标见证通过信息进行解密,得到见证信息关键信息;响应于确定所得到的见证信息关键信息与解密得到的见证信息明文中的预设关键信息相同,将见证权重和更新为见证权重和与所确定的见证者信息中的见证者权重之和。
最后,响应于确定见证者权重和大于等于预设权重和阈值,确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件。
本申请的上述实施例提供的方法通过在中间商设备中确定针对数字资产密文的授权内容信息,再在中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与数字资产密文对应的中间商授权证书密文,从而实现了由中间商设备为数字资产发行授权证书。
进一步参考图5,作为对上述各图所示方法的实现,本申请提供了一种用于发行证书的装置的一个实施例,该装置实施例与图4所示的方法实施例相对应,该装置具体可以应用于各种设置有可信执行环境的电子设备中。
如图5所示,本实施例的用于发行证书的装置500包括:确定单元501和生成单元502。其中,确定单元501,被配置成响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;生成单元502,被配置成在上述中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,其中,上述中间商授权证书生成操作包括:利用上述中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;利用上述中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;将上述中间商见证信息密文发送给各第一目标见 证者设备,其中,上述第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;响应于确定从各上述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用上述中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为上述中间商设备的用户标识,生成中间商授权证书,将上述中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将上述中间商授权证书中的授权内容信息更新为所确定的授权内容信息;利用上述中间商设备的可信执行环境中存储的授权证书密钥对上述中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
在本实施例中,用于发行证书的装置500的确定单元501和生成单元502的具体处理及其所带来的技术效果可分别参考图4对应实施例中步骤401和步骤402的相关说明,在此不再赘述。
在本实施例的一些可选的实现方式中,上述中间商设备的用户标识可以是上述中间商设备的用户标识集合中的用户标识;以及上述装置500还可以包括:添加单元403,被配置成响应于检测到包括第二用户标识类别标识的第二用户标识生成请求,分别将上述第二用户标识类别标识和上述中间商设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到上述中间商设备的用户标识集合中,其中,上述用户标识生成操作包括:获取用于指示上述目标可信执行环境的、包括厂商标识和产品标识的环境标识;随机生成随机数;用上述目标可信执行环境中存储的用户标识密钥对扩展用户标识进行加密,得到与上述目标用户标识类别标识和上述目标可信执行环境对应的用户标识,其中,上述扩展 用户标识包括所获取的环境标识、所生成的随机数和上述目标用户标识类别标识。
在本实施例的一些可选的实现方式中,见证者信息还可以包括见证者权重,见证通过条件可以包括见证者权重和大于等于预设权重和阈值;以及上述确定从各上述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,可以包括:将预设时间段内从各上述第一目标见证者设备接收到的见证通过信息确定为目标见证通过信息集合;将见证权重和置零;对于上述目标见证通过信息集合中的每个目标见证通过信息,执行以下见证者权重和更新操作:确定解密得到的见证信息明文中的见证者信息集合中与发送该目标见证通过信息的见证者设备对应的见证者信息;按照上述预设算法,根据所确定的见证者信息中的见证者用户标识,生成见证信息密钥;用所生成的见证信息密钥对该目标见证通过信息进行解密,得到见证信息关键信息;响应于确定所得到的见证信息关键信息与解密得到的见证信息明文中的上述预设关键信息相同,将上述见证权重和更新为上述见证权重和与所确定的见证者信息中的见证者权重之和;响应于确定上述见证者权重和大于等于上述预设权重和阈值,确定从各上述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件。
需要说明的是,本申请实施例提供的用于发行证书的装置中各单元的实现细节和技术效果可以参考本申请中其它实施例的说明,在此不再赘述。
下面参考图6,其示出了适于用来实现本申请实施例的电子设备的计算机系统600的结构示意图。图6示出的电子设备仅仅是一个示例,不应对本申请实施例的功能和使用范围带来任何限制。
如图6所示,计算机系统600包括中央处理单元(CPU,Central Processing Unit)601,其可以根据存储在只读存储器(ROM,Read Only Memory)602中的程序或者从存储部分608加载到随机访问存储器(RAM,Random Access Memory)603中的程序而执行各种适当的动 作和处理。在RAM 603中,还存储有系统600操作所需的各种程序和数据。CPU 601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O,Input/Output)接口605也连接至总线604。
以下部件连接至I/O接口605:包括键盘、鼠标等的输入部分606;包括诸如阴极射线管(CRT,Cathode Ray Tube)、液晶显示器(LCD,Liquid Crystal Display)等以及扬声器等的输出部分607;包括硬盘等的存储部分608;以及包括诸如LAN(局域网,Local Area Network)卡、调制解调器等的网络接口卡的通信部分609。通信部分609经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至I/O接口605。可拆卸介质611,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器610上,以便于从其上读出的计算机程序根据需要被安装入存储部分608。
特别地,根据本公开的实施例,上文参考流程图描述的过程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分609从网络上被下载和安装,和/或从可拆卸介质611被安装。在该计算机程序被中央处理单元(CPU)601执行时,执行本申请的方法中限定的上述功能。需要说明的是,本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基 带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++、Python,还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实 现,也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中,例如,可以描述为:一种处理器包括确定单元和生成单元。其中,这些单元的名称在某种情况下并不构成对该单元本身的限定,例如,确定单元还可以被描述为“确定授权内容信息的单元”。
作为另一方面,本申请还提供了一种计算机可读介质,该计算机可读介质可以是上述实施例中描述的装置中所包含的;也可以是单独存在,而未装配入该装置中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被该装置执行时,使得该装置:响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;在中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文,其中,中间商授权证书生成操作包括:利用中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;将中间商见证信息密文发送给各第一目标见证者设备,其中,第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;响应于确定从各第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为中间商设备的用户标识,生成中间商授权证书,将中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值,以及将中间商授权证书中的授权内容信息更新为所确定的授权内容信息;利用中间商设备的可信执行环境中存储的授权证书密钥对中间商授权证书进行加密,得 到与所收到的数字资产密文对应的中间商授权证书密文。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的发明范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离上述发明构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (30)

  1. 一种用于发行证书的发行者设备,包括:
    处理器;以及
    存储器,所述存储器存储有机器可读指令,所述机器可读指令能够由所述处理器运行以执行以下操作:
    响应于检测到包括目标数字资产、授权证书参数信息和第一见证信息参数信息的密文生成请求,在该发行者设备的可信执行环境中,执行密文生成操作,得到与所述目标数字资产对应的数字资产密文、授权证书密文和见证信息密文;以及
    将所得到的数字资产密文、授权证书密文和见证信息密文发送给所述授权证书参数信息中的中间商用户标识所指示的中间商设备。
  2. 根据权利要求1所述的发行者设备,
    其中,所述授权证书参数信息和所述第一见证信息参数信息均包括:证书类别、发行者用户标识、证书标识和中间商用户标识,所述授权证书参数信息还包括加密算法标识、加密密钥、解密算法标识和解密密钥;以及
    其中,所述第一见证信息参数信息还包括:见证通过条件、数字资产描述信息和见证者信息集合,见证者信息集合包括见证者用户标识。
  3. 根据权利要求1所述的发行者设备,其中,所述密文生成操作包括:
    生成授权证书,以及将所述授权证书的各项参数的值设置为所述授权证书参数信息中相应参数的值;
    利用该发行者设备的可信执行环境中存储的授权证书密钥对所述授权证书进行加密,得到与所述目标数字资产对应的授权证书密文;
    生成第一见证信息,以及将所述第一见证信息的各项参数的值设 置为所述第一见证信息参数信息中相应参数的值;
    利用该发行者设备的可信执行环境中存储的见证信息密钥对所述第一见证信息进行加密,得到与所述目标数字资产对应的见证信息密文;以及
    利用所述授权证书参数信息中的加密算法标识所指示的算法和加密密钥对所述目标数字资产进行加密,得到与所述目标数字资产对应的数字资产密文。
  4. 根据权利要求2所述的发行者设备,其中,所述授权证书参数信息和所述第一见证信息参数信息中的发行者用户标识是发行者设备的用户标识集合中的用户标识,并且所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于检测到包括第一用户标识类别标识的第一用户标识生成请求,分别将所述第一用户标识类别标识和所述发行者设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境;
    在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识;以及
    将所得到的用户标识添加到所述发行者设备的用户标识集合中。
  5. 根据权利要求4所述的发行者设备,其中,所述用户标识生成操作包括:
    获取用于指示所述目标可信执行环境的、包括厂商标识和产品标识的环境标识;
    随机生成随机数;
    用所述目标可信执行环境中存储的用户标识密钥对扩展用户标识进行加密,得到与所述目标用户标识类别标识和所述目标可信执行环境对应的用户标识,其中,所述扩展用户标识包括所获取的环境标识、所生成的随机数和所述目标用户标识类别标识。
  6. 根据权利要求2所述的发行者设备,其中,在将所述授权证书的各项参数的值设置为所述授权证书参数信息中相应参数的值之后,所述密文生成操作还包括:
    利用所述发行者设备的可信执行环境中存储的用户标识密钥分别对所述授权证书参数信息和所述第一见证信息参数信息中的发行者用户标识和中间商用户标识进行解密,得到发行者扩展用户标识和中间商扩展用户标识;
    将所述授权证书中的发行者用户标识和中间商用户标识分别更新为所述发行者扩展用户标识中的环境标识和所述中间商扩展用户标识中的环境标识。
  7. 根据权利要求2所述的发行者设备,其中,在将所述第一见证信息的各项参数的值设置为所述第一见证信息参数信息中相应参数的值之后,所述密文生成操作还包括:
    将所述第一见证信息中的发行者用户标识和中间商用户标识分别更新为所述发行者扩展用户标识中的环境标识和所述中间商扩展用户标识中的环境标识;将所述第一见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与所述见证者用户标识对应的见证者环境标识,其中,与所述见证者用户标识对应的见证者环境标识是利用所述发行者设备的可信执行环境中存储的用户标识密钥对所述见证者用户标识进行解密所得到的扩展用户标识中的环境标识。
  8. 根据权利要求2所述的发行者设备,其中,所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于检测到多方见证信息加密请求,在所述发行者设备的可信执行环境中,执行见证信息生成及信息加密操作,得到与所述待加密信息对应的信息密文和见证信息密文,
    其中,所述多方见证信息加密请求包括待加密信息和对应的第二见证信息参数信息,其中,所述第二见证信息参数信息包括证书类别、发行者用户标识、见证者信息集合、加密算法标识、加密密钥、解密 算法标识、解密密钥、见证通过条件和加密信息描述信息。
  9. 根据权利要求8所述的发行者设备,其中,所述见证信息生成及信息加密操作包括:
    利用所述发行者设备的可信执行环境中存储的用户标识密钥对所述第二见证信息参数信息中的发行者用户标识进行解密,得到发行者扩展用户标识;
    生成第二见证信息;
    将所述第二见证信息的各项参数的值设置为所述第二见证信息参数信息中相应参数的值;
    将所述第二见证信息中的发行者用户标识更新为解密得到的发行者扩展用户标识中的环境标识;
    将所述第二见证信息中的见证者信息集合中的每个见证者信息中的见证者用户标识更新为与所述见证者用户标识对应的见证者环境标识,其中,与所述见证者用户标识对应的见证者环境标识是利用所述发行者设备的可信执行环境中存储的用户标识密钥对所述见证者用户标识进行解密所得到的扩展用户标识中的环境标识;
    利用所述第二见证信息参数信息中的加密算法标识所指示的算法和加密密钥对所述待加密信息进行加密,得到与所述待加密信息对应的信息密文;以及
    用所述发行者设备的可信执行环境中存储的见证信息密钥对所述第二见证信息进行加密,得到与所述待加密信息对应的见证信息密文。
  10. 根据权利要求3所述的发行者设备,其中,授权证书参数信息和授权证书还包括证书类型标识。
  11. 根据权利要求10所述的发行者设备,其中,授权证书参数信息还包括证书失效时间,第一见证信息参数信息、第二见证信息参数信息、第一见证信息和第二见证信息还包括见证信息失效时间。
  12. 一种用于发行证书的中间商设备,包括:
    处理器;以及
    存储器,所述存储器存储有机器可读指令,所述机器可读指令能够由所述处理器运行以执行以下操作:
    响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;
    在所述中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文。
  13. 根据权利要求12所述的中间商设备,其中,所述中间商授权证书生成操作包括:
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;
    将所述中间商见证信息密文发送给各第一目标见证者设备,其中,所述第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;
    响应于确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用所述中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;
    响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为所述中间商设备的用户标识,生成中间商授权证书;
    将所述中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值;以及
    将所述中间商授权证书中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的授权证书密钥对所述中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
  14. 根据权利要求12所述的中间商设备,其中,所述中间商授权证书生成操作包括:
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;
    从所述中间商设备的可信执行环境中提取待见证关键信息;
    利用所述中间商在所述可信执行环境中预设的第二见证信息密钥对所述待见证关键信息进行加密,以得到中间商见证信息密文;
    将所述中间商见证信息密文发送给各第一目标见证者设备,其中,所述第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;
    响应于确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用所述第二见证信息密钥对所述中间商见证信息密文进行解密以得到明文;
    核实所述明文中的待见证关键信息的摘要并利用与所述见证者用户标识对应的公钥对所述待见证关键信息的摘要进行验证;
    响应于所述验证被通过,生成中间商授权证书;
    将所述中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值;以及
    将所述中间商授权证书中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的授权证书密钥对所述中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
  15. 根据权利要求13或14所述的中间商设备,其中,所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于检测到包括第二用户标识类别标识的第二用户标识生成请求,分别将所述第二用户标识类别标识和所述中间商设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行所述用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到所述中间商设备的用户标识集合中。
  16. 根据权利要求15所述的中间商设备,见证者信息还包括见证者权重,见证通过条件包括见证者权重和大于等于预设权重和阈值,并且所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    将预设时间段内从各所述第一目标见证者设备接收到的见证通过信息确定为目标见证通过信息集合;
    将见证权重和置零;
    对于所述目标见证通过信息集合中的每个目标见证通过信息,执行以下见证者权重和更新操作:确定解密得到的见证信息明文中的见证者信息集合中与发送所述目标见证通过信息的见证者设备对应的见证者信息;按照所述预设算法,根据所确定的见证者信息中的见证者用户标识,生成见证信息密钥;用所生成的见证信息密钥对所述目标见证通过信息进行解密,得到见证信息关键信息;响应于确定所得到的见证信息关键信息与解密得到的见证信息明文中的所述预设关键信息相同,将所述见证权重和更新为所述见证权重和与所确定的见证者信息中的见证者权重之和;
    响应于确定所述见证者权重和大于等于所述预设权重和阈值,确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件。
  17. 一种用于发行证书的见证者设备,包括:
    处理器;以及
    存储器,所述存储器存储有机器可读指令,所述机器可读指令能够由所述处理器运行以执行以下操作:
    响应于接收到中间商设备发送的见证信息密文,在所述见证者设备的可信执行环境中利用所述见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息;以及
    向发送所收到的见证信息密文的中间商设备发送所生成的见证通过信息。
  18. 根据权利要求17所述的见证者设备,其中,所述第一见证信息参数信息中的见证者信息集合中的见证者信息中的见证者用户标识是见证者设备的用户标识集合中的用户标识;并且所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于检测到包括第三用户标识类别标识的第三用户标识生成请求,分别将所述第三用户标识类别标识和所述见证者设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境;
    在所确定的目标可信执行环境中,执行所述用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识;以及
    将所得到的用户标识添加到所述见证者设备的用户标识集合中。
  19. 根据权利要求17所述的见证者设备,其中,所述机器可读指 令能够由所述处理器运行以进一步执行以下操作:
    在所述见证者设备的可信执行环境中执行以下见证通过信息生成操作,得到与所收到的见证信息密文对应的见证通过信息,所述见证通过信息生成操作包括:响应于对解密得到的见证信息明文进行完整性校验通过,按照预设算法,根据所述见证者设备的可信执行环境的环境标识生成见证信息密钥;用所生成的见证信息密钥对解密得到的见证信息明文中的预设关键信息进行加密,得到与所收到的见证信息密文对应的见证通过信息。
  20. 根据权利要求17所述的见证者设备,其中,所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于接收到使用者设备发送的见证信息密文,在所述见证者设备的可信执行环境中利用所述见证者设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    呈现解密得到的见证信息明文;
    响应于检测到用户针对所呈现的见证信息明文输入的见证同意操作,生成见证通过信息;以及
    将所生成的见证通过信息发送给发送所收到的见证信息密文的使用者设备。
  21. 一种证书的使用者设备,包括:
    处理器;以及
    存储器,所述存储器存储有机器可读指令,所述机器可读指令能够由所述处理器运行以执行以下操作:
    响应于检测到针对待解密数字资产密文的解密请求,确定与所述待解密数字资产密文对应的中间商授权证书密文;
    在所述使用者设备的可信执行环境中,执行数字资产解密操作得到与所述待解密数字资产密文对应的数字资产明文。
  22. 根据权利要求21所述的使用者设备,其中,所述数字资产解 密操作包括:
    利用所述使用者设备的可信执行环境中存储的授权证书密钥对所确定的中间商授权证书密文进行解密,得到中间商授权证书明文;
    响应于确定所述使用者设备的可信执行环境的环境标识属于解密得到的中间商授权证书明文中的授权内容信息中的授权用户标识集合,利用解密得到的授权证书明文中的解密算法标识所指示的算法和解密密钥对所述待解密数字资产密文进行解密,得到与所述待解密数字资产密文对应的数字资产明文。
  23. 根据权利要求21所述的使用者设备,其中,所述机器可读指令能够由所述处理器运行以进一步执行以下操作:
    响应于检测到多方见证信息解密请求,在所述使用者设备的可信执行环境中执行多方见证信息密文解密操作,得到与所述待解密信息密文对应的信息明文,其中,所述多方见证信息解密请求包括待解密信息密文和对应的见证信息密文。
  24. 根据权利要求23所述的使用者设备,其中,所述多方见证信息密文解密操作包括:
    利用所述使用者设备的可信执行环境中存储的见证信息密钥对所述多方见证信息解密请求中的见证信息密文进行解密得到见证信息明文;
    将所述多方见证信息解密请求中的见证信息密文发送给各个第二目标见证者设备,其中,所述第二目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;
    响应于确定从各所述第二见证者设备接收的见证通过信息满足解密得到的见证信息明文中的见证通过条件,利用解密得到的见证信息明文中的加密算法标识所指示的算法和加密密钥对所述待解密信息密文进行解密得到与所述待解密信息密文对应的信息明文。
  25. 一种用于发行证书的方法,应用于用于发行证书的系统中的中间商设备,所述用于发行证书的系统包括发行者设备、中间商设备和见证者设备,发行者设备、中间商设备和见证者设备均设置可信执行环境,所述方法包括:
    响应于接收到发行者设备发送的数字资产密文、授权证书密文和见证信息密文,确定针对所收到的数字资产密文的授权内容信息;
    在所述中间商设备的可信执行环境中执行中间商授权证书生成操作,得到与所收到的数字资产密文对应的中间商授权证书密文。
  26. 根据权利要求25所述的方法,其中,所述中间商授权证书生成操作包括:
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对更新后的解密得到的见证信息明文进行加密,得到中间商见证信息密文;
    将所述中间商见证信息密文发送给各第一目标见证者设备,其中,所述第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;
    响应于确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用所述中间商设备的可信执行环境中存储的授权证书密钥对所收到的授权证书密文进行解密,得到授权证书明文;
    响应于确定解密得到的授权证书明文中的发行者用户标识和证书标识分别与解密得到的见证信息明文中的相应参数相同以及解密得到的授权证书明文和解密得到的见证信息明文中的中间商用户标识均为所述中间商设备的用户标识,生成中间商授权证书,将所述中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的 值,以及将所述中间商授权证书中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的授权证书密钥对所述中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
  27. 根据权利要求25所述的方法,其中,
    利用所述中间商设备的可信执行环境中存储的见证信息密钥对所收到的见证信息密文进行解密得到见证信息明文;
    将解密得到的见证信息明文中的授权内容信息更新为所确定的授权内容信息;
    从所述中间商设备的可信执行环境中提取待见证关键信息;
    利用所述中间商在所述可信执行环境中预设的第二见证信息密钥对所述待见证关键信息进行加密,以得到中间商见证信息密文;
    将所述中间商见证信息密文发送给各第一目标见证者设备,其中,所述第一目标见证者设备为解密得到的见证信息明文中的见证者信息集合中见证者信息中的见证者用户标识所指示的见证者设备;
    响应于确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,用所述第二见证信息密钥对所述中间商见证信息密文进行解密以得到明文;
    核实所述明文中的待见证关键信息的摘要并利用与所述见证者用户标识对应的公钥对所述待见证关键信息的摘要进行验证;
    响应于所述验证被通过,生成中间商授权证书;
    将所述中间商授权证书中各项参数的值设置为解密得到的授权证书明文中相应参数的值;以及
    将所述中间商授权证书中的授权内容信息更新为所确定的授权内容信息;
    利用所述中间商设备的可信执行环境中存储的授权证书密钥对所述中间商授权证书进行加密,得到与所收到的数字资产密文对应的中间商授权证书密文。
  28. 根据权利要求25所述的方法,其中,所述中间商设备的用户标识是所述中间商设备的用户标识集合中的用户标识;以及
    所述方法还包括:
    响应于检测到包括第二用户标识类别标识的第二用户标识生成请求,分别将所述第二用户标识类别标识和所述中间商设备的可信执行环境确定为目标用户标识类别标识和目标可信执行环境,在所确定的目标可信执行环境中,执行用户标识生成操作,得到与所确定的目标用户标识类别标识和所确定的目标可信执行环境对应的用户标识,以及将所得到的用户标识添加到所述中间商设备的用户标识集合中,其中,所述用户标识生成操作包括:获取用于指示所述目标可信执行环境的、包括厂商标识和产品标识的环境标识;随机生成随机数;用所述目标可信执行环境中存储的用户标识密钥对扩展用户标识进行加密,得到与所述目标用户标识类别标识和所述目标可信执行环境对应的用户标识,其中,所述扩展用户标识包括所获取的环境标识、所生成的随机数和所述目标用户标识类别标识。
  29. 根据权利要求25所述的方法,其中,见证者信息还包括见证者权重,见证通过条件包括见证者权重和大于等于预设权重和阈值;以及
    所述确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件,包括:
    将预设时间段内从各所述第一目标见证者设备接收到的见证通过信息确定为目标见证通过信息集合;
    将见证权重和置零;
    对于所述目标见证通过信息集合中的每个目标见证通过信息,执行以下见证者权重和更新操作:确定解密得到的见证信息明文中的见证者信息集合中与发送该目标见证通过信息的见证者设备对应的见证者信息;按照所述预设算法,根据所确定的见证者信息中的见证者用户标识,生成见证信息密钥;用所生成的见证信息密钥对该目标见证 通过信息进行解密,得到见证信息关键信息;响应于确定所得到的见证信息关键信息与解密得到的见证信息明文中的所述预设关键信息相同,将所述见证权重和更新为所述见证权重和与所确定的见证者信息中的见证者权重之和;
    响应于确定所述见证者权重和大于等于所述预设权重和阈值,确定从各所述第一目标见证者设备接收到的见证通过信息满足解密得到的见证信息明文中的见证通过条件。
  30. 一种计算机可读存储介质,其上存储有计算机程序,其中,所述计算机程序被一个或多个处理器执行时实现如权利要求25-29中任一所述的方法。
PCT/CN2019/099944 2018-09-05 2019-08-09 用于发行证书的系统和方法 WO2020048290A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811030447.8A CN110879876B (zh) 2018-09-05 2018-09-05 用于发行证书的系统和方法
CN201811030447.8 2018-09-05

Publications (1)

Publication Number Publication Date
WO2020048290A1 true WO2020048290A1 (zh) 2020-03-12

Family

ID=69722994

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/099944 WO2020048290A1 (zh) 2018-09-05 2019-08-09 用于发行证书的系统和方法

Country Status (2)

Country Link
CN (1) CN110879876B (zh)
WO (1) WO2020048290A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112202772B (zh) * 2020-09-29 2021-06-29 北京海泰方圆科技股份有限公司 一种授权管理方法、装置、电子设备及介质
CN113886773A (zh) * 2021-08-23 2022-01-04 阿里巴巴(中国)有限公司 数据处理方法及装置
CN113891115B (zh) * 2021-09-29 2024-03-15 平安国际智慧城市科技股份有限公司 适用于浏览器的视频播放方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101246527A (zh) * 2007-02-15 2008-08-20 华为技术有限公司 提供、使用版权描述的方法及系统
CN102063590A (zh) * 2010-12-23 2011-05-18 李岩 用可复写存储设备发行数字影视的版权保护方法及装置
US20130152180A1 (en) * 2011-12-07 2013-06-13 Azuki Systems, Inc. Device using secure processing zone to establish trust for digital rights management
CN105184440A (zh) * 2015-07-17 2015-12-23 华数传媒网络有限公司 一种为在线点播和下载档期电影而制作发行电影并在线发行的系统
CN105893792A (zh) * 2016-03-28 2016-08-24 湖北三新文化传媒有限公司 数字版权管理方法、装置和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7383205B1 (en) * 1999-03-27 2008-06-03 Microsoft Corporation Structure of a digital content package
US20040088541A1 (en) * 2002-11-01 2004-05-06 Thomas Messerges Digital-rights management system
US20060282391A1 (en) * 2005-06-08 2006-12-14 General Instrument Corporation Method and apparatus for transferring protected content between digital rights management systems
US9055056B2 (en) * 2013-08-14 2015-06-09 Red Hat, Inc. Managing digital content entitlements
US10270591B2 (en) * 2015-06-30 2019-04-23 Activevideo Networks, Inc. Remotely managed trusted execution environment for digital-rights management in a distributed network with thin clients
JP2017175226A (ja) * 2016-03-18 2017-09-28 株式会社インテック 公開鍵証明書を発行するためのプログラム、方法およびシステム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101246527A (zh) * 2007-02-15 2008-08-20 华为技术有限公司 提供、使用版权描述的方法及系统
CN102063590A (zh) * 2010-12-23 2011-05-18 李岩 用可复写存储设备发行数字影视的版权保护方法及装置
US20130152180A1 (en) * 2011-12-07 2013-06-13 Azuki Systems, Inc. Device using secure processing zone to establish trust for digital rights management
CN105184440A (zh) * 2015-07-17 2015-12-23 华数传媒网络有限公司 一种为在线点播和下载档期电影而制作发行电影并在线发行的系统
CN105893792A (zh) * 2016-03-28 2016-08-24 湖北三新文化传媒有限公司 数字版权管理方法、装置和系统

Also Published As

Publication number Publication date
CN110879876B (zh) 2023-06-06
CN110879876A (zh) 2020-03-13

Similar Documents

Publication Publication Date Title
KR101661930B1 (ko) 블록체인을 기반으로 하는 공인인증서 발급시스템
JP4619665B2 (ja) ディジタル権利管理(drm)システムでのパブリッシャ使用ライセンスのオフラインでの発行
JP4524124B2 (ja) ディジタル権利管理(drm)サーバのdrmアーキテクチャへのエンロール/サブエンロール
EP1686504B1 (en) Flexible licensing architecture in content rights management systems
TWI454111B (zh) 用於確保通訊之鑑別及完備性的技術
US9355389B2 (en) Purchase transaction system with encrypted payment card data
US20110085667A1 (en) Various methods and apparatuses for securing an application container
WO2017024934A1 (zh) 实现电子签章的方法、装置及签章服务器
US8386799B2 (en) Methods and apparatuses for providing DRM interoperability
CN104471581B (zh) 利用媒体安全控制器保护媒体项目
CA3027741A1 (en) Blockchain systems and methods for user authentication
CN105745660B (zh) 用于在客户机设备上支持多个数字权利管理协议的技术
WO2020048290A1 (zh) 用于发行证书的系统和方法
EP1805638A1 (en) Contents encryption method, system and method for providing contents through network using the encryption method
MXPA04001292A (es) Conteniendo digital de publicacion dentro de un universo definido tal como una organizacion de acuerdo con un sistema de administracion digital de derechos (drm).
WO2021169767A1 (zh) 一种数据处理方法、装置、设备及介质
JP2007072608A (ja) 機器情報送信プログラム、サービス制御プログラム、機器情報送信装置、サービス制御装置および機器情報送信方法
JP2014513882A (ja) デジタルコンテンツのオブジェクトの購入又は情報要求を可能にするための方法及び装置
TWI622949B (zh) 具多重密鑰的kyc資料標記之爭議救濟系統及其方法
CN114528571A (zh) 资源访问和数据处理的方法、装置、电子设备及介质
US20050060544A1 (en) System and method for digital content management and controlling copyright protection
US8706635B2 (en) Use of licensed content without identification thereof
US10853898B1 (en) Method and apparatus for controlled messages
WO2023101778A1 (en) Implementing a cryptography agent and a secure hardware-based enclave to prevent computer hacking of client applications
CN110881015B (zh) 用于处理用户信息的系统和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19858536

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19858536

Country of ref document: EP

Kind code of ref document: A1