CN110493272B - Communication method and communication system using multiple keys - Google Patents

Communication method and communication system using multiple keys Download PDF

Info

Publication number
CN110493272B
CN110493272B CN201910915161.6A CN201910915161A CN110493272B CN 110493272 B CN110493272 B CN 110493272B CN 201910915161 A CN201910915161 A CN 201910915161A CN 110493272 B CN110493272 B CN 110493272B
Authority
CN
China
Prior art keywords
key
client
server
authentication
data
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
Application number
CN201910915161.6A
Other languages
Chinese (zh)
Other versions
CN110493272A (en
Inventor
孙振宝
袁辉
孟宪伟
钱明
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.)
Hainan Yunhui Enterprise Management Center LP
Original Assignee
Beijing Fengxin Technology 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 Beijing Fengxin Technology Co ltd filed Critical Beijing Fengxin Technology Co ltd
Priority to CN201910915161.6A priority Critical patent/CN110493272B/en
Publication of CN110493272A publication Critical patent/CN110493272A/en
Application granted granted Critical
Publication of CN110493272B publication Critical patent/CN110493272B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • 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
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/3263—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 involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • 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/3271—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 challenge-response
    • H04L9/3273—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 challenge-response for mutual authentication
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • 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/3226—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 predetermined code, e.g. password, passphrase or PIN
    • 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/3236—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 cryptographic hash functions
    • H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC

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)
  • Storage Device Security (AREA)

Abstract

The present disclosure provides a communication method using multiple keys including a master key, an authentication key, and a transport key, wherein the master key is used to update the authentication key and the transport key. The communication method comprises the following steps: the client and the server negotiate to determine a master key; the client and the server respectively generate authentication information by using the master key for mutually verifying; and after the verification is passed, the client and the server negotiate to generate an authentication key and a transmission key. The present disclosure provides a multiple key technology, which has a more secure authentication, key distribution, key rotation, and key storage mechanism, and can better ensure communication security.

Description

Communication method and communication system using multiple keys
Technical Field
The present disclosure relates to the field of information security technologies, and in particular, to a communication method and a communication system using multiple keys.
Background
With the development of science and technology and the popularization of networks, the human society can not leave various network-based systems and applications regardless of life or work. In using these systems and applications, whether network communications are secure concerns for personal, business, government, etc. interests. At present, various systems and applications based on network communication often ignore or have simple encryption mechanisms and key management measures in the development process, so that data in the communication process is stolen.
The common practice in the prior art is to simply implement directly using HTTPS suite, or implement encryption of communication based on SSL/TLS protocol, including the following steps: step 0: one-way or two-way authentication; step 1: negotiating a symmetric encryption key used for data communication between two parties; step 2: the initiator encrypts data by using the encryption key; and step 3: transmitting through a communication protocol; and 4, step 4: the receiver decrypts the data using the encryption key; and 5: and (6) ending.
The encryption method has the disadvantages that a single key management framework is used in the communication process to ensure the communication safety, the authentication process is simple, and the safety is not high.
Disclosure of Invention
In view of this, according to a first aspect of the present disclosure, there is provided a communication method using multiple keys including a master key, an authentication key, and a transmission key, the communication method including:
the client and the server negotiate to determine a master key;
the client and the server respectively generate authentication information by using the master key for mutually verifying; and
after the verification is passed, the client and the server negotiate to generate an authentication key and a transmission key.
In one possible embodiment, the client and the server use the master key to generate authentication information respectively for verifying each other, specifically including
A client sends a key updating request to a server, wherein the key updating request at least comprises a client random number and client authentication information, and the client authentication information is generated by carrying out encryption operation on data at least comprising the client random number by using a master key;
the server side uses the master key to carry out encryption operation on the data at least comprising the client side random number, and compares the encryption operation result with the received client side authentication information for verification;
the server side sends a key updating response message to the client side, wherein the key updating response message at least comprises a server side random number and server side authentication information, and the server side authentication information is generated by carrying out encryption operation on data at least comprising the server side random number by using the master key; and
and the client uses the master key to carry out encryption operation on the data at least comprising the server random number, and compares the encryption operation result with the received server authentication information for verification.
In one possible embodiment, the client and the server negotiate to generate an authentication key and a transmission key, which may specifically include
Enabling the key updating request to comprise a transmission key random number, an authentication key random number and a client key negotiation algorithm parameter;
the server side calculates a first negotiation key by using the received client side key negotiation algorithm parameters, calculates a transmission key based on the first negotiation key and the transmission key random number, and calculates an authentication key based on the first negotiation key and the authentication key random number;
enabling server-side key agreement algorithm parameters to be included in the key update response message;
the client side calculates a second negotiation key by using the received server side key negotiation algorithm parameters, calculates a transmission key based on the second negotiation key and the transmission key random number, and calculates an authentication key based on the second negotiation key and the authentication key random number.
In one possible embodiment, the method may further include:
the client sends the authentication information encrypted by using the authentication key to the server; and
and the client sends the transmission data encrypted by using the transmission key to the server.
In a possible embodiment, the communication method may further include negotiating, via the registry, an initial master key, an authentication key, and a transport key between the client and the server, specifically including:
the server side registers the allowed client side information to a registration center, the registration information at least comprises a client side identification and verification data, and the verification data is generated by carrying out encryption operation on the data at least comprising the client side identification by using a personal identification number PIN;
the registration center returns an initial master key, an authentication key and a transmission key to the server side;
the server distributes the PIN to the client through a trusted channel;
the method comprises the steps that a client side initiates an activation request to a registration center, wherein the activation request at least comprises a client side identification and encrypted data, and the encrypted data is generated by carrying out encryption operation on data at least comprising the client side identification through a PIN;
the registration center verifies whether the client identifier and the encrypted data in the activation request are registered by the server, and if the client identifier and the encrypted data pass the verification, the initial master key, the authentication key and the transmission key are sent to the client.
In one possible embodiment, the server side and the client side can mutually verify with the registry by using a certification authority after connecting to the registry, and the two sides are ensured to be credible.
In one possible embodiment, the registration information may further include: identity information, expiration time, retry times, and an encrypted data ID, and the activation request of the registry authentication client further comprises the authentication expiration time and retry times, and the encrypted data ID is further sent to the client after the authentication is passed.
In one possible embodiment, the key update request of the client may further include an encrypted data ID, and the client authentication information is generated by performing an encryption operation on data including at least a client random number and the encrypted data ID using a master key.
In one possible embodiment, the method may further comprise encrypting the data packet using a segment key, which is a transmission key + a data packet number + a random number.
In one possible embodiment, the communication method is performed in any of the following cases: the client monitors that any key expires and actively triggers the key updating; when the server monitors that any key expires, the server sends a rejection message to trigger the client to update the key; after the number of the data packet exceeds a set value, the server side sends a rejection message to trigger the client side to update the key; the client authentication fails, the server side sends a rejection message to trigger the client to update the key; and satisfying the registry-defined rekeying rules.
In one possible embodiment, the master key, the authentication key, and the transport key are stored locally at the client and the server, and the method may include:
using a start-up database for storing data for decrypting a key metadata repository, and storing a master key, an authentication key, a transport key in the key metadata repository, wherein
The starting database is an encrypted database, and the key generation mode is as follows: PBKDF2(password, salt, repeat _ count, hash _ length), where password is built in the code, salt is stored in the boot file of the client, repeat _ count is the number of repeated iterations, hash _ length is hash length, the storage content of the startup database includes salt corresponding to the user Key, SHA of the user Key,
the Key metadata base is an encrypted database, and a Key generation mode of the Key metadata base is PBKDF2(password, salt, repeat _ count, hash _ length), wherein password is SHA of a user Key, salt is salt stored in a starting database, repeat _ count is the number of repeated iterations, and hash _ length is hash length.
According to a second aspect of the present disclosure, there is provided a communication system using multiple keys, the multiple keys including a master key, an authentication key and a transport key, the communication system comprising a client and a server, the client and the server being configured to perform the communication method according to the first aspect.
According to a third aspect of the present disclosure, there is provided a computer-readable storage medium comprising instructions that when executed implement the communication method of the first aspect.
The present disclosure provides a technique using a multiple key, which has a more secure authentication, key distribution, key rotation, and key storage mechanism, and can better ensure communication security.
Drawings
FIG. 1 shows a schematic block diagram of a multiple key communication system according to an embodiment of the invention;
FIG. 2 shows a schematic flow diagram of an initialization process for multiple key communication according to an embodiment of the invention;
FIG. 3 shows a schematic flow chart diagram of a rekeying process for multiple key communication, according to an embodiment of the present invention;
FIG. 4 shows a schematic diagram of multiple key storage according to an embodiment of the invention;
fig. 5 shows a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The words "a", "an" and "the" and the like as used herein are also intended to include the meanings of "a plurality" and "the" unless the context clearly dictates otherwise. Furthermore, the terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.
All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.
Fig. 1 shows a schematic block diagram of a multiple key communication system 100 according to an embodiment of the invention. The multiple key communication system 100 uses multiple keys during communication, thereby improving data security.
In particular, the multiple key communication system 100 provides the following keys to accomplish the secure communication process:
activation key (personal identification number PIN): the method is used for activating the client, and the main key Km, the authentication key Ka, the transmission key Kt and the like are obtained after activation.
Master key (Km): the master keys for exchanging Kt and Ka are only used for key rotation.
Authentication key (Ka): the key used for authentication is only used for identity authentication.
Transport key (Kt): the key used for data transmission is only used for data transmission.
Data segment key (Kd): optionally, the independent key used to encrypt each packet, Kd ═ Kt + packagenumber [ + nonce ], where the package number is the packet number and the nonce is a random number as an offset, is stored in the boot file of the communication party.
As shown in fig. 1, the multiple key communication system 100 includes a registry 110, a communication server 120 and its local storage 130, a communication client 140 and local information storage 150, an authentication CA or proxy 160, and an authentication CA or proxy 170.
The communication client 140 may be used as an initiator of network communications; the communication server side 120 may act as a recipient of network communications; the local storage 150 is used for storing relevant data needing persistence, which are used in the process of initiating the communication flow and the communication process by the client 140; the local storage 130 is used to store the relevant data needing to be persisted, which is used in the process of accepting the communication flow and the communication process by the server 120. The registry 110 is used for the server side 120 to register client side authorization information allowing a communication flow to be established therewith and issue information to the client side 140, including an activation Password (PIN) or the like mentioned below. The CA or proxy 160 is used by the server side 120 to verify digital certificates such as SSL/TLS certificates. The CA or proxy 170 is used for the client 140 to authenticate digital certificates such as SSL/TLS certificates.
Specifically, the registry 110 may operate on the internet or in the cloud for the communication server side 120 and the communication client side 140 to initiate connection, for example, distribute a plurality of keys (including a master key Km, an authentication key Ka, and a transmission key Kt, which are described in detail below) to the communication server side 120 and the communication client side, respectively. The registry 110 after initiating the connection is no longer involved in subsequent communications to the communication client 140 and the communication server 120.
The server side 120 may operate on the internet or in the cloud for providing the registry 110 with an identification of clients 140 with which to allow communication, as well as in encrypted communication with authenticated clients 140. According to the embodiment of the present invention, the server 120 and the client 140 encrypt the transmission authentication information and the payload data, and encrypt them by using the authentication key Ka and the transmission key Kt, respectively. The payload data may be, for example, application data, image data, voice data, text data, and the like.
The client 140 may be implemented as an Application (APP) installed at the mobile terminal or a communication program installed at the PC terminal, so that an end user can transmit various data with the server terminal 120 via the client 140. According to the embodiment of the present invention, the client 140 and the server 120 encrypt the transmission authentication information and the payload data, and encrypt them by using the authentication key Ka and the transmission key Kt, respectively. The payload data may be, for example, application data, image data, voice data, text data, and the like.
The local storage 130 is located at the server side 120, and stores the relevant data to be persisted used in the communication process and initiated by the server side 120. For example, local store 130 may store keys (Km, Ka, Kt) in encrypted form.
Similarly, local store 150 is located at client 140, and stores relevant data to be persisted used by client 130 in initiating communication procedures and communications. For example, local store 150 may store keys (Km, Ka, Kt) encrypted.
The CA or agents 160 and 170 may issue digital certificates for their users (e.g., server side 120 and client side 140) that serve to prove that the user listed in the certificate is in legitimate possession of the public key listed in the certificate. The CAs or agents 160 and 170 are used to verify, identify the identities of the server side 120 and the client side 140, and sign digital certificates to ensure ownership of the certificate holder's identity and public key.
Fig. 2 shows a schematic flow diagram of an initialization procedure 200 for multiple key communication according to an embodiment of the invention, comprising the steps of:
step 210: the server 120 establishes a Transport Layer Security (TLS) connection with the registry 110, and uses the CA or the agent 160 to perform certificate verification on the registry 110, and the registry 110 also performs certificate verification on the server 120 to ensure the trust of both parties.
Step 220: server side 120 registers client information with registry 110 that allows communications to be initiated thereto, which may include client unique identification ID, Principal identity information (e.g., username, mailbox address, telephone number), expiration time, number of retries, encrypted data ID, using the TLS connection established in step 210. Wherein, the encrypted data may be a encrypted value calculated by using a hash algorithm (such as HMAC-SHA 256); the specific encryption parameters are: the key is a PIN and the encrypted data may be a unique ID + identity information (e.g., username, mailbox address, phone number) + Salt for the client, where Salt is a random number that may be stored in the boot file.
Step 230: the registry 110 returns the success or failure of the registration result and the initial Km, Kt, Ka to the server 120 in step 220. The initial Km, Kt, Ka may be generated by the registry 110 using conventional key generation algorithms.
Step 240: the server side 120 distributes the PIN to the client 140 through other trusted distribution channels (e.g., mail, etc.).
Step 250: the client 140 establishes a TLS connection with the registry 110 and uses the CA or proxy 170 to perform certificate validation on the registry, and the registry 110 also performs certificate validation on the client 140 to ensure that both parties are trusted.
Step 260: the client 140 initiates an activation request to the registry 110 using the established TLS connection. The request message comprises a unique identification ID of the client, an IMEI (hardware equipment), a system model, Principal identity information (such as a user name, a mailbox address and a telephone number) and encrypted data. Similar to step 220, the encrypted data may be an encrypted value calculated using HMAC-SHA256, and the encryption parameters are: the key is a PIN, and the encrypted data is the unique identification ID of the client + identity information (such as a user name, a mailbox address and a telephone number) + Salt.
Step 270: registry 110 verifies whether the client unique identification ID, Principal identity information, encrypted data in the request of step 260 has been registered at the registry, or expired, or exceeded a number of times, per step 220. If the verification fails, the communication request is ended; if successful, the encrypted data ID and the initial Km, Kt, Ka registered in step 220 are returned.
It can be seen that the encrypted data ID and the initial Km, Kt, Ka received by the client 140 are the same as the server 120, i.e. the initialization process of the communication between the client 140 and the server 120 is completed. However, since the Km, Kt, and Ka are generated by the registry 110 and transmitted through the network, security is low, and thus, it is necessary to update the Km, Kt, and Ka to improve security.
Fig. 3 shows a schematic flow diagram of a rekeying process 300 for multiple key communication according to an embodiment of the present invention, including:
step 310: the client 140 can complete the Km negotiation process with the server 120 using the key negotiation algorithm and the authentication algorithm, that is, update Km. In this case, the client 140 and the server 120 may negotiate the key Km without sharing any secret (i.e., without transmitting the secret over the network). For example, an ECDH (elliptic curve Diffie-Hellman) key agreement algorithm and an ECDSA (elliptic curve digital signature algorithm) authentication algorithm may be used. These algorithms are known and will not be described in detail.
Step 320: the client 140 initiates an update request of Kt and Ka to the server 120. The update request may include: encrypted data ID, algorithm suite (cipher _ suite), nonce (client _ nonce) used for generating encrypted exchange protocol, nonce (Kt _ nonce) used for generating Kt exchange protocol, nonce (Ka _ nonce) used for generating Ka exchange protocol, ECDH algorithm parameter (client _ ECDH _ params), and client authentication information (client _ auth _ data). Wherein the client _ ecddh _ params comprises an ECDH negotiation algorithm name (algorithm _ name) and an ECDH Public Key (ecddh _ pub _ Key); the client _ auth _ data is encrypted using a hash algorithm, such as the HMACSHA256 algorithm, the key is Km, and the encrypted data is the encrypted data ID + client _ nonce _ + ecdh _ pub _ key.
Step 330: the server side 120 processes the update request of step 320. Correspondingly, the server side 120 uses HMACSHA256 algorithm to calculate the encrypted data ID + client _ nonce _ + ecdh _ pub _ key by using Km as a key for encryption, and compares the encrypted data ID + client _ nonce _ key with the client _ auth _ data transferred in step 320 for verification.
Step 340: after the verification is passed, a new negotiation key (new _ key) is calculated using the ECDH negotiation algorithm parameter (client _ ECDH _ params) provided in step 320, and the new negotiation key is used for calculating Kt and Ka. Specifically, Kt may be calculated using the algorithm PBKDF2_ HMAC _ SHA256 with the subscribed _ key and Kt _ nonce as parameters, for example; ka is calculated using the PBKDF2_ HMAC _ SHA256 algorithm with the new _ key, Ka _ nonce as parameters.
Step 350: the server side 120 returns a response message for the update request to the client side 140, which may include: encrypted data ID, result (result) (which is hint information indicating the results of steps 330 and 340, for example, whether hints Ka and Kt are generated at the server side 120), algorithm suite (cipher _ suite), client _ nonce provided in step 320, nonce used by the encryption switching protocol (server _ nonce), ECDH algorithm parameter (server _ ecddh _ params), and server authentication information (server _ auth _ data). Wherein, similar to step 320, server _ ecddh _ params includes ECDH negotiation algorithm name (algorithm _ name), ECDH Public Key (ecddh _ pub _ Key); the server _ auth _ data uses HMACSHA256 algorithm, the key is Km, and the data is encrypted data ID + server _ nonce + ecdh _ pub _ key.
Step 360: the client 140 processes the response information returned by the server 120. Specifically, using HMACSHA256 algorithm, encrypted data ID + server _ nonce _ + ecdh _ pub _ key is calculated using Km as a key for encryption, and compared with the server _ auth _ data passed in step 350 for verification.
Step 370: after the verification is passed, a new key (signed _ key) is calculated using the ECDH negotiation algorithm parameter (server _ ECDH _ params) provided in step 350, and is used to calculate Kt and Ka. Calculating Kt by using a PBKDF2_ HMAC _ SHA256 algorithm and using the subscribed _ key and the Kt _ nonce as parameters; ka is calculated using the PBKDF2_ HMAC _ SHA256 algorithm with the new _ key, Ka _ nonce as parameters. This is similar to step 340. Therefore, the key updating of the client 140 and the server 120 is realized, and the updated keys Km, Ka and Kt are respectively calculated and generated by the client 140 and the server 120 without network transmission, so that the security is better.
Step 380: the client 140 encrypts and transmits authentication information such as identity using Ka as a key in combination with an encryption algorithm (e.g., AES-GCM).
Step 390: the client 140 encrypts and transmits the data packets using Kt as a key in conjunction with an encryption algorithm (e.g., AES-GCM). Alternatively, data may be transmitted using a data segment key (Kd), i.e., an independent key that encrypts each packet, Kd ═ Kt + packet number [ + nonce ]. Here, the packet number is a packet number, and the nonce is an optional random number.
In addition to updating keys Km, Ka, Kt after the initialization process is complete, the present invention provides a key update mechanism to provide greater security. Specifically, the key update process 300 described above may be performed when any of the following conditions is satisfied:
the client 140 monitors the key expiration, actively triggering a key update.
The server side 120 monitors that the key expires, and the server side 120 sends a REJ message to trigger the client side 140 to update the key.
After the number of the data packet exceeds the set value, the server 120 sends a REJ message to trigger the client 140 to update the key.
The client 140 fails authentication, the server 120 sends a REJ message, triggering the client 140 to update the key.
Customized according to business rules, update rules can be defined and issued by registry 110.
In one embodiment, the expiration time of the key and the setting value of the data packet number may be set in the message sent by the server side 120 to the registry 110 in the above step 220, but is not limited thereto.
FIG. 4 shows a schematic diagram of local storage according to an embodiment of the invention. Referring to fig. 1 in combination, the server side 120 and the client side 140 have local storages 130 and 150, and the local storages 130 and 150 may store keys of Km, Ka, Kt, etc., and various data are required in generating and updating the keys. As shown in fig. 4, the local storage includes a startup database 410 and a key metadata repository 420, the startup database 410 stores data used to decrypt the key metadata repository 420, and the key metadata repository 420 stores data of Km, Ka, Kt, and the like.
And dynamically obtaining a private Key of the user password or the hardware PKI, encrypting and storing the private Key to form the user Key.
The startup database 410 may be an encrypted database with the key generation method: PBKDF2(password, salt, repeat _ count, HASH _ length), where password is built in the code, salt is stored in the boot file of the client or server, repeat _ count is the number of repeated iterations, and HASH _ length is the HASH length. The content of the startup database 410 includes the type of the user Key, the salt corresponding to the user Key, and the SHA of the user Key.
The Key metadata repository 420 is also an encryption database, and the Key generation method is as follows: PBKDF2(password, salt, repeat _ count, hash _ length), where password is SHA of user Key and salt is salt stored in the startup database. The content of the key metadata base comprises Km, Ka, Kt and other persistent data. It can be seen that the keys of Km, Ka, Kt and the like are locally stored through two-stage encryption, so that the security is better.
Fig. 5 shows a schematic structural diagram of an electronic device for implementing an embodiment of the invention. The electronic device is adapted to implement the client and server side shown in fig. 1. As shown in fig. 5, the electronic apparatus 500 includes a Central Processing Unit (CPU)501 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. In the RAM 503, various programs and data necessary for the operation of the electronic apparatus 500 are also stored. The CPU 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input/output (I/O) interface 505 is also connected to bus 504.
The following components are connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output portion 507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The driver 510 is also connected to the I/O interface 505 as necessary. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer-readable medium bearing instructions that, in such embodiments, may be downloaded and installed from a network via the communication section 509, and/or installed from the removable media 511. The various method steps described in the present invention are performed when the instructions are executed by a Central Processing Unit (CPU) 501.
In addition, the authentication algorithm, the key agreement algorithm and the encryption algorithm of both parties in the communication flow process are not limited to the content described in the patent, and may be replaced by more efficient and safer algorithms with the same security level, which may be software or hardware.
Although example embodiments have been described, it will be apparent to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the inventive concept. Accordingly, it should be understood that the above-described exemplary embodiments are not limiting, but illustrative.

Claims (17)

1. A communication method using multiple keys including a master key, an authentication key, and a transmission key, the communication method comprising:
the client and the server negotiate to determine a master key;
the client and the server respectively generate authentication information by using the master key for mutually verifying;
after the verification is passed, the client and the server negotiate to generate an authentication key and a transmission key;
the client and the server encrypt and transmit the authentication information by using the authentication key, encrypt and transmit the payload data by using the transmission key,
the communication method further includes negotiating an initial master key, an authentication key, and a transmission key between the client and the server via the registry, and specifically includes:
the server side registers the allowed client side information to a registration center, the registration information at least comprises a client side identification and verification data, and the verification data is generated by carrying out encryption operation on the data at least comprising the client side identification by using a personal identification number PIN;
the registration center returns an initial master key, an authentication key and a transmission key to the server side;
the server distributes the PIN to the client through a trusted channel;
the method comprises the steps that a client side initiates an activation request to a registration center, wherein the activation request at least comprises a client side identification and encrypted data, and the encrypted data is generated by carrying out encryption operation on data at least comprising the client side identification through a PIN;
the registration center verifies whether the client identifier and the encrypted data in the activation request are registered by the server, and if the client identifier and the encrypted data pass the verification, the initial master key, the authentication key and the transmission key are sent to the client.
2. The communication method according to claim 1, wherein the client and the server respectively generate authentication information using the master key for verifying each other, specifically comprising:
a client sends a key updating request to a server, wherein the key updating request at least comprises a client random number and client authentication information, and the client authentication information is generated by carrying out encryption operation on data at least comprising the client random number by using a master key;
the server side uses the master key to carry out encryption operation on the data at least comprising the client side random number, and compares the encryption operation result with the received client side authentication information for verification;
the server side sends a key updating response message to the client side, wherein the key updating response message at least comprises a server side random number and server side authentication information, and the server side authentication information is generated by carrying out encryption operation on data at least comprising the server side random number by using the master key; and
and the client uses the master key to carry out encryption operation on the data at least comprising the server random number, and compares the encryption operation result with the received server authentication information for verification.
3. The communication method according to claim 2, wherein the negotiating between the client and the server for generating the authentication key and the transmission key specifically includes:
the key updating request comprises a transmission key random number, an authentication key random number and a client key negotiation algorithm parameter;
the server side calculates a first negotiation key by using the received client side key negotiation algorithm parameters, calculates a transmission key based on the first negotiation key and the transmission key random number, and calculates an authentication key based on the first negotiation key and the authentication key random number;
the key updating response message comprises server-side key negotiation algorithm parameters;
the client side calculates a second negotiation key by using the received server side key negotiation algorithm parameters, calculates a transmission key based on the second negotiation key and the transmission key random number, and calculates an authentication key based on the second negotiation key and the authentication key random number.
4. The communication method according to claim 1, wherein the server and the client verify with the registry using a certification authority after connecting to the registry, and ensure the authenticity of both parties.
5. The communication method of claim 1, wherein the registration information further comprises: identity information, expiration time, retry times, and an encrypted data ID, and the activation request of the registry authentication client further comprises the authentication expiration time and retry times, and the encrypted data ID is further sent to the client after the authentication is passed.
6. The communication method according to claim 2, wherein the key update request of the client further includes an encrypted data ID, and the client authentication information is generated by performing an encryption operation on data including at least a client random number and the encrypted data ID using a master key.
7. The communication method according to claim 2, wherein the communication method is performed in any of the following cases:
the client monitors that any key expires and actively triggers the key updating;
when the server monitors that any key expires, the server sends a rejection message to trigger the client to update the key;
after the number of the data packet exceeds a set value, the server side sends a rejection message to trigger the client side to update the key;
the client authentication fails, the server side sends a rejection message to trigger the client to update the key; and
satisfying the key update rule defined by the registration center.
8. The communication method of claim 1, the method further comprising:
the master key, the authentication key and the transmission key are stored locally at the client and the server;
using the start-up database to store data for decrypting the key metadata repository, and storing the master key, the authentication key, the transport key in the key metadata repository, wherein,
the starting database is an encrypted database, and the key generation mode is as follows: PBKDF2(password, salt, repeat _ count, hash _ length), where password is built in the code, salt is stored in the boot file of the client, repeat _ count is the number of repeated iterations, hash _ length is hash length, the storage content of the startup database includes salt corresponding to the user Key, SHA of the user Key,
the Key metadata base is an encrypted database, and a Key generation mode of the Key metadata base is PBKDF2(password, salt, repeat _ count, hash _ length), wherein password is SHA of a user Key, salt is salt stored in a starting database, repeat _ count is the number of repeated iterations, and hash _ length is hash length.
9. A communication system using multiple keys including a master key, an authentication key and a transport key, the communication system comprising a client, a server and a registry, the client and the server being configured to
The client and the server negotiate to determine a master key;
the client and the server respectively generate authentication information by using a master key for mutually verifying;
after the verification is passed, the client and the server negotiate to generate an authentication key and a transmission key;
the client and the server encrypt and transmit authentication information using an authentication key, encrypt and transmit payload data using a transmission key,
the method includes that a client and a server are configured to negotiate an initial master key, an authentication key and a transmission key between the client and the server via a registration center, and specifically includes:
the server side registers the allowed client side information to a registration center, the registration information at least comprises a client side identification and verification data, and the verification data is generated by carrying out encryption operation on the data at least comprising the client side identification by using a personal identification number PIN;
the registration center returns an initial master key, an authentication key and a transmission key to the server side;
the server distributes the PIN to the client through a trusted channel;
the method comprises the steps that a client side initiates an activation request to a registration center, wherein the activation request at least comprises a client side identification and encrypted data, and the encrypted data is generated by carrying out encryption operation on data at least comprising the client side identification through a PIN;
the registration center verifies whether the client identifier and the encrypted data in the activation request are registered by the server, and if the client identifier and the encrypted data pass the verification, the initial master key, the authentication key and the transmission key are sent to the client.
10. The communication system of claim 9, wherein the client and the server respectively generate authentication information using the master key for verifying each other, specifically comprising:
a client sends a key updating request to a server, wherein the key updating request at least comprises a client random number and client authentication information, and the client authentication information is generated by carrying out encryption operation on data at least comprising the client random number by using a master key;
the server side uses the master key to carry out encryption operation on the data at least comprising the client side random number, and compares the encryption operation result with the received client side authentication information for verification;
the server side sends a key updating response message to the client side, wherein the key updating response message at least comprises a server side random number and server side authentication information, and the server side authentication information is generated by carrying out encryption operation on data at least comprising the server side random number by using the master key; and
and the client uses the master key to carry out encryption operation on the data at least comprising the server random number, and compares the encryption operation result with the received server authentication information for verification.
11. The communication system of claim 10, wherein the client and the server negotiate to generate an authentication key and a transmission key, and specifically comprises:
the key updating request comprises a transmission key random number, an authentication key random number and a client key negotiation algorithm parameter;
the server side calculates a first negotiation key by using the received client side key negotiation algorithm parameters, calculates a transmission key based on the first negotiation key and the transmission key random number, and calculates an authentication key based on the first negotiation key and the authentication key random number;
the key updating response message comprises server-side key negotiation algorithm parameters;
the client side calculates a second negotiation key by using the received server side key negotiation algorithm parameters, calculates a transmission key based on the second negotiation key and the transmission key random number, and calculates an authentication key based on the second negotiation key and the authentication key random number.
12. The communication system of claim 9, wherein the server and the client, after connecting to the registry, mutually authenticate with the registry using a certification authority to ensure the authenticity of both parties.
13. The communication system of claim 9, wherein the registration information further comprises: identity information, expiration time, retry times, and an encrypted data ID, and the activation request of the registry authentication client further comprises the authentication expiration time and retry times, and the encrypted data ID is further sent to the client after the authentication is passed.
14. The communication system according to claim 10, wherein the key update request of the client further includes an encrypted data ID, and the client authentication information is generated by encrypting data including at least a client random number and the encrypted data ID using a master key.
15. The communication system of claim 10, wherein the communication system is adapted for any of:
the client monitors that any key expires and actively triggers the key updating;
when the server monitors that any key expires, the server sends a rejection message to trigger the client to update the key;
after the number of the data packet exceeds a set value, the server side sends a rejection message to trigger the client side to update the key;
the client authentication fails, the server side sends a rejection message to trigger the client to update the key; and
satisfying the key update rule defined by the registration center.
16. The communication system of claim 9, wherein the master key, the authentication key, and the transport key are stored locally at the client and the server;
the communication system comprises a start-up database storing data for decrypting a key metadata database storing master keys, authentication keys, transport keys, and a key metadata database storing master keys, authentication keys, transport keys,
the starting database is an encrypted database, and the key generation mode is as follows: PBKDF2(password, salt, repeat _ count, hash _ length), where password is built in the code, salt is stored in the boot file of the client, repeat _ count is the number of repeated iterations, hash _ length is hash length, the storage content of the startup database includes salt corresponding to the user Key, SHA of the user Key,
the Key metadata base is an encrypted database, and a Key generation mode of the Key metadata base is PBKDF2(password, salt, repeat _ count, hash _ length), wherein password is SHA of a user Key, salt is salt stored in a starting database, repeat _ count is the number of repeated iterations, and hash _ length is hash length.
17. A computer-readable storage medium storing instructions which, when executed by a processor, implement the communication method of any one of claims 1 to 8.
CN201910915161.6A 2019-09-25 2019-09-25 Communication method and communication system using multiple keys Active CN110493272B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910915161.6A CN110493272B (en) 2019-09-25 2019-09-25 Communication method and communication system using multiple keys

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910915161.6A CN110493272B (en) 2019-09-25 2019-09-25 Communication method and communication system using multiple keys

Publications (2)

Publication Number Publication Date
CN110493272A CN110493272A (en) 2019-11-22
CN110493272B true CN110493272B (en) 2020-10-02

Family

ID=68544362

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910915161.6A Active CN110493272B (en) 2019-09-25 2019-09-25 Communication method and communication system using multiple keys

Country Status (1)

Country Link
CN (1) CN110493272B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112910627B (en) * 2019-12-03 2023-02-10 华为技术有限公司 Key updating method, data decryption method and digital signature verification method
CN112995109B (en) * 2019-12-17 2023-05-26 阿里巴巴集团控股有限公司 Data encryption system, data encryption method, data processing device and electronic equipment
CN112134849B (en) * 2020-08-28 2024-02-20 国电南瑞科技股份有限公司 Dynamic trusted encryption communication method and system for intelligent substation
CN112597501A (en) * 2020-12-16 2021-04-02 山东可信云信息技术研究院 Data protection method and system under trusted cloud environment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945114A (en) * 2010-09-20 2011-01-12 西安电子科技大学 Identity authentication method based on fuzzy vault and digital certificate
CN102571702A (en) * 2010-12-22 2012-07-11 中兴通讯股份有限公司 Key generation method, system and equipment in Internet of things
CN107453880A (en) * 2017-08-28 2017-12-08 国家康复辅具研究中心 A kind of cloud secure storage method of data and system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047493A (en) * 2006-06-02 2007-10-03 华为技术有限公司 Method and system for acquiring simple network management protocol management key
CN102036242B (en) * 2009-09-29 2014-11-05 中兴通讯股份有限公司 Access authentication method and system in mobile communication network
JP2014103590A (en) * 2012-11-21 2014-06-05 Toshiba Corp Communication device, communication method, system, and program
CN106714156A (en) * 2015-07-13 2017-05-24 中兴通讯股份有限公司 Wireless access point and management platform authentication method and device
US20170244692A1 (en) * 2016-02-24 2017-08-24 Gemalto Inc. Authentication of a user using a security device
CN105792193B (en) * 2016-02-26 2019-02-26 东南大学常州研究院 Mobile terminal sound End to End Encryption method based on iOS operating system
CN108965338B (en) * 2018-09-21 2021-03-23 杭州师范大学 Three-factor identity authentication and key agreement method under multi-server environment
CN109639412A (en) * 2018-12-05 2019-04-16 成都卫士通信息产业股份有限公司 A kind of communication means, system and electronic equipment and storage medium
CN109818749B (en) * 2019-01-11 2021-11-16 如般量子科技有限公司 Quantum computation resistant point-to-point message transmission method and system based on symmetric key pool

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101945114A (en) * 2010-09-20 2011-01-12 西安电子科技大学 Identity authentication method based on fuzzy vault and digital certificate
CN102571702A (en) * 2010-12-22 2012-07-11 中兴通讯股份有限公司 Key generation method, system and equipment in Internet of things
CN107453880A (en) * 2017-08-28 2017-12-08 国家康复辅具研究中心 A kind of cloud secure storage method of data and system

Also Published As

Publication number Publication date
CN110493272A (en) 2019-11-22

Similar Documents

Publication Publication Date Title
CN110380852B (en) Bidirectional authentication method and communication system
CN107948189B (en) Asymmetric password identity authentication method and device, computer equipment and storage medium
CN110493272B (en) Communication method and communication system using multiple keys
US9137017B2 (en) Key recovery mechanism
CN108599925B (en) Improved AKA identity authentication system and method based on quantum communication network
US11044082B2 (en) Authenticating secure channel establishment messages based on shared-secret
CN111756529B (en) Quantum session key distribution method and system
WO2010078755A1 (en) Method and system for transmitting electronic mail, wlan authentication and privacy infrastructure (wapi) terminal thereof
JP7292263B2 (en) Method and apparatus for managing digital certificates
CN110635901B (en) Local Bluetooth dynamic authentication method and system for Internet of things equipment
KR20110083886A (en) Apparatus and method for other portable terminal authentication in portable terminal
WO2020020007A1 (en) Network access method and device, terminal, base station, and readable storage medium
JP2016514913A (en) Method and apparatus for establishing a session key
CN115766066A (en) Data transmission method, device, safety communication system and storage medium
CN104243452A (en) Method and system for cloud computing access control
CN111698264A (en) Method and apparatus for maintaining user authentication sessions
US20240113885A1 (en) Hub-based token generation and endpoint selection for secure channel establishment
WO2016134631A1 (en) Processing method for openflow message, and network element
EP3624394B1 (en) Establishing a protected communication channel through a ttp
CN110417722B (en) Business data communication method, communication equipment and storage medium
KR100456624B1 (en) Authentication and key agreement scheme for mobile network
WO2022135394A1 (en) Identity authentication method and apparatus, storage medium, program, and program product
CN115766119A (en) Communication method, communication apparatus, communication system, and storage medium
CN113918971A (en) Block chain based message transmission method, device, equipment and readable storage medium
CN117729056B (en) Equipment identity authentication method and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20201118

Address after: Room 02-a078, 2 / F, block B, No.22, information road, Haidian District, Beijing 100085

Patentee after: Information technology (Beijing) Co.,Ltd.

Address before: No. a-2012-061, 17th floor, building 1, No. 18, Zhongguancun East Road, Haidian District, Beijing 100000

Patentee before: Beijing Fengxin Technology Co.,Ltd.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20240311

Address after: 570100, No. 2 Shimao East Road, Longhua District, Haikou City, Hainan Province, China. Building 804, Shimao Yayuan F, Zhongchuang Space-473

Patentee after: Hainan Yunhui Enterprise Management Center (Limited Partnership)

Country or region after: China

Address before: Room 02-A078, 2nd Floor, Building B, No. 22 Information Road, Haidian District, Beijing, 100085

Patentee before: Information technology (Beijing) Co.,Ltd.

Country or region before: China

TR01 Transfer of patent right