KEY EXCHANGE SYSTEM, TERMINAL, KEY EXCHANGE METHOD, AND PROGRAM

Abstract

The key exchange system according to the embodiment includes a plurality of terminals that perform a key exchange and a server that performs authentication of the terminals and intermediation of the key exchange. The server includes a nonce generator for generating a nonce used when performing the authentication with each terminal through federation by OpenID Connect, a key generator for generating a public key and a secret key for token-controlled encryption, a first transmitter for transmitting the nonce and the public key to the terminal, and a decryptor for decrypting a ciphertext received from the terminal by using the secret key and a token received from the terminal. The terminal includes an encryptor that generates the ciphertext by encrypting predetermined data using the public key and the token generated from the nonce, a second transmitter that transmits the ciphertext to the server, and a long-term secret string generator that generates, by using the nonce, a long-term secret string used for the key exchange.

Description

[Technical field]

[0001] The present invention relates to a key exchange system, a terminal ,key The present invention relates to an exchange method and a program. [Background technology]

[0002] In order to enable secret communications between multiple terminals, a technique called a multi-party key exchange protocol is known that exchanges a shared key (session key) used for encryption and decryption of the secret communications (e.g., Non-Patent Documents 1 and 2). The protocols described in Non-Patent Documents 1 and 2 are server-assisted key exchange protocols, and are techniques for sharing session keys between multiple terminals via a server.

[0003] The techniques described in Non-Patent Documents 1 and 2 require a terminal to manage multiple keys in order to satisfy security requirements such as forward secrecy and short-term secret key leak resistance. Specifically, the private key of the public key cryptography or the private key of the attribute-based cryptography and the long-term secret string must be managed as long-term private keys, and the short-term secret string must be managed as a short-term private key. In particular, the long-term private key should be managed semi-permanently in the terminal. Here, forward secrecy means that even if the long-term private key is leaked, the contents of past communications are still safe, and short-term private key leak resistance means that the key shared in the session is still safe even if the random number generator that generates the random numbers used specifically in the key exchange session is vulnerable (i.e., the output of the random number generator is predictable). [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Kazuki Yoneyama, Reo Yoshida, Yuto Kawahara, Tetsutaro Kobayashi, Hitoshi Fuji, Tomohide Yamamoto, "Multi-Cast Key Distribution: Scalable, Dynamic and Provably Secure Construction," International Conference on Provable Security (ProvSec 2016), LNCS10005, pp.207-226, Nov. 2016. [Non-Patent Document 2] Yoneyama, Kazuki, et al. "Exposure-Resilient Identity-Based Dynamic Multi-Cast Key Distribution." IEICE TRANSACTIONS on Fundamentals of Electronics, Communications and Computer Sciences 101.6 (2018): 929-944. Summary of the Invention [Problem to be solved by the invention]

[0005] However, in the techniques described in Non-Patent Documents 1 and 2, when key exchange is performed on multiple unspecified terminals using one user account, it is necessary to store the long-term private key associated with the user account in advance on the terminal. In addition, it is necessary to delete the long-term private key from terminals that are no longer needed. Thus, when key exchange is performed on multiple unspecified terminals using one user account, there is a problem that the operation and management costs of the long-term private key become large. To address this problem, it is considered that a method in which the terminal does not need to possess the private key of the public key cryptography or the private key of the attribute-based cryptography can be achieved by combining an authentication collaboration protocol called OpenID Connect (hereinafter, also referred to as "OIDC"). It is also considered that a method in which the long-term secret string does not need to be possessed semi-permanently can be achieved.

[0006] The simplest method to make it unnecessary to possess the long-term secret string semi-permanently is to generate the long-term secret string at the terminal each time the key exchange protocol is executed. However, this means that the long-term secret string and the short-term secret string are generated using the same random number generator, so if the random number generator is vulnerable, both strings will be leaked, and resistance to leakage of the short-term private key cannot be achieved. For this reason, the long-term secret string and the short-term secret string must be generated using separate random number generators.

[0007] One embodiment of the present invention has been made in consideration of the above points, and aims to realize a server-assisted key exchange that reduces the operation and management costs of long-term private keys. [Means for solving the problem]

[0008] In order to achieve the above-mentioned object, a key exchange system according to one embodiment is a key exchange system including a plurality of terminals which perform key exchange, and a server which authenticates the terminals and mediates the key exchange, wherein the server includes a nonce generation unit which generates a nonce used when performing the authentication through authentication collaboration with the terminals by OpenID Connect, a key generation unit which generates a public key and a private key for a token control encryption, a first transmission unit which transmits the nonce and the public key to the terminal, and a decryption unit which decrypts a ciphertext received from the terminal, using the private key and a token received from the terminal, and the terminal includes an encryption unit which generates a ciphertext by encrypting predetermined data, using the public key and the token generated from the nonce, a second transmission unit which transmits the ciphertext to the server, and a long-term secret string generation unit which generates a long-term secret string to be used in the key exchange, using the nonce. Effect of the Invention

[0009] It is possible to realize server-assisted key exchange that reduces the operation and management costs of long-term private keys. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating an example of an overall configuration of a key exchange system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an example of a functional configuration of a terminal according to the present embodiment. [Diagram 3] FIG. 2 is a diagram illustrating an example of a functional configuration of a server according to the present embodiment. [Figure 4] FIG. 11 is a sequence diagram showing an example of authentication collaboration (implicit flow) and key exchange processing according to the embodiment. [Diagram 5] 11 is a sequence diagram showing an example of authentication collaboration (authorization code flow) and key exchange processing according to the embodiment. FIG. [Figure 6] FIG. 2 illustrates an example of a hardware configuration of a computer. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] An embodiment of the present invention will be described below. In this embodiment, a key exchange system 1 will be described that can realize a server-assisted key exchange that reduces the operation and management costs of long-term private keys by combining OIDC. Note that the server-assisted key exchange is assumed to be the technology described in Non-Patent Documents 1 or 2. For IDC, see, for example, Reference 1 "OpenID Connect Core 1.0 incorporating errata set 1, Internet<URL:http: / / openid-foundation-japan.github.io / openid-connect-core-1_0.ja.html> Please refer to " etc.

[0012] <Preparation> First, the encryption method and functions used in this embodiment are prepared.

[0013] Public Key Cryptography Public key cryptography consists of the following three algorithms (KeyGen, Enc, Dec).

[0014] KeyGen(1 κ ) → (pk,sk): 1 bit string of security parameter κ length 1 κ A key generation algorithm that takes input and outputs a key pair (pk, sk) consisting of a public key pk and a private key sk.

[0015] Enc(pk, m) → C: An encryption algorithm that takes public key pk and message m as input and outputs ciphertext C.

[0016] Dec(sk, C) → m': A decryption algorithm that takes the private key sk and the ciphertext C as input and outputs the message m'.

[0017] Public key cryptography also requires the following conditions for validity:

[0018] Validity condition: For any security parameter κ, any key pair (pk,sk) ← KeyGen(1 κ), for any message m, Dec(sk,Enc(pk,m))=m.

[0019] ≪Token-controlled public key cryptography≫ Token control public key cryptography consists of the following three algorithms (TKeyGen, TEnc, TDec).

[0020] TKeyGen(1 κ ) → (pk,sk): 1 bit string of security parameter κ length 1 κ A key generation algorithm that takes input and outputs a key pair (pk, sk) consisting of a public key pk and a private key sk.

[0021] TEnc(pk, m, token) → C: An encryption algorithm that takes public key pk, message m, and token token as input and outputs ciphertext C.

[0022] TDec(sk, C, token) → m': A decryption algorithm that takes the private key sk, the ciphertext C, and the token token as input, and outputs the message m'.

[0023] Token-controlled public key cryptography also requires the following conditions for validity:

[0024] Validity condition: For any security parameter κ, any key pair (pk, sk) ← TKeyGen(1 κ ), for any token and any message m, TDec(sk,TEnc(pk,m,token),token)=m.

[0025] An example of token-controlled public key encryption is the encryption method described in Reference 2, “Galindo, David, and Javier Herranz. “A generic construction for token controlled public key encryption.” International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2006.”

[0026] <Key derivation function> The key derivation function KDF(x, s) is a function that takes a string x and a salt s as input and outputs a key K, such that the output K for any string x is computationally indistinguishable from a key K' drawn uniformly at random from the same key space.

[0027] An example of a key derivation function is PBKDF2, which is described in Reference 3, "Moriarty, KM, B. Kaliski, and Andreas Rusch. "RFC 8018: PKCS#5: Password-Based Cryptography Specification Version 2.1." Internet Activities Board (2017)."

[0028] <Pseudorandom function> A pseudorandom function PRF(k,s) is a function that takes a key k and a string s as input and outputs a key K. It is a function such that the output of the PRF is computationally difficult to distinguish from the output of any function that has the same domain as the input to the right of the PRF and the same range of values ​​as the PRF.

[0029] An example of a pseudorandom function is HMAC, which is described in Reference 4, "Krawczyk, Hugo, Mihir Bellare, and Ran Canetti. "RFC2104: HMAC: Keyed-hashing for message authentication." (1997)."

[0030] <Overall composition> Next, the overall configuration of the key exchange system 1 according to this embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the overall configuration of the key exchange system 1 according to this embodiment.

[0031] As shown in Fig. 1, the key exchange system 1 according to this embodiment includes a plurality of terminals 10, a server 20, and an ID provider 30. These are connected to be able to communicate with each other via a communication network N such as the Internet. In the following, the terminals 10 performing key exchange are referred to as "terminal 10-1", ..., "terminal 10-N." Here, N (where N ≥ 2) is the total number of terminals.

[0032] The terminal 10 is a user terminal that performs key exchange by a server-assisted key exchange protocol with one or more other terminals 10. Examples of the terminal 10 include various devices and equipment such as a general-purpose server, a PC (personal computer), a smartphone, a tablet terminal, a wearable device, an in-vehicle device, an industrial device, a home appliance, and a robot.

[0033] The server 20 is a server that supports key exchange when a key exchange is performed between multiple terminals 10 using a server-assisted key exchange protocol (i.e., mediates key exchange between multiple terminals 10). Here, when key exchange is performed between multiple terminals 10, the server 20 needs to authenticate each of these terminals 10 (signature verification, encryption, etc.). In this embodiment, this authentication is performed using token-controlled public key cryptography with a nonce used in OIDC as a token, and a long-term secret string is generated from the nonce. This eliminates the need for each terminal 10 to hold a private key for public key cryptography or a private key for attribute-based cryptography, and also eliminates the need for each terminal 10 to semi-permanently hold a long-term secret string. This realizes server-assisted key exchange that reduces the operation and management costs of long-term private keys.

[0034] In addition to the above, in this embodiment, each terminal 10 can be authenticated using any authentication method requested by the OP, and authentication can be performed using token-controlled public key cryptography using the same nonce within the validity period of the OIDC ID token (or within the validity period specified by the server 20), so there is no need to perform re-authentication when each key exchange session is executed within the validity period.

[0035] The ID provider 30 is a server or the like that functions as an OP (OpenID Provider) of OIDC. The ID provider 30 requests the terminal 10 to perform user authentication using a predetermined arbitrary authentication method.

[0036] <Functional configuration> Next, the functional configurations of the terminal 10 and the server 20 according to the present embodiment will be described.

[0037] <Terminal 10> The functional configuration of the terminal 10 according to this embodiment will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the functional configuration of the terminal 10 according to this embodiment.

[0038] 2, the terminal 10 according to this embodiment includes an authentication collaboration unit 101, a key pair generation unit 102, an encryption unit 103, a decryption unit 104, and a long-term secret string generation unit 105. Each of these units is realized by, for example, processing executed by a processor such as a CPU (Central Processing Unit) by one or more programs installed in the terminal 10.

[0039] Moreover, the terminal 10 according to the present embodiment includes a storage unit 106. The storage unit 106 is realized by various memory devices such as a hard disk drive (HDD), a solid state drive (SSD), or a flash memory.

[0040] The authentication collaboration unit 101 executes various processes for performing authentication collaboration 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 an encryption algorithm TEnc using a hash value of a nonce used in OIDC as a token to generate ciphertext. The decryption unit 104 executes a decryption algorithm Dec to decrypt the ciphertext. The long-term secret string generation unit 105 generates a long-term secret string from a nonce used in OIDC. The storage unit 106 stores information necessary for each of the above units to execute various processes and the execution results thereof (for example, various keys, nonce, ID token, long-term secret string, etc.).

[0041] <Server 20> The functional configuration of the server 20 according to this embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the functional configuration of the server 20 according to this embodiment.

[0042] 3, the server 20 according to this embodiment includes an authentication collaboration unit 201, a key pair generation unit 202, an encryption unit 203, and a decryption unit 204. Each of these units is realized by, for example, processing performed by a processor such as a CPU by one or more programs installed in the server 20.

[0043] Moreover, the server 20 according to this embodiment has a storage unit 205. The storage unit 205 is realized by various memory devices such as an HDD, an SSD, a flash memory, etc. Note that the storage unit 205 may be realized by a storage device connected to the server 20 via a communication network, for example.

[0044] The authentication collaboration unit 201 executes various processes for performing authentication collaboration by OIDC. In particular, the authentication collaboration 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 an encryption algorithm Enc to generate ciphertext. The decryption unit 204 executes a decryption algorithm TDec to decrypt the ciphertext. At this time, the decryption unit 204 decrypts the ciphertext using a hash value of the nonce it generated. The storage unit 205 stores information necessary for each of the above units to execute various processes and the execution results thereof (for example, various keys, nonces, ID tokens, etc.).

[0045] <Authentication collaboration and key exchange processing> The authentication federation and key exchange process according to this embodiment will be described below. In the server-assisted key exchange protocol described in Non-Patent Documents 1 and 2, as described above, the long-term secret keys held by each terminal 10 include the private key of public key cryptography or attribute-based cryptography and the long-term secret strings st and st'. These long-term secret strings are used as inputs to the twisted pseudorandom function in the Dist / Join / Leave phases together with short-term secret strings generated in each phase. In Non-Patent Document 1, the private key of public key cryptography and the long-term secret strings st and st' are the long-term secret keys, and in Non-Patent Document 2, the private key of attribute-based cryptography and the long-term secret strings st and st' are the long-term secret keys.

[0046] The above long-term secret strings st and st' are generated by each terminal 10 at the time of setup, but in this embodiment, these long-term secret strings st and st' are generated from a nonce. Therefore, each terminal 10 does not retain the long-term secret strings st and st' semi-permanently, but regenerates the long-term secret strings st and st' for each validity period of the OIDC ID token (or the validity period specified by the server 20) and retains them only for that period. However, the long-term secret strings st and st' that have been generated once may be retained semi-permanently.

[0047] In OIDC, there are authentication flows called implicit flow and authorization code flow. Therefore, the following describes the cases where the authentication flow is the implicit flow and the authorization code flow. When the authentication flow is the implicit flow, the terminal 10 and the server 20 correspond to the RP (Relying Party), and when the authentication flow is the authorization code flow, the server 20 corresponds to the RP.

[0048] <If authentication integration is implicit flow> The authentication collaboration and key exchange process in the case where the authentication flow is an implicit flow will be described with reference to Fig. 4. Fig. 4 is a sequence diagram showing an example of the authentication collaboration (implicit flow) and key exchange process according to this embodiment.

[0049] The authentication coordinating unit 101 of the terminal 10 transmits an authentication request to the server 20 (step S101).

[0050] When the authentication request is received, the authentication collaboration unit 201 of the server 20 generates a nonce to be used in OIDC (step S102). κ )→(pk S ,sk S ) public key pk S and the private key sk S The key pair (pk S ,sk S) (step S103). Next, 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 collaboration unit 201 generates a nonce and a public key pk S Include this in the redirect instructions.

[0051] When the authentication collaborating unit 101 of the terminal 10 receives the redirect instruction, it 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 collaborating unit 101 transmits a nonce to the ID provider 30 during user authentication. Note that examples of the authentication method requested by the ID provider 30 include various authentication methods such as "ID and password," "SMS authentication," "fingerprint authentication," and "multi-factor authentication."

[0052] If the above user authentication is successful, an ID token signed by the ID provider 30 and with a nonce is returned from the ID provider 30 to the terminal 10 (step S106).

[0053] When the key pair generation unit 102 of the terminal 10 receives the ID token from the ID provider 30, the key pair generation unit 102 executes KeyGen(1 κ )→(pk C ,sk C ) public key pk C and the private key sk C The key pair (pk C ,sk C Next, the encryption unit 103 of the terminal 10 generates a hash value obtained by inputting the nonce to a predetermined hash function (for example, SHA-256) as a token, and generates the ID token and the public key pk C Message m containing public key pk S In other words, the encryption unit 103 generates a ciphertext C encrypted by TEnc(pk S, m, token) → C to generate ciphertext C. Then, the encryption unit 103 of the terminal 10 transmits the ciphertext C to the server 20 (step S109).

[0054] When the decryption unit 204 of the server 20 receives the ciphertext C, the decryption unit 204 inputs the nonce to a predetermined hash function (e.g., SHA-256) to obtain a hash value as a token, and decrypts the ciphertext C with the private key sk. S That is, the decoding unit 204 decodes the TDec(sk S ,C,token)→m to obtain message m. This allows obtaining the ID token and public key pk C is obtained.

[0055] The authentication collaboration unit 201 of the server 20 verifies the ID token obtained in the above step S110 (step S111). That is, the authentication collaboration unit 201 verifies the signature of the ID token, and then verifies that the nonce assigned to the ID token matches the nonce generated in the above step S102.

[0056] Next, if the verification in the above step S111 is successful, the long-term secret string generation unit 105 of the terminal 10 generates long-term secret strings st and st' from the nonce by either the following method 1 or method 2 (step S112).

[0057] Method 1: The output of the key derivation function KDF, which takes a nonce and a salt as input, is set as a long-term secret string. In other words, with two salts s and s', long-term secret strings st and st' are generated by st = KDF(nonce,s), st' = KDF(nonce,s'). Note that the salts s and s' can be, for example, s = '0001', s' = '0002', etc.

[0058] Method 2: The output of a pseudorandom function PRF that takes a nonce and a character string as input is set as a long-term secret string. In other words, with two character strings s and s', long-term secret strings st and st' are generated by st = PRF(nonce,s), st' = PRF(nonce,s'). Note that the character strings s and s' may be, for example, s = '0001', s' = '0002', etc.

[0059] In this way, by generating a long-term secret string from a random number (i.e., a nonce) generated by a random number generator different from the random number generator used by terminal 10, the long-term secret string will not be leaked even if the random number generator of terminal 10 is vulnerable, thereby realizing a secure key exchange. In addition, since the OIDC nonce is used, there is no need to perform extra communication or calculations to generate the long-term secret string, and it is possible to generate the long-term secret string efficiently.

[0060] Then, when the long-term secret strings st and st' are generated in step S112, the terminal 10 and the server 20 exchange keys (step S113). Details of this key exchange will be described later.

[0061] <If the authentication integration is the authorization code flow> The authentication collaboration and key exchange process in the case where the authentication collaboration is an authorization code flow will be described with reference to Fig. 5. Fig. 5 is a sequence diagram showing an example of the authentication collaboration (authorization code flow) and key exchange process according to this embodiment.

[0062] The authentication coordinating unit 101 of the terminal 10 transmits an authentication request to the server 20 (step S201).

[0063] When the authentication request is received, the authentication collaboration unit 201 of the server 20 generates a nonce to be used in OIDC (step S202). κ )→(pk S ,sk S ) public key pk Sand the private key sk S The key pair (pk S ,sk S ) (step S203). Next, 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 collaboration unit 201 generates a nonce and a public key pk S Include this in the redirect instructions.

[0064] When the authentication sharing unit 101 of the terminal 10 receives the redirect instruction, it redirects the terminal 10 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 sharing unit 101 transmits a nonce to the ID provider 30 during user authentication.

[0065] If the above user authentication is successful, the ID provider 30 returns an authorization code to the terminal 10 (step S206).

[0066] When the key pair generation unit 102 of the terminal 10 receives the authorization code from the ID provider 30, the key pair generation unit 102 executes KeyGen(1 κ )→(pk C ,sk C ) public key pk C and the private key sk C The key pair (pk C ,sk C Next, the encryption unit 103 of the terminal 10 generates a hash value obtained by inputting the nonce to a predetermined hash function (for example, SHA-256) as a token, and generates the authorization code and the public key pk C Message m containing public key pk S In other words, the encryption unit 103 generates a ciphertext C encrypted by TEnc(pk S , m, token) → C to generate ciphertext C. Then, the encryption unit 103 of the terminal 10 transmits the ciphertext C to the server 20 (step S209).

[0067] When the decryption unit 204 of the server 20 receives the ciphertext C, the decryption unit 204 inputs the nonce to a predetermined hash function (e.g., SHA-256) to obtain a hash value as a token, and decrypts the ciphertext C with the private key sk. S That is, the decoding unit 204 decodes the TDec(sk S ,C,token)→m to obtain message m. This allows obtaining the authorization code and public key pk C is obtained.

[0068] Next, the authentication collaboration unit 201 of the server 20 transmits the authorization code obtained in step S210 above to the ID provider 30 (step S211). As a result, an ID token with a signature and a nonce by the ID provider 30 is returned from the ID provider 30 to the server 20 (step S212).

[0069] The authentication collaboration unit 201 of the server 20 verifies the ID token obtained in the above step S212 (step S213). That is, the authentication collaboration unit 201 verifies the signature of the ID token, and then verifies that the nonce assigned to the ID token matches the nonce generated in the above step S202.

[0070] Next, if the verification in the above step S213 is successful, the long-term secret string generation unit 105 of the terminal 10 generates long-term secret strings st and st' from the nonce by either method 1 or method 2, as in step S112 of FIG. 4 (step S214).

[0071] Then, when the long-term secret strings st and st' are generated in step S214, the terminal 10 and the server 20 exchange keys (step S215). Details of this key exchange will be described later.

[0072] <Key exchange process> The key exchange in step S113 or step S215 above will be described. Here, the case where the key exchange described in the above non-patent documents 1 and 2 is performed will be described. Note that for processes other than those specifically described below, please refer to non-patent documents 1 and 2.

[0073] In the key exchange described in Non-Patent Documents 1 and 2, the server 20 first transmits a MAC key and a key for attribute-based encryption to the terminal 10. At this time, the encryption unit 203 of the server 20 encrypts a message m' including these keys with a public key pk C Generate the ciphertext C encrypted with pk C ,m')→C to generate ciphertext C, and transmits the ciphertext C to the terminal 10. The decryption unit 104 of the terminal 10 then decrypts the ciphertext C, that is, Dec(sk C , C) → m' to generate a message m', and extract the MAC key and the key for the attribute-based encryption from this message m'. The subsequent processing is the same as that described in Non-Patent Documents 1 and 2.

[0074] <Hardware configuration> Finally, the hardware configuration of the terminal 10 and the server 20 according to the present embodiment will be described. The terminal 10 and the server 20 according to the present embodiment are realized, for example, by the hardware configuration of a computer 500 shown in Fig. 6. Fig. 6 is a diagram showing an example of the hardware configuration of the computer 500.

[0075] 6 includes 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 connected to each other via a bus 507 so as to be able to communicate with each other.

[0076] The input device 501 is, for example, a keyboard, a mouse, a touch panel, etc. The display device 502 is, for example, a display, etc. Note that the computer 500 does not necessarily have to have at least one of the input device 501 and the display device 502, for example.

[0077] The external I / F 503 is an interface with an external device such as a recording medium 503a. The computer 500 can read and write data from and to the recording medium 503a via the external I / F 503. Examples of the recording medium 503a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0078] The communication I / F 504 is an interface for connecting the computer 500 to a communication network. The processor 505 is, for example, various types of arithmetic devices such as a CPU. The memory device 506 is, for example, various types of storage devices such as an HDD, SSD, flash memory, RAM (Random Access Memory), and ROM (Read Only Memory).

[0079] The terminal 10 and the server 20 according to this embodiment can realize the above-mentioned authentication collaboration and key exchange process by having the hardware configuration shown in Fig. 6. Note that the hardware configuration shown in Fig. 6 is an example, and the computer 500 may have, for example, multiple processors, multiple memory devices, or may have various hardware configurations.

[0080] The present invention is not limited to the above-described embodiments specifically disclosed, and various modifications, changes, combinations with known technologies, etc. are possible without departing from the scope of the claims. [Explanation of symbols]

[0081] 1. Key Exchange System 10 Terminal 20 Servers 30 Identity Providers 101 Authentication Collaboration Department 102 Key Pair Generation Unit 103 Encryption section 104 Decoding section 105 Long-term secret string generator 106 Storage section 201 Authentication Collaboration Department 202 Key Pair Generation Unit 203 Encryption section 204 Decoding section 205 Storage section N Communication Network

Claims

1. A key exchange system including a plurality of terminals that perform key exchange, and a server that authenticates the terminals and mediates the key exchange, The server, a nonce generation unit that generates a nonce used when performing the authentication through authentication collaboration with the terminal by OpenID Connect; a key generation unit that generates a public key and a private key for token control encryption; a first transmission unit that transmits the nonce and the public key to the terminal; a decryption unit that generates a plaintext message by decrypting a ciphertext received from the terminal using the private key and a first token generated from the nonce; a verification unit that verifies whether the authentication federation has been successful based on authentication federation information included in the message; The terminal includes: an encryption unit that generates a ciphertext by encrypting a message including authentication federation information to be used for the authentication federation, by using the public key and a second token generated from a nonce received from the server; A second transmission unit that transmits the ciphertext to the server; a long-term secret string generator that uses the nonce to generate a long-term secret string for use in the key exchange; A key exchange system having

2. The long term secret string generator comprises:

2. The key exchange system of claim 1, wherein the long-term secret string is generated by a key derivation function or a pseudorandom function that takes the nonce as input.

3. A terminal connected to another terminal that performs key exchange and a server that authenticates each terminal and mediates the key exchange via a communication network, an encryption unit that generates a ciphertext by encrypting a message including authentication federation information to be used in the authentication federation, using a public key of a token control cipher that is generated by the server and a token generated from a nonce used when performing the authentication by authentication federation with the server using OpenID Connect; A transmission unit that transmits the ciphertext to the server; a long-term secret string generator that uses the nonce to generate a long-term secret string for use in the key exchange; A terminal having the above configuration.

4. 1. A key exchange method used in a key exchange system including a plurality of terminals that perform key exchange and a server that authenticates the terminals and mediates the key exchange, comprising: The server, a nonce generation step of generating a nonce to be used when performing the authentication by authentication federation with the terminal using OpenID Connect; a key generation step for generating public and private keys for a token-controlled cipher; a first transmission step of transmitting the nonce and the public key to the terminal; a decryption step of generating a plaintext message by decrypting a ciphertext received from the terminal using the private key and a first token generated from the nonce; a verification step of verifying whether the authentication federation has been successful based on authentication federation information included in the message; The terminal, an encryption step of generating a ciphertext by encrypting a message including authentication federation information to be used for the authentication federation, by using the public key and a second token generated from a nonce received from the server; a second transmission step of transmitting the ciphertext to the server; a long-term secret string generation step using said nonce to generate a long-term secret string for use in said key exchange; A key exchange method that performs

5. A program for causing a computer to function as a terminal or a server included in the key exchange system according to claim 1 or 2.

Images