KEY EXCHANGE SYSTEM, TERMINAL, SERVER, 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 and a second transmitter that transmits the ciphertext to the server.

Description

[Technical field]

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

[0002] There are known protocols (e.g., Non-Patent Documents 1 to 4) that share a key (session key) via a server 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"). These protocols are server-assisted key exchange protocols in which the server authenticates the initiator and responder, and if the authentication is successful, key exchange occurs between the initiator and responder. With these protocols, the session key can be shared without even the server knowing, making it possible to realize end-to-end encrypted communication between the initiator and responder.

[0003] In each of the above protocols, the authentication method of the initiator and the responder to the server is clearly designed. For example, the key exchange described in Non-Patent Document 1, Non-Patent Document 3, and Non-Patent Document 5 is a public key-based method, and the key exchange described in Non-Patent Document 2 is an ID-based method. These authentication methods are completely different from the "ID / password", "SMS authentication", "fingerprint authentication", and "multi-factor authentication" that combines them, which are widely used these days. For this reason, in order to increase the flexibility of the authentication method, it is required to realize a server-assisted key exchange with various authentication methods such as "ID / password", "SMS authentication", "fingerprint authentication", and "multi-factor authentication".

[0004] Here, an authentication collaboration protocol called OpenID Connect (hereinafter, also referred to as "OIDC") is known (for example, Non-Patent Document 5, etc.). If the initiator and responder are authenticated to the server using the ID token of this OIDC, it is possible to realize a server-assisted key exchange with any authentication method required by the ID provider (OP: OpenID Provider). [Prior art documents] [Non-patent literature]

[0005] [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. [Non-Patent Document 3] Boyd, Colin, et al. "Offline assisted group key exchange." International Conference on Information Security. Springer, Cham, 2018. [Non-Patent Document 4] Cohn-Gordon, Katriel, et al. "A Formal Security Analysis of the Signal Messaging Protocol." 2017 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2017. [Non-Patent Document 5] OpenID Connect Core 1.0 incorporating errata set 1, Internet<URL:http: / / openid-foundation-japan.github.io / openid-connect-core-1_0.ja.html> Summary of the Invention [Problem to be solved by the invention]

[0006] However, in the protocols described in the above Non-Patent Documents 1 to 4, authentication is performed with respect to the server every time a key exchange is performed. Therefore, if OIDC is simply applied to these protocols, authentication with the ID provider must be performed every time a key exchange is performed, which is inefficient.

[0007] An embodiment of the present invention has been made in view of the above points, and has an object to realize an efficient server-assisted key exchange using an arbitrary authentication method. [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 has 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 terminals, 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 has an encryption unit which generates a ciphertext by encrypting specified data using the public key and the token generated from the nonce, and a second transmission unit which transmits the ciphertext to the server. Effect of the Invention

[0009] It is possible to realize efficient server-assisted key exchange using any authentication scheme. [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 that can realize efficient server-assisted key exchange that makes it possible to use any authentication method using OIDC and eliminates the need for re-authentication even during multiple key exchange sessions will be described.

[0012] <Preparation> First, the encryption method used in this embodiment is 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 1, “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] <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.

[0027] 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.

[0028] The terminal 10 is a user terminal that performs key exchange with one or more other terminals 10 using a server-assisted key exchange protocol. Among the multiple terminals 10, there is one terminal 10 that serves as an initiator and one or more terminals 10 that serve as responders.

[0029] 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.

[0030] The server 20 is a server that supports key exchange when 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, as described above, 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 by token-controlled public key cryptography using a nonce used in OIDC as a token. This makes it possible to perform the authentication by any authentication method requested by the OP, and also allows authentication to be performed by token-controlled public key cryptography using the same nonce during the validity period of the OIDC ID token (or during the validity period specified by the server 20), eliminating the need to perform re-authentication when each key exchange session is executed during the validity period, thereby realizing efficient key exchange.

[0031] 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 to perform user authentication using a predetermined arbitrary authentication method.

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

[0033] <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.

[0034] 2, the terminal 10 according to this embodiment includes an authentication collaboration unit 101, a key pair generation unit 102, an encryption unit 103, and a decryption unit 104. 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.

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

[0036] 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 storage unit 105 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.).

[0037] <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.

[0038] 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.

[0039] 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.

[0040] 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.).

[0041] <Authentication collaboration and key exchange processing> The authentication federation and key exchange process according to this embodiment will be described below. Here, since there are an authentication flow called an implicit flow and an authentication flow called an authorization code flow in OIDC, the case where the authentication flow is the implicit flow and the case where the authentication flow is the authorization code flow will be described. When the authentication flow is the implicit flow, the terminal 10 and the server 20 correspond to RPs (Relying Parties), and when the authentication flow is the authorization code flow, the server 20 corresponds to the RP.

[0042] <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.

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

[0044] 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.

[0045] 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."

[0046] 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).

[0047] 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).

[0048] 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.

[0049] 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.

[0050] If the verification in step S111 is successful, the terminal 10 and the server 20 exchange keys (step S112). Details of this key exchange will be described later.

[0051] <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.

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

[0053] 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 S and 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.

[0054] 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.

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

[0056] 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).

[0057] 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.

[0058] 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).

[0059] 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.

[0060] If the verification in step S213 is successful, the terminal 10 and the server 20 exchange keys (step S214). Details of this key exchange will be described later.

[0061] <Key exchange process (Example 1)> As a first embodiment of the key exchange in step S112 or step S214, a case will be described in which the key exchange described in the above non-patent documents 1 and 2 is performed. Note that for processes other than those specifically described below, please refer to non-patent documents 1 and 2.

[0062] 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 attribute-based encryption from this message m'. The subsequent processing is similar to the processing described in Non-Patent Documents 1 and 2. As a result, the terminal 10 can execute the key exchange protocol without performing user authentication again with the ID provider 30 as long as it is within the validity period of the ID token (or within the validity period specified by the server 20).

[0063] <Key exchange process (Example 2)> As a second embodiment of the key exchange in step S112 or step S214, a case will be described in which the key exchange described in the above Non-Patent Document 3 is performed. Please refer to Non-Patent Document 3 for processes other than those specifically described below.

[0064] When terminal 10 performs key exchange as the initiator Here, we will explain the changes from Fig. 10 in Non-Patent Document 3. In Stage 1, the terminal 10 sends a nonce N I When sending a message including the public key pk and the partner identifier pid (this message will be referred to as m'), the encryption unit 103 of the terminal 10 inputs the nonce used in OIDC to a predetermined hash function (e.g., SHA-256, etc.) to obtain a hash value as a token, and encrypts the message m' with the public key pk S Generate the ciphertext C encrypted with TEnc(pk S , m', token) → C to generate a ciphertext C, and transmit this ciphertext C to the server 20. Then, when the decryption unit 204 of the server 20 receives the ciphertext C, it uses the hash value obtained by inputting the nonce used in OIDC to a predetermined hash function (e.g., SHA-256, etc.) as the token token and the private key sk S Decrypt the ciphertext C with TDec(sk S ,C,token)→m' to generate message m', and derive nonce N from this message m'. I and the partner identifier pid. In this way, the server 20 authenticates the terminal 10 by being able to decrypt the token token. The subsequent processing is the same as that shown in FIG. 10 described in Non-Patent Document 3.

[0065] When terminal 10 performs key exchange as a responder Similarly, the following describes the changes from FIG. 10 in Non-Patent Document 3. In Stage 3, the terminal 10 transmits the blinded ciphertext C ~When sending a message (this message is referred to as m'') including the session identifier sid (to be precise, "~" is written directly above the C), the encryption unit 103 of the terminal 10 inputs the nonce used in OIDC into a predetermined hash function (e.g., SHA-256, etc.) to obtain a hash value, and encrypts the message m'' with the public key pk S Generate the ciphertext C encrypted with TEnc(pk S , m'', token) → C to generate a ciphertext C, and transmit this ciphertext C to the server 20. Then, when the decryption unit 204 of the server 20 receives the ciphertext C, it uses the hash value obtained by inputting the nonce used in OIDC to a predetermined hash function (e.g., SHA-256, etc.) as the token token and the private key sk S Decrypt the ciphertext C with TDec(sk S , C,token) → m'', generate message m'', and generate blinded ciphertext C ~ and extracts the session identifier sid. In this way, the server 20 authenticates the terminal 10 by being able to decrypt the token 'token'. The subsequent processing is the same as that shown in FIG. 10 in Non-Patent Document 3.

[0066] <Key exchange process (Example 3)> As a third embodiment of the key exchange in step S112 or step S214, a case will be described in which the key exchange described in the above Non-Patent Document 4 is performed. Please refer to Non-Patent Document 4 for processes other than those specifically described below.

[0067] When terminal 10 performs key exchange as the initiator Here, we will explain the changes from Fig. 1 in Non-Patent Document 4. In this case, the terminal 10 is regarded as Alice, and the communication partner is regarded as Bob.

[0068] In FIG. 1B, when the terminal 10 sends a message (this message is referred to as m') including the identifier of the communication partner to the server 20, the encryption unit 103 of the terminal 10 inputs the nonce used in OIDC into a predetermined hash function (e.g., SHA-256, etc.) to obtain a hash value, and uses the hash value as a token, and encrypts the message m' with the public key pk S Generate the ciphertext C encrypted with TEnc(pk S , m', token) → C to generate a ciphertext C, and transmit this ciphertext C to the server 20. Then, when the decryption unit 204 of the server 20 receives the ciphertext C, it uses the hash value obtained by inputting the nonce used in OIDC to a predetermined hash function (e.g., SHA-256, etc.) as the token token and the private key sk S Decrypt the ciphertext C with TDec(sk S , C, token) → m' to generate a message m', and extract the identifier of the communication partner from this message m'. In this way, the server 20 authenticates the terminal 10 by being able to decrypt the token. The subsequent processing is the same as that shown in FIG. 1 described in Non-Patent Document 4.

[0069] When terminal 10 performs key exchange as a responder Similarly, we will explain the changes from Fig. 1 in Non-Patent Document 4. In this case, the terminal 10 is regarded as Bob, and the communication partner is regarded as Alice.

[0070] In FIG. 1(a), when the terminal 10 sends a message (this message is referred to as m'') including its own public key, a signed pre-public key, and multiple temporary private keys to the server 20, the encryption unit 103 of the terminal 10 inputs the nonce used in OIDC into a predetermined hash function (e.g., SHA-256, etc.) to obtain a hash value, and converts the message m'' into a public key pk S Generate the ciphertext C encrypted with TEnc(pk S, m'', token) → C to generate a ciphertext C, and transmit this ciphertext C to the server 20. Then, when the decryption unit 204 of the server 20 receives the ciphertext C, it uses the hash value obtained by inputting the nonce used in OIDC to a predetermined hash function (e.g., SHA-256, etc.) as the token token and the private key sk S Decrypt the ciphertext C with TDec(sk S , C, token) → m'', a message m'' is generated, and the public key of the terminal 10, the signed pre-public key, and multiple temporary private keys are extracted from this message m''. In this way, the server 20 authenticates the terminal 10 by being able to decrypt the message with the token. The subsequent processing is the same as that shown in FIG. 1 described in Non-Patent Document 4.

[0071] As described above, when a session key is shared and encrypted communication is performed using the server-assisted key exchange protocols described in Non-Patent Documents 1 to 4, authentication can be performed using any authentication method requested by the OP, and re-authentication is not required during each key exchange session within a specified validity period, thereby realizing efficient key exchange. Also, since the management of private keys on the terminal 10 side, which was previously required, is no longer necessary, server-assisted key exchange can be performed from multiple different terminals 10, browsers, etc., depending on the authentication method requested by the OP.

[0072] <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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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).

[0077] 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.

[0078] 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]

[0079] 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 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 key exchange system having

2. The server, 2. The key exchange system according to claim 1, wherein if the encrypted text is correctly decrypted by the decryption unit, authentication of the terminal is deemed successful, and if the encrypted text cannot be decrypted, authentication of the terminal is deemed unsuccessful.

3. The server, a first hash calculation unit that calculates a hash value of the nonce by using a predetermined hash function; The terminal includes: a second hash calculation unit that calculates a hash value of the nonce by using the hash function; The decoding unit is decrypting the ciphertext using the hash value calculated by the first hash calculation unit as the first token; The encryption unit includes:

3. The key exchange system according to claim 1, wherein the encrypted text is generated using the hash value calculated by the second hash calculation unit as the second token.

4. 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 terminal having the above configuration.

5. A server that is connected to a plurality of terminals that perform key exchange via a communication network, and that authenticates the terminals and mediates the key exchange, 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 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 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; A server having:

6. 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 key exchange method that performs

7. A program for causing a computer to function as a terminal or a server included in the key exchange system according to any one of claims 1 to 3.

Images