WO2017200791A1 - Procédé et système de transmission sécurisée de données - Google Patents

Procédé et système de transmission sécurisée de données Download PDF

Info

Publication number
WO2017200791A1
WO2017200791A1 PCT/US2017/031606 US2017031606W WO2017200791A1 WO 2017200791 A1 WO2017200791 A1 WO 2017200791A1 US 2017031606 W US2017031606 W US 2017031606W WO 2017200791 A1 WO2017200791 A1 WO 2017200791A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
server
key
dynamic message
hash function
Prior art date
Application number
PCT/US2017/031606
Other languages
English (en)
Inventor
Yingfang FU
Shuanlin LIU
Original Assignee
Alibaba Group Holding Limited
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
Priority claimed from CN201610339148.7A external-priority patent/CN107404461B/zh
Application filed by Alibaba Group Holding Limited filed Critical Alibaba Group Holding Limited
Priority to KR1020187033013A priority Critical patent/KR20190005878A/ko
Priority to JP2018555211A priority patent/JP2019517184A/ja
Priority to EP17799879.6A priority patent/EP3459202A4/fr
Priority to SG11201808991WA priority patent/SG11201808991WA/en
Publication of WO2017200791A1 publication Critical patent/WO2017200791A1/fr

Links

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/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/0852—Quantum cryptography

Definitions

  • This disclosure is generally related to secure data transmission technologies. More specifically, this disclosure is related to a quantum state based secure data transmission system.
  • Related Art
  • Asymmetric encryption also called public key encryption
  • Public key encryption does not have the key distribution problem, because different keys (public and private) are used to encrypt and decrypt data.
  • Public key encryptions are often used for secure exchange of symmetric encryption keys.
  • Public key cryptography systems are considered more secure, because they rely on cryptographic algorithms based on mathematical problems that currently admit no efficient solution, particularly those inherent in certain integer factorization, discrete logarithm, and elliptic curve relationships.
  • HTTPS Hypertext Transfer Protocol Secure
  • the client may generate a pre-master key, encrypt the pre-master key using the server's public key, and send the encrypted pre-master key to the server.
  • Both the server and client can then generate a master key (also known as the session key) from the pre-master key.
  • the session key can then be used to encrypt data flows between the client and server.
  • the current key-distribution process can be time-consuming due to the complexity of the involved asymmetric encryption algorithm.
  • HTTPS Transport Layer Security
  • SSL Secure Socket Layer
  • One embodiment described herein provides a system and method for establishing a secure communication channel between a client and a server.
  • the client generates a service request comprising a first dynamic message, transmits the first service request to the server, which authenticates the client based on the first dynamic message, and receives a second dynamic message from the server in response to the first dynamic message.
  • the client authenticates the server based on the second dynamic message, and negotiates, via a quantum- key-distribution process, a secret key shared between the client and the server.
  • the client and server then establish a secure communication channel based on at least a first portion of the secret key.
  • establishing the secure communication channel comprises using the first portion of the secret key as a symmetric encryption/decryption key for data transmission.
  • the first dynamic message includes at least one of: identification (ID) of the client, a first hash function calculated based on the client's ID and a client- specific key previously shared between the client and the server, and a random number.
  • the client encrypts the random number using the client-specific key.
  • the second dynamic message includes a second hash function of the random number or a concatenation of the server' s ID and the random number.
  • authenticating the server involves calculating a third hash function based at least on the random number and comparing the calculated third hash function with the second hash function included in the second dynamic message.
  • the client further extracts a second portion of the secret key and updates the client- specific key using a second portion of the secret key.
  • One embodiment described herein provides a system and method for establishing a secure communication channel between a client and a server.
  • the server receives a service request comprising a first dynamic message from the client, and authenticates the client based on the first dynamic message.
  • the server generates a second dynamic message based on information included in the first dynamic message and sends the second dynamic message to the client, which authenticates the server based on the second dynamic message.
  • the server negotiates, via a quantum-key-distribution process, a secret key shared between the client and the server.
  • the client and server then establish a secure communication channel by using at least a first portion of the secret key as a symmetric encryption/decryption key for data transmission.
  • FIG. 1 illustrates a time-state diagram describing the process of establishing a conventional HTTPS session.
  • FIG. 2 presents a time-state diagram describing the process of system
  • FIG. 3A presents a time-state diagram describing the process of authenticating a server by a client, according to one embodiment of the present invention.
  • FIG. 3B presents a time-state diagram describing the process of authenticating a client by a server, according to one embodiment of the present invention.
  • FIG. 3C presents a time-state diagram describing the process of mutual authentication between a client and a server, according to one embodiment of the present invention.
  • FIG. 4 presents a flow chart describing the process of establishing a secure communication channel between a server and a client, according to one embodiment of the present invention.
  • FIG. 5 presents a diagram illustrating an exemplary process for negotiating a secret string between the client and the server, in accordance with one embodiment of the present invention.
  • FIG. 6 presents a diagram illustrating an exemplary client device, in accordance with an embodiment of the present invention.
  • FIG. 7 presents a diagram illustrating an exemplary server device, in accordance with one embodiment of the present invention.
  • FIG. 8 illustrates an exemplary client-server network environment for
  • FIG. 9 conceptually illustrates an electronic system with which some
  • Table 1 illustrates two exemplary mechanical quantity measurement schemes based on using two different sets of quantum states, in accordance with one embodiment described herein.
  • Table ⁇ illustrates the mapping between client IDs and client- specific keys, in accordance with one embodiment described herein.
  • Regular optical signals can be used in traditional communication systems where laws of classical mechanics apply, whereas quantum optical signals can be used in quantum communication systems where laws of quantum mechanics apply.
  • a quantum optical signal typically can consist of weak coherent pulses, ideally one photon in each pulse.
  • an optical pulse in a regular optical signal often has many more photons and, hence, has much higher intensity.
  • a regular optical signal can also referred to as a high-intensity optical signal, due to its higher intensity compared to a quantum optical signal.
  • quantum communication information is transmitted based on quantum states, and the data security can be guaranteed by the laws of quantum mechanics, such as the uncertainty principle, the principle of quantum state measurement, and the no-cloning theorem. It has been shown that quantum cryptography can achieve unconditional data transmission security and detectability against eavesdroppers.
  • Various embodiments disclosed herein provide a system and method for establishing a secure communication channel between a server and a client. More specifically, to reduce the amount of computation needed for asymmetric key exchange and to enhance security, the server and client can authenticate each other using a hash-based technique (e.g., by calculating the hash value of a client- or node-specific key known only to the server and client). After authentication, the server and client can exchange a symmetric session key using a quantum key-exchange process. The symmetric session key can then be used for establishing a secure channel between the client and server.
  • a hash-based technique e.g., by calculating the hash value of a client- or node-specific key known only to the server and client.
  • the server and client can exchange a symmetric session key using a quantum key-exchange process.
  • the symmetric session key can then be used for establishing a secure channel between the client and server.
  • information exchanged during the quantum key-exchange process can also include a new node-specific key that can later be used to authenticate the client and the server.
  • quantum physics some physical quantities of the microscopic world cannot continuously change but take on certain discrete values, and the difference between two adjacent discrete values is referred to as a "quantum," e.g., a photon is a single quantum of light.
  • a quantum quantity can also take on a mixed state obtained by the superposition of the two basic states with coefficients ⁇ 3 ⁇ 4 ⁇ , respectively.
  • a mixed state can be expressed as:
  • _ ) ⁇ can be generated by superpositioning the basic quantum states IO>/ ⁇ — » and ll>/ ⁇ using the following formulae:
  • states I0> and ll> are orthogonal to each other while states l+> and l-> are orthogonal to each other.
  • each mechanical quantity can be expressed by a Hermitian operator (or Hermitian matrix).
  • the measurement results correspond to the eigenvalues (or the “characteristic values") of the Hermitian operator for this mechanical quantity.
  • the quantum state being measured collapses to the eigenstates (or the
  • eigenvectors corresponding to the obtained eigenvalues.
  • Table 1 illustrates two exemplary mechanical quantity measurement schemes based on using two different sets of quantum states in accordance with one embodiment described herein.
  • FIG. 1 illustrates a time-state diagram describing the process of establishing a conventional HTTPS session.
  • a client 102 sends an HTTPS request to a server 104 (operation 106).
  • a user may type in the address bar of the web browser the address of an HTTPS website.
  • the HTTPS website transmits a digital certification (e.g., a Secure Sockets Layer (SSL) certificate) to the web browser of client 102 (operation 108).
  • SSL certification can be one obtained from a trust authority or one generated by server 104.
  • Self- generated or self- signed digital certificate may need to be verified by client 102 in order for the process to continue.
  • the digital certificate can include a public key needed to begin the secure session.
  • the digital certificate may also include other useful information, including the name of the certificate authority, expiration date, etc.
  • the public key and its corresponding private key can be generated using various asymmetric algorithms, such as RSA.
  • client 102 Upon receiving the digital certification, client 102 verifies the digital certificate
  • client 102 may display an error message in its browser. If the digital certificate is valid client 102 can generate a random key (e.g., a random number) and encrypt the generated random key using the public key included in the digital certificate (operation 112). Client 102 then sends the encrypted random key to server 104 (operation 114), which can then obtain the random key using its private key (operation 116). The random key becomes the shared secrete between client 102 and server 104. The client and server can then communicate with each other using the random key (operation 118). For example, the server may send encrypted content using the random key, and the client can decrypt the content using the same random key.
  • a random key e.g., a random number
  • the current HTTPS technology has certain security deficiencies. For example, it can be vulnerable to the man-in-the-middle ( ⁇ ) attacks. Note that, when the digital certificate is not verified, the client browser often displays a warring message and let the user to choose whether to continue. Many users ignore the warning and suffer the SSL man-in-the- middle attacks. Moreover, although the exchange of the shared secret (i.e., the random key) between the client and server is protected by the public key encryption mechanism, advancement made in cloud computing or quantum computing has made classical cryptograph schemes less secure. For example, Shor's algorithm has shown the ability to break public -key cryptography schemes (e.g., RSA), and Graver's algorithm has significantly reduces the amount of
  • the disclosed secure data transmission technique is based on the following assumptions. It is assumed that the classical channel meets the conventional requirements of a secure channel, such as an HTTPS channel. For example, it can be assumed that, before starting data communication, each of the client and the server has its own public and private key pairs and an associated identity certificate.
  • the client can obtain a node-specific key from the server.
  • This process can involve asymmetric encryption/decryption.
  • client A may send a request carrying its public key certificate to the server.
  • the server can verify the certificate and transmit a key (which can be encrypted using the public key of client A) that is specifically assigned to client A back to client A.
  • client B may send a request carrying its public key certificate to the server to obtain a key that is specifically assigned to client B.
  • the server can maintain a mapping between the clients and the client- or node-specific key.
  • the client- or node-specific key can be dynamically updated. For example, the server may periodically or at random intervals send updated client- specific keys to clients.
  • a client may also periodically or at random intervals request the updated client- specific key.
  • each of the communication parties installs a lightweight quantum state basis library.
  • the quantum-state-basis library stores a plurality of quantum state bases, each of which including orthogonal quantum states, which can be labeled for differentiation. For example, if we label the orthogonal basis ⁇ I0>, ll> ⁇ as "1,” then state I0> can be labeled as 1.1, and state ll> as 1.2; then we label the orthogonal basis ⁇ l+>, l-> ⁇ as "2,” then state l+> can be labeled as 2.1, and state l-> as 2.2, and so on.
  • each quantum state basis in the quantum-state-basis library can be identified by a unique quantum state basis identifier (QID).
  • QID quantum state basis identifier
  • the quantum states can be periodically relabeled in a synchronized manner on both the client and server sides based on a predetermined relabeling scheme. For example, if x represents the current identifier of a given quantum state, while y represents the identifier of the same quantum state for the next service request, then y can be deduced from x using some deduction rules.
  • the client in light of the disclosed dynamic -pas sword authentication technique, the client can use the quantum states of a quantum state basis as the measurement basis for measuring the dynamic information transmitted by the server; while the server can use the same quantum state basis to encode the dynamic information.
  • the disclosed secure data transmission technique can include certain security measures used by classical HTTPS communication, such as an encrypted secure communication channel.
  • certain security measures used by classical HTTPS communication such as an encrypted secure communication channel.
  • public key certificate instead of using public key certificate for
  • the authentication process now involves a hash-based authentication process, and the key exchange involves a quantum key-exchange process.
  • the key exchange involves a quantum key-exchange process.
  • subsequent communications between the server and the client do not involve any asymmetric algorithms.
  • FIG. 2 presents a time-state diagram describing the process of system
  • a client 202 sends a client- initialization request to a server 204 (operation 206).
  • the request includes a digital certificate that can be used to authenticate client 202.
  • the client's digital certificate can also include a public key of client 202.
  • server 204 Upon receiving the client- initialization request, server 204 verifies the client's digital certificate (operation 208). If the client's digital certificate is invalid, server 204 may send an error message or a warning to client 202, and discards the request. If the client's digital certificate is valid, server 204 can respond to the client-initialization request by sending a string encrypted using the public key of client 202 (operation 210). This string will later serve as a client- specific key of client 202. In other words, server 204 will not send the same string to any other client. Server 204 can store the mapping between client 202 and its client- specific key in a key database (operation 212). For example, the key database can include a table indexed by the identification of each client (CID), as shown below.
  • CID identification of each client
  • server 204 can also include in its response to client 202 its own digital certificate.
  • client 202 Upon receiving the response from server 204, client 202 verifies the server's digital certificate (operation 214). If the server's digital certificate is invalid, client 202 may halt any further communication. If the server's digital certificate is valid, client 202 can decrypt, using its corresponding private key, the client- specific key included in the response from server 204 (operation 216). Client 202 can then store the client- specific key and completes the system initialization (operation 218).
  • FIG. 3A presents a time-state diagram describing the process of authenticating a server by a client, according to one embodiment of the present invention.
  • a client 302 can send an authentication request that includes the identification (ID) of client 302 in plain text, expressed as ID_C, to a server 304 (operation 306).
  • ID_C the identification of client 302 in plain text
  • server 304 Upon receiving the authentication request, server 304 can perform a lookup in its key database to obtain the key that is specifically assigned to client 302, expressed as IDC_Key (operation 308), and calculate its hash function (e.g., a cryptographic hash function), hash (IDC_Key) (operation 310). Note that the way the hash function is calculated has been previously agreed on between server 304 and client 302. Server 304 can then send the calculated hash function back to client 302 as a response to the
  • client 302 can calculate the same hash function of its locally stored client-specific key (operation 314) and compares its calculated hash function with the hash function received from server 304 (operation 316). If they match, client 302 can successfully authenticate server 304. Otherwise, authentication of server 304 is failed. Client 302 can optionally send the authentication result back to server 304
  • server 304 can also send additional information that can be used by client 302 for authentication of server 304.
  • the server may also send its own identification (ID_S) along with the hash function of the client- specific key.
  • the server can calculate the hash function of (ID_S, IDC_Key), which is the concatenation of the two strings, and send ⁇ ID_S, hash (ID_S, IDC_Key) ⁇ to the client.
  • the client can then use the received ID_S and its locally stored IDC_Key to calculate hash (ID_S, IDC_Key) and compare its calculated hash function with the one sent by the server.
  • client 302 can calculate a hash function based on the client- specific key and optionally the client ID (operation 322).
  • the hash function can be hash (IDC_Key) or hash (ID_C, IDC_Key).
  • Client 302 can send a message containing its client ID in plain text and the hash function to server 304 (operation 324).
  • the message can be ⁇ ID_C, hash (ID_C, IDC_Key) ⁇ .
  • server 304 can perform a lookup in its key database the client- specific key assigned to client 302 based on the received client ID (ID_C) (operation 326), and calculate a hash function based on the lookup result and optionally the received client ID (operation 328). Depending on the agreement between client 302 and server 304, server 304 may calculate hash (ID_C, IDC_Key) or hash(IDC_Key). Server 304 can then compare its calculated hash function to the hash function received from client 302 (operation 330). If they match, server 304 can successfully authenticate client 302. Otherwise,
  • Server 304 can optionally send the authentication result back to client 302 (operation 332).
  • FIG. 3C presents a time-state diagram describing the process of mutual authentication between a client and a server, according to one embodiment of the present invention.
  • client 302 can calculate a hash function based on the client ID (ID_C) and the client- specific key (IDC_Key) (operation 342). Client 302 can also generate a dynamic string (r), and encrypt the dynamic string using the client- specific key (operation 344).
  • the encrypted message can be written as: Enincjc ey (r).
  • the dynamic string r can be generated randomly or using a predetermined algorithm. Because r changes for each authentication operation, playback attacks can be prevented.
  • Client 302 can send the client ID in plain text, the hash function, and the encrypted dynamic string to server 304 (operation 346). For example, client 302 can send a dynamic message ⁇ ID_C, hash (ID_C, IDC_Key), Enincjc ey (r) ⁇ to server 304.
  • server 304 can perform a lookup in its key database of the client-specific key assigned to client 302 based on the received client ID (ID_C) (operation 348), and calculate a hash function based on the lookup result and optionally the received client ID (operation 350). Server 304 can then compare its calculated hash function to the hash function received from client 302 (operation 352). If they match, server 304 can successfully authenticate client 302; otherwise, authentication of client 302 fails.
  • ID_C client ID
  • server 304 can perform a lookup in its key database of the client- specific key assigned to client 302 based on the received client ID (ID_C) (operation 348), and calculate a hash function based on the lookup result and optionally the received client ID (operation 350). Server 304 can then compare its calculated hash function to the hash function received from client 302 (operation 352). If they match, server 304 can successfully authenticate client 302; otherwise, authentication of client 302 fails.
  • Server 304 can obtain the dynamic string by decrypting the received encrypted message, using IDC_key, Eni DC _ Key (r) (operation 354), and generate a hash function based on the server's identification (ID_S) and the dynamic string (operation 356).
  • the hash function can be generated as hash (ID_S, r), where (ID_S, f) is the concatenation of the server's ID and the dynamic string.
  • Server 304 can then send the server's identification in plain text and the hash function to client 302 (operation 358).
  • server 304 can send a dynamic message ⁇ ID_S, hash (ID_S, r) ⁇ to client 302.
  • server 304 may simply send ⁇ hash(r) ⁇ to client 302.
  • client 302 Upon receiving the message from server 304, client 302 can calculate, based on the received server ID and the previously generated dynamic string r, a hash function (e.g., hash (ID_S, r)) (operation 360), and compare the calculated hash function with the hash function received from client 302 (operation 362). If they match, client 302 can successfully authenticate server 304, thus completing the mutual authentication. Otherwise, authentication of server 304 is failed. In some embodiments, client 302 can optionally send the authentication result to server 304 (operation 364).
  • a hash function e.g., hash (ID_S, r)
  • server 304 may generate the hash function based on ID_S and a value that is derived from the dynamic string r. For example, server 304 can generate hash (ID_S, r + n), where n is a dynamic seed value that can be synchronously updated between client 302 and 304. In other words, n is a secret shared between client 302 and server 304. For example, n can be the number of exchanges between client 302 and server 304. More details about the synchronous updating of seed value n can be described later.
  • server 304 sends hash(ID_S, r + n) to client 302, client 302 will need to use its locally stored dynamic r string and seed value n to generate hash(ID_S, r + n), and compare the generated hash function with the received hash function.
  • the new authentication scheme Compared with conventional authentication based on the exchange of the public key certificates, the new authentication scheme, such as the ones shown in FIGs. 3A-3C, no longer requires public key certificates. If the server can send the client- specific keys to clients via a separate secure channel, neither the server nor the client needs to obtain and/or maintain a public key certificate. Considering the cost and complexity involved in obtaining digital certificates from a certificate authority (CA), this new authentication scheme can significantly reduce cost without compromising security.
  • CA certificate authority
  • the client and the server can exchange a symmetric key that can be used for the secure
  • FIG. 4 presents a flow chart describing the process of establishing a secure communication channel between a server and a client, according to one embodiment of the present invention.
  • a client and a server can perform an authentication process, which can involve the server authenticating the client, the client authenticating the server, or both (operation 402).
  • the authentication process can be similar to the one shown in FIGs. 3A, 3B, or 3C. If the authentication fails, the process stops.
  • the client and the server can negotiate, using quantum-key-distribution schemes, a secret string (operation 404).
  • quantum-key-distribution schemes can be used for distributing the secret string, including but not limited to schemes based on the Bennett-Brassard-84 (BB84) or Ekert-91(E91) protocol.
  • operation 404 can be optional. Instead, the client and the server can synchronously obtain from the quantum-key pool a quantum key used as the secret string.
  • the server can then extract from the secret string, which can include a set of bits, a first subset of bits that can be used as a symmetric key for subsequent secure communications between the client and the server (operation 406).
  • a second subset of bits can also be extracted (e.g., by the server) from the secret string (operation 408). This second set of bits can be used to replace/update the client- specific key previously assigned to the client by the server.
  • the server can communicate the extraction criteria (e.g., the number of bits and the position of the bits) of the first and second subsets with the client to allow the client to extract the same subsets of bits from the secret string (operation 410). It is also possible for the client to determine and send the extraction criteria to the server. Alternatively, the extraction criteria can be established beforehand between the client and the server, and there is no need to communicate the extraction criteria. For example, the client and the server may agree to extract the first n bits from the secret string to be used as a symmetric key and the subsequent m bits to be used as the updated client- specific key. Alternatively, the client and the server may agree to extract the first m bits from the secret string to be used as the updated client- specific key and the subsequent n bits to be used as the symmetric key.
  • the extraction criteria e.g., the number of bits and the position of the bits
  • the client and the server each store the symmetric key and the updated client-specific key (operation 412). More specifically, the server can store in its key database the updated client- specific key for this particular client. The updated client- specific key can later be used for authentication purposes when the client and the server initiate a new secure communication session. The client and the server can then start to communicate with each other using the symmetric key as an encryption/decryption key (operation 414).
  • FIG. 5 presents a diagram illustrating an exemplary process for negotiating a secret string between the client and the server, in accordance with one embodiment of the present invention.
  • a client 502 can generate a random binary string, known as a quantum-control sequence (operation 506).
  • Client 502 can select, from a pre-installed quantum- state-basis library, a set of quantum state bases, and assigns a length value for each selected quantum state basis (operation 508).
  • the sum of the length values of the selected quantum state bases equals the length of the quantum-control sequence.
  • Client 502 can then generate a sequence of quantum bits (qubits), also known as a quantum string, based on the selected quantum state bases, their assigned lengths, and the quantum-control sequence (operation 510).
  • the length of the quantum string equals the length of the quantum-control sequence, with each qubit corresponding to a bit in the quantum-control sequence.
  • a particular qubit can be represented by a single photon in a certain polarization state, depending on the quantum state basis corresponding to the bit position and the bit value of a corresponding bit in the quantum-control sequence.
  • Client 502 can then send, via a quantum channel, the quantum string (i.e., a sequence of single photons) to server 504 (operation 512).
  • the quantum channel can include optical fibers or free space.
  • server 504 can select, from its quantum-state-basis library, a set of quantum state bases and measure the receiving quantum string using the selected quantum state bases (operation 514).
  • Client 502 can generate a message that includes information regarding the quantum state bases used for generating the qubits (operation 516) and send the message to server 504 (operation 518).
  • the message can be encrypted (e.g., using the client- specific key), and can include the QIDs and their assigned length value.
  • a general form of the message can be ⁇ QIDi, QID 2 , ', QID n , l n ⁇ iDc_Key-
  • the message may specify the QID used for encoding each qubit.
  • the message in the above example can be: ⁇ 2, 2, 2, 4, 4, 4, 4, 4, 4 ⁇ iDc_key- In this case, instead of specifying the numbers of bits encoded by each quantum state basis, the QIDs corresponding to all nine bits are listed.
  • bit number (or length value) corresponding to each QID can also be encoded.
  • client 502 and server 504 can each maintain a length-value database, which can map bit lengths to various codes. Instead of sending a particular length value assigned to a quantum state basis, client 502 can send a code corresponding to that length value. Upon receiving the code, server 504 can perform a lookup in the length-value database to determine the particular length value assigned to a particular quantum state basis.
  • server 504 can obtain quantum state basis information (e.g., the data string: QIDi, l ⁇ , QID 2 , ', ⁇ QID n , Z n ) (operation 520).
  • server 504 may need to decrypt (e.g., using the client- specific key stored on the server) the received message.
  • Server 504 can also send a message to client 502 containing information regarding the quantum state bases used by server 504 for measuring the received qubits (operation 522). Based on these exchanged messages, client 502 and server 504 each discard the bits where server 504 uses a different quantum state basis for measurement and keep the remaining bits as the secret string (operations 524 and 526).
  • client 502 states ⁇ 2, 3; 4, 6 ⁇
  • server 504 states ⁇ 2,9 ⁇
  • client 502 and server 504 will only keep the first three bits while discarding the remaining six bits.
  • server 504 can also determine whether the measurement result of the received quantum string meets one or more predetermined criteria based on the quantum state basis information (operation 528). If so, server 504 can determine that no eavesdropping is detected, and the key exchange succeeds. Otherwise, server 504 can determine that eavesdropping activities have been detected, and the key exchange fails.
  • the predetermined criteria used for detecting eavesdropping can include the photon-loss rate, the bit error rate, or both. A more detailed description regarding criteria used for detecting eavesdropping can be found in U.S. Patent Application No. 15/497,678, Attorney Docket No.
  • Server 504 can send the eavesdropping-detection result to client 502 (operation 530).
  • the quantum key-exchange scheme no longer involves asynchronous encryption/decryption, thus being more computationally efficient and can be faster. Moreover, the quantum key-exchange scheme can enhance security by detecting any possible eavesdropping.
  • FIG. 6 presents a diagram illustrating an exemplary client device, in accordance with an embodiment of the present invention.
  • Client 600 can include a regular zone 610 handling regular signals and a quantum zone 620 handling quantum signals. More specifically, regular zone 610 can include a communication-request generator 602, a key-management module 604, a random-string generator 606, an encryption/decryption module 608, a hash module 612, and a regular optical module 614; quantum zone 620 can include a quantum-state-basis library 622, a single-photon generator 624, and a quantum encoder 626.
  • communication-request generator 602 can be responsible for generating a request for initiating a secure communication channel, e.g., an HTTPS channel.
  • Key- management module 604 can be responsible for storing and updating the client- specific key assigned to client 600 and the symmetric session key negotiated between client 600 and a server. Key-management module 604 can also store the client ID along with the client- specific key.
  • Random- string generator 606 can be responsible for generating random strings.
  • Encryption/decryption module 608 can be responsible for encryption and decryption of messages, including during authentication and key negotiation, and for subsequent secure communication.
  • Hash module 612 is for calculating hash functions and comparing a calculated hash function with a received hash function.
  • Regular optical module 614 can be responsible for transmitting and receiving regular optical signals based on electrical signals generated by the various modules in regular zone 610. For example, the communication request generated by communication-request generator 602 can be converted to regular optical signals by regular optical module 614 before being sent to the server via an optical channel, such as optical fibers.
  • the regular optical signals can include any optical signal that does not carry or maintain quantum state information.
  • the regular optical signals can sometimes be referred to as high-intensity optical signals due to their relative higher intensity compared to quantum signals that carry quantum state information.
  • quantum- state-basis library 622 stores the quantum state bases, each of which is identified by a unique identifier (QID).
  • Single-photon generator 624 can be responsible for generating single photons.
  • Quantum encoder 626 can be responsible for selecting quantum state bases from quantum-state-basis library 622 and encoding the single photons using selected quantum state bases, based on a random string generated by random-string generator 606.
  • communication-request generator 602 generates a request for initiating secure communication between client 600 and a remote server.
  • a request can be in the form of an authentication request.
  • the authentication request from client 600 can include the ID of client 600, a hash function generated by hash module 612, and an encrypted random string or number r.
  • the random string or number r can be generated by random-string generator 606 and encrypted by encryption/decryption module 608 using a client-specific key managed by key-management module 604.
  • the hash function can be hash(ID_C, IDC_Key), where ID_C is the client ID and IDC_Key is the client-specific key, and (ID_C, IDC_Key) can be the concatenation of the two strings.
  • Regular optical signals carrying information of the request can be generated by regular optical module 614 and sent to the server via a regular optical channel.
  • regular optical module 614 can receive from the server a regular optical signal carrying the server's response, which can include the server's ID (ID_S) and a hash function of the server's ID and the random string sent by client 600 (e.g., hash(ID_S, r)).
  • Hash module 612 calculates a hash function using the server's ID and the random string, and compares the calculated hash function with the received hash function in order to authenticate the server.
  • quantum encoder 626 can encode a sequence of single photons using quantum state bases selected from a quantum-state-basis library 622 to generate a quantum signal.
  • the particular quantum state (e.g., polarization state) of each photon can be determined based on a corresponding selected quantum state basis and a random quantum- control sequence generated by random-string generator 606. In other words, information associated with the random quantum-control sequence is represented by quantum states of the single photons.
  • Quantum encoder 626 can send the quantum signal to the server via a quantum channel.
  • Client 600 can also send, via regular optical module 614, information regarding quantum state bases used for encoding to the server, and receive the server' s feedback, indicating the quantum state bases used by the server for measurement of the quantum signal.
  • key-management module 604 can obtain a secret string shared between client 600 and the server by discarding bits from the quantum-control sequence corresponding to qubits that were measured using different quantum state bases.
  • the secret string can be stored in key-management module 604.
  • a portion of the secret string can be used to update the client- specific key, whereas the remaining portion can be used as a symmetric session key for secure communications between client 600 and the server.
  • Such secure communications only involve regular optical signals generated by regular optical module 614.
  • client 600 may also include a counter (not shown in FIG. 6), which can be part of key- management module 604.
  • the counter can be synchronized with a similar counter located on the server. Both counters increment by one each time client 600 and the server interact with each other.
  • the counter value n can be used by the server to modify a random number, based on which a hash function is calculated. This way, the hash function sent from the server back to client 600 will be hash(ID_S, r + n).
  • hash module 612 can obtain the current counter value n and calculate hash(ID_S, r + n) accordingly.
  • FIG. 7 presents a diagram illustrating an exemplary server device, in accordance with one embodiment of the present invention.
  • server 700 can include a regular zone 710 handling regular signals and a quantum zone 720 handling quantum signals.
  • regular zone 710 can include a regular optical module 702, a communication- request-receiving module 704, a key database 706, a hash module 708, an encryption/decryption module 712, a quantum-key-management module 714, and an eavesdropping-detection-result generator 716;
  • quantum zone 720 can include a quantum-state-basis library 722 and a quantum- state-measurement module 724.
  • the functionalities of the various modules in server 700 can be similar to the corresponding ones in client 600.
  • communication-request-receiving module 704 can receive, via regular optical module 702, a request for secure communication from the client.
  • a request for secure communication can be in the form of an authentication request that includes the client ID, a hash function, and an encrypted random string or number r.
  • the hash function can be the hash of the client ID and a client- specific key, such as hash(ID_C, IDC_Key).
  • hash module 708 can obtain the client- specific key corresponding to the client ID from key database 706, and calculate a hash function based on the obtained client- specific key and the client ID.
  • Hash module 708 can further compare the calculated hash function with the received hash function in order to authenticate the client.
  • Encryption/decryption module 712 can perform a decryption operation to obtain the random string or number r.
  • Hash module 708 can also generate a hash function based on the server's ID (ID_S) and the random string or number r.
  • server 700 may also include a counter (not shown in FIG. 7), which can be synchronized with a similar counter located on the client.
  • hash module 708 may modify the random string using the counter value n. For example, hash module 708 can calculate a sum of the random string and the counter value, and calculate a hash based on the server ID and the sum.
  • the hash function is calculated as hash(ID_S, r + n).
  • Quantum-state-measurement module 724 can receive quantum signal (e.g., single photons) from the client and can randomly select one or more quantum states from quantum- state-basis library 722 to measure the quantum states of the received single photons, thus obtaining a measured quantum-control sequence. Because the quantum state bases used for the measurements are not the same as the ones used by the client for transmission, the measured quantum-control sequence is not the same as the control sequence sent by the client.
  • quantum signal e.g., single photons
  • Regular optical module 702 can also receive, from the client, a message that includes information regarding the quantum state bases used by the client for encoding the single photons. This message can also be encrypted (e.g., using the client- specific key).
  • Encryption/decryption module 712 can decrypt the received message to obtain the information regarding the quantum state bases. In some embodiments, this message may also include the quantum-control sequence itself. [0086] Quantum-key-management module 714 can determine, based on quantum state bases used for measurement and quantum state bases used by the client for encoding, which bits within the measured quantum-control sequence to be discarded. Quantum-key-management module 714 can then keep the remaining bits a secret string. A portion of the secret string can be used to update the client- specific key stored in key database 706, whereas the remaining portion can be used as a symmetric session key for secure communications between the client and server 700. The symmetric session key can either be maintained by quantum-key-management module 714. During subsequent secure communication, encryption/decryption module 712 can obtain the symmetric session key from quantum-key-management module 714.
  • Eavesdropping-detection-result generator 716 can obtain information regarding the quantum state bases used for encoding at the client's side and optionally the quantum-control sequence from encryption/decryption module 712, and the measured quantum-control sequence and quantum state bases used for the measurement from quantum- state-measurement module 724. Eavesdropping-detection-result generator 716 can then generate an eavesdropping-detection result based on the obtained information. More specifically, eavesdropping-detection-result generator 716 can determine whether the measurement result meets one or more predetermined criteria, and can generate a result indicating whether eavesdropping is detected.
  • the generated eavesdropping-detection-result can be sent to the client via regular optical module 702.
  • the predetermined criteria can be based on the photon-loss rate, the bit error rate (BER) of the measured quantum-control sequence, or both. For example, if eavesdropping-detection-result generator 716 determines that the photon-loss rate exceeds a predetermined threshold, eavesdropping-detection-result generator 716 may generate a result indicating that eavesdropping is detected.
  • the client may be coupled to the server via a classical channel (e.g., optical fibers or free space) and a quantum channel (e.g.,
  • the regular optical signal and the quantum signal can be multiplexed together using various multiplexing techniques, including but not limited to: wavelength-domain-multiplexing (WDM) and time-domain- multiplexing techniques.
  • WDM wavelength-domain-multiplexing
  • time-domain- multiplexing techniques are examples of multiplexing techniques.
  • the computations performed by the client and the server only involve the calculation of certain hash functions and symmetric encryption/decryption, both of which are much more computationally efficient than asymmetric encryption/decryption.
  • the quantum-key- exchange process can ensure the security of the exchanged symmetric keys, due to the laws of quantum mechanics, such as the uncertainty principle, the principle of quantum state
  • the secure communication channel established between the client and server can be similar to an HTTPS channel established between the client and server.
  • the presently disclosed technology can be used to enable secure data transmission between any types of network nodes.
  • a secure peer-to-peer communication channel may also be established using a similar technology, as long as the participating nodes can establish a certain secret key beforehand that is specific to one of the node or the node pair.
  • FIG. 8 illustrates an exemplary client-server network environment for
  • a network environment 800 includes a number of electronic devices 802, 804 and 806 communicably connected to a server 810 by a network 808.
  • One or more remote servers 820 are further coupled to the server 810 and/or the one or more electronic devices 802, 804 and 806.
  • electronic devices 802, 804 and 806 can be computing devices such as laptop or desktop computers, smartphones, PDAs, portable media players, tablet computers, televisions or other displays with one or more processors coupled thereto or embedded therein, or other appropriate computing devices that can be used for displaying a web page or web application.
  • the electronic devices 802, 804 and 806 store a user agent such as a browser or application.
  • electronic device 802 is depicted as a smartphone
  • electronic device 804 is depicted as a desktop computer
  • electronic device 806 is depicted as a PDA.
  • Server 810 includes a processing device 812 and a data store 814.
  • Processing device 812 executes computer instructions stored in data store 814, for example, to assist in scheduling a customer-initiated service or a service-provider-initiated service between a service provider and a customer at electronic devices 802, 804 and 806 during a service scheduling process.
  • server 810 can be a single computing device such as a computer server. In other embodiments, server 810 can represent more than one computing device working together to perform the actions of a server computer (e.g., cloud computing).
  • the server 810 may host the web server communicably coupled to the browser at the client device (e.g., electronic devices 802, 804 or 806) via network 808.
  • the server 810 may host a client application for scheduling a customer-initiated service or a service-provider-initiated service between a service provider and a customer during a service scheduling process.
  • Server 810 may further be in communication with one or more remote servers 820 either through the network 808 or through another network or communication means.
  • the one or more remote servers 820 may perform various functionalities and/or storage capabilities described herein with regard to the server 810 either alone or in combination with server 810.
  • Each of the one or more remote servers 820 may host various services.
  • servers 820 may host services providing information regarding one or more suggested locations such as web pages or websites associated with the suggested locations, services for determining the location of one or more users, or establishments, search engines for identifying results for a user query, one or more user review or query services, or one or more other services providing information regarding one or more establishments, customers and/or review or feedback regarding the establishments.
  • Server 810 may further maintain or be in communication with social networking services hosted on one or more remote servers 820.
  • the one or more social networking services may provide various services and may enable users to create a profile and associate themselves with other users at a remote social networking service.
  • the server 810 and/or the one or more remote servers 820 may further facilitate the generation and maintenance of a social graph including the user-created associations.
  • the social graphs may include, for example, a list of all users of the remote social networking service and their associations with other users of a remote social networking service.
  • Each of the one or more remote servers 820 can be a single computing device such as a computer server or can represent more than one computing device working together to perform the actions of a server computer (e.g., cloud computing).
  • server 810 and one or more remote servers 820 may be implemented as a single server or a cluster of servers.
  • server 810 and one or more remote servers 820 may communicate through the user agent at the client device (e.g., electronic devices 802, 804 or 806) via network 808.
  • Users may interact with the system hosted by server 810, and/or one or more services hosted by remote servers 820, through a client application installed at the electronic devices 802, 804, and 806.
  • the user may interact with the system and the one or more social networking services through a web-based browser application at the electronic devices 802, 804, 806.
  • Communication among client devices 802, 804, 806 and the system, and/or one or more services, may be facilitated through a network (e.g., network 808).
  • client devices 802, 804, 806, server 810 and/or one or more remote servers 820 may be facilitated through various communication protocols.
  • client devices 802, 804, 806, server 810 and/or one or more remote servers 820 may communicate wirelessly through a communication interface (not shown), which may include digital signal processing circuitry where necessary.
  • the communication interface may provide for communications under various modes or protocols, including Global System for Mobile communication (GSM) voice calls; Short Message Service (SMS), Enhanced Messaging Service (EMS), or Multimedia Messaging Service (MMS) messaging; Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Personal Digital Cellular (PDC), Wideband Code Division Multiple Access (WCDMA), CDMA2000, or General Packet Radio System (GPRS), among others.
  • GSM Global System for Mobile communication
  • SMS Short Message Service
  • EMS Enhanced Messaging Service
  • MMS Multimedia Messaging Service
  • CDMA Code Division Multiple Access
  • TDMA Time Division Multiple Access
  • PDC Personal Digital Cellular
  • WCDMA Wideband Code Division Multiple Access
  • CDMA2000 Code Division Multiple Access 2000
  • GPRS General Packet Radio System
  • Network 808 can include, for example, any one or more of a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), a broadband network (BBN), the Internet, and the like. Further, network 808 can include, but is not limited to, any one or more of the following network topologies, including a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, and the like.
  • PAN personal area network
  • LAN local area network
  • CAN campus area network
  • MAN metropolitan area network
  • WAN wide area network
  • BBN broadband network
  • the Internet and the like.
  • network 808 can include, but is not limited to, any one or more of the following network topologies, including a bus network, a star network, a ring network, a mesh network, a star-bus network, a tree or hierarchical network, and the like
  • FIG. 9 conceptually illustrates an electronic system with which some
  • Electronic system 900 can be a client, a server, a computer, a smartphone, a PDA, a laptop, or a tablet computer with one or more processors embedded therein or coupled thereto, or any other sort of electronic device.
  • Such an electronic system includes various types of computer-readable media and interfaces for various other types of computer-readable media.
  • Electronic system 900 includes a bus 908, processing unit(s) 912, a system memory 904, a read-only memory (ROM) 910, a permanent storage device 902, an input device interface 914, an output device interface 906, and a network interface 916.
  • ROM read-only memory
  • Bus 908 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 900. For instance, bus 908 communicatively connects processing unit(s) 912 with ROM 910, system memory 904, and permanent storage device 902.
  • processing unit(s) 912 retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure.
  • the processing unit(s) can be a single processor or a multi-core processor in different
  • ROM 910 stores static data and instructions that are needed by processing unit(s) 912 and other modules of electronic system 900.
  • Permanent storage device 902 is a read-and- write memory device. This device is a non- volatile memory unit that stores instructions and data even when electronic system 900 is off.
  • Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 902.
  • system memory 904 is a read-and- write memory device. However, unlike storage device 902, system memory 904 is a volatile read-and- write memory, such a random access memory. System memory 904 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 904, permanent storage device 902, and/or ROM 910. From these various memory units, processing unit(s) 912 retrieves instructions to execute and data to process in order to execute the processes of some implementations.
  • Bus 908 also connects to input and output device interfaces 914 and 906.
  • Input device interface 914 enables the user to communicate information and select commands to the electronic system.
  • Input devices used with input device interface 914 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices").
  • Output device interface 906 enables, for example, the display of images generated by electronic system 900.
  • Output devices used with output device interface 906 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.
  • CTR cathode ray tubes
  • LCD liquid crystal displays
  • bus 908 also couples electronic system 900 to a network (not shown) through a network interface 916.
  • the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 900 can be used in conjunction with the subject disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Dans un mode de réalisation, l'invention concerne un système et un procédé permettant d'établir un canal de communication sécurisé entre un client et un serveur. Pendant le fonctionnement, le client génère une requête de service comprenant un premier message dynamique, transmet la première requête de service au serveur, qui authentifie le client sur la base du premier message dynamique, et reçoit un second message dynamique du serveur en réponse au premier message dynamique. Le client authentifie le serveur sur la base du second message dynamique, et négocie, via un processus de distribution de clés quantiques, une clé secrète partagée entre le client et le serveur. Le client et le serveur établissent ensuite un canal de communication sécurisé sur la base d'une première partie au moins de la clé secrète.
PCT/US2017/031606 2016-05-19 2017-05-08 Procédé et système de transmission sécurisée de données WO2017200791A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020187033013A KR20190005878A (ko) 2016-05-19 2017-05-08 보안 데이터 송신을 위한 방법 및 시스템
JP2018555211A JP2019517184A (ja) 2016-05-19 2017-05-08 安全なデータ伝送のための方法及びシステム
EP17799879.6A EP3459202A4 (fr) 2016-05-19 2017-05-08 Procédé et système de transmission sécurisée de données
SG11201808991WA SG11201808991WA (en) 2016-05-19 2017-05-08 Method and system for secure data transmission

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201610339148.7 2016-05-19
CN201610339148.7A CN107404461B (zh) 2016-05-19 2016-05-19 数据安全传输方法、客户端及服务端方法、装置及***
US15/588,462 US10439806B2 (en) 2016-05-19 2017-05-05 Method and system for secure data transmission
US15/588,462 2017-05-05

Publications (1)

Publication Number Publication Date
WO2017200791A1 true WO2017200791A1 (fr) 2017-11-23

Family

ID=60325518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/031606 WO2017200791A1 (fr) 2016-05-19 2017-05-08 Procédé et système de transmission sécurisée de données

Country Status (1)

Country Link
WO (1) WO2017200791A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108234501A (zh) * 2018-01-11 2018-06-29 北京国电通网络技术有限公司 一种基于量子密钥融合的虚拟电厂安全通信方法
CN109995739A (zh) * 2018-01-02 2019-07-09 ***通信有限公司研究院 一种信息传输方法、客户端、服务器及存储介质
CN110839240A (zh) * 2018-08-17 2020-02-25 阿里巴巴集团控股有限公司 一种建立连接的方法及装置
CN113726523A (zh) * 2021-09-01 2021-11-30 国网四川省电力公司信息通信公司 一种基于Cookie和DR身份密码体制的多重身份认证方法及装置
CN113852460A (zh) * 2021-09-16 2021-12-28 国科量子通信网络有限公司 一种基于量子密钥增强工作密钥安全性的实现方法和***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0962070B1 (fr) * 1997-12-24 2005-11-02 Koninklijke Philips Electronics N.V. Estion et utilisation de nombres aleatoires secrets non encore utilises dans un environnement a reseau
US20080114983A1 (en) * 2006-11-15 2008-05-15 Research In Motion Limited Client credential based secure session authentication method and apparatus
US20130101119A1 (en) * 2010-06-15 2013-04-25 Los Alamos National Security Llc Quantum key distribution using card, base station and trusted authority
US20150381363A1 (en) * 2014-01-31 2015-12-31 Teixem Corp. System and method for performing secure communications

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0962070B1 (fr) * 1997-12-24 2005-11-02 Koninklijke Philips Electronics N.V. Estion et utilisation de nombres aleatoires secrets non encore utilises dans un environnement a reseau
US20080114983A1 (en) * 2006-11-15 2008-05-15 Research In Motion Limited Client credential based secure session authentication method and apparatus
US20130101119A1 (en) * 2010-06-15 2013-04-25 Los Alamos National Security Llc Quantum key distribution using card, base station and trusted authority
US20150381363A1 (en) * 2014-01-31 2015-12-31 Teixem Corp. System and method for performing secure communications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3459202A4 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109995739A (zh) * 2018-01-02 2019-07-09 ***通信有限公司研究院 一种信息传输方法、客户端、服务器及存储介质
CN109995739B (zh) * 2018-01-02 2021-06-15 ***通信有限公司研究院 一种信息传输方法、客户端、服务器及存储介质
CN108234501A (zh) * 2018-01-11 2018-06-29 北京国电通网络技术有限公司 一种基于量子密钥融合的虚拟电厂安全通信方法
US11233639B2 (en) 2018-01-11 2022-01-25 Beijing Guodian Tong Network Technology Co., Ltd Method and device for quantum key fusion-based virtual power plant security communication and medium
CN110839240A (zh) * 2018-08-17 2020-02-25 阿里巴巴集团控股有限公司 一种建立连接的方法及装置
CN110839240B (zh) * 2018-08-17 2022-07-05 阿里巴巴集团控股有限公司 一种建立连接的方法及装置
CN113726523A (zh) * 2021-09-01 2021-11-30 国网四川省电力公司信息通信公司 一种基于Cookie和DR身份密码体制的多重身份认证方法及装置
CN113726523B (zh) * 2021-09-01 2023-09-01 国网四川省电力公司信息通信公司 基于Cookie和DR身份密码体制的多重身份认证方法及装置
CN113852460A (zh) * 2021-09-16 2021-12-28 国科量子通信网络有限公司 一种基于量子密钥增强工作密钥安全性的实现方法和***
CN113852460B (zh) * 2021-09-16 2023-10-13 国科量子通信网络有限公司 一种基于量子密钥增强工作密钥安全性的实现方法和***

Similar Documents

Publication Publication Date Title
US10439806B2 (en) Method and system for secure data transmission
US10491383B2 (en) Method and system for detecting eavesdropping during data transmission
US10855452B2 (en) Method and system for data security based on quantum communication and trusted computing
US10103880B2 (en) Method and system for quantum key distribution based on trusted computing
CN108292402B (zh) 用于信息的安全交换的公共秘密的确定和层级确定性密钥
US20190149327A1 (en) Method and system for quantum key distribution and data processing
US20170126654A1 (en) Method and system for dynamic password authentication based on quantum states
US20170214664A1 (en) Secure connections for low power devices
WO2017200791A1 (fr) Procédé et système de transmission sécurisée de données
US12010216B2 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
US11750580B2 (en) Systems and methods for encryption in network communication
US11528127B2 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
KR20100024605A (ko) Ｒｓａ기반 패스워드 인증을 통한 세션키 분배방법
Sasikumar et al. Modeling and simulation of a novel secure quantum key distribution (SQKD) for ensuring data security in cloud environment
Liu et al. Cryptanalysis of controlled quantum secure direct communication and authentication protocol based on five-particle cluster state and quantum one-time pad
EP2713545A1 (fr) Système de partage de données, système de distribution de données et procédé de protection de données
WO2017074953A1 (fr) Procédé et système d'authentification par mot de passe dynamique basée sur des états quantiques
CN108599941A (zh) 随机非对称扩充字节通信数据加密方法
Ahilan et al. Breaking barriers in conventional cryptography by integrating with quantum key distribution
WO2017196545A1 (fr) Procédé et système de détection d'écoute clandestine pendant une transmission de données
Zhong et al. Quantum Secret Sharing with Identity Authentication Based on GHZ States Entanglement Swapping

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018555211

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20187033013

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17799879

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017799879

Country of ref document: EP

Effective date: 20181219