US11728978B2 - Method and apparatus for establishing trusted channel between user and trusted computing cluster - Google Patents

Method and apparatus for establishing trusted channel between user and trusted computing cluster Download PDF

Info

Publication number
US11728978B2
US11728978B2 US17/401,064 US202117401064A US11728978B2 US 11728978 B2 US11728978 B2 US 11728978B2 US 202117401064 A US202117401064 A US 202117401064A US 11728978 B2 US11728978 B2 US 11728978B2
Authority
US
United States
Prior art keywords
trusted computing
trusted
cluster
computing unit
key
Prior art date
Legal status (The legal status 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 status listed.)
Active, expires
Application number
US17/401,064
Other versions
US20220021520A1 (en
Inventor
Aihui Zhou
Qunshan HUANG
Chaofan YU
Weiwen CAI
Lei Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
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 Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to US17/401,064 priority Critical patent/US11728978B2/en
Publication of US20220021520A1 publication Critical patent/US20220021520A1/en
Application granted granted Critical
Publication of US11728978B2 publication Critical patent/US11728978B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • One or more implementations of the present specification relate to the secure computing field, and in particular, to a method and an apparatus for establishing a trusted channel with a trusted computing cluster.
  • trusted computing units are usually used for trusted computing and data processing.
  • the trusted computing unit can ensure that the code execution is secure, and those outside, including an operating system or a driver, cannot obtain secrets such as an internal runtime memory.
  • a same encrypted key is usually obtained through negotiation first, and this key is impossible for anyone to crack except for two communication parties.
  • the data transmission between the two parties is encrypted using the key obtained through negotiation.
  • the user equipment has established a trusted channel with the trusted computing unit, and can securely transmit confidential data on the trusted channel.
  • the user equipment communicates with a plurality of trusted computing units in a trusted computing platform. For this reason, the user equipment usually negotiates a key with these trusted computing units separately to establish a trusted channel with these trusted computing units separately.
  • the number of trusted computing units in the trusted platform increases to a large value, user access becomes complicated and cumbersome and costly.
  • One or more implementations of the present specification describe methods and apparatuses for establishing and re-establishing a trusted channel.
  • the implementations enable a user to establish a trusted channel with the entire trusted computing cluster simply and securely.
  • a method for establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a first trusted computing unit, wherein the first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster includes a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs, the method including: obtaining a first session key through negotiation with a user, and establishing a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; encrypting the first session key using the first cluster key to obtain a first encrypted key; and sending a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
  • the first session key is obtained through negotiation with the user in the following manner: sending a first public key of a first key pair of the first trusted computing unit to the user, the first key pair including the first public key and a first private key, and obtaining a user public key provided by the user; and generating the first session key based on the first public key, the first private key, and the user public key.
  • the method further includes: before sending the first notification to the cluster manager, sending an identifier request message for the first trusted channel to the cluster manager; obtaining a first session identifier allocated by the cluster manager to the first trusted channel; and including the first session identifier into the first notification.
  • a method for establishing a trusted channel between a user and a trusted computing cluster where the method is performed by a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the method including: receiving a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; determining a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and transferring the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
  • the method further includes: allocating a first session identifier to the first trusted channel in response to an identifier request message of the first trusted computing unit for the first trusted channel; and adding the first trusted computing unit to a first trusted computing unit list corresponding to the first session identifier.
  • the first notification further includes a first session identifier
  • the method further includes: transferring the first session identifier to the second trusted computing unit; and adding the second trusted computing unit to the first trusted computing unit list.
  • the cluster manager uses a maintained cluster information table to determine a first trusted computing cluster to which the first trusted computing unit belongs, and each trusted computing unit included in the first trusted computing cluster.
  • the cluster manager further transfers the first encrypted key to a third trusted computing unit in the first trusted computing cluster, so that the third trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the third trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
  • a method for re-establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a fourth trusted computing unit, the fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager, the method including: obtaining, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; encrypting the second session key using the second cluster key to obtain a second encrypted key; and sending a second notification to the cluster manager, where the second
  • a method for re-establishing a trusted channel between a user and a trusted computing cluster where the method is performed by a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the method including: receiving a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; obtaining, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging
  • the method further includes: adding the fifth trusted computing unit to the second trusted computing unit list.
  • an apparatus for establishing a trusted channel between a user and a trusted computing cluster where the apparatus is deployed in a first trusted computing unit, the first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster including a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs, the apparatus including: a key negotiation module, configured to obtain a first session key through negotiation with a user, and establish a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; a first encryption module, configured to encrypt the first session key using the first cluster key to obtain a first encrypted key; and a first notification sending module, configured to send a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
  • an apparatus for establishing a trusted channel between a user and a trusted computing cluster where the apparatus is deployed in a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the apparatus including: a first notification receiving module, configured to receive a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; a cluster determination module, configured to determine a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and a first transferring module, configured to transfer the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus
  • an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster where the apparatus is deployed in a fourth trusted computing unit, the fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster including a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager, the apparatus including: a key update module, configured to obtain, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; a second encryption module, configured to encrypt the second session key using the second cluster key to obtain a second encrypted key; and
  • an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster where the apparatus is deployed in a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the apparatus including: a second notification receiving module, configured to receive a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; a second list acquisition module, configured to obtain, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list
  • a computer-readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the methods according to the first aspect to the fourth aspect.
  • a computing device including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the methods according to the first aspect to the fourth aspect.
  • a user when a user wants to establish a trusted channel with a trusted computing cluster, the user only negotiates a session key with any one of the trusted computing units in the cluster to establish the trusted channel. Then, a cluster manager transmits an encrypted session key in the trusted computing cluster, so that other trusted computing units in the cluster obtain the session key and join the trusted channel. Thus, the user establishes a trusted channel with the entire trusted computing cluster. In such process, the user does not need to negotiate and communicate with each trusted computing unit separately in a sequence, and does not need to pay attention to cluster details of the trusted computing cluster either. For the user, the process of establishing a trusted channel becomes very simple and clear.
  • FIG. 1 is a schematic diagram of a relationship among a trusted computing unit, a session, and a session node according to some embodiments of the present specification;
  • FIG. 2 shows an entire life cycle of a trusted channel according to some embodiments of the present specification
  • FIG. 3 is a schematic diagram of establishing a trusted channel between a user and a trusted computing cluster according to some embodiments
  • FIG. 4 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments
  • FIG. 5 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments
  • FIG. 6 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments.
  • FIG. 7 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments.
  • FIG. 8 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments.
  • FIG. 9 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments.
  • a trusted channel can be established between a user and a trusted computing cluster securely, quickly, and conveniently.
  • the trusted computing cluster may be a pre-established cluster, which includes a plurality of trusted computing units.
  • the trusted computing unit may be a computing module or computing device with a certain isolation capability to ensure computing security, for example, a trusted computing container enclave, which is, for example, implemented using technologies such as Software Guard Extension (SGX) or Trust Zone.
  • SGX Software Guard Extension
  • Trust Zone Trust Zone
  • the plurality of trusted computing units can form a trusted computing cluster through mutual authentication of identities.
  • various trusted computing units maintain a same cluster key through key negotiation and other methods, which may form premise and basis for implementing some solutions in the present specification.
  • a trusted channel is established and maintained between the user and the entire trusted cluster in a unified manner, so as to avoid the cumbersome establishment of separate channels between the user and various trusted computing units.
  • a user establishes a trusted channel with the trusted computing cluster, it is assumed that the user has established a trusted relationship with the trusted computing cluster.
  • a session can be considered as a trusted channel relationship established between a user and a trusted computing cluster.
  • One trusted computing cluster can establish a plurality of trusted relationships with a plurality of users, which is assumed that the trusted computing cluster can correspond to a plurality of trusted channels, that is, a plurality of sessions.
  • the two parties in communication negotiate and exchange an encrypted key, which is referred to as a session key in the present specification.
  • the session key corresponds to the trusted channel and is used to encrypt and decrypt data transmitted through the trusted channel.
  • the concept of session node can be derived, which is used to represent an entity corresponding to a trusted computing unit in a trusted computing cluster in each session. Since a trusted computing cluster can be involved in a plurality of sessions, each trusted computing unit can correspond to a plurality of session nodes.
  • one session can correspond to one or more session nodes.
  • a criterion for determining whether a session node N has joined a certain session S is whether the session node N has a correct session key k corresponding to the session S. If the session node N has the correct session key k, it is considered that the session node N has joined the session S; if the session node N does not have the correct session key k, it is considered that the session node N has not yet joined the session S.
  • FIG. 1 is a schematic diagram of a relationship among a trusted computing unit, a session, and a session node according to some embodiments of the present specification.
  • a certain trusted computing cluster includes five trusted computing units, which are denoted as A, B, C, D, and E, respectively.
  • the trusted computing cluster has three sessions, which correspond to trusted channel 1 , trusted channel 2 , and trusted channel 3 established with users U 1 , U 2 , and U 3 , respectively.
  • trusted computing unit A includes session nodes A- 1 , A- 2 , and A- 3 corresponding to sessions 1 , 2 , and 3 , respectively;
  • trusted computing unit B includes session nodes B- 1 , B- 2 , and B- 3 corresponding to sessions 1 , 2 , and 3 , respectively.
  • the horizontal direction shows a relationship between each session and the session node.
  • session 1 includes session nodes A- 1 , B- 1 , C- 1 , D- 1 , and E- 1 corresponding to computing units A, B, C, D, and E, respectively.
  • whether these nodes join the corresponding sessions depends on whether these nodes have the correct session keys.
  • session node A- 3 does not join session 3 because session node A- 3 does not have the correct session key.
  • the foregoing describes the overall management architecture and concept for the trusted channel (or session) between the user and the trusted computing cluster.
  • the trusted channel between the user and the trusted computing cluster can be established or re-established securely and quickly.
  • FIG. 2 shows an entire life cycle of a trusted channel according to some embodiments of the present specification.
  • the user establishes a trusted channel with a certain trusted computing unit(s) (for example, trusted computing unit A) in the trusted computing cluster, that is, creates a session.
  • the session is expanded so that more corresponding session node(s) in the cluster (for example, the session nodes shown in FIG. 1 ) joins the session.
  • This process may involve transmitting the corresponding session key throughout the trusted computing cluster.
  • each trusted computing unit in the trusted computing cluster obtains the session key, so each trusted computing unit joins the session, and the user establishes a trusted channel with the entire trusted computing cluster.
  • the session key may need to be replaced.
  • the session is shrunk to remove a session node(s) that does not have the latest session key, and then is expanded again to transmit the latest session key to the entire cluster again.
  • the user re-establishes a trusted channel with the entire trusted computing cluster. This process can continue until the session is eliminated.
  • the following describes example processes of establishing a trusted channel through session expansion, and the process of re-establishing a trusted channel through session shrinking and session expansion.
  • FIG. 3 is a schematic diagram of establishing a trusted channel between a user and a trusted computing cluster according to some embodiments.
  • the example of FIG. 3 shows the process of establishing a trusted channel between user U and trusted computing cluster C 1 , where user U represents a computing device or terminal used by the user, and trusted computing cluster C 1 is a pre-established trusted computing cluster that includes a plurality of trusted computing units.
  • trusted computing cluster C 1 includes trusted computing units A, B, C, D, and E.
  • the trusted computing cluster may include any number of trusted computing units.
  • the established trusted computing cluster is managed using a cluster manager.
  • the cluster manager maintains a cluster information table, which records information about each trusted computing unit included in each cluster. After a plurality of trusted computing units successfully form a trusted computing cluster, they register with the cluster manager and notify the cluster manager of the establishment of the trusted computing cluster. As such, the cluster manager maintains and updates the cluster information table based on received registration information. Table 1 shows an example of the cluster information table.
  • Cluster information table Cluster identifier Computing unit C1 A, B, C, D, and E C2 G, H, I, M, N, and P C3 X, Y, and Z . . . . .
  • a trusted computing unit that first establishes a trusted channel with the user is referred to as a first trusted computing unit.
  • the first trusted computing unit is, for example, trusted computing unit A.
  • trusted computing unit A obtains a session key K 1 through negotiation with user U, and establishes a trusted channel with user U.
  • a trusted channel is referred to as the first trusted channel herein.
  • the session key K 1 aims at or corresponds to the first trusted channel, and is used to encrypt and decrypt data transmitted through the first trusted channel.
  • first”, second, etc. in the present specification are merely intended to distinguish similar concepts for simplicity of description, and do not impose any limitation.
  • trusted computing unit A and user U can perform key negotiation in a variety of ways to obtain the session key K 1 .
  • trusted computing unit A locally maintains an asymmetric public-private key pair (KA-Pub, KA-Pri), and user U also maintains its own asymmetric public-private key pair (KU-Pub, KU-Pri).
  • KA-Pub, KA-Pri asymmetric public-private key pair
  • KU-Pub, KU-Pri asymmetric public-private key pair
  • trusted computing unit A and user U exchange their own public keys with each other. That is, trusted computing unit A sends the public key KA-Pub in its local public-private key pair to user U, and receives the user's public key KU-Pub from user U.
  • trusted computing unit A exchanges its calculated K 1 with K 1 ′ calculated by user U, and completes the key negotiation in response to that K 1 is equal to K 1 ′.
  • trusted computing unit A and user U obtain the same session key K 1 , thereby achieving the key negotiation.
  • the two parties in communication exchange some device information, and generate a session key based on the device information of the two parties and an agreed algorithm; or it is agreed that one party generates a session key in some way, and then notifies the other party of the session key, and so on.
  • trusted computing unit A uses a cluster key of trusted computing cluster C 1 to which trusted computing unit A belongs, hereinafter referred to as a first cluster secret, to encrypt the first session key K 1 to obtain an encrypted key E 1 (K 1 ).
  • a cluster secret a cluster key of trusted computing cluster C 1 to which trusted computing unit A belongs
  • each trusted computing unit maintains a cluster key specific to the cluster.
  • Each of the trusted computing units A-E in the trusted computing cluster C 1 maintains the cluster key E 1 . Therefore, trusted computing unit A can calculate the encrypted key E 1 (K 1 ) based on the cluster key E 1 maintained by trusted computing unit A and by using an encryption algorithm.
  • trusted computing unit A sends a notification to the cluster manager, hereinafter referred to as a first notification, which includes the encrypted key E 1 (K 1 ) obtained through encryption using the cluster key E 1 .
  • the cluster manager After the cluster manager receives the notification from trusted computing unit A, in step S 37 , the cluster manager first determines information about the trusted computing cluster to which trusted computing unit A belongs. As described previously, when each trusted computing cluster is established, the trusted computing cluster registers with the cluster manager, so the cluster manager maintains information about each trusted computing cluster. For example, the cluster information is maintained using the cluster information table in Table 1.
  • step S 37 the cluster manager can determine, by querying the maintained cluster information table, the trusted computing cluster to which trusted computing unit A belongs, which is referred to as a first trusted computing cluster, and can further determine other trusted computing units included in the first trusted computing cluster.
  • the cluster manager can determine that trusted computing unit A belongs to trusted computing cluster C 1 , and trusted computing cluster further includes trusted computing units B, C, D, and E.
  • step S 38 the cluster manager transfers the encrypted key E 1 (K 1 ) in the first notification received in step S 35 to other trusted computing units in the first trusted computing cluster.
  • any one of the other trusted computing units is referred to as a second trusted computing unit.
  • the cluster manager transfers the encrypted key E 1 (K 1 ) to trusted computing unit B.
  • the first trusted computing cluster C 1 includes a plurality of trusted computing units each maintaining a same cluster key E 1 . Therefore, after receiving the encrypted key E 1 (K 1 ), the second trusted computing unit (for example, trusted computing unit B) can decrypt the encrypted key E 1 (K 1 ) using the cluster key E 1 maintained by the second trusted computing unit, to obtain the session key K 1 . With the correct session key K 1 , the second trusted computing unit can join the first trusted channel for communicating with user U.
  • the second trusted computing unit for example, trusted computing unit B
  • the second trusted computing unit can decrypt the encrypted key E 1 (K 1 ) using the cluster key E 1 maintained by the second trusted computing unit, to obtain the session key K 1 .
  • the second trusted computing unit can join the first trusted channel for communicating with user U.
  • the cluster manager can transfer the encrypted key E 1 (K 1 ) to various trusted computing units in the first trusted computing cluster (C 1 ) one by one.
  • the cluster manager further transfers the encrypted key E 1 (K 1 ) to a third trusted computing unit such as trusted computing unit C, so trusted computing unit C also joins the first trusted channel; similarly, trusted computing units D and E can also join the first trusted channel after receiving the E 1 (K 1 ) transferred by the cluster manager, and then decrypting the E 1 (K 1 ) to obtain K 1 .
  • the cluster manager can transfer the encrypted key to all trusted computing units in the first trusted computing cluster, so that each trusted computing unit joins the first trusted channel.
  • the cluster manager can alternatively transfer the encrypted key to some trusted computing units in the first trusted computing cluster according to a determined rule, predetermined or dynamically determined, or based on needs. For example, if a certain trusted computing unit fails, or processing performance of a trusted computing unit is severely degraded, or a processing capability of a trusted computing unit is insufficient, the cluster manager can avoid transferring the encrypted key to such a trusted computing unit.
  • the processing status of a trusted computing unit can be periodically reported by the trusted computing unit to the cluster manager, or can be uniformly evaluated and managed by the cluster manager.
  • the cluster manager transmits the encrypted key E 1 (K 1 ) obtained through encryption using the cluster key E 1 , and the cluster key E 1 is only held and maintained by the members of the corresponding trusted computing cluster. Even if the encrypted key E 1 (K 1 ) is obtained by another computing device during the transmission, the computing device still cannot decrypt the session key K 1 because it does not have the corresponding cluster key E 1 , and thus cannot join the session of the first trusted channel. As such, the security of the establishment of a trusted channel is ensured.
  • the cluster manager not only maintains the information about the established cluster, but also manages and maintains the status of each trusted channel in the form of a session, that is, maintains the status of each session.
  • the following describes the management of the session corresponding to the first trusted channel by the cluster manager in the process of establishing the first trusted channel.
  • trusted computing unit A after trusted computing unit A and user U successfully establish the first trusted channel, trusted computing unit A sends a message to the cluster manager to notify the cluster manager that a new trusted channel has been established, and requests to allocate a session identifier to the trusted channel.
  • the cluster manager allocates a session identifier to the first trusted channel, which is referred to as a first session identifier here.
  • the session identifier can be presented in the form of a session ID, for example, denoted as SID1.
  • the cluster manager after allocating the first session identifier, the cluster manager further establishes a corresponding trusted computing unit list for the newly created first session identifier, which is referred to as a first trusted computing unit list here, and is used to record the trusted computing unit that joins the corresponding session.
  • the request message for the first trusted channel comes from first trusted computing unit A, indicating that the first trusted channel was created by trusted computing unit A, and trusted computing unit A has already joined the session. Therefore, in an example, when creating the first trusted computing unit list, the cluster manager adds a unit identifier of first trusted computing unit A to the first trusted computing unit list.
  • trusted computing unit A includes the first session identifier SID1 obtained above in the first notification.
  • the first notification includes the encrypted key E 1 (K 1 ) for the first trusted channel and the session identifier SID1 corresponding to the first trusted channel, and the two are correspondingly associated with each other.
  • the cluster manager after receiving the first notification, and determining that first trusted computing unit A has obtained the session key for the first trusted channel, the cluster manager adds the unit identifier of first trusted computing unit A to the first trusted computing unit list corresponding to the first session identifier.
  • the first trusted computing unit list can be expressed as follows: SID1: ⁇ A>.
  • the cluster manager transfers the encrypted key E 1 (K 1 ) to the second trusted computing unit, for example, trusted computing unit B.
  • the cluster manager further transfers the first session identifier SID1 to the second trusted computing unit, so that the second trusted computing unit knows the session identifier of the trusted channel that the second trusted computing unit has joined.
  • the cluster manager further adds the unit identifier corresponding to the second trusted computing unit to the first trusted computing unit list corresponding to the first session identifier.
  • the first trusted computing unit list can be expressed as follows: SID1: ⁇ A,B>.
  • the cluster manager After subsequently transferring the encrypted key E 1 (K 1 ) to trusted computing units C, D, and E, the cluster manager similarly adds the unit identifiers of these trusted computing units to the first trusted computing unit list.
  • the list can be expressed as follows: SID1: ⁇ A,B,C,D,E>.
  • the status of the session corresponding to the first trusted channel is recorded and managed using the session identifier and the corresponding trusted computing unit list.
  • the cluster manager records and manages the status of each session corresponding to each trusted channel.
  • the cluster manager records the status of each session using a session status table
  • the session status table records a trusted computing unit list corresponding to each session identifier.
  • Table 2 shows the session status table in an example.
  • Session status table Session identifier Trusted computing unit list SID1 A, B, C, D, and E SID2 A, B, C, and D SID3 G, H, I, M, N, and P . . . . .
  • the session status can be continuously managed when the session is subsequently shrunk and expanded again.
  • the following describes the process of re-establishing a trusted channel between the user and the trusted computing cluster through the shrinking and expansion of the session.
  • the user can establish a trusted channel with any one of the trusted computing units in the trusted computing cluster, so as to establish a trusted channel with, e.g., the entire trusted computing cluster, and then perform data communication with the trusted computing cluster through the trusted channel.
  • a trusted channel with, e.g., the entire trusted computing cluster, and then perform data communication with the trusted computing cluster through the trusted channel.
  • the user replaces the session key with the trusted computing cluster. This process is referred to as the re-establishment of the trusted channel.
  • a certain trusted computing cluster here is referred to as a second trusted computing cluster
  • the established trusted channel is referred to as a second trusted channel.
  • the second trusted computing cluster here and the first trusted computing cluster may be the same cluster or different clusters.
  • the second trusted channel and the first trusted channel may be the same or different.
  • the user when the user wants to replace the session key for the second trusted channel, the user only updates the session key using any one of the trusted computing units in the second trusted computing cluster.
  • any one trusted computing unit is referred to as a fourth trusted computing unit.
  • FIG. 4 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments. The method is performed by the fourth trusted computing unit.
  • the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, and the second trusted computing cluster has established a second trusted channel with the user.
  • the second trusted computing cluster is cluster C 2 shown in Table 1, and the cluster includes trusted computing units G, H, I, M, N, and P.
  • the information about the second trusted computing cluster has been pre-registered in the cluster manager.
  • the user has established a trusted channel with trusted computing cluster C 2 in a method similar to FIG. 3 , and the trusted channel is referred to as the second trusted channel in these embodiments.
  • the cluster manager allocates a second session identifier, such as SID3, to the second trusted channel, and records a trusted computing unit list corresponding to the second session identifier using the session status table in Table 2, for example.
  • the cluster manager further returns the second session identifier to each trusted computing unit joining the session. Therefore, trusted computing units G, H, I, M, N, and P all obtain the second session identifier corresponding to the second trusted channel.
  • the fourth trusted computing unit H executes the following process.
  • step 41 the fourth trusted computing unit H obtains, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data.
  • the key update request is initiated by the user.
  • the user can send the key update request based on his/her own needs.
  • the key update request can alternatively be initiated by the cluster manager according to a determined management rule, predetermined or dynamically determined.
  • a management rule may stipulate that each trusted channel updates the session key every determined time interval.
  • the fourth trusted computing unit such as trusted computing unit H obtains, through negotiation with the user, a new session key for the trusted channel, which is referred to as a second session key here and is denoted as K 2 .
  • the processes for key negotiation of the second session key are similar as those in the process for establishing a trusted channel, and details are omitted here for simplicity. It can be understood that, the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data.
  • the fourth trusted computing unit uses the cluster key of the second computing cluster to which the fourth trusted computing unit belongs, that is, the second cluster key, to encrypt the second session key to obtain the second encrypted key.
  • trusted computing unit H since trusted computing unit H belongs to the second computing cluster C 2 , trusted computing unit H maintains the second cluster key E 2 specific to C 2 .
  • the second cluster key E 2 can be used to encrypt the second session key K 2 to obtain the second encrypted key E 2 (K 2 ).
  • fourth trusted computing unit H when pre-establishing or joining the second trusted channel, fourth trusted computing unit H obtains the second session identifier corresponding to the second trusted channel from the cluster manager, such as SID3. Therefore, in step 45 , the fourth trusted computing unit can send a second notification to the cluster manager, where the second notification includes the second encrypted key E 2 (K 2 ) and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
  • FIG. 5 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments. The method is performed by a cluster manager.
  • the cluster manager receives a second notification from a fourth trusted computing unit, where the second notification includes a second encrypted key and a second session identifier.
  • the second session identifier corresponds to a second trusted channel between the fourth trusted computing unit and the user, and the second encrypted key is obtained by encrypting the updated second session key using the second cluster key.
  • the cluster manager receives the second notification from trusted computing unit H, where the second notification includes the second encrypted key E 2 (K 2 ) and the second session identifier SID3.
  • step 53 the cluster manager obtains, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster.
  • the cluster manager is configured to manage each pre-established trusted computing cluster, for example, record the trusted computing cluster as the cluster information table shown in Table 1.
  • the cluster manager further maintains the status of each session established with each trusted computing cluster.
  • the cluster manager records and maintains the status of each session established with each trusted computing cluster using the session status table in Table 2.
  • the cluster manager can query and obtain a second trusted computing unit list corresponding to the second session identifier, where the second trusted computing unit list records the trusted computing unit that joins the second trusted channel.
  • the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit that also belongs to the second trusted computing cluster.
  • the cluster manager can determine, for example, by querying the session status table in Table 2, that the second trusted computing unit list corresponding to the second session identifier SID3 includes: SID3: ⁇ G,H,I,M,N,P>.
  • the second trusted computing unit list includes fourth trusted computing unit H and other trusted computing units G, I, M, N, and P that also belong to the second trusted computing cluster C 2 .
  • step 55 the cluster manager removes each of the at least one other trusted computing units from the second trusted computing unit list.
  • the cluster manager removes each of the at least one other trusted computing units from the second trusted computing unit list.
  • step 55 all units other than fourth trusted computing unit H are removed from the list. In such case, the second trusted computing unit list is updated to: SID3: ⁇ H>.
  • step 57 the cluster manager transfers the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, so that the fifth trusted computing unit decrypts the second encrypted key based on the second cluster key maintained by the fifth trusted computing unit to obtain the second session key, and thus rejoins the second trusted channel based on the second session key.
  • the fifth trusted computing unit is any one of the trusted computing units that previously joined the second trusted channel other than the fourth trusted computing unit. Therefore, the fifth trusted computing unit must belong to the same second trusted cluster as the fourth trusted computing unit, and therefore also maintains the second cluster key. As such, after receiving the second encrypted key, the fifth trusted computing unit can decrypt the second encrypted key using the second cluster key, to obtain the second session key, which is a new session key of the second trusted channel. Thus, the fifth trusted computing unit can rejoin the second trusted channel.
  • the cluster manager after the transferring the second encrypted key to the fifth trusted computing unit, the cluster manager adds the unit identifier of the fifth trusted computing unit to the second trusted computing unit list again to indicate that the fifth trusted computing unit rejoins the second session.
  • the cluster manager can transfer the second encrypted key to the trusted computing units previously joined the second trusted channel one by one, so that these trusted computing units rejoin the second trusted channel. Further, the cluster manager can add the unit identifiers of these trusted computing units to the second trusted computing unit list.
  • step 55 all units other than fourth trusted computing unit H are removed from the second trusted computing unit list. That is, the removed units include G, I, M, N, and P.
  • step 57 the second encrypted key E 2 (K 2 ) is transferred to the fifth trusted computing unit in the removed units, for example, trusted computing unit G.
  • trusted computing unit G can decrypt E 2 (K 2 ) using the second cluster key E 2 maintained by trusted computing unit G to obtain the updated session key K 2 for the second trusted channel, thereby rejoining the second trusted channel.
  • the cluster manager adds the unit identifier of trusted computing unit G back to the second trusted computing unit list.
  • the second trusted computing unit list is updated to: SID3: ⁇ G,H>.
  • the cluster manager further transfers the second encrypted key E 2 (K 2 ) to trusted computing units I, M, N, and P, so that these trusted computing units rejoin the second trusted channel.
  • the second trusted computing unit list is updated again to: SID3: ⁇ G,H,I,M,N,P>.
  • the second session corresponding to the second channel is shrunk to the minimum and includes only the fourth trusted computing unit.
  • the second session is expanded again.
  • the nodes included in the session SID3 are shrunk to ⁇ H>, and then are expanded to ⁇ G,H,I,M,N,P> again.
  • FIG. 6 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments.
  • the establishment apparatus is deployed in the trusted computing unit.
  • the trusted computing unit is referred to as the first trusted computing unit.
  • the first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster includes a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs. As shown in FIG.
  • the establishment apparatus 600 includes: a key negotiation module 61 , configured to obtain a first session key through negotiation with a user, and establish a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; a first encryption module 63 , configured to encrypt the first session key using the first cluster key to obtain a first encrypted key; and a first notification sending module 65 , configured to send a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
  • a key negotiation module 61 configured to obtain a first session key through negotiation with a user, and establish a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel
  • a first encryption module 63 configured to encrypt the first session key using the first cluster key to obtain a first encrypted key
  • a first notification sending module 65 configured to send a first notification to the cluster manager, where
  • the key negotiation module 61 is configured to: send a first public key of a first key pair of the first trusted computing unit to the user, the first key pair including the first public key and a first private key, and obtain a user public key provided by the user; and generate the first session key based on the first public key, the first private key, and the user public key.
  • the apparatus 600 further includes an identifier acquisition module (not shown), configured to perform the following steps before the first notification sending module 65 sends a first notification to the cluster manager: sending an identifier request message for the first trusted channel to the cluster manager; obtaining a first session identifier allocated by the cluster manager to the first trusted channel; and including the first session identifier into the first notification.
  • an identifier acquisition module (not shown), configured to perform the following steps before the first notification sending module 65 sends a first notification to the cluster manager: sending an identifier request message for the first trusted channel to the cluster manager; obtaining a first session identifier allocated by the cluster manager to the first trusted channel; and including the first session identifier into the first notification.
  • FIG. 7 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments.
  • the establishment apparatus is deployed in the cluster manager.
  • the cluster manager is configured to manage at least one pre-established trusted computing cluster. As shown in FIG.
  • the establishment apparatus 700 includes: a first notification receiving module 71 , configured to receive a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; a cluster determination module 73 , configured to determine a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and a first transferring module 75 , configured to transfer the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
  • a first notification receiving module 71 configured to receive a first notification from a first trusted computing unit, where the first notification includes a first
  • the establishment apparatus 700 further includes (not shown): a session identifier allocation module, configured to allocate a first session identifier to the first trusted channel in response to an identifier request message of the first trusted computing unit for the first trusted channel; and a first list adding module, configured to add the first trusted computing unit to a first trusted computing unit list corresponding to the first session identifier.
  • a session identifier allocation module configured to allocate a first session identifier to the first trusted channel in response to an identifier request message of the first trusted computing unit for the first trusted channel
  • a first list adding module configured to add the first trusted computing unit to a first trusted computing unit list corresponding to the first session identifier.
  • the first notification further includes the first session identifier
  • the first transferring module 75 is further configured to transfer the first session identifier to the second trusted computing unit
  • the first list adding module is further configured to add the second trusted computing unit to the first trusted computing unit list.
  • the cluster determination module 73 is configured to use a maintained cluster information table to determine a first trusted computing cluster to which the first trusted computing unit belongs, and each trusted computing unit included in the first trusted computing cluster.
  • the first transferring module 75 is further configured to: transfer the first encrypted key to a third trusted computing unit in the first trusted computing cluster, so that the third trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the third trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
  • FIG. 8 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments.
  • the re-establishment apparatus is deployed in the trusted computing unit.
  • the trusted computing unit is referred to as the fourth trusted computing unit.
  • the fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager.
  • the re-establishment apparatus 800 includes: a key update module 81 , configured to obtain, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; a second encryption module 83 , configured to encrypt the second session key using the second cluster key to obtain a second encrypted key; and a second notification sending module 85 , configured to send a second notification to the cluster manager, where the second notification includes the second encrypted key and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
  • a key update module 81 configured to obtain, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data
  • a second encryption module 83 configured to encrypt the
  • FIG. 9 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments.
  • the re-establishment apparatus is deployed in the cluster manager.
  • the cluster manager is configured to manage at least one pre-established trusted computing cluster. As shown in FIG.
  • the re-establishment apparatus 900 includes: a second notification receiving module 91 , configured to receive a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; a second list acquisition module 93 , configured to obtain, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster; a removing module 95 , configured to remove each of the at least one other trusted trusted
  • the re-establishment apparatus 900 further includes a second list adding module (not shown), configured to: after the second transferring module 97 transfers the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, add the fifth trusted computing unit to the second trusted computing unit list.
  • a second list adding module (not shown), configured to: after the second transferring module 97 transfers the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, add the fifth trusted computing unit to the second trusted computing unit list.
  • a computer-readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the methods described with reference to FIG. 3 to FIG. 5 .
  • a computing device including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the methods described with reference to FIG. 3 to FIG. 5 .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Some embodiments of the present specification provide a method and an apparatus for establishing a trusted channel between a user and a trusted computing cluster. According to the method, when a user wants to establish a trusted channel with a trusted computing cluster, the user only negotiates a session key with any first trusted computing unit in the cluster to establish the trusted channel. Then, the first trusted computing unit encrypts the session key using a cluster key common to the trusted computing cluster to which the first trusted computing unit belongs, and sends the encrypted session key to a cluster manager. The cluster manager transmits the encrypted session key in the trusted computing cluster, so that other trusted computing units in the cluster obtain the session key and join the trusted channel. Thus, the user establishes a trusted channel with the entire trusted computing cluster.

Description

BACKGROUND Technical Field
One or more implementations of the present specification relate to the secure computing field, and in particular, to a method and an apparatus for establishing a trusted channel with a trusted computing cluster.
Description of the Related Art
For the security of computing and data transmission, trusted computing units are usually used for trusted computing and data processing. The trusted computing unit can ensure that the code execution is secure, and those outside, including an operating system or a driver, cannot obtain secrets such as an internal runtime memory.
Before user equipment exchanges to-be-processed data with a trusted computing unit, a same encrypted key is usually obtained through negotiation first, and this key is impossible for anyone to crack except for two communication parties. The data transmission between the two parties is encrypted using the key obtained through negotiation. Thus, it is considered that the user equipment has established a trusted channel with the trusted computing unit, and can securely transmit confidential data on the trusted channel.
In many cases, the user equipment communicates with a plurality of trusted computing units in a trusted computing platform. For this reason, the user equipment usually negotiates a key with these trusted computing units separately to establish a trusted channel with these trusted computing units separately. When the number of trusted computing units in the trusted platform increases to a large value, user access becomes complicated and cumbersome and costly.
Therefore, an improved solution is needed.
BRIEF SUMMARY
One or more implementations of the present specification describe methods and apparatuses for establishing and re-establishing a trusted channel. The implementations enable a user to establish a trusted channel with the entire trusted computing cluster simply and securely.
According to a first aspect, a method for establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a first trusted computing unit, wherein the first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster includes a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs, the method including: obtaining a first session key through negotiation with a user, and establishing a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; encrypting the first session key using the first cluster key to obtain a first encrypted key; and sending a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
According to some embodiments, the first session key is obtained through negotiation with the user in the following manner: sending a first public key of a first key pair of the first trusted computing unit to the user, the first key pair including the first public key and a first private key, and obtaining a user public key provided by the user; and generating the first session key based on the first public key, the first private key, and the user public key.
In some embodiments, the method further includes: before sending the first notification to the cluster manager, sending an identifier request message for the first trusted channel to the cluster manager; obtaining a first session identifier allocated by the cluster manager to the first trusted channel; and including the first session identifier into the first notification.
According to a second aspect, a method for establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the method including: receiving a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; determining a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and transferring the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
According to some implementations, the method further includes: allocating a first session identifier to the first trusted channel in response to an identifier request message of the first trusted computing unit for the first trusted channel; and adding the first trusted computing unit to a first trusted computing unit list corresponding to the first session identifier.
In some embodiments, the first notification further includes a first session identifier, and the method further includes: transferring the first session identifier to the second trusted computing unit; and adding the second trusted computing unit to the first trusted computing unit list.
According to some implementations, the cluster manager uses a maintained cluster information table to determine a first trusted computing cluster to which the first trusted computing unit belongs, and each trusted computing unit included in the first trusted computing cluster.
In some embodiments, the cluster manager further transfers the first encrypted key to a third trusted computing unit in the first trusted computing cluster, so that the third trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the third trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
According to a third aspect, a method for re-establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a fourth trusted computing unit, the fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager, the method including: obtaining, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; encrypting the second session key using the second cluster key to obtain a second encrypted key; and sending a second notification to the cluster manager, where the second notification includes the second encrypted key and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
According to a fourth aspect, a method for re-establishing a trusted channel between a user and a trusted computing cluster is provided, where the method is performed by a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the method including: receiving a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; obtaining, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster; removing each of the at least one other trusted computing units from the second trusted computing unit list; and transferring the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, so that the fifth trusted computing unit decrypts the second encrypted key based on the second cluster key maintained by the fifth trusted computing unit to obtain the second session key, and thus rejoins the second trusted channel based on the second session key.
In some embodiments, the method further includes: adding the fifth trusted computing unit to the second trusted computing unit list.
According to a fifth aspect, an apparatus for establishing a trusted channel between a user and a trusted computing cluster is provided, where the apparatus is deployed in a first trusted computing unit, the first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster including a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs, the apparatus including: a key negotiation module, configured to obtain a first session key through negotiation with a user, and establish a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; a first encryption module, configured to encrypt the first session key using the first cluster key to obtain a first encrypted key; and a first notification sending module, configured to send a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
According to a sixth aspect, an apparatus for establishing a trusted channel between a user and a trusted computing cluster is provided, where the apparatus is deployed in a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the apparatus including: a first notification receiving module, configured to receive a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; a cluster determination module, configured to determine a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and a first transferring module, configured to transfer the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
According to a seventh aspect, an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster is provided, where the apparatus is deployed in a fourth trusted computing unit, the fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster including a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager, the apparatus including: a key update module, configured to obtain, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; a second encryption module, configured to encrypt the second session key using the second cluster key to obtain a second encrypted key; and a second notification sending module, configured to send a second notification to the cluster manager, where the second notification includes the second encrypted key and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
According to an eighth aspect, an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster is provided, where the apparatus is deployed in a cluster manager, and the cluster manager is configured to manage at least one pre-established trusted computing cluster, the apparatus including: a second notification receiving module, configured to receive a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; a second list acquisition module, configured to obtain, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster; a removing module, configured to remove each of the at least one other trusted computing units from the second trusted computing unit list; and a second transferring module, configured to transfer the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, so that the fifth trusted computing unit decrypts the second encrypted key based on the second cluster key maintained by the fifth trusted computing unit to obtain the second session key, and thus rejoins the second trusted channel based on the second session key.
According to a ninth aspect, a computer-readable storage medium is provided, where the computer-readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the methods according to the first aspect to the fourth aspect.
According to a tenth aspect, a computing device is provided, including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the methods according to the first aspect to the fourth aspect.
According to the methods and apparatuses provided in the embodiments of the present specification, when a user wants to establish a trusted channel with a trusted computing cluster, the user only negotiates a session key with any one of the trusted computing units in the cluster to establish the trusted channel. Then, a cluster manager transmits an encrypted session key in the trusted computing cluster, so that other trusted computing units in the cluster obtain the session key and join the trusted channel. Thus, the user establishes a trusted channel with the entire trusted computing cluster. In such process, the user does not need to negotiate and communicate with each trusted computing unit separately in a sequence, and does not need to pay attention to cluster details of the trusted computing cluster either. For the user, the process of establishing a trusted channel becomes very simple and clear.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
To describe the technical solutions in the embodiments of this application more clearly, the following briefly describes the accompanying drawings for describing the embodiments. Clearly, the accompanying drawings in the following description show merely some embodiments of this application, and a person of ordinary skill in the art may still derive other drawings from these accompanying drawings without creative efforts.
FIG. 1 is a schematic diagram of a relationship among a trusted computing unit, a session, and a session node according to some embodiments of the present specification;
FIG. 2 shows an entire life cycle of a trusted channel according to some embodiments of the present specification;
FIG. 3 is a schematic diagram of establishing a trusted channel between a user and a trusted computing cluster according to some embodiments;
FIG. 4 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments;
FIG. 5 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments;
FIG. 6 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments;
FIG. 7 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments;
FIG. 8 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments; and
FIG. 9 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments.
 DETAILED DESCRIPTION
The solutions provided in the present specification are described herein with reference to the accompanying drawings.
According to the solutions in some embodiments of the present specification, a trusted channel can be established between a user and a trusted computing cluster securely, quickly, and conveniently. The trusted computing cluster may be a pre-established cluster, which includes a plurality of trusted computing units. The trusted computing unit may be a computing module or computing device with a certain isolation capability to ensure computing security, for example, a trusted computing container enclave, which is, for example, implemented using technologies such as Software Guard Extension (SGX) or Trust Zone.
The plurality of trusted computing units can form a trusted computing cluster through mutual authentication of identities. In the process of establishing a trusted computing cluster, various trusted computing units maintain a same cluster key through key negotiation and other methods, which may form premise and basis for implementing some solutions in the present specification.
According to some embodiments in the present specification, a trusted channel is established and maintained between the user and the entire trusted cluster in a unified manner, so as to avoid the cumbersome establishment of separate channels between the user and various trusted computing units.
If a user establishes a trusted channel with the trusted computing cluster, it is assumed that the user has established a trusted relationship with the trusted computing cluster. For clarity of description, the concept of “session” is introduced to express such trusted relationship. In other words, in the present specification, a session can be considered as a trusted channel relationship established between a user and a trusted computing cluster.
One trusted computing cluster can establish a plurality of trusted relationships with a plurality of users, which is assumed that the trusted computing cluster can correspond to a plurality of trusted channels, that is, a plurality of sessions.
As described previously, to perform secure data transmission between the user and the trusted computing cluster, the two parties in communication negotiate and exchange an encrypted key, which is referred to as a session key in the present specification. The session key corresponds to the trusted channel and is used to encrypt and decrypt data transmitted through the trusted channel.
On the basis of the concept of session, in combination with the session key, the concept of session node can be derived, which is used to represent an entity corresponding to a trusted computing unit in a trusted computing cluster in each session. Since a trusted computing cluster can be involved in a plurality of sessions, each trusted computing unit can correspond to a plurality of session nodes.
From the perspective of sessions, one session can correspond to one or more session nodes. A criterion for determining whether a session node N has joined a certain session S is whether the session node N has a correct session key k corresponding to the session S. If the session node N has the correct session key k, it is considered that the session node N has joined the session S; if the session node N does not have the correct session key k, it is considered that the session node N has not yet joined the session S.
FIG. 1 is a schematic diagram of a relationship among a trusted computing unit, a session, and a session node according to some embodiments of the present specification. In FIG. 1 , it is assumed that a certain trusted computing cluster includes five trusted computing units, which are denoted as A, B, C, D, and E, respectively. In addition, the trusted computing cluster has three sessions, which correspond to trusted channel 1, trusted channel 2, and trusted channel 3 established with users U1, U2, and U3, respectively.
In FIG. 1 , the vertical direction shows a relationship between each trusted computing unit and the session nodes. For example, trusted computing unit A includes session nodes A-1, A-2, and A-3 corresponding to sessions 1, 2, and 3, respectively; trusted computing unit B includes session nodes B-1, B-2, and B-3 corresponding to sessions 1, 2, and 3, respectively.
In FIG. 1 , the horizontal direction shows a relationship between each session and the session node. For example, session 1 includes session nodes A-1, B-1, C-1, D-1, and E-1 corresponding to computing units A, B, C, D, and E, respectively. However, whether these nodes join the corresponding sessions depends on whether these nodes have the correct session keys. For example, in FIG. 1 , session node A-3 does not join session 3 because session node A-3 does not have the correct session key.
The foregoing describes the overall management architecture and concept for the trusted channel (or session) between the user and the trusted computing cluster. On the basis of such a management architecture, the trusted channel between the user and the trusted computing cluster can be established or re-established securely and quickly.
FIG. 2 shows an entire life cycle of a trusted channel according to some embodiments of the present specification. As shown in FIG. 2 , first, the user establishes a trusted channel with a certain trusted computing unit(s) (for example, trusted computing unit A) in the trusted computing cluster, that is, creates a session. Then, the session is expanded so that more corresponding session node(s) in the cluster (for example, the session nodes shown in FIG. 1 ) joins the session. This process may involve transmitting the corresponding session key throughout the trusted computing cluster. As such, each trusted computing unit in the trusted computing cluster obtains the session key, so each trusted computing unit joins the session, and the user establishes a trusted channel with the entire trusted computing cluster.
After the user uses the trusted channel to communicate with the trusted computing cluster for a period of time, under certain circumstances, the session key may need to be replaced. In such case, the session is shrunk to remove a session node(s) that does not have the latest session key, and then is expanded again to transmit the latest session key to the entire cluster again. Thus, the user re-establishes a trusted channel with the entire trusted computing cluster. This process can continue until the session is eliminated.
The following describes example processes of establishing a trusted channel through session expansion, and the process of re-establishing a trusted channel through session shrinking and session expansion.
FIG. 3 is a schematic diagram of establishing a trusted channel between a user and a trusted computing cluster according to some embodiments. For example, the example of FIG. 3 shows the process of establishing a trusted channel between user U and trusted computing cluster C1, where user U represents a computing device or terminal used by the user, and trusted computing cluster C1 is a pre-established trusted computing cluster that includes a plurality of trusted computing units. In the example of FIG. 3 , the example of FIG. 1 is used, and it is assumed that trusted computing cluster C1 includes trusted computing units A, B, C, D, and E. However, it can be understood that in other examples, the trusted computing cluster may include any number of trusted computing units.
In some embodiments, the established trusted computing cluster is managed using a cluster manager. In some embodiments, the cluster manager maintains a cluster information table, which records information about each trusted computing unit included in each cluster. After a plurality of trusted computing units successfully form a trusted computing cluster, they register with the cluster manager and notify the cluster manager of the establishment of the trusted computing cluster. As such, the cluster manager maintains and updates the cluster information table based on received registration information. Table 1 shows an example of the cluster information table.
TABLE 1
Cluster information table
Cluster identifier Computing unit
C1 A, B, C, D, and E
C2 G, H, I, M, N, and P
C3 X, Y, and Z
. . . . . .
It is worthwhile to note that, in the process of constructing a trusted computing cluster, various trusted computing units mutually verify respective identities, perform security key negotiation, and ultimately maintain a same cluster key. This may be a basis for some implementations of this solution. Therefore, in the following description, when an established trusted computing cluster is referred to, it is assumed that each trusted computing unit in the trusted computing cluster maintains a cluster key specific to the cluster.
When user U wants to establish a trusted channel with trusted computing cluster C1, according to some embodiments of the present specification, user U can first establish a trusted channel with any one of the trusted computing units in cluster C1. For simplicity of description, a trusted computing unit that first establishes a trusted channel with the user is referred to as a first trusted computing unit. In an example, the first trusted computing unit is, for example, trusted computing unit A.
In step S31 of FIG. 3 , trusted computing unit A obtains a session key K1 through negotiation with user U, and establishes a trusted channel with user U. For simplicity of description, such trusted channel is referred to as the first trusted channel herein. It can be understood that the session key K1 aims at or corresponds to the first trusted channel, and is used to encrypt and decrypt data transmitted through the first trusted channel. It should be understood that the descriptions of “first”, “second”, etc., in the present specification are merely intended to distinguish similar concepts for simplicity of description, and do not impose any limitation.
For example, trusted computing unit A and user U can perform key negotiation in a variety of ways to obtain the session key K1.
In an example, trusted computing unit A locally maintains an asymmetric public-private key pair (KA-Pub, KA-Pri), and user U also maintains its own asymmetric public-private key pair (KU-Pub, KU-Pri). To negotiate a same session key, trusted computing unit A and user U exchange their own public keys with each other. That is, trusted computing unit A sends the public key KA-Pub in its local public-private key pair to user U, and receives the user's public key KU-Pub from user U.
Then, trusted computing unit A can calculate the session key K1 based on the local public-private key pair (KA-Pub, KA-Pri) and the received public key KU-Pub of user U, and by using an encryption algorithm SE, that is, K1=SE(KA-Pub, KA-Pri, KU-Pub).
According to some implementations, user U calculates a session key K1′ based on the public-private key pair (KU-Pub, KU-Pri) of user U and received public key KA-Pub of trusted computing unit A, and by using the encryption algorithm, that is, K1′=SE(KU-Pub, KU-Pri, KA-Pub).
The encryption algorithm SE can be designed such that SE(KA-Pub, KA-Pri, KU-Pub)=SE(KU-Pub, KU-Pri, KA-Pub). Thus, trusted computing unit A exchanges its calculated K1 with K1′ calculated by user U, and completes the key negotiation in response to that K1 is equal to K1′.
As such, trusted computing unit A and user U obtain the same session key K1, thereby achieving the key negotiation.
In other embodiments, other key negotiation methods that are known in the art or will be adopted in the future can be used. For example, the two parties in communication exchange some device information, and generate a session key based on the device information of the two parties and an agreed algorithm; or it is agreed that one party generates a session key in some way, and then notifies the other party of the session key, and so on.
After trusted computing unit A negotiates with user U to obtain the first session key K1, in step S33, trusted computing unit A uses a cluster key of trusted computing cluster C1 to which trusted computing unit A belongs, hereinafter referred to as a first cluster secret, to encrypt the first session key K1 to obtain an encrypted key E1(K1). As described previously, in a trusted computing cluster that has been constructed, each trusted computing unit maintains a cluster key specific to the cluster. Each of the trusted computing units A-E in the trusted computing cluster C1 maintains the cluster key E1. Therefore, trusted computing unit A can calculate the encrypted key E1(K1) based on the cluster key E1 maintained by trusted computing unit A and by using an encryption algorithm.
After that, in step S35, trusted computing unit A sends a notification to the cluster manager, hereinafter referred to as a first notification, which includes the encrypted key E1(K1) obtained through encryption using the cluster key E1.
After the cluster manager receives the notification from trusted computing unit A, in step S37, the cluster manager first determines information about the trusted computing cluster to which trusted computing unit A belongs. As described previously, when each trusted computing cluster is established, the trusted computing cluster registers with the cluster manager, so the cluster manager maintains information about each trusted computing cluster. For example, the cluster information is maintained using the cluster information table in Table 1.
In step S37, the cluster manager can determine, by querying the maintained cluster information table, the trusted computing cluster to which trusted computing unit A belongs, which is referred to as a first trusted computing cluster, and can further determine other trusted computing units included in the first trusted computing cluster.
For example, by querying the cluster information table in Table 1, the cluster manager can determine that trusted computing unit A belongs to trusted computing cluster C1, and trusted computing cluster further includes trusted computing units B, C, D, and E.
Thus, in step S38, the cluster manager transfers the encrypted key E1(K1) in the first notification received in step S35 to other trusted computing units in the first trusted computing cluster. In such case, any one of the other trusted computing units is referred to as a second trusted computing unit. For example, the cluster manager transfers the encrypted key E1(K1) to trusted computing unit B.
As described previously, the first trusted computing cluster C1 includes a plurality of trusted computing units each maintaining a same cluster key E1. Therefore, after receiving the encrypted key E1(K1), the second trusted computing unit (for example, trusted computing unit B) can decrypt the encrypted key E1(K1) using the cluster key E1 maintained by the second trusted computing unit, to obtain the session key K1. With the correct session key K1, the second trusted computing unit can join the first trusted channel for communicating with user U.
It can be understood that after step S38, or in parallel with step S38, the cluster manager can transfer the encrypted key E1(K1) to various trusted computing units in the first trusted computing cluster (C1) one by one. For example, in step S39, the cluster manager further transfers the encrypted key E1(K1) to a third trusted computing unit such as trusted computing unit C, so trusted computing unit C also joins the first trusted channel; similarly, trusted computing units D and E can also join the first trusted channel after receiving the E1(K1) transferred by the cluster manager, and then decrypting the E1(K1) to obtain K1.
In some embodiments, the cluster manager can transfer the encrypted key to all trusted computing units in the first trusted computing cluster, so that each trusted computing unit joins the first trusted channel. In other embodiments, the cluster manager can alternatively transfer the encrypted key to some trusted computing units in the first trusted computing cluster according to a determined rule, predetermined or dynamically determined, or based on needs. For example, if a certain trusted computing unit fails, or processing performance of a trusted computing unit is severely degraded, or a processing capability of a trusted computing unit is insufficient, the cluster manager can avoid transferring the encrypted key to such a trusted computing unit. The processing status of a trusted computing unit can be periodically reported by the trusted computing unit to the cluster manager, or can be uniformly evaluated and managed by the cluster manager.
It can be determined from the process that, when user U wants to establish a trusted channel with trusted computing cluster C1, user U only negotiates with any one of the trusted computing units (for example, trusted computing unit A) in cluster C1 to obtain the session key K1, so as to establish the first trusted channel. Then, the cluster manager transmits the encrypted session key E1(K1) in the trusted computing cluster C1, so that other trusted computing units in the cluster obtain the session key and join the first trusted channel. Thus, it can be considered that user U has established the first trusted channel with the entire trusted computing cluster. In such process, user U does not need to negotiate and communicate with each trusted computing unit separately in a sequence, and does not need to pay attention to cluster details of trusted computing cluster C1 either. For the user, the process of establishing a trusted channel becomes very simple and clear.
In addition, the cluster manager transmits the encrypted key E1(K1) obtained through encryption using the cluster key E1, and the cluster key E1 is only held and maintained by the members of the corresponding trusted computing cluster. Even if the encrypted key E1(K1) is obtained by another computing device during the transmission, the computing device still cannot decrypt the session key K1 because it does not have the corresponding cluster key E1, and thus cannot join the session of the first trusted channel. As such, the security of the establishment of a trusted channel is ensured.
Further, in some embodiments, the cluster manager not only maintains the information about the established cluster, but also manages and maintains the status of each trusted channel in the form of a session, that is, maintains the status of each session. The following describes the management of the session corresponding to the first trusted channel by the cluster manager in the process of establishing the first trusted channel.
In some implementations, after trusted computing unit A and user U successfully establish the first trusted channel, trusted computing unit A sends a message to the cluster manager to notify the cluster manager that a new trusted channel has been established, and requests to allocate a session identifier to the trusted channel.
Thus, after step S31 and before step S35, the cluster manager allocates a session identifier to the first trusted channel, which is referred to as a first session identifier here. In an example, the session identifier can be presented in the form of a session ID, for example, denoted as SID1.
In some embodiments, after allocating the first session identifier, the cluster manager further establishes a corresponding trusted computing unit list for the newly created first session identifier, which is referred to as a first trusted computing unit list here, and is used to record the trusted computing unit that joins the corresponding session.
The request message for the first trusted channel comes from first trusted computing unit A, indicating that the first trusted channel was created by trusted computing unit A, and trusted computing unit A has already joined the session. Therefore, in an example, when creating the first trusted computing unit list, the cluster manager adds a unit identifier of first trusted computing unit A to the first trusted computing unit list.
Then, the cluster manager returns the first session identifier to trusted computing unit A. Thus, in some embodiments, trusted computing unit A includes the first session identifier SID1 obtained above in the first notification. In such case, the first notification includes the encrypted key E1(K1) for the first trusted channel and the session identifier SID1 corresponding to the first trusted channel, and the two are correspondingly associated with each other.
In another example, after receiving the first notification, and determining that first trusted computing unit A has obtained the session key for the first trusted channel, the cluster manager adds the unit identifier of first trusted computing unit A to the first trusted computing unit list corresponding to the first session identifier.
For example, in such case, the first trusted computing unit list can be expressed as follows: SID1:<A>.
Next, in step S38, the cluster manager transfers the encrypted key E1(K1) to the second trusted computing unit, for example, trusted computing unit B. In some embodiments, the cluster manager further transfers the first session identifier SID1 to the second trusted computing unit, so that the second trusted computing unit knows the session identifier of the trusted channel that the second trusted computing unit has joined. In addition, the cluster manager further adds the unit identifier corresponding to the second trusted computing unit to the first trusted computing unit list corresponding to the first session identifier. In such case, the first trusted computing unit list can be expressed as follows: SID1:<A,B>.
After subsequently transferring the encrypted key E1(K1) to trusted computing units C, D, and E, the cluster manager similarly adds the unit identifiers of these trusted computing units to the first trusted computing unit list. In such case, the list can be expressed as follows: SID1:<A,B,C,D,E>.
As such, the status of the session corresponding to the first trusted channel is recorded and managed using the session identifier and the corresponding trusted computing unit list.
It can be understood that, similar to the first session corresponding to the first trusted channel, the cluster manager records and manages the status of each session corresponding to each trusted channel. In an example, the cluster manager records the status of each session using a session status table, and the session status table records a trusted computing unit list corresponding to each session identifier. Table 2 shows the session status table in an example.
TABLE 2
Session status table
Session identifier Trusted computing unit list
SID1 A, B, C, D, and E
SID2 A, B, C, and D
SID3 G, H, I, M, N, and P
. . . . . .
As such, the session status can be continuously managed when the session is subsequently shrunk and expanded again. The following describes the process of re-establishing a trusted channel between the user and the trusted computing cluster through the shrinking and expansion of the session.
As described above, the user can establish a trusted channel with any one of the trusted computing units in the trusted computing cluster, so as to establish a trusted channel with, e.g., the entire trusted computing cluster, and then perform data communication with the trusted computing cluster through the trusted channel. In practice, for security reasons, when certain conditions are satisfied, for example, a determined key update time interval, predetermined or dynamically determined, is satisfied, or the trusted channel has been used to transmit a determined amount of data, predetermined or dynamically determined, and so on, the user replaces the session key with the trusted computing cluster. This process is referred to as the re-establishment of the trusted channel.
It is assumed that the user has established a trusted channel with a certain trusted computing cluster. For simplicity of description, a certain trusted computing cluster here is referred to as a second trusted computing cluster, and the established trusted channel is referred to as a second trusted channel. It can be understood that the second trusted computing cluster here and the first trusted computing cluster (for example, cluster C1) may be the same cluster or different clusters. Correspondingly, the second trusted channel and the first trusted channel may be the same or different.
According to one or more implementations of the present specification, when the user wants to replace the session key for the second trusted channel, the user only updates the session key using any one of the trusted computing units in the second trusted computing cluster. For simplicity of description, any one trusted computing unit is referred to as a fourth trusted computing unit.
FIG. 4 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments. The method is performed by the fourth trusted computing unit. The fourth trusted computing unit belongs to a pre-established second trusted computing cluster, and the second trusted computing cluster has established a second trusted channel with the user.
The following provides a description with reference to an example. It is assumed that the second trusted computing cluster is cluster C2 shown in Table 1, and the cluster includes trusted computing units G, H, I, M, N, and P. The information about the second trusted computing cluster has been pre-registered in the cluster manager. In addition, the user has established a trusted channel with trusted computing cluster C2 in a method similar to FIG. 3 , and the trusted channel is referred to as the second trusted channel in these embodiments. It can be understood that, in the process of establishing the second trusted channel, the cluster manager allocates a second session identifier, such as SID3, to the second trusted channel, and records a trusted computing unit list corresponding to the second session identifier using the session status table in Table 2, for example. In addition, the cluster manager further returns the second session identifier to each trusted computing unit joining the session. Therefore, trusted computing units G, H, I, M, N, and P all obtain the second session identifier corresponding to the second trusted channel.
Now it is assumed that the user updates the session key using any one of the trusted computing units H. The fourth trusted computing unit H executes the following process.
In step 41, the fourth trusted computing unit H obtains, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data.
In some embodiments, the key update request is initiated by the user. For example, the user can send the key update request based on his/her own needs.
In other embodiments, the key update request can alternatively be initiated by the cluster manager according to a determined management rule, predetermined or dynamically determined. For example, a management rule may stipulate that each trusted channel updates the session key every determined time interval.
In response to a key update request for the second trusted channel, the fourth trusted computing unit such as trusted computing unit H obtains, through negotiation with the user, a new session key for the trusted channel, which is referred to as a second session key here and is denoted as K2. The processes for key negotiation of the second session key are similar as those in the process for establishing a trusted channel, and details are omitted here for simplicity. It can be understood that, the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data.
Next, in step 43, the fourth trusted computing unit uses the cluster key of the second computing cluster to which the fourth trusted computing unit belongs, that is, the second cluster key, to encrypt the second session key to obtain the second encrypted key.
For example, when the fourth trusted computing unit is trusted, e.g., computing unit H, since trusted computing unit H belongs to the second computing cluster C2, trusted computing unit H maintains the second cluster key E2 specific to C2. Thus, the second cluster key E2 can be used to encrypt the second session key K2 to obtain the second encrypted key E2(K2).
In addition, as described above, when pre-establishing or joining the second trusted channel, fourth trusted computing unit H obtains the second session identifier corresponding to the second trusted channel from the cluster manager, such as SID3. Therefore, in step 45, the fourth trusted computing unit can send a second notification to the cluster manager, where the second notification includes the second encrypted key E2(K2) and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
Next, the process of shrinking and expanding the session of the second trusted channel is executed by the cluster manager.
FIG. 5 is a flowchart of re-establishing a trusted channel between a user and a trusted computing cluster according to some embodiments. The method is performed by a cluster manager.
As shown in FIG. 5 , in step 51, the cluster manager receives a second notification from a fourth trusted computing unit, where the second notification includes a second encrypted key and a second session identifier. The second session identifier corresponds to a second trusted channel between the fourth trusted computing unit and the user, and the second encrypted key is obtained by encrypting the updated second session key using the second cluster key. For example, corresponding to step 45 in FIG. 4 , the cluster manager receives the second notification from trusted computing unit H, where the second notification includes the second encrypted key E2(K2) and the second session identifier SID3.
Next, in step 53, the cluster manager obtains, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster.
As described above, the cluster manager is configured to manage each pre-established trusted computing cluster, for example, record the trusted computing cluster as the cluster information table shown in Table 1. In addition, the cluster manager further maintains the status of each session established with each trusted computing cluster. In some embodiments, the cluster manager records and maintains the status of each session established with each trusted computing cluster using the session status table in Table 2.
Through the session status table, the cluster manager can query and obtain a second trusted computing unit list corresponding to the second session identifier, where the second trusted computing unit list records the trusted computing unit that joins the second trusted channel. Referring to the process of FIG. 3 , it can be understood that the units that join the second trusted channel together with the fourth trusted computing unit must belong to the second trusted computing cluster. Therefore, the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit that also belongs to the second trusted computing cluster.
For example, for the second session identifier SID3 included in the second notification, the cluster manager can determine, for example, by querying the session status table in Table 2, that the second trusted computing unit list corresponding to the second session identifier SID3 includes: SID3: <G,H,I,M,N,P>.
The second trusted computing unit list includes fourth trusted computing unit H and other trusted computing units G, I, M, N, and P that also belong to the second trusted computing cluster C2.
Next, in step 55, the cluster manager removes each of the at least one other trusted computing units from the second trusted computing unit list. In other words, because currently only the fourth trusted computing unit has obtained the updated session key, it is considered that only the fourth trusted computing unit remains in the session corresponding to the second trusted channel, and other trusted computing units were removed from the session because the key was not updated. Therefore, these trusted computing units are removed from the second trusted computing unit list.
The example is still used for description. After the second trusted computing unit list <G,H,I,M,N,P> corresponding to the second session identifier SID3 is determined in step 53, in step 55, all units other than fourth trusted computing unit H are removed from the list. In such case, the second trusted computing unit list is updated to: SID3: <H>.
After that, in step 57, the cluster manager transfers the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, so that the fifth trusted computing unit decrypts the second encrypted key based on the second cluster key maintained by the fifth trusted computing unit to obtain the second session key, and thus rejoins the second trusted channel based on the second session key.
It is worthwhile to note that, the fifth trusted computing unit is any one of the trusted computing units that previously joined the second trusted channel other than the fourth trusted computing unit. Therefore, the fifth trusted computing unit must belong to the same second trusted cluster as the fourth trusted computing unit, and therefore also maintains the second cluster key. As such, after receiving the second encrypted key, the fifth trusted computing unit can decrypt the second encrypted key using the second cluster key, to obtain the second session key, which is a new session key of the second trusted channel. Thus, the fifth trusted computing unit can rejoin the second trusted channel.
In some embodiments, after the transferring the second encrypted key to the fifth trusted computing unit, the cluster manager adds the unit identifier of the fifth trusted computing unit to the second trusted computing unit list again to indicate that the fifth trusted computing unit rejoins the second session.
In the same way, the cluster manager can transfer the second encrypted key to the trusted computing units previously joined the second trusted channel one by one, so that these trusted computing units rejoin the second trusted channel. Further, the cluster manager can add the unit identifiers of these trusted computing units to the second trusted computing unit list.
The example is used for description. In step 55, all units other than fourth trusted computing unit H are removed from the second trusted computing unit list. That is, the removed units include G, I, M, N, and P. In step 57, the second encrypted key E2(K2) is transferred to the fifth trusted computing unit in the removed units, for example, trusted computing unit G. Thus, trusted computing unit G can decrypt E2(K2) using the second cluster key E2 maintained by trusted computing unit G to obtain the updated session key K2 for the second trusted channel, thereby rejoining the second trusted channel.
In addition, the cluster manager adds the unit identifier of trusted computing unit G back to the second trusted computing unit list. In such case, the second trusted computing unit list is updated to: SID3: <G,H>.
After that, the cluster manager further transfers the second encrypted key E2(K2) to trusted computing units I, M, N, and P, so that these trusted computing units rejoin the second trusted channel. After that, the second trusted computing unit list is updated again to: SID3: <G,H,I,M,N,P>.
In the process, when all units other than the fourth trusted computing unit are removed from the second trusted computing unit list, the second session corresponding to the second channel is shrunk to the minimum and includes only the fourth trusted computing unit. After that, as the second encrypted key is transmitted again, the second session is expanded again. For example, at the shrinking stage, the nodes included in the session SID3 are shrunk to <H>, and then are expanded to <G,H,I,M,N,P> again. Through the process of shrinking the session and then expanding the session again, the process of re-establishing the trusted channel between the user and the trusted computing cluster is implemented.
In the process, when user U replaces the session key of the second trusted channel that has been established, user U only negotiates with any one of the trusted computing units in the cluster to obtain a new session key K2, and the cluster manager removes the trusted computing units that previously joined the second trusted channel out of the corresponding second session, and then transmits the encrypted session key E2(K2) again in the cluster, so that these trusted computing units rejoin the second session. In the entire process, the user does not need to negotiate and communicate with each trusted computing unit separately in a sequence, and does not need to pay attention to cluster details of the trusted computing cluster either. The re-establishment process is simple and secure.
According to some embodiments in another aspect, an apparatus for establishing a trusted channel between a user and a trusted computing cluster is further provided. FIG. 6 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments. The establishment apparatus is deployed in the trusted computing unit. In the following description, the trusted computing unit is referred to as the first trusted computing unit. The first trusted computing unit belongs to a pre-established first trusted computing cluster, the first trusted computing cluster includes a plurality of trusted computing units each maintaining a same first cluster key, and the first trusted computing unit pre-registers with a cluster manager for information about the first trusted computing cluster to which the first trusted computing unit belongs. As shown in FIG. 6 , the establishment apparatus 600 includes: a key negotiation module 61, configured to obtain a first session key through negotiation with a user, and establish a first trusted channel with the user, where the first session key is used to encrypt data to be transmitted through the first trusted channel; a first encryption module 63, configured to encrypt the first session key using the first cluster key to obtain a first encrypted key; and a first notification sending module 65, configured to send a first notification to the cluster manager, where the first notification includes the first encrypted key, so that the cluster manager transfers the first encrypted key to other trusted computing units in the first trusted computing cluster.
According to some embodiments, the key negotiation module 61 is configured to: send a first public key of a first key pair of the first trusted computing unit to the user, the first key pair including the first public key and a first private key, and obtain a user public key provided by the user; and generate the first session key based on the first public key, the first private key, and the user public key.
In some embodiments, the apparatus 600 further includes an identifier acquisition module (not shown), configured to perform the following steps before the first notification sending module 65 sends a first notification to the cluster manager: sending an identifier request message for the first trusted channel to the cluster manager; obtaining a first session identifier allocated by the cluster manager to the first trusted channel; and including the first session identifier into the first notification.
According to some embodiments in still another aspect, an apparatus for establishing a trusted channel between a user and a trusted computing cluster is further provided. FIG. 7 is a schematic block diagram illustrating an apparatus for establishing a trusted channel according to some embodiments. The establishment apparatus is deployed in the cluster manager. The cluster manager is configured to manage at least one pre-established trusted computing cluster. As shown in FIG. 7 , the establishment apparatus 700 includes: a first notification receiving module 71, configured to receive a first notification from a first trusted computing unit, where the first notification includes a first encrypted key, the first encrypted key is obtained by encrypting a first session key using a first cluster key, and the first session key is a data encryption key corresponding to a first trusted channel between the first trusted computing unit and the user; a cluster determination module 73, configured to determine a first trusted computing cluster to which the first trusted computing unit belongs, where each trusted computing unit in the first trusted computing cluster maintains the first cluster key; and a first transferring module 75, configured to transfer the first encrypted key to a second trusted computing unit in the first trusted computing cluster, so that the second trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the second trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
According to some embodiments, the establishment apparatus 700 further includes (not shown): a session identifier allocation module, configured to allocate a first session identifier to the first trusted channel in response to an identifier request message of the first trusted computing unit for the first trusted channel; and a first list adding module, configured to add the first trusted computing unit to a first trusted computing unit list corresponding to the first session identifier.
Further, in some embodiments, the first notification further includes the first session identifier, and the first transferring module 75 is further configured to transfer the first session identifier to the second trusted computing unit; and the first list adding module is further configured to add the second trusted computing unit to the first trusted computing unit list.
According to some implementations, the cluster determination module 73 is configured to use a maintained cluster information table to determine a first trusted computing cluster to which the first trusted computing unit belongs, and each trusted computing unit included in the first trusted computing cluster.
In some embodiments, the first transferring module 75 is further configured to: transfer the first encrypted key to a third trusted computing unit in the first trusted computing cluster, so that the third trusted computing unit decrypts the first encrypted key based on the first cluster key maintained by the third trusted computing unit to obtain the first session key, and thus joins the first trusted channel based on the first session key.
According to some embodiments in another aspect, an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster is further provided. FIG. 8 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments. The re-establishment apparatus is deployed in the trusted computing unit. In the following description, the trusted computing unit is referred to as the fourth trusted computing unit. The fourth trusted computing unit has established a second trusted channel with the user, the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the fourth trusted computing unit pre-registers with a cluster manager for information about the second trusted computing cluster to which the fourth trusted computing unit belongs, and the fourth trusted computing unit obtains a second session identifier corresponding to the second trusted channel from the cluster manager. Under the premise, the re-establishment apparatus 800 includes: a key update module 81, configured to obtain, through negotiation with the user, a second session key for the second trusted channel in response to a key update request for the second trusted channel, where the second session key is used to replace an original key of the second trusted channel to encrypt transmitted data; a second encryption module 83, configured to encrypt the second session key using the second cluster key to obtain a second encrypted key; and a second notification sending module 85, configured to send a second notification to the cluster manager, where the second notification includes the second encrypted key and the second session identifier, so that the cluster manager transfers the second encrypted key to other trusted computing units related to the second session identifier.
According to some embodiments in still another aspect, an apparatus for re-establishing a trusted channel between a user and a trusted computing cluster is further provided. FIG. 9 is a schematic block diagram illustrating an apparatus for re-establishing a trusted channel according to some embodiments. The re-establishment apparatus is deployed in the cluster manager. The cluster manager is configured to manage at least one pre-established trusted computing cluster. As shown in FIG. 9 , the re-establishment apparatus 900 includes: a second notification receiving module 91, configured to receive a second notification from a fourth trusted computing unit, where the fourth trusted computing unit belongs to a pre-established second trusted computing cluster, the second trusted computing cluster includes a plurality of trusted computing units each maintaining a same second cluster key, the second notification includes a second session identifier and a second encrypted key, the second session identifier corresponds to a second trusted channel that has been established between the fourth trusted computing unit and the user, the second encrypted key is obtained by encrypting a second session key using the second cluster key, and the second session key is an updated key for the second trusted channel; a second list acquisition module 93, configured to obtain, based on the second session identifier, a second trusted computing unit list of trusted computing units that join the second trusted channel, where the second trusted computing unit list includes the fourth trusted computing unit and at least one other trusted computing unit belonging to the second trusted computing cluster; a removing module 95, configured to remove each of the at least one other trusted computing units from the second trusted computing unit list; and a second transferring module 97, configured to transfer the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, so that the fifth trusted computing unit decrypts the second encrypted key based on the second cluster key maintained by the fifth trusted computing unit to obtain the second session key, and thus rejoins the second trusted channel based on the second session key.
In some embodiments, the re-establishment apparatus 900 further includes a second list adding module (not shown), configured to: after the second transferring module 97 transfers the second encrypted key to a fifth trusted computing unit of the at least one other trusted computing units, add the fifth trusted computing unit to the second trusted computing unit list.
According to some embodiments in another aspect, a computer-readable storage medium is further provided, where the computer-readable storage medium stores a computer program, and when the computer program is executed in a computer, the computer is enabled to perform the methods described with reference to FIG. 3 to FIG. 5 .
According to some embodiments in yet another aspect, a computing device is further provided, including a memory and a processor, where the memory stores executable code, and the processor executes the executable code to implement the methods described with reference to FIG. 3 to FIG. 5 .
A person skilled in the art should be aware that, in the one or more examples, functions described in the present application can be implemented by hardware, software, firmware, or any combination thereof. When being implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code in the computer-readable medium.
The objectives, technical solutions, and beneficial effects of the present application are further described in detail in the implementations. It should be understood that the descriptions are merely implementations of the present application, but are not intended to limit the protection scope of the present application. Any modification, equivalent replacement, or improvement made based on the technical solutions of the present application shall fall within the protection scope of the present application.
The various embodiments described above can be combined to provide further embodiments. All of the U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entirety. Aspects of the embodiments can be modified, if necessary to employ concepts of the various patents, applications and publications to provide yet further embodiments.
These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.

Claims (20)

The invention claimed is:
1. A method for establishing a trusted channel between a user and a trusted computing cluster, the trusted computing cluster including a plurality of trusted computing units each maintaining a first cluster key, the method comprising:
obtaining, by a first trusted computing unit of the trusted computing cluster, a first session key through negotiation with a user, and establishing a first trusted channel with the user, the first session key configured to encrypt data to be transmitted through the first trusted channel;
encrypting, by the first trusted computing unit, the first session key using the first cluster key to obtain a first encrypted key; and
causing the first encrypted key to be sent to a second trusted computing unit in of the trusted computing cluster.
2. The method according to claim 1, wherein the obtaining the first session key through negotiation with the user includes:
sending a first public key of a first key pair of the first trusted computing unit to the user, the first key pair including the first public key and a first private key, and obtaining a user public key provided by the user; and
generating the first session key based on the first public key, the first private key, and the user public key.
3. The method according to claim 1, comprising:
before the causing the first encrypted key to be sent to the second trusted computing unit:
sending an identifier request message for the first trusted channel to a cluster manager;
obtaining, from the cluster manager, a first session identifier allocated to the first trusted channel; and
causing the first session identifier to be sent together with the first encrypted key to the second trusted computing unit.
4. A method, comprising:
receiving, from a first trusted computing unit, an encrypted key, the encrypted key corresponding to a trusted channel between the first trusted computing unit and a user outside a trusted computing environment of the first trusted computing unit;
determining a trusted computing cluster to which the first trusted computing unit belongs; and
sending the encrypted key to a second trusted computing unit of the trusted computing cluster, enabling the second trusted computing unit to decrypt the encrypted key using a cluster key of the trusted computing cluster to obtain a session key for the trusted channel and to join the trusted channel based on the session key.
5. The method of claim 4, comprising:
receiving from the first trusted computing unit, a session identifier corresponding to the trusted channel; and
obtaining, based on the session identifier, a list of trusted computing units of the trusted computing cluster that join the trusted channel, the list including the first trusted computing unit.
6. The method of claim 5, comprising:
before the sending the encrypted key to the second trusted computing unit of the trusted computing cluster, removing all trusted computing units from the list except for the first trusted computing unit.
7. The method according to claim 4, further comprising:
receiving, from the first trusted computing unit, a request for an identifier with respect to the trusted channel;
allocating a session identifier to the trusted channel in response to the request; and
adding the first trusted computing unit to a list of trusted computing unit of the trusted computing cluster corresponding to the session identifier.
8. The method according to claim 7, comprising:
sending the session identifier to the second trusted computing unit; and
adding the second trusted computing unit to the list of trusted computing units.
9. The method according to claim 4, wherein the determining the trusted computing cluster to which the first trusted computing unit belongs includes:
using a maintained cluster information table to determine the trusted computing cluster to which the first trusted computing unit belongs and each trusted computing unit included in the trusted computing cluster.
10. A non-transitory storage medium having computer executable instructions stored thereon, which when executed by one or more processors, configure the one or more processors to perform acts including:
receiving, from a first trusted computing unit, an encrypted key, the encrypted key corresponding to a trusted channel between the first trusted computing unit and a user outside a trusted computing environment of the first trusted computing unit;
determining a trusted computing cluster to which the first trusted computing unit belongs; and
sending the encrypted key to a second trusted computing unit of the trusted computing cluster, enabling the second trusted computing unit to decrypt the encrypted key using a cluster key of the trusted computing cluster to obtain a session key for the trusted channel and to join the trusted channel based on the session key.
11. The storage medium according to claim 10, wherein the acts include:
receiving from the first trusted computing unit, a session identifier corresponding to the trusted channel; and
obtaining, based on the session identifier, a list of trusted computing units of the trusted computing cluster that join the trusted channel, the list including the first trusted computing unit.
12. The storage medium according to claim 11, wherein the acts include:
before the sending the encrypted key to the second trusted computing unit of the trusted computing cluster, removing all trusted computing units from the list except for the first trusted computing unit.
13. The storage medium according to claim 10, wherein the acts include:
receiving, from the first trusted computing unit, a request for an identifier with respect to the trusted channel;
allocating a session identifier to the trusted channel in response to the request; and
adding the first trusted computing unit to a list of trusted computing unit of the trusted computing cluster corresponding to the session identifier.
14. The storage medium according to claim 13, wherein the acts include:
sending the session identifier to the second trusted computing unit; and
adding the second trusted computing unit to the list of trusted computing units.
15. The storage medium according to claim 10, wherein the determining the trusted computing cluster to which the first trusted computing unit belongs includes:
using a maintained cluster information table to determine the trusted computing cluster to which the first trusted computing unit belongs and each trusted computing unit included in the trusted computing cluster.
16. A computing device, comprising:
a processor;
a memory having computer executable instructions stored thereon, which, when executed by the processor, configure the processor to perform acts including:
receiving, from a first trusted computing unit, an encrypted key, the encrypted key corresponding to a trusted channel between the first trusted computing unit and a user outside a trusted computing environment of the first trusted computing unit;
determining a trusted computing cluster to which the first trusted computing unit belongs; and
sending the encrypted key to a second trusted computing unit of the trusted computing cluster, enabling the second trusted computing unit to decrypt the encrypted key using a cluster key of the trusted computing cluster to obtain a session key for the trusted channel and to join the trusted channel based on the session key.
17. The computing device according to claim 16, wherein the acts include:
receiving from the first trusted computing unit, a session identifier corresponding to the trusted channel; and
obtaining, based on the session identifier, a list of trusted computing units of the trusted computing cluster that join the trusted channel, the list including the first trusted computing unit.
18. The computing device according to claim 17, wherein the acts include:
before the sending the encrypted key to the second trusted computing unit of the trusted computing cluster, removing all trusted computing units from the list except for the first trusted computing unit.
19. The computing device according to claim 16, wherein the acts include:
receiving, from the first trusted computing unit, a request for an identifier with respect to the trusted channel;
allocating a session identifier to the trusted channel in response to the request; and
adding the first trusted computing unit to a list of trusted computing unit of the trusted computing cluster corresponding to the session identifier.
20. The computing device according to claim 19, wherein the acts include:
sending the session identifier to the second trusted computing unit; and
adding the second trusted computing unit to the list of trusted computing units.
US17/401,064 2018-12-12 2021-08-12 Method and apparatus for establishing trusted channel between user and trusted computing cluster Active 2039-11-07 US11728978B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/401,064 US11728978B2 (en) 2018-12-12 2021-08-12 Method and apparatus for establishing trusted channel between user and trusted computing cluster

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
CN201811521029.9A CN109873801B (en) 2018-12-12 2018-12-12 Method, device, storage medium and computing equipment for establishing trusted channel between user and trusted computing cluster
CN201811521029.9 2018-12-12
PCT/CN2019/112645 WO2020119263A1 (en) 2018-12-12 2019-10-23 Method and apparatus for establishing trusted channel between user and trusted computing cluster
US17/158,987 US11121865B2 (en) 2018-12-12 2021-01-26 Method and apparatus for establishing trusted channel between user and trusted computing cluster
US17/401,064 US11728978B2 (en) 2018-12-12 2021-08-12 Method and apparatus for establishing trusted channel between user and trusted computing cluster

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US17/158,987 Continuation US11121865B2 (en) 2018-12-12 2021-01-26 Method and apparatus for establishing trusted channel between user and trusted computing cluster

Publications (2)

Publication Number Publication Date
US20220021520A1 US20220021520A1 (en) 2022-01-20
US11728978B2 true US11728978B2 (en) 2023-08-15

Family

ID=66917092

Family Applications (2)

Application Number Title Priority Date Filing Date
US17/158,987 Active US11121865B2 (en) 2018-12-12 2021-01-26 Method and apparatus for establishing trusted channel between user and trusted computing cluster
US17/401,064 Active 2039-11-07 US11728978B2 (en) 2018-12-12 2021-08-12 Method and apparatus for establishing trusted channel between user and trusted computing cluster

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US17/158,987 Active US11121865B2 (en) 2018-12-12 2021-01-26 Method and apparatus for establishing trusted channel between user and trusted computing cluster

Country Status (6)

Country Link
US (2) US11121865B2 (en)
EP (1) EP3813298B1 (en)
CN (1) CN109873801B (en)
SG (1) SG11202100968YA (en)
TW (1) TWI714270B (en)
WO (1) WO2020119263A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109873801B (en) 2018-12-12 2020-07-24 阿里巴巴集团控股有限公司 Method, device, storage medium and computing equipment for establishing trusted channel between user and trusted computing cluster
CN109861980B (en) 2018-12-29 2020-08-04 阿里巴巴集团控股有限公司 Method, device, storage medium and computing equipment for establishing trusted computing cluster
CN110535628B (en) * 2019-08-29 2020-07-17 阿里巴巴集团控股有限公司 Method and device for performing multi-party security calculation through certificate signing and issuing
US11038699B2 (en) 2019-08-29 2021-06-15 Advanced New Technologies Co., Ltd. Method and apparatus for performing multi-party secure computing based-on issuing certificate
CN110750803B (en) * 2019-10-18 2021-04-09 支付宝(杭州)信息技术有限公司 Method and device for providing and fusing data
CN113965789B (en) * 2021-12-15 2022-05-17 荣耀终端有限公司 Screen projection method, terminal and communication system
US11722468B1 (en) * 2022-02-05 2023-08-08 Uab 360 It Optimized messaging in a mesh network

Citations (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030044020A1 (en) * 2001-09-06 2003-03-06 Microsoft Corporation Establishing secure peer networking in trust webs on open networks using shared secret device key
CN1415158A (en) 1999-04-28 2003-04-30 D.S.P.C.科技有限公司 System and method for joint time tracking of multiple paths
EP1396972A2 (en) 1998-10-07 2004-03-10 Denon, Ltd. Multicarrier transmission of two data sets
US20040054891A1 (en) * 2002-08-27 2004-03-18 Hengeveld Thomas Andrew Secure encryption key distribution
US20040210767A1 (en) * 2003-04-15 2004-10-21 Microsoft Corporation Small-scale secured computer network group without centralized management
CN1564514A (en) 2004-03-26 2005-01-12 中兴通讯股份有限公司 Self arranged net mode shared key authentication and conversation key consulant method of radio LAN
US20050223217A1 (en) * 2004-04-01 2005-10-06 Microsoft Corporation Authentication broker service
US20070003064A1 (en) * 2005-06-30 2007-01-04 Wiseman Willard M Apparatus and method for group session key and establishment using a certified migration key
US20070076889A1 (en) * 2005-09-29 2007-04-05 International Business Machines Corporation Pre-generation of generic session keys for use in communicating within communications environments
US20070297613A1 (en) * 2006-06-23 2007-12-27 Honeywell International Inc. Secure group communication among wireless devices with distributed trust
CN101170404A (en) 2006-10-24 2008-04-30 华为技术有限公司 Method for secret key configuration based on specified group
US20080159541A1 (en) * 2006-12-29 2008-07-03 Kumar Mohan J Methods and apparatus for protecting data
CN101594386A (en) 2009-06-29 2009-12-02 北京航空航天大学 Reliable virtual organization construction method and device based on distributed strategy verification
US20090300358A1 (en) * 2006-09-23 2009-12-03 China Iwncomm Co. Ltd Method for managing network key and updating session key
CN101651543A (en) 2009-09-04 2010-02-17 瑞达信息安全产业股份有限公司 Creditable calculation platform key migration system and key migration method thereof
US20100162036A1 (en) * 2008-12-19 2010-06-24 Watchguard Technologies, Inc. Self-Monitoring Cluster of Network Security Devices
US20100332829A1 (en) * 2009-06-26 2010-12-30 Nagravision S.A. Method for detecting the use of a cloned user unit communicating with a server
CA2731006A1 (en) 2010-02-26 2011-08-26 Research In Motion Limited Methods and devices for computing a shared encryption key
CN102244577A (en) 2010-05-10 2011-11-16 东北大学技术转移中心 Node authentication
US8176336B1 (en) * 2008-12-19 2012-05-08 Emc Corporation Software trusted computing base
US20120189117A1 (en) * 2008-05-27 2012-07-26 Priyadarsini Devanand Methods And Apparatus For Protecting Digital Content
WO2012159272A1 (en) 2011-05-26 2012-11-29 Nokia Corporation Performing a group authentication and key agreement procedure
US20130002968A1 (en) * 2011-06-28 2013-01-03 Bridge Robert F User Control of the Visual Performance of a Compressive Imaging System
US20130003968A1 (en) * 2011-06-30 2013-01-03 Electronics And Telecommunications Research Institute Method and apparatus for generating session key and cluster key
CN102986163A (en) 2010-03-05 2013-03-20 交互数字专利控股公司 Method and apparatus for providing security to devices
WO2013046088A1 (en) 2011-09-27 2013-04-04 Koninklijke Philips Electronics N.V. Management of group secrets by group members
CN103051455A (en) 2012-12-22 2013-04-17 中国船舶重工集团公司第七0九研究所 Method for realizing delegation of cipher function of TCM (trusted cryptographic module) under cloud computing environment
US20130108050A1 (en) * 2011-10-27 2013-05-02 Archtecture Technology, Inc. Network having multicast security and method therefore
CN103856477A (en) 2012-12-06 2014-06-11 阿里巴巴集团控股有限公司 Trusted computing system, corresponding attestation method and corresponding devices
CN103959735A (en) 2011-08-25 2014-07-30 网络存储技术公司 Systems and methods for providing secure multicast intra-cluster communication
US8954740B1 (en) * 2010-10-04 2015-02-10 Symantec Corporation Session key proxy decryption method to secure content in a one-to-many relationship
US20150195261A1 (en) * 2012-07-27 2015-07-09 Telefonaktiebolaget L M Ericsson (Publ) Secure Session for a Group of Network Nodes
CN105790938A (en) 2016-05-23 2016-07-20 中国银联股份有限公司 System and method for generating safety unit key based on reliable execution environment
CN105915502A (en) 2015-02-19 2016-08-31 恩智浦有限公司 Method and system for facilitating network joining
CN106101252A (en) 2016-07-01 2016-11-09 何钟柱 Information Security Risk guard system based on big data and trust computing
CN106332074A (en) 2015-06-15 2017-01-11 中国移动通信集团辽宁有限公司 Multi-party communication authentication method and system
US20170083716A1 (en) * 2015-09-22 2017-03-23 Mastercard International Incorporated Secure computer cluster with encryption
CN106991329A (en) 2017-03-31 2017-07-28 山东超越数控电子有限公司 A kind of trust calculation unit and its operation method based on domestic TCM
CN206611427U (en) 2017-03-28 2017-11-03 浙江神州量子网络科技有限公司 A kind of key storage management system based on trust computing device
CN107924445A (en) 2015-09-25 2018-04-17 英特尔公司 Retain the mutual accreditation of the calculating of privacy
CN108259469A (en) 2017-12-19 2018-07-06 浪潮软件集团有限公司 Cluster security authentication method based on block chain, node and cluster
CN108491727A (en) 2018-04-08 2018-09-04 成都三零嘉微电子有限公司 It is a kind of fusion general-purpose computations, trust computing, cryptographic calculations safe processor
CN108833522A (en) 2018-06-06 2018-11-16 北京八分量信息科技有限公司 A kind of believable system and method for determining node
CN108847928A (en) 2018-04-26 2018-11-20 如般量子科技有限公司 The communication system and communication means of the transmission of information encryption and decryption are realized based on group's type quantum key card
US20190005274A1 (en) * 2017-06-30 2019-01-03 Microsoft Technology Licensing, Llc Theft and tamper resistant data protection
CN109861980A (en) 2018-12-29 2019-06-07 阿里巴巴集团控股有限公司 A kind of method and apparatus for establishing trust computing cluster
CN109873801A (en) 2018-12-12 2019-06-11 阿里巴巴集团控股有限公司 The method and device of trusted channel is established between user and trust computing cluster
US20200067912A1 (en) * 2018-08-21 2020-02-27 International Business Machines Corporation Implementing authentication protocol for merging multiple server nodes with trusted platform modules utilizing provisioned node certificates to support concurrent node add and remove

Patent Citations (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1396972A2 (en) 1998-10-07 2004-03-10 Denon, Ltd. Multicarrier transmission of two data sets
CN1415158A (en) 1999-04-28 2003-04-30 D.S.P.C.科技有限公司 System and method for joint time tracking of multiple paths
US20030044020A1 (en) * 2001-09-06 2003-03-06 Microsoft Corporation Establishing secure peer networking in trust webs on open networks using shared secret device key
US20040054891A1 (en) * 2002-08-27 2004-03-18 Hengeveld Thomas Andrew Secure encryption key distribution
US20040210767A1 (en) * 2003-04-15 2004-10-21 Microsoft Corporation Small-scale secured computer network group without centralized management
CN1564514A (en) 2004-03-26 2005-01-12 中兴通讯股份有限公司 Self arranged net mode shared key authentication and conversation key consulant method of radio LAN
US20050223217A1 (en) * 2004-04-01 2005-10-06 Microsoft Corporation Authentication broker service
US20070003064A1 (en) * 2005-06-30 2007-01-04 Wiseman Willard M Apparatus and method for group session key and establishment using a certified migration key
US20070076889A1 (en) * 2005-09-29 2007-04-05 International Business Machines Corporation Pre-generation of generic session keys for use in communicating within communications environments
US20070297613A1 (en) * 2006-06-23 2007-12-27 Honeywell International Inc. Secure group communication among wireless devices with distributed trust
US20090300358A1 (en) * 2006-09-23 2009-12-03 China Iwncomm Co. Ltd Method for managing network key and updating session key
CN101170404A (en) 2006-10-24 2008-04-30 华为技术有限公司 Method for secret key configuration based on specified group
US20080159541A1 (en) * 2006-12-29 2008-07-03 Kumar Mohan J Methods and apparatus for protecting data
US20120189117A1 (en) * 2008-05-27 2012-07-26 Priyadarsini Devanand Methods And Apparatus For Protecting Digital Content
US20100162036A1 (en) * 2008-12-19 2010-06-24 Watchguard Technologies, Inc. Self-Monitoring Cluster of Network Security Devices
US8176336B1 (en) * 2008-12-19 2012-05-08 Emc Corporation Software trusted computing base
US20100332829A1 (en) * 2009-06-26 2010-12-30 Nagravision S.A. Method for detecting the use of a cloned user unit communicating with a server
CN101594386A (en) 2009-06-29 2009-12-02 北京航空航天大学 Reliable virtual organization construction method and device based on distributed strategy verification
CN101651543A (en) 2009-09-04 2010-02-17 瑞达信息安全产业股份有限公司 Creditable calculation platform key migration system and key migration method thereof
CA2731006A1 (en) 2010-02-26 2011-08-26 Research In Motion Limited Methods and devices for computing a shared encryption key
CN102986163A (en) 2010-03-05 2013-03-20 交互数字专利控股公司 Method and apparatus for providing security to devices
CN102244577A (en) 2010-05-10 2011-11-16 东北大学技术转移中心 Node authentication
US8954740B1 (en) * 2010-10-04 2015-02-10 Symantec Corporation Session key proxy decryption method to secure content in a one-to-many relationship
WO2012159272A1 (en) 2011-05-26 2012-11-29 Nokia Corporation Performing a group authentication and key agreement procedure
US20130002968A1 (en) * 2011-06-28 2013-01-03 Bridge Robert F User Control of the Visual Performance of a Compressive Imaging System
US20130003968A1 (en) * 2011-06-30 2013-01-03 Electronics And Telecommunications Research Institute Method and apparatus for generating session key and cluster key
CN103959735A (en) 2011-08-25 2014-07-30 网络存储技术公司 Systems and methods for providing secure multicast intra-cluster communication
WO2013046088A1 (en) 2011-09-27 2013-04-04 Koninklijke Philips Electronics N.V. Management of group secrets by group members
CN103828289A (en) 2011-09-27 2014-05-28 皇家飞利浦有限公司 Management of group secrets by group members
US20130108050A1 (en) * 2011-10-27 2013-05-02 Archtecture Technology, Inc. Network having multicast security and method therefore
US20150195261A1 (en) * 2012-07-27 2015-07-09 Telefonaktiebolaget L M Ericsson (Publ) Secure Session for a Group of Network Nodes
CN103856477A (en) 2012-12-06 2014-06-11 阿里巴巴集团控股有限公司 Trusted computing system, corresponding attestation method and corresponding devices
CN103051455A (en) 2012-12-22 2013-04-17 中国船舶重工集团公司第七0九研究所 Method for realizing delegation of cipher function of TCM (trusted cryptographic module) under cloud computing environment
CN105915502A (en) 2015-02-19 2016-08-31 恩智浦有限公司 Method and system for facilitating network joining
CN106332074A (en) 2015-06-15 2017-01-11 中国移动通信集团辽宁有限公司 Multi-party communication authentication method and system
US20170083716A1 (en) * 2015-09-22 2017-03-23 Mastercard International Incorporated Secure computer cluster with encryption
CN107924445A (en) 2015-09-25 2018-04-17 英特尔公司 Retain the mutual accreditation of the calculating of privacy
CN105790938A (en) 2016-05-23 2016-07-20 中国银联股份有限公司 System and method for generating safety unit key based on reliable execution environment
CN106101252A (en) 2016-07-01 2016-11-09 何钟柱 Information Security Risk guard system based on big data and trust computing
CN206611427U (en) 2017-03-28 2017-11-03 浙江神州量子网络科技有限公司 A kind of key storage management system based on trust computing device
CN106991329A (en) 2017-03-31 2017-07-28 山东超越数控电子有限公司 A kind of trust calculation unit and its operation method based on domestic TCM
US20190005274A1 (en) * 2017-06-30 2019-01-03 Microsoft Technology Licensing, Llc Theft and tamper resistant data protection
CN108259469A (en) 2017-12-19 2018-07-06 浪潮软件集团有限公司 Cluster security authentication method based on block chain, node and cluster
CN108491727A (en) 2018-04-08 2018-09-04 成都三零嘉微电子有限公司 It is a kind of fusion general-purpose computations, trust computing, cryptographic calculations safe processor
CN108847928A (en) 2018-04-26 2018-11-20 如般量子科技有限公司 The communication system and communication means of the transmission of information encryption and decryption are realized based on group's type quantum key card
CN108833522A (en) 2018-06-06 2018-11-16 北京八分量信息科技有限公司 A kind of believable system and method for determining node
US20200067912A1 (en) * 2018-08-21 2020-02-27 International Business Machines Corporation Implementing authentication protocol for merging multiple server nodes with trusted platform modules utilizing provisioned node certificates to support concurrent node add and remove
CN109873801A (en) 2018-12-12 2019-06-11 阿里巴巴集团控股有限公司 The method and device of trusted channel is established between user and trust computing cluster
CN109861980A (en) 2018-12-29 2019-06-07 阿里巴巴集团控股有限公司 A kind of method and apparatus for establishing trust computing cluster

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP Technical Specification Group Services and System Aspects, 3GPP System Architecture Evolution (SAE), Security Architecture (Release 12), GPP TS 133.401, V12.16.0, 2015.

Also Published As

Publication number Publication date
US20210184838A1 (en) 2021-06-17
EP3813298A4 (en) 2021-11-10
TW202023227A (en) 2020-06-16
WO2020119263A1 (en) 2020-06-18
EP3813298A1 (en) 2021-04-28
CN109873801A (en) 2019-06-11
TWI714270B (en) 2020-12-21
US20220021520A1 (en) 2022-01-20
SG11202100968YA (en) 2021-03-30
US11121865B2 (en) 2021-09-14
CN109873801B (en) 2020-07-24
EP3813298B1 (en) 2023-06-28

Similar Documents

Publication Publication Date Title
US11728978B2 (en) Method and apparatus for establishing trusted channel between user and trusted computing cluster
Naoui et al. Enhancing the security of the IoT LoraWAN architecture
US7957320B2 (en) Method for changing a group key in a group of network elements in a network system
JP2017073777A (en) Extended security for direct link communication
WO2019041809A1 (en) Registration method and apparatus based on service-oriented architecture
WO2019041802A1 (en) Discovery method and apparatus based on service-oriented architecture
EP3395091A1 (en) Authentication and key agreement in communication network
US11212265B2 (en) Perfect forward secrecy (PFS) protected media access control security (MACSEC) key distribution
WO2009143765A1 (en) Key distributing method, public key of key distribution centre online updating method and device
WO2009143766A1 (en) Method, system for distributing key and method, system for online updating public key
Bilal et al. A secure key agreement protocol for dynamic group
US12081626B2 (en) Methods for seamless session transfer without re-keying
Naoui et al. Security analysis of existing IoT key management protocols
Daghighi et al. Toward secure group communication in wireless mobile environments: Issues, solutions, and challenges
US20230179400A1 (en) Key management method and communication apparatus
Yan et al. Secure pervasive social networking based on multi-dimensional trust levels
Daghighi et al. Key management paradigm for mobile secure group communications: Issues, solutions, and challenges
TWI801615B (en) Communication method between terminal and server, server communicating with terminal, and terminal communicating with server
Renugadevi et al. Key management schemes for secure group communication in wireless networks-a survey
del Valle et al. Overview the key management in ad hoc networks
Salma et al. Improved group key management region based cluster protocol in cloud
SuganyaDevi et al. Secure multicast key distribution for mobile ad hoc networks
WO2023160375A1 (en) Session key generation method, control device, and device clustering system
KR101507572B1 (en) ID-Based Key Authentication Method for Security of Sensor Data Communications
Nguyen et al. A three-way energy efficient authentication protocol using bluetooth low energy

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STPP Information on status: patent application and granting procedure in general

Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED

STCF Information on status: patent grant

Free format text: PATENTED CASE