WO2022244150A1 - 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム - Google Patents

鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム Download PDF

Info

Publication number
WO2022244150A1
WO2022244150A1 PCT/JP2021/019016 JP2021019016W WO2022244150A1 WO 2022244150 A1 WO2022244150 A1 WO 2022244150A1 JP 2021019016 W JP2021019016 W JP 2021019016W WO 2022244150 A1 WO2022244150 A1 WO 2022244150A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
key
server
token
authentication
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.)
Ceased
Application number
PCT/JP2021/019016
Other languages
English (en)
French (fr)
Japanese (ja)
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.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2023522086A priority Critical patent/JP7626212B2/ja
Priority to US18/555,615 priority patent/US20240205206A1/en
Priority to PCT/JP2021/019016 priority patent/WO2022244150A1/ja
Publication of WO2022244150A1 publication Critical patent/WO2022244150A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/321—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 a third party or a trusted authority
    • H04L9/3213—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 a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • 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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates

Definitions

  • the present invention relates to a key exchange system, terminal, server, key exchange method, and program.
  • a key is transmitted between a communication terminal that is a session initiator (hereinafter simply referred to as "initiator”) and one or more communication terminals that are session responders (hereinafter simply referred to as “responders”) via a server.
  • a communication terminal that is a session initiator (hereinafter simply referred to as "initiator”) and one or more communication terminals that are session responders (hereinafter simply referred to as “responders”) via a server.
  • These protocols are server-assisted key exchange protocols, in which the server authenticates the initiator and the responder, and if the authentication succeeds, the initiator and the responder exchange keys. These protocols enable end-to-end encrypted communication between the initiator and the responder because they can share session keys without even being known to the server.
  • Each of the above protocols is clearly designed, including the authentication method of the initiator and responder for the server.
  • the key exchanges described in Non-Patent Document 1, Non-Patent Document 3, and Non-Patent Document 5 use a public key-based method
  • the key exchange described in Non-Patent Document 2 uses an ID-based method.
  • These authentication methods are completely different from the widely used "ID/password”, “SMS authentication”, “fingerprint authentication”, and “multi-factor authentication” combining them.
  • server-assisted key exchange is realized with various authentication methods such as “ID/password”, “SMS authentication”, “fingerprint authentication”, and “multi-factor authentication”. is required.
  • OpenID Connect an authentication collaboration protocol called OpenID Connect (hereinafter also referred to as "OIDC") is known (for example, Non-Patent Document 5, etc.). If this OIDC ID token is used to authenticate the initiator and responder to the server, it is possible to implement server-assisted key exchange using any authentication method required by the ID provider (OP: OpenID Provider). .
  • OIDC OpenID Connect
  • An embodiment of the present invention has been made in view of the above points, and aims to realize efficient server-assisted key exchange using an arbitrary authentication method.
  • a key exchange system is a key exchange system that includes a plurality of terminals that exchange keys, and a server that authenticates the terminals and mediates the key exchange.
  • the server has a nonce generation unit that generates a nonce that is used when performing the above-mentioned authentication by authentication cooperation based on OpenID Connect with the terminal, and a key generation unit that generates a public key and a private key for token control encryption a first transmitting unit that transmits the nonce and the public key to the terminal; and a decryption that decrypts the ciphertext received from the terminal using the private key and the token received from the terminal.
  • FIG. 4 is a sequence diagram showing an example of authentication cooperation (implicit flow) and key exchange processing according to the present embodiment;
  • FIG. 4 is a sequence diagram showing an example of authentication cooperation (authorization code flow) and key exchange processing according to the present embodiment;
  • a key exchange system 1 that enables use of any authentication method by OIDC and realizes efficient server-assisted key exchange that does not require re-authentication even during multiple key exchange sessions will be described. do.
  • Public key cryptography consists of the following three algorithms (KeyGen, Enc, Dec).
  • KeyGen(1 ⁇ ) ⁇ (pk, sk) A key generation algorithm that takes as input a security parameter ⁇ -length 1-bit string 1 ⁇ and outputs a key pair (pk, sk) of a public key pk and a secret key sk.
  • Enc(pk,m) ⁇ C An encryption algorithm that outputs a ciphertext C with a public key pk and a message m as inputs.
  • Dec(sk, C) ⁇ m' A decryption algorithm that takes a private key sk and a ciphertext C as input and outputs a message m'.
  • Token-controlled public key cryptography consists of the following three algorithms (TKeyGen, TEnc, and TDec).
  • TKeyGen(1 ⁇ ) ⁇ (pk, sk) A key generation algorithm that takes as input a security parameter ⁇ -length 1-bit string 1 ⁇ and outputs a key pair (pk, sk) of a public key pk and a secret key sk.
  • TEnc (pk, m, token) ⁇ C An encryption algorithm that outputs a ciphertext C with a public key pk, a message m, and a token token as inputs.
  • TDec (sk, C, token) ⁇ m' A decryption algorithm that takes as input the secret key sk, the ciphertext C, and the token token, and outputs the message m'.
  • Token-controlled public-key cryptography also requires the following conditions for legitimacy.
  • FIG. 1 is a diagram showing an example of the overall configuration of a key exchange system 1 according to this embodiment.
  • the key exchange system 1 includes a plurality of terminals 10, a server 20, and an ID provider 30. These are communicably connected via a communication network N such as the Internet.
  • a communication network N such as the Internet.
  • each of the terminals 10 that perform key exchange is referred to as "terminal 10-1", . . . , "terminal 10-N".
  • N (where N ⁇ 2) is the total number of terminals.
  • a terminal 10 is a user terminal that performs key exchange with one or more other terminals 10 using a server-assisted key exchange protocol.
  • the plurality of terminals 10 there are one terminal 10 serving as an initiator and one or more terminals 10 serving as responders.
  • Examples of the terminal 10 include various devices and devices such as general-purpose servers, PCs (personal computers), smartphones, tablet terminals, wearable devices, vehicle-mounted devices, industrial devices, home appliances, robots, and the like.
  • the server 20 is a server that supports key exchange when key exchange is performed between a plurality of terminals 10 using a server-assisted key exchange protocol (that is, mediates key exchange between a plurality of terminals 10).
  • a server-assisted key exchange protocol that is, mediates key exchange between a plurality of terminals 10.
  • the server 20 needs to authenticate (signature verification, encryption, etc.) each of these terminals 10.
  • the ID provider 30 is a server or the like that functions as an OP of OIDC.
  • the ID provider 30 requests the terminal 10 for user authentication by any predetermined authentication method.
  • FIG. 2 is a diagram showing an example of the functional configuration of the terminal 10 according to this embodiment.
  • the terminal 10 has an authentication cooperation unit 101, a key pair generation unit 102, an encryption unit 103, and a decryption unit 104. These units are implemented by, for example, one or more programs installed in the terminal 10 causing a processor such as a CPU (Central Processing Unit) to execute processing.
  • a processor such as a CPU (Central Processing Unit) to execute processing.
  • the terminal 10 has a storage unit 105 .
  • the storage unit 105 is realized by various memory devices such as HDD (Hard Disk Drive), SSD (Solid State Drive), and flash memory.
  • the authentication cooperation unit 101 executes various processes for authentication cooperation by OIDC.
  • the key pair generation unit 102 executes a key generation algorithm KeyGen to generate a key pair of its own public key and private key.
  • the encryption unit 103 executes the encryption algorithm TEnc using the nonce hash value used in OIDC as a token to generate a ciphertext.
  • the decryption unit 104 executes the decryption algorithm Dec to decrypt the ciphertext.
  • the storage unit 105 stores information necessary for each unit to execute various processes, execution results thereof, and the like (for example, various keys, nonce, ID tokens, etc.).
  • FIG. 3 is a diagram showing an example of the functional configuration of the server 20 according to this embodiment.
  • the server 20 has an authentication cooperation unit 201, a key pair generation unit 202, an encryption unit 203, and a decryption unit 204. These units are implemented by, for example, one or more programs installed in the server 20 causing a processor such as a CPU to execute processing.
  • the server 20 also has a storage unit 205 .
  • the storage unit 205 is realized by, for example, various memory devices such as HDD, SSD, and flash memory. Note that the storage unit 205 may be implemented by, for example, a storage device or the like connected to the server 20 via a communication network.
  • the authentication cooperation unit 201 executes various processes for authentication cooperation by OIDC.
  • the authentication cooperation unit 201 generates a nonce used in OIDC.
  • the key pair generation unit 202 executes a key generation algorithm TKeyGen to generate a key pair of a server's public key and private key.
  • the encryption unit 203 executes the encryption algorithm Enc to generate ciphertext.
  • the decryption unit 204 executes the decryption algorithm TDec to decrypt the ciphertext. At this time, the decryption unit 204 decrypts the ciphertext using the nonce hash value generated by itself.
  • the storage unit 205 stores information necessary for each unit to execute various processes, execution results thereof, and the like (for example, various keys, nonce, ID token, etc.).
  • OIDC has an authentication flow called an implicit flow and an authentication flow called an authorization code flow
  • RP Relying Party
  • the server 20 corresponds to the RP.
  • FIG. 4 is a sequence diagram showing an example of authentication cooperation (implicit flow) and key exchange processing according to this embodiment.
  • the authentication collaboration unit 101 of the terminal 10 transmits an authentication request to the server 20 (step S101).
  • the authentication cooperation unit 201 of the server 20 Upon receiving the authentication request, the authentication cooperation unit 201 of the server 20 generates a nonce used in OIDC (step S102). Further, the key pair generation unit 202 of the server 20 generates a key pair (pk S , sk S ) of the public key pk S and the private key sk S by TKeyGen(1 ⁇ ) ⁇ (pk S , sk S ) (step S103). Subsequently, the authentication collaboration unit 201 of the server 20 transmits a redirect instruction to the ID provider 30 to the terminal 10 (step S104). At this time, the authentication cooperation unit 201 includes the nonce and the public key pkS in the redirect instruction.
  • the authentication collaboration unit 101 of the terminal 10 redirects to the ID provider 30, and performs user authentication by the authentication method requested by the ID provider 30 (step S105). At this time, the authentication collaboration unit 101 transmits the nonce to the ID provider 30 during user authentication.
  • the authentication methods requested by the ID provider 30 include, for example, various authentication methods such as "ID/password”, “SMS authentication”, “fingerprint authentication”, and "multi-factor authentication”.
  • the ID provider 30 returns an ID token signed by the ID provider 30 and with a nonce to the terminal 10 (step S106).
  • the key pair generation unit 102 of the terminal 10 Upon receiving the ID token from the ID provider 30, the key pair generation unit 102 of the terminal 10 generates a key pair ( pk C , sk C ) (step S107).
  • the encryption unit 103 of the terminal 10 uses the hash value obtained by inputting the nonce to a predetermined hash function (for example, SHA-256) as the token token, and converts the ID token and the public key pkC to A ciphertext C is generated by encrypting the containing message m with a public key pk S (step S108). That is, the encryption unit 103 generates the ciphertext C by TEnc(pk S , m, token) ⁇ C. The encryption unit 103 of the terminal 10 then transmits the ciphertext C to the server 20 (step S109).
  • a predetermined hash function for example, SHA-256
  • the decryption unit 204 of the server 20 receives the ciphertext C
  • the hash value obtained by inputting the nonce nonce into a predetermined hash function for example, SHA-256
  • the ciphertext C is Decrypt with the private key sk S (step S110). That is, the decryption unit 204 obtains the message m by decrypting the ciphertext C by TDec(sk S , C, token) ⁇ m.
  • the ID token and public key pk C are obtained from this message m.
  • the authentication cooperation unit 201 of the server 20 verifies the ID token obtained in step S110 (step S111). That is, after verifying the signature of the ID token, the authentication cooperation unit 201 verifies that the nonce given to the ID token matches the nonce generated in step S102.
  • step S111 the terminal 10 and the server 20 perform key exchange (step S112). The details of this key exchange will be described later.
  • FIG. 5 is a sequence diagram showing an example of authentication cooperation (authorization code flow) and key exchange processing according to this embodiment.
  • the authentication collaboration unit 101 of the terminal 10 transmits an authentication request to the server 20 (step S201).
  • the authentication cooperation unit 201 of the server 20 Upon receiving the authentication request, the authentication cooperation unit 201 of the server 20 generates a nonce used in OIDC (step S202). Further, the key pair generation unit 202 of the server 20 generates a key pair (pk S , sk S ) of the public key pk S and the private key sk S by TKeyGen(1 ⁇ ) ⁇ (pk S , sk S ) (step S203). Subsequently, the authentication collaboration unit 201 of the server 20 transmits a redirect instruction to the ID provider 30 to the terminal 10 (step S204). At this time, the authentication cooperation unit 201 includes the nonce and the public key pkS in the redirect instruction.
  • the authentication cooperation unit 101 of the terminal 10 redirects to the ID provider 30, and performs user authentication by the authentication method requested by the ID provider 30 (step S205). At this time, the authentication collaboration unit 101 transmits the nonce to the ID provider 30 during user authentication.
  • an authorization code is returned from the ID provider 30 to the terminal 10 (step S206).
  • the key pair generation unit 102 of the terminal 10 Upon receiving the authorization code from the ID provider 30, the key pair generation unit 102 of the terminal 10 generates a key pair ( pk C , sk C ) (step S207).
  • the encryption unit 103 of the terminal 10 uses the hash value obtained by inputting the nonce nonce to a predetermined hash function (for example, SHA-256) as the token token, and converts the authorization code and the public key pkC to A ciphertext C is generated by encrypting the containing message m with a public key pk S (step S208). That is, the encryption unit 103 generates the ciphertext C by TEnc(pk S , m, token) ⁇ C. The encryption unit 103 of the terminal 10 then transmits the ciphertext C to the server 20 (step S209).
  • a predetermined hash function for example, SHA-256
  • the decryption unit 204 of the server 20 receives the ciphertext C
  • the hash value obtained by inputting the nonce nonce into a predetermined hash function for example, SHA-256
  • the ciphertext C is Decrypt with the secret key sk S (step S210). That is, the decryption unit 204 obtains the message m by decrypting the ciphertext C by TDec(sk S , C, token) ⁇ m. This gives the authorization code and the public key pk C from this message m.
  • the authentication cooperation unit 201 of the server 20 transmits the authorization code obtained in step S210 above to the ID provider 30 (step S211).
  • an ID token with a signature and a nonce is returned from the ID provider 30 to the server 20 (step S212).
  • the authentication cooperation unit 201 of the server 20 verifies the ID token obtained in step S212 (step S213). That is, after verifying the signature of the ID token, the authentication cooperation unit 201 verifies that the nonce given to the ID token matches the nonce generated in step S202.
  • step S214 the terminal 10 and the server 20 perform key exchange. The details of this key exchange will be described later.
  • Example 1 of the key exchange in step S112 or step S214 the case of performing the key exchange described in Non-Patent Documents 1 and 2 will be described. Please refer to Non-Patent Literatures 1 and 2 for processing other than those specifically described below.
  • the server 20 first transmits the MAC key and the attribute-based encryption key to the terminal 10 . Therefore, at this time, the encryption unit 203 of the server 20 generates a ciphertext C by encrypting the message m′ including these keys with the public key pk C , that is, by Enc(pk C , m′) ⁇ C A ciphertext C is generated and the ciphertext C is transmitted to the terminal 10 .
  • the decryption unit 104 of the terminal 10 decrypts this ciphertext C, that is, generates a message m′ by Dec(sk C , C) ⁇ m′, and from this message m′, the MAC key and the attribute-based encryption key take out. Subsequent processing is the same as the processing described in Non-Patent Documents 1 and 2. As a result, within the validity period of the ID token (or within the validity period specified by the server 20), the terminal 10 can execute the key exchange protocol without performing user authentication again with the ID provider 30. is.
  • a message including a nonce N I and a partner identifier pid is transmitted from the terminal 10 to the server 20 (this message is referred to as m')
  • the encryption unit 103 of the terminal 10 uses the nonce used in OIDC as a predetermined
  • the message m′ is encrypted with the public key pk S to generate the ciphertext C, that is, TEnc (pk S , m′, token) ⁇ C to generate a ciphertext C and transmit this ciphertext C to the server 20 .
  • the decryption unit 204 of the server 20 receives the ciphertext C, the hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256 etc.) as a token token , decrypts the ciphertext C with the secret key sk S , that is, generates a message m' by TDec(sk S , C, token) ⁇ m', and extracts the nonce N I and the partner identifier pid from this message m'.
  • a predetermined hash function for example, SHA-256 etc.
  • the terminal 10 When the terminal 10 performs key exchange as a responder FIG. 10 will be explained.
  • the terminal 10 sends a message including the blind ciphertext C ⁇ (more precisely, " ⁇ " is written directly above C) and the session identifier sid (this message is called m'') to the server 20.
  • the encryption unit 103 of the terminal 10 uses a hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256) as a token token, and converts the message m'' A ciphertext C encrypted with a public key pk S is generated, that is, a ciphertext C is generated by TEnc(pk S , m′′, token) ⁇ C, and this ciphertext C is transmitted to the server 20 .
  • a hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256) as a token token, and converts the message m'' A ciphertext C encrypted with a public key pk S is generated, that is, a ciphertext C is generated by TEnc(pk S , m′′, token) ⁇ C, and this ciphertext C is transmitted to the server 20 .
  • a predetermined hash function for
  • the decryption unit 204 of the server 20 receives the ciphertext C, the hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256 etc.) as a token token , decrypts the ciphertext C with the secret key sk S , that is, generates a message m'' by TDec(sk S , C, token) ⁇ m'', and from this message m'', the blind ciphertext C and the session identifier Get the sid.
  • a predetermined hash function for example, SHA-256 etc.
  • FIG. 10 When the terminal 10 performs key exchange as an initiator
  • FIG. 1 The changes from 1 will be explained.
  • the terminal 10 is assumed to be Alice, and its communication partner is assumed to be Bob.
  • Fig. 1 (b) when a message including the identifier of the communication partner (this message is assumed to be m') is transmitted from the terminal 10 to the server 20, the encryption unit 103 of the terminal 10 encrypts the nonce used in OIDC. is input to a predetermined hash function (for example, SHA-256, etc.) as a token token, and a ciphertext C is generated by encrypting the message m′ with the public key pk S , that is, TEnc ( pk S , m′, token) ⁇ C to generate a ciphertext C and transmit this ciphertext C to the server 20 .
  • a predetermined hash function for example, SHA-256, etc.
  • the decryption unit 204 of the server 20 receives the ciphertext C, the hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256 etc.) as a token token , decrypts the ciphertext C with the secret key sk S , that is, generates a message m′ by TDec(sk S , C, token) ⁇ m′, and extracts the identifier of the communication partner from this message m′.
  • a predetermined hash function for example, SHA-256 etc.
  • Fig. 1(a) when the terminal 10 sends a message (this message is m'') containing its own public key, a signed pre-public key, and a plurality of temporary private keys to the server 20, the terminal 10
  • the encryption unit 103 uses the hash value obtained by inputting the nonce used in OIDC to a predetermined hash function (for example, SHA-256 etc.) as the token token, and uses the message m'' as the public key pk S , that is, TEnc(pk S , m′′, token) ⁇ C to generate the ciphertext C, and transmit the ciphertext C to the server 20 .
  • a predetermined hash function for example, SHA-256 etc.
  • the decryption unit 204 of the server 20 receives the ciphertext C, the hash value obtained by inputting the nonce nonce used in OIDC to a predetermined hash function (for example, SHA-256 etc.) as a token token , decrypt the ciphertext C with the secret key sk S , that is, generate a message m'' by TDec(sk S , C, token) ⁇ m'', and from this message m'', the public key of the terminal 10, signed Retrieve the pre-public key and multiple temporary private keys.
  • a predetermined hash function for example, SHA-256 etc.
  • any arbitrary Authentication can be performed by the above authentication method, and re-authentication is not required when each key exchange session is executed within a predetermined effective period, so that efficient key exchange can be realized.
  • server-assisted key exchange can be executed from multiple different terminals 10, browsers, etc., depending on the authentication method requested by the OP. becomes possible.
  • FIG. 6 is a diagram showing an example of the hardware configuration of the computer 500. As shown in FIG.
  • a computer 500 shown in FIG. 6 has an input device 501, a display device 502, an external I/F 503, a communication I/F 504, a processor 505, and a memory device 506. Each of these pieces of hardware is communicably connected via a bus 507 .
  • the input device 501 is, for example, a keyboard, mouse, touch panel, or the like.
  • the display device 502 is, for example, a display. Note that the computer 500 may not have at least one of the input device 501 and the display device 502, for example.
  • the external I/F 503 is an interface with an external device such as a recording medium 503a.
  • the computer 500 can perform reading, writing, etc. of the recording medium 503a via the external I/F 503 .
  • Examples of the recording medium 503a include CD (Compact Disc), DVD (Digital Versatile Disk), SD memory card (Secure Digital memory card), USB (Universal Serial Bus) memory card, and the like.
  • a communication I/F 504 is an interface for connecting the computer 500 to a communication network.
  • the processor 505 is, for example, various arithmetic units such as a CPU.
  • the memory device 506 is, for example, various storage devices such as HDD, SSD, flash memory, RAM (Random Access Memory), ROM (Read Only Memory).
  • the terminal 10 and server 20 have the hardware configuration shown in FIG. 6, so that the above-described authentication cooperation and key exchange processing can be realized.
  • the hardware configuration shown in FIG. 6 is just an example, and the computer 500 may have, for example, multiple processors or multiple memory devices, and various hardware configurations may be used. may have.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
PCT/JP2021/019016 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム Ceased WO2022244150A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023522086A JP7626212B2 (ja) 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム
US18/555,615 US20240205206A1 (en) 2021-05-19 2021-05-19 Key exchange system, terminal, server, key exchange method, and program
PCT/JP2021/019016 WO2022244150A1 (ja) 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/019016 WO2022244150A1 (ja) 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022244150A1 true WO2022244150A1 (ja) 2022-11-24

Family

ID=84141412

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/019016 Ceased WO2022244150A1 (ja) 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム

Country Status (3)

Country Link
US (1) US20240205206A1 (https=)
JP (1) JP7626212B2 (https=)
WO (1) WO2022244150A1 (https=)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008131652A (ja) * 2006-11-22 2008-06-05 Research In Motion Ltd モバイルユーザ証明書の共有知識を用いる安全な記録プロトコルのためのシステムおよび方法
JP2019139520A (ja) * 2018-02-09 2019-08-22 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
JP2020520017A (ja) * 2017-05-15 2020-07-02 アマゾン テクノロジーズ インコーポレイテッド 汎用入退管理装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008131652A (ja) * 2006-11-22 2008-06-05 Research In Motion Ltd モバイルユーザ証明書の共有知識を用いる安全な記録プロトコルのためのシステムおよび方法
JP2020520017A (ja) * 2017-05-15 2020-07-02 アマゾン テクノロジーズ インコーポレイテッド 汎用入退管理装置
JP2019139520A (ja) * 2018-02-09 2019-08-22 キヤノン株式会社 情報処理システムと、その制御方法とプログラム

Also Published As

Publication number Publication date
US20240205206A1 (en) 2024-06-20
JPWO2022244150A1 (https=) 2022-11-24
JP7626212B2 (ja) 2025-02-04

Similar Documents

Publication Publication Date Title
US20250202693A1 (en) Systems and methods for deployment, management and use of dynamic cipher key systems
CN114651421B (zh) 使用临时密钥的传输层安全中的正向安全
CN108352015B (zh) 用于基于区块链的系统结合钱包管理系统的安全多方防遗失存储和加密密钥转移
CN106416123B (zh) 基于密码的认证
CN105993146B (zh) 用于与客户端设备建立安全会话的方法和装置
US20240356730A1 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
CN106664202A (zh) 提供多个设备上的加密的方法、系统和计算机程序产品
CN114785487B (zh) 基于ca和国密算法的抗量子计算https通信方法及系统
US20200235915A1 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
CN113472731B (zh) 一种针对数据库用户身份验证的双因素认证方法
WO2016114259A1 (ja) 鍵交換方法、鍵交換システム、鍵装置、端末装置、およびプログラム
CN114398618B (zh) 一种设备身份的认证方法、装置、电子设备及存储介质
Patel et al. Secure and privacy enhanced authentication framework for cloud computing
CN119995863B (zh) 一种抗量子计算的通信实现方法、系统和计算机设备
JP7626210B2 (ja) 鍵交換システム、機器、鍵交換方法、及びプログラム
JP7619446B2 (ja) 鍵交換システム、端末、鍵交換方法、及びプログラム
JP7626212B2 (ja) 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム
KR20110053578A (ko) 유비쿼터스 컴퓨팅 네트워크 환경에서 커뮤니티 컴퓨팅을 위한 디바이스 멤버 인증방법
WO2020240741A1 (ja) 鍵交換システム、通信装置、鍵交換方法及びプログラム
Zhang et al. Security Enhancement Method for MQTT Based on TEE
FI131933B1 (en) Arrangement and method for securely enabling group communication
JP7292648B2 (ja) 鍵交換システム、情報処理装置、鍵交換方法及びプログラム
JP7377495B2 (ja) 暗号システム及び方法
Soler et al. Qerberos: A protocol for secure distribution of QRNG keys
Divya et al. Security in data forwarding through elliptic curve cryptography in cloud

Legal Events

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

Ref document number: 21940766

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023522086

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18555615

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21940766

Country of ref document: EP

Kind code of ref document: A1