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

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

Info

Publication number
WO2022244151A1
WO2022244151A1 PCT/JP2021/019017 JP2021019017W WO2022244151A1 WO 2022244151 A1 WO2022244151 A1 WO 2022244151A1 JP 2021019017 W JP2021019017 W JP 2021019017W WO 2022244151 A1 WO2022244151 A1 WO 2022244151A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
terminal
nonce
server
key exchange
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/019017
Other languages
English (en)
French (fr)
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 JP2023522087A priority Critical patent/JP7619446B2/ja
Priority to PCT/JP2021/019017 priority patent/WO2022244151A1/ja
Priority to US18/555,610 priority patent/US20240129111A1/en
Publication of WO2022244151A1 publication Critical patent/WO2022244151A1/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/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
    • 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)
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions

Definitions

  • the present invention relates to a key exchange system, terminal, server, key exchange method, and program.
  • Non-Patent Documents 1 and 2 In order to enable confidential communication between many terminals, a technique called a multi-party key exchange protocol is known that exchanges a shared key (session key) used for encryption/decryption of this confidential communication.
  • the protocols described in Non-Patent Documents 1 and 2 are server-assisted key exchange protocols, which are techniques for sharing a session key between a plurality of terminals via a server.
  • Non-Patent Documents 1 and 2 require multiple keys to be managed by the terminal in order to satisfy security such as forward secrecy and short-term secret key leakage resistance. Specifically, it is necessary to manage a secret key for public key cryptography or a secret key for attribute-based cryptography and a long-term secret string as a long-term secret key, and manage a short-term secret string as a short-term secret key.
  • the long-term private key should be semi-permanently managed by the terminal.
  • forward secrecy means that past communication contents are still safe even if the long-term secret key is leaked. is weak (i.e. if the output of the random number generator is predictable), the keys shared in that session are still secure.
  • Non-Patent Documents 1 and 2 when key exchange is performed with a plurality of unspecified terminals using one user account, the long-term private key associated with the user account is stored in advance. It should be stored in the terminal. Also, long-term private keys must be deleted from terminals that are no longer needed. In this way, when a single user account is used to perform key exchange with a plurality of unspecified terminals, there is a problem that the long-term secret key operation and management cost increases.
  • OpenID Connect an authentication federation protocol called OpenID Connect (hereinafter also referred to as "OIDC")
  • OIDC OpenID Connect
  • the simplest method for making 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.
  • An embodiment of the present invention has been made in view of the above points, and aims to realize server-assisted key exchange that reduces the operation and management costs of long-term secret keys.
  • 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.
  • an encryption unit for generating a ciphertext by encrypting predetermined data using the public key and a token generated from the nonce; and a long-term secret string generator for using the nonce to generate a long-term secret string for use in the key exchange.
  • 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;
  • Non-Patent Document 1 a key exchange system 1 that can implement server-assisted key exchange with reduced long-term secret key operation and management costs by combining OIDC will be described.
  • IDC 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.
  • 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.
  • the key derivation function KDF(x, s) is a function that takes a character string x and a salt s as input and outputs a key K, and the output K for any character string x is uniformly randomly extracted from the same key space. It is a function that is computationally difficult to distinguish from the key K'.
  • the pseudo-random function PRF (k, s) is a function that inputs a key k and a character string s and outputs a key K, has the same domain as the output of the PRF and the input on the right side of the PRF, and A function whose output is computationally indistinguishable from any function with the same range.
  • 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.
  • Examples of the terminal 10 include general-purpose servers, PCs (personal computers), smartphones, tablet terminals, wearable devices, vehicle-mounted devices, industrial devices, household appliances, and robots.
  • 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.
  • server-assisted key exchange that reduces the cost of operating and managing long-term secret keys is realized.
  • each terminal 10 can be authenticated by any authentication method requested by the OP, and within the valid period of the OIDC ID token (or the valid period specified by the server 20) Since authentication can be performed by token-controlled public-key cryptography using the same nonce, re-authentication is not required when executing each key exchange session within the validity period.
  • the ID provider 30 is a server or the like that functions as an OIDC OP (OpenID Provider).
  • OIDC OP OpenID Provider
  • 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, a decryption unit 104, and a long-term secret string generation unit 105. 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 106 .
  • the storage unit 106 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.
  • a long-term secret string generator 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, execution results thereof, etc. (for example, various keys, nonces, ID tokens, long-term secret strings, 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.).
  • the long-term secret key held by each terminal 10 is a secret key of public key cryptography or attribute-based cryptography and a long-term There are secret strings st and st'. These long-term secret strings are used in the Dist/Join/Leave phases, along with short-term secret strings generated in each phase, to input twisted pseudo-random functions.
  • Non-Patent Document 1 the secret key for public key encryption and long-term secret strings st and st' are long-term secret keys, and in Non-Patent Document 2, the secret key for attribute-based encryption and long-term secret strings st and st' are the long-term secret keys.
  • a long-term private key the secret key for public key encryption and long-term secret strings st and st' are long-term secret keys.
  • each terminal 10 does not store the long-term secret strings st and st′ semi-permanently, but uses the long-term secret strings st and st for each period of validity of the OIDC ID token (or the period of validity specified by the server 20). ' and keep it only for that period. However, once generated long-term secret strings st and st' may be held semi-permanently.
  • OIDC has an authentication flow called implicit flow and an authentication flow called authorization code flow. For this reason, 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 below.
  • the terminal 10 and the server 20 correspond to RP (Relying Party) when the authentication flow is the implicit flow, and the server 20 corresponds to the RP when it is the authorization code flow.
  • 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 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 below. (Step S112).
  • step S113 when the long-term secret strings st and st' are generated in step S112 above, the terminal 10 and the server 20 perform key exchange (step S113). 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 S213 the long-term secret string generation unit 105 of the terminal 10 generates a long-term secret string from the nonce by either method 1 or method 2, as in step S112 in FIG. st and st' are generated (step S214).
  • step S215 when the long-term secret strings st and st' are generated in step S214 above, the terminal 10 and the server 20 perform key exchange (step S215). The details of this key exchange will be described later.
  • 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.
  • 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.
  • Reference Signs List 1 key exchange system 10 terminal 20 server 30 ID provider 101 authentication collaboration unit 102 key pair generation unit 103 encryption unit 104 decryption unit 105 long-term secret string generation unit 106 storage unit 201 authentication collaboration unit 202 key pair generation unit 203 encryption unit 204 Decoding unit 205 Storage unit N Communication network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

一実施形態に係る鍵交換システムは、鍵交換を行う複数の端末と、前記端末の認証と前記鍵交換の仲介とを行うサーバとが含まれる鍵交換システムであって、前記サーバは、前記端末との間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスを生成するノンス生成部と、トークン制御暗号の公開鍵と秘密鍵とを生成する鍵生成部と、前記ノンスと、前記公開鍵とを前記端末に送信する第１の送信部と、前記秘密鍵と、前記端末から受信したトークンとを用いて、前記端末から受信した暗号文を復号する復号部と、を有し、前記端末は、前記公開鍵と、前記ノンスから生成されたトークンとを用いて、所定のデータを暗号化した暗号文を生成する暗号化部と、前記暗号文を前記サーバに送信する第２の送信部と、前記ノンスを用いて、前記鍵交換で使用する長期秘密ストリングを生成する長期秘密ストリング生成部と、を有する。

Description

鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム
　本発明は、鍵交換システム、端末、サーバ、鍵交換方法、及びプログラムに関する。
　多数の端末間で秘匿通信を行えるようにするために、この秘匿通信の暗号化・復号に利用される共有鍵（セッション鍵）を交換する多者間鍵交換プロトコルと呼ばれる技術が知られている（例えば、非特許文献１及び２等）。非特許文献１及び２に記載されているプロトコルはサーバ支援型の鍵交換プロトコルであり、サーバを介して複数の端末間でセッション鍵を共有する技術である。
　非特許文献１及び２に記載されている技術は、前方秘匿性や短期秘密鍵漏洩耐性といった安全性を満たすために、複数の鍵を端末で管理する必要がある。具体的には、公開鍵暗号の秘密鍵又は属性ベース暗号の秘密鍵と長期秘密ストリングとを長期秘密鍵として管理し、短期秘密ストリングを短期秘密鍵として管理する必要がある。特に、長期秘密鍵は端末で半永続的に管理しておくべきものである。ここで、前方秘匿性とは長期秘密鍵が漏洩しても過去の通信内容はなおも安全というものであり、短期秘密鍵漏洩耐性とは鍵交換セッション固有で利用される乱数を生成する乱数生成器が脆弱（つまり、乱数生成器の出力に予測可能性がある場合）であってもそのセッションで共有された鍵はなおも安全というものである。
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. 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.
　しかしながら、非特許文献１及び２に記載されている技術では、１つのユーザアカウントを用いて複数の不特定の端末で鍵交換を実行する場合には、ユーザアカウントに紐づく長期秘密鍵を予めその端末に格納しておく必要がある。また、不要となった端末からは長期秘密鍵を削除する必要がある。このように、１つのユーザアカウントを用いて複数の不特定の端末で鍵交換を実行する場合には長期秘密鍵の運用・管理コストが大きくなる、という問題がある。この問題に対して、ＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔ（以下、「ＯＩＤＣ」ともいう。）と呼ばれる認証連携プロトコルを組み合わせることで、公開鍵暗号の秘密鍵又は属性ベース暗号の秘密鍵を端末が所持する必要のない方式にすることができると考えられる。また、長期秘密ストリングに関しても半永続的に所持する必要のない方式にすることができると考えられる。
　なお、長期秘密ストリングを半永続的に所持する必要のない方式にする最も単純な方法としては、鍵交換プロトコルを実行するたびに、長期秘密ストリングを端末で生成することである。一方で、これは、長期秘密ストリングと短期秘密ストリングとを同一の乱数生成器で生成していることになるため、乱数生成器が脆弱であった場合には両方のストリングが漏洩してしまうことになり、短期秘密鍵漏洩耐性を満たすことができない。このため、長期秘密ストリングと短期秘密ストリングはそれぞれ別の乱数生成器から生成する必要がある。
　本発明の一実施形態は、上記の点に鑑みてなされたもので、長期秘密鍵の運用・管理コストを削減したサーバ支援型の鍵交換を実現することを目的とする。
　上記目的を達成するため、一実施形態に係る鍵交換システムは、鍵交換を行う複数の端末と、前記端末の認証と前記鍵交換の仲介とを行うサーバとが含まれる鍵交換システムであって、前記サーバは、前記端末との間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスを生成するノンス生成部と、トークン制御暗号の公開鍵と秘密鍵とを生成する鍵生成部と、前記ノンスと、前記公開鍵とを前記端末に送信する第１の送信部と、前記秘密鍵と、前記端末から受信したトークンとを用いて、前記端末から受信した暗号文を復号する復号部と、を有し、前記端末は、前記公開鍵と、前記ノンスから生成されたトークンとを用いて、所定のデータを暗号化した暗号文を生成する暗号化部と、前記暗号文を前記サーバに送信する第２の送信部と、前記ノンスを用いて、前記鍵交換で使用する長期秘密ストリングを生成する長期秘密ストリング生成部と、を有する。
　長期秘密鍵の運用・管理コストを削減したサーバ支援型の鍵交換を実現することができる。
本実施形態に係る鍵交換システムの全体構成の一例を示す図である。 本実施形態に係る端末の機能構成の一例を示す図である。 本実施形態に係るサーバの機能構成の一例を示す図である。 本実施形態に係る認証連携（インプリシットフロー）及び鍵交換処理の一例を示すシーケンス図である。 本実施形態に係る認証連携（認可コードフロー）及び鍵交換処理の一例を示すシーケンス図である。 コンピュータのハードウェア構成の一例を示す図である。
　以下、本発明の一実施形態について説明する。本実施形態では、ＯＩＤＣを組み合わせることで、長期秘密鍵の運用・管理コストを削減したサーバ支援型の鍵交換を実現することができる鍵交換システム１について説明する。なお、サーバ支援型の鍵交換としては、非特許文献１又は２に記載されている技術を想定する。ＩＤＣについては、例えば、参考文献１「OpenID Connect Core 1.0 incorporating errata set 1, インターネット＜ＵＲＬ：http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html＞」等を参照されたい。
　＜準備＞
　まず、本実施形態で利用する暗号方式や関数を準備する。
　　≪公開鍵暗号≫
　公開鍵暗号は、以下の３つのアルゴリズム（ＫｅｙＧｅｎ，Ｅｎｃ，Ｄｅｃ）で構成される。
　ＫｅｙＧｅｎ（１κ）→（ｐｋ，ｓｋ）：セキュリティパラメータκ長の１ビット列１κを入力とし、公開鍵ｐｋと秘密鍵ｓｋの鍵ペア（ｐｋ，ｓｋ）を出力する鍵生成アルゴリズム。
　Ｅｎｃ（ｐｋ，ｍ）→Ｃ：公開鍵ｐｋとメッセージｍを入力とし、暗号文Ｃを出力する暗号化アルゴリズム。
　Ｄｅｃ（ｓｋ，Ｃ）→ｍ'：秘密鍵ｓｋと暗号文Ｃを入力とし、メッセージｍ'を出力する復号アルゴリズム。
　公開鍵暗号は、正当性として以下の条件も必要とする。
　正当性条件：任意のセキュリティパラメータκ、任意の鍵ペア（ｐｋ，ｓｋ）←ＫｅｙＧｅｎ（１κ）、任意のメッセージｍに対して、Ｄｅｃ（ｓｋ，Ｅｎｃ（ｐｋ，ｍ））＝ｍが成り立つ。
　　≪トークン制御公開鍵暗号≫
　トークン制御公開鍵暗号は、以下の３つのアルゴリズム（ＴＫｅｙＧｅｎ，ＴＥｎｃ，ＴＤｅｃ）で構成される。
　ＴＫｅｙＧｅｎ（１κ）→（ｐｋ，ｓｋ）：セキュリティパラメータκ長の１ビット列１κを入力とし、公開鍵ｐｋと秘密鍵ｓｋの鍵ペア（ｐｋ，ｓｋ）を出力する鍵生成アルゴリズム。
　ＴＥｎｃ（ｐｋ，ｍ，ｔｏｋｅｎ）→Ｃ：公開鍵ｐｋとメッセージｍとトークンｔｏｋｅｎを入力とし、暗号文Ｃを出力する暗号化アルゴリズム。
　ＴＤｅｃ（ｓｋ，Ｃ，ｔｏｋｅｎ）→ｍ'：秘密鍵ｓｋと暗号文Ｃとトークンｔｏｋｅｎを入力とし、メッセージｍ'を出力する復号アルゴリズム。
　トークン制御公開鍵暗号は、正当性として以下の条件も必要とする。
　正当性条件：任意のセキュリティパラメータκ、任意の鍵ペア（ｐｋ，ｓｋ）←ＴＫｅｙＧｅｎ（１κ）、任意のトークンｔｏｋｅｎ、任意のメッセージｍに対して、ＴＤｅｃ（ｓｋ，ＴＥｎｃ（ｐｋ，ｍ，ｔｏｋｅｎ），ｔｏｋｅｎ）＝ｍが成り立つ。
　なお、トークン制御公開鍵暗号の一例としては、例えば、参考文献２「Galindo, David, and Javier Herranz. "A generic construction for tokencontrolled public key encryption." International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2006.」に記載されている暗号方式等が挙げられる。
　　≪鍵導出関数≫
　鍵導出関数ＫＤＦ（ｘ，ｓ）は文字列ｘとソルトｓを入力とし、鍵Ｋを出力する関数であり、任意の文字列ｘに対する出力Ｋが、同じ鍵空間から一様ランダムに抽出された鍵Ｋ'と計算量的に識別困難であるような関数のことである。
　なお、鍵導出関数の一例としては、例えば、参考文献３「Moriarty, K. M., B. Kaliski, and Andreas Rusch. "RFC 8018: PKCS#5: Password-Based Cryptography Specification Version 2.1." Internet Activities Board (2017).」に記載されているＰＢＫＤＦ２等が挙げられる。
　　≪疑似ランダム関数≫
　疑似ランダム関数ＰＲＦ（ｋ，ｓ）は鍵ｋと文字列ｓを入力とし、鍵Ｋを出力する関数であり、ＰＲＦの出力と、ＰＲＦの右側の入力と同じ定義域を持ち、かつ、ＰＲＦと同じ値域を持つ任意の関数の出力とが計算量的に識別困難であるような関数のことである。
　なお、疑似ランダム関数の一例としては、例えば、参考文献４「Krawczyk, Hugo, Mihir Bellare, and Ran Canetti. "RFC2104: HMAC: Keyed-hashing for message authentication." (1997).」に記載されているＨＭＡＣ等が挙げられる。
　＜全体構成＞
　次に、本実施形態に係る鍵交換システム１の全体構成について、図１を参照しながら説明する。図１は、本実施形態に係る鍵交換システム１の全体構成の一例を示す図である。
　図１に示すように、本実施形態に係る鍵交換システム１には、複数の端末１０と、サーバ２０と、ＩＤプロバイダ３０とが含まれる。これらは、例えば、インターネット等の通信ネットワークＮを介して通信可能に接続される。なお、以下では、鍵交換を行う各端末１０の各々を「端末１０－１」、・・・、「端末１０－Ｎ」とする。ここで、Ｎ（ただし、Ｎ≧２）は端末の総数である。
　端末１０は、１以上の他の端末１０との間でサーバ支援型の鍵交換プロトコルにより鍵交換を行うユーザ端末である。なお、端末１０としては、例えば、汎用サーバ、ＰＣ（パーソナルコンピュータ）、スマートフォン、タブレット端末、ウェアラブルデバイス、車載器、産業用機器、家電製品、ロボット等といった各種装置や機器等が挙げられる。
　サーバ２０は、サーバ支援型の鍵交換プロトコルにより複数の端末１０間で鍵交換を行う際にその鍵交換を支援する（つまり、複数の端末１０間での鍵交換を仲介する）サーバである。ここで、複数の端末１０間で鍵交換を行う際に、サーバ２０は、これらの各端末１０を認証（署名検証、暗号化等）する必要がある。本実施形態では、この認証をＯＩＤＣで利用されるノンスをトークンとしたトークン制御公開鍵暗号により行うと共に、当該ノンスから長期秘密ストリングを生成する。これにより、各端末１０は、公開鍵暗号の秘密鍵又は属性ベース暗号の秘密鍵を保持する必要がなくなると共に、長期秘密ストリングも半永続的に所持する必要はなくなる。このため、長期秘密鍵の運用・管理コストを削減したサーバ支援型の鍵交換が実現される。
　なお、上記に加えて、本実施形態では、ＯＰが要求する任意の認証方式によって各端末１０の認証が可能になると共に、ＯＩＤＣのＩＤトークンの有効期間内（又は、サーバ２０が指定した有効期間内）では同一のノンスを使用したトークン制御公開鍵暗号により認証を行うことができるため、当該有効期間内の各鍵交換セッション実行時では再認証を行う必要もなくなる。
　ＩＤプロバイダ３０は、ＯＩＤＣのＯＰ（OpenID Provider）として機能するサーバ等である。ＩＤプロバイダ３０は、予め決められた任意の認証方式によるユーザ認証を端末１０に要求する。
　＜機能構成＞
　次に、本実施形態に係る端末１０及びサーバ２０の機能構成について説明する。
　　≪端末１０≫
　本実施形態に係る端末１０の機能構成について、図２を参照しながら説明する。図２は、本実施形態に係る端末１０の機能構成の一例を示す図である。
　図２に示すように、本実施形態に係る端末１０は、認証連携部１０１と、鍵ペア生成部１０２と、暗号化部１０３と、復号部１０４と、長期秘密ストリング生成部１０５とを有する。これら各部は、例えば、端末１０にインストールされた１以上のプログラムが、ＣＰＵ（Central Processing Unit）等のプロセッサに実行させる処理により実現される。
　また、本実施形態に係る端末１０は、記憶部１０６を有する。記憶部１０６は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等の各種メモリ装置により実現される。
　認証連携部１０１は、ＯＩＤＣにより認証連携を行うための各種処理を実行する。鍵ペア生成部１０２は、鍵生成アルゴリズムＫｅｙＧｅｎを実行し、自身の公開鍵と秘密鍵の鍵ペアを生成する。暗号化部１０３は、ＯＩＤＣで利用されるノンスのハッシュ値をトークンとして暗号化アルゴリズムＴＥｎｃを実行し、暗号文を生成する。復号部１０４は、復号アルゴリズムＤｅｃを実行し、暗号文を復号する。長期秘密ストリング生成部１０５は、ＯＩＤＣで利用されるノンスから長期秘密ストリングを生成する。記憶部１０６は、上記の各部が各種処理を実行するために必要な情報やその実行結果等（例えば、各種鍵、ノンス、ＩＤトークン、長期秘密ストリング等）を記憶する。
　　≪サーバ２０≫
　本実施形態に係るサーバ２０の機能構成について、図３を参照しながら説明する。図３は、本実施形態に係るサーバ２０の機能構成の一例を示す図である。
　図３に示すように、本実施形態に係るサーバ２０は、認証連携部２０１と、鍵ペア生成部２０２と、暗号化部２０３と、復号部２０４とを有する。これら各部は、例えば、サーバ２０にインストールされた１以上のプログラムが、ＣＰＵ等のプロセッサに実行させる処理により実現される。
　また、本実施形態に係るサーバ２０は、記憶部２０５を有する。記憶部２０５は、例えば、ＨＤＤやＳＳＤ、フラッシュメモリ等の各種メモリ装置により実現される。なお、記憶部２０５は、例えば、サーバ２０と通信ネットワークを介して接続される記憶装置等により実現されてもよい。
　認証連携部２０１は、ＯＩＤＣにより認証連携を行うための各種処理を実行する。特に、認証連携部２０１は、ＯＩＤＣで利用されるノンスを生成する。鍵ペア生成部２０２は、鍵生成アルゴリズムＴＫｅｙＧｅｎを実行し、サーバの公開鍵と秘密鍵の鍵ペアを生成する。暗号化部２０３は、暗号化アルゴリズムＥｎｃを実行し、暗号文を生成する。復号部２０４は、復号アルゴリズムＴＤｅｃを実行し、暗号文を復号する。このとき、復号部２０４は、自身が生成したノンスのハッシュ値を用いて暗号文を復号する。記憶部２０５は、上記の各部が各種処理を実行するために必要な情報やその実行結果等（例えば、各種鍵、ノンス、ＩＤトークン等）を記憶する。
　＜認証連携及び鍵交換処理＞
　以下では、本実施形態に係る認証連携及び鍵交換処理について説明する。ここで、非特許文献１及び２に記載されているサーバ支援型の鍵交換プロトコルでは、上述したように、各端末１０が保持する長期秘密鍵として公開鍵暗号又は属性ベース暗号の秘密鍵と長期秘密ストリングｓｔ及びｓｔ'とが存在する。これらの長期秘密ストリングはＤｉｓｔ／Ｊｏｉｎ／Ｌｅａｖｅフェーズにおいて、各フェーズで生成する短期秘密ストリングと合わせてねじれ疑似ランダム関数の入力に使用される。なお、非特許文献１では公開鍵暗号の秘密鍵と長期秘密ストリングｓｔ及びｓｔ'とが長期秘密鍵であり、非特許文献２では属性ベース暗号の秘密鍵と長期秘密ストリングｓｔ及びｓｔ'とが長期秘密鍵である。
　上記の長期秘密ストリングｓｔ及びｓｔ'はセットアップ時に各端末１０で生成されるが、本実施形態では、これらの長期秘密ストリングｓｔ及びｓｔ'をノンスから生成する。したがって、各端末１０は長期秘密ストリングｓｔ及びｓｔ'を半永続的に保持するのではなく、ＯＩＤＣのＩＤトークンの有効期間（又は、サーバ２０が指定した有効期間）毎に長期秘密ストリングｓｔ及びｓｔ'を再生成し、その期間の間だけ保持することになる。ただし、１度生成した長期秘密ストリングｓｔ及びｓｔ'を半永続的に保持することとしてもよい。
　ＯＩＤＣにはインプリシットフローと呼ばれる認証フローと認可コードフローと呼ばれる認証フローとが存在する。このため、以下では、認証フローがインプリシットフローである場合と認可コードフローである場合のそれぞれについて説明する。認証フローがインプリシットフローである場合は端末１０とサーバ２０がＲＰ（Relying Party）に相当し、認可コードフローである場合はサーバ２０がＲＰに相当する。
　　≪認証連携がインプリシットフローである場合≫
　認証フローがインプリシットフローである場合の認証連携及び鍵交換処理について、図４を参照しながら説明する。図４は、本実施形態に係る認証連携（インプリシットフロー）及び鍵交換処理の一例を示すシーケンス図である。
　端末１０の認証連携部１０１は、認証要求をサーバ２０に送信する（ステップＳ１０１）。
　サーバ２０の認証連携部２０１は、認証要求を受信すると、ＯＩＤＣで利用するノンスｎｏｎｃｅを生成する（ステップＳ１０２）。また、サーバ２０の鍵ペア生成部２０２は、ＴＫｅｙＧｅｎ（１κ）→（ｐｋＳ，ｓｋＳ）により公開鍵ｐｋＳと秘密鍵ｓｋＳの鍵ペア（ｐｋＳ，ｓｋＳ）を生成する（ステップＳ１０３）。続いて、サーバ２０の認証連携部２０１は、ＩＤプロバイダ３０へのリダイレクト指示を当該端末１０に送信する（ステップＳ１０４）。このとき、認証連携部２０１は、ノンスｎｏｎｃｅと公開鍵ｐｋＳとをリダイレクト指示に含める。
　端末１０の認証連携部１０１は、リダイレクト指示を受信すると、ＩＤプロバイダ３０にリダイレクトし、このＩＤプロバイダ３０が要求する認証方式によってユーザ認証を行う（ステップＳ１０５）。このとき、認証連携部１０１は、ユーザ認証の際にノンスｎｏｎｃｅをＩＤプロバイダ３０に送信する。なお、ＩＤプロバイダ３０が要求する認証方式としては、例えば、「ＩＤ・パスワード」、「ＳＭＳ認証」、「指紋認証」、「多要素認証」等といった様々な認証方式が挙げられる。
　上記のユーザ認証に成功した場合、ＩＤプロバイダ３０から端末１０に対して、ＩＤプロバイダ３０による署名付き、かつ、ノンス付きのＩＤトークンが返信される（ステップＳ１０６）。
　端末１０の鍵ペア生成部１０２は、ＩＤプロバイダ３０からＩＤトークンを受信すると、ＫｅｙＧｅｎ（１κ）→（ｐｋＣ，ｓｋＣ）により公開鍵ｐｋＣと秘密鍵ｓｋＣの鍵ペア（ｐｋＣ，ｓｋＣ）を生成する（ステップＳ１０７）。次に、端末１０の暗号化部１０３は、ノンスｎｏｎｃｅを所定のハッシュ関数（例えば、ＳＨＡ－２５６等）に入力することで得られたハッシュ値をトークンｔｏｋｅｎとして、ＩＤトークンと公開鍵ｐｋＣを含むメッセージｍを公開鍵ｐｋＳで暗号化した暗号文Ｃを生成する（ステップＳ１０８）。すなわち、暗号化部１０３は、ＴＥｎｃ（ｐｋＳ，ｍ，ｔｏｋｅｎ）→Ｃにより暗号文Ｃを生成する。そして、端末１０の暗号化部１０３は、暗号文Ｃをサーバ２０に送信する（ステップＳ１０９）。
　サーバ２０の復号部２０４は、暗号文Ｃを受信すると、ノンスｎｏｎｃｅを所定のハッシュ関数（例えば、ＳＨＡ－２５６等）に入力することで得られたハッシュ値をトークンｔｏｋｅｎとして、当該暗号文Ｃを秘密鍵ｓｋＳで復号する（ステップＳ１１０）。すなわち、復号部２０４は、ＴＤｅｃ（ｓｋＳ，Ｃ，ｔｏｋｅｎ）→ｍにより暗号文Ｃを復号してメッセージｍを得る。これにより、このメッセージｍからＩＤトークンと公開鍵ｐｋＣが得られる。
　サーバ２０の認証連携部２０１は、上記のステップＳ１１０で得られたＩＤトークンの検証を行う（ステップＳ１１１）。すなわち、認証連携部２０１は、当該ＩＤトークンの署名検証を行った後、当該ＩＤトークンに付与されたノンスが上記のステップＳ１０２で生成したノンスｎｏｎｃｅと一致することを検証する。
　続いて、上記のステップＳ１１１の検証に成功した場合、端末１０の長期秘密ストリング生成部１０５は、以下の方法１又は方法２のいずれかにより、ノンスｎｏｎｃｅから長期秘密ストリングｓｔ及びｓｔ'を生成する（ステップＳ１１２）。
　方法１：ノンスｎｏｎｃｅとソルトを入力とする鍵導出関数ＫＤＦの出力を長期秘密ストリングとする。すなわち、２つのソルトをｓ，ｓ'として、ｓｔ＝ＫＤＦ（ｎｏｎｃｅ，ｓ），ｓｔ'＝ＫＤＦ（ｎｏｎｃｅ，ｓ'）により長期秘密ストリングｓｔ及びｓｔ'を生成する。なお、ソルトｓ，ｓ'としては、例えば、ｓ＝'０００１'，ｓ'＝'０００２'等とすればよい。
　方法２：ノンスｎｏｎｃｅと文字列を入力とする疑似ランダム関数ＰＲＦの出力を長期秘密ストリングとする。すなわち、２つの文字列をｓ，ｓ'として、ｓｔ＝ＰＲＦ（ｎｏｎｃｅ，ｓ），ｓｔ'＝ＰＲＦ（ｎｏｎｃｅ，ｓ'）により長期秘密ストリングｓｔ及びｓｔ'を生成する。なお、文字列ｓ，ｓ'としては、例えば、ｓ＝'０００１'，ｓ'＝'０００２'等とすればよい。
　このように、端末１０で使われる乱数生成器とは異なる乱数生成器から生成した乱数（つまり、ノンスｎｏｎｃｅ）から長期秘密ストリングを生成することで、仮に端末１０の乱数生成器が脆弱であっても長期秘密ストリングが漏洩することがないため、安全な鍵交換が実現できる。また、ＯＩＤＣのノンスｎｏｎｃｅを用いるため、長期秘密ストリングを生成するための余分な通信や計算を行う必要がなく、長期秘密ストリングを効率的に生成することが可能である。
　そして、上記のステップＳ１１２で長期秘密ストリングｓｔ及びｓｔ'が生成された場合、端末１０とサーバ２０は鍵交換を行う（ステップＳ１１３）。この鍵交換の詳細については後述する。
　　≪認証連携が認可コードフローである場合≫
　認証連携が認可コードフローである場合の認証連携及び鍵交換処理について、図５を参照しながら説明する。図５は、本実施形態に係る認証連携（認可コードフロー）及び鍵交換処理の一例を示すシーケンス図である。
　端末１０の認証連携部１０１は、認証要求をサーバ２０に送信する（ステップＳ２０１）。
　サーバ２０の認証連携部２０１は、認証要求を受信すると、ＯＩＤＣで利用するノンスｎｏｎｃｅを生成する（ステップＳ２０２）。また、サーバ２０の鍵ペア生成部２０２は、ＴＫｅｙＧｅｎ（１κ）→（ｐｋＳ，ｓｋＳ）により公開鍵ｐｋＳと秘密鍵ｓｋＳの鍵ペア（ｐｋＳ，ｓｋＳ）を生成する（ステップＳ２０３）。続いて、サーバ２０の認証連携部２０１は、ＩＤプロバイダ３０へのリダイレクト指示を当該端末１０に送信する（ステップＳ２０４）。このとき、認証連携部２０１は、ノンスｎｏｎｃｅと公開鍵ｐｋＳとをリダイレクト指示に含める。
　端末１０の認証連携部１０１は、リダイレクト指示を受信すると、ＩＤプロバイダ３０にリダイレクトし、このＩＤプロバイダ３０が要求する認証方式によってユーザ認証を行う（ステップＳ２０５）。このとき、認証連携部１０１は、ユーザ認証の際にノンスｎｏｎｃｅをＩＤプロバイダ３０に送信する。
　上記のユーザ認証に成功した場合、ＩＤプロバイダ３０から端末１０に対して、認可コードが返信される（ステップＳ２０６）。
　端末１０の鍵ペア生成部１０２は、ＩＤプロバイダ３０から認可コードを受信すると、ＫｅｙＧｅｎ（１κ）→（ｐｋＣ，ｓｋＣ）により公開鍵ｐｋＣと秘密鍵ｓｋＣの鍵ペア（ｐｋＣ，ｓｋＣ）を生成する（ステップＳ２０７）。次に、端末１０の暗号化部１０３は、ノンスｎｏｎｃｅを所定のハッシュ関数（例えば、ＳＨＡ－２５６等）に入力することで得られたハッシュ値をトークンｔｏｋｅｎとして、認可コードと公開鍵ｐｋＣを含むメッセージｍを公開鍵ｐｋＳで暗号化した暗号文Ｃを生成する（ステップＳ２０８）。すなわち、暗号化部１０３は、ＴＥｎｃ（ｐｋＳ，ｍ，ｔｏｋｅｎ）→Ｃにより暗号文Ｃを生成する。そして、端末１０の暗号化部１０３は、暗号文Ｃをサーバ２０に送信する（ステップＳ２０９）。
　サーバ２０の復号部２０４は、暗号文Ｃを受信すると、ノンスｎｏｎｃｅを所定のハッシュ関数（例えば、ＳＨＡ－２５６等）に入力することで得られたハッシュ値をトークンｔｏｋｅｎとして、当該暗号文Ｃを秘密鍵ｓｋＳで復号する（ステップＳ２１０）。すなわち、復号部２０４は、ＴＤｅｃ（ｓｋＳ，Ｃ，ｔｏｋｅｎ）→ｍにより暗号文Ｃを復号してメッセージｍを得る。これにより、このメッセージｍから認可コードと公開鍵ｐｋＣが得られる。
　次に、サーバ２０の認証連携部２０１は、上記のステップＳ２１０で得られた認可コードをＩＤプロバイダ３０に送信する（ステップＳ２１１）。これにより、ＩＤプロバイダ３０からサーバ２０に対して、ＩＤプロバイダ３０による署名付き、かつ、ノンス付きのＩＤトークンが返信される（ステップＳ２１２）。
　サーバ２０の認証連携部２０１は、上記のステップＳ２１２で得られたＩＤトークンの検証を行う（ステップＳ２１３）。すなわち、認証連携部２０１は、当該ＩＤトークンの署名検証を行った後、当該ＩＤトークンに付与されたノンスが上記のステップＳ２０２で生成したノンスｎｏｎｃｅと一致することを検証する。
　続いて、上記のステップＳ２１３の検証に成功した場合、端末１０の長期秘密ストリング生成部１０５は、図４のステップＳ１１２と同様に、方法１又は方法２のいずれかにより、ノンスｎｏｎｃｅから長期秘密ストリングｓｔ及びｓｔ'を生成する（ステップＳ２１４）。
　そして、上記のステップＳ２１４で長期秘密ストリングｓｔ及びｓｔ'が生成された場合、端末１０とサーバ２０は鍵交換を行う（ステップＳ２１５）。この鍵交換の詳細については後述する。
　　≪鍵交換処理≫
　上記のステップＳ１１３又はステップＳ２１５の鍵交換について説明する。ここでは、上記の非特許文献１及び２に記載されている鍵交換を行う場合について説明する。なお、以下で特に説明を行った処理以外に関しては非特許文献１及び２を参照されたい。
　これらの非特許文献１及び２に記載されている鍵交換では、最初にサーバ２０から端末１０にＭＡＣ鍵と属性ベース暗号の鍵が送信される。そこで、このとき、サーバ２０の暗号化部２０３は、これらの鍵を含むメッセージｍ'を公開鍵ｐｋＣで暗号化した暗号文Ｃを生成、つまり、Ｅｎｃ（ｐｋＣ，ｍ'）→Ｃにより暗号文Ｃを生成し、その暗号文Ｃを当該端末１０に送信する。そして、端末１０の復号部１０４は、この暗号文Ｃを復号、つまり、Ｄｅｃ（ｓｋＣ，Ｃ）→ｍ'によりメッセージｍ'を生成し、このメッセージｍ'からＭＡＣ鍵と属性ベース暗号の鍵を取り出す。その後の処理は、非特許文献１及び２に記載されている処理と同様である。
　＜ハードウェア構成＞
　最後に、本実施形態に係る端末１０及びサーバ２０のハードウェア構成について説明する。本実施形態に係る端末１０及びサーバ２０は、例えば、図６に示すコンピュータ５００のハードウェア構成により実現される。図６は、コンピュータ５００のハードウェア構成の一例を示す図である。
　図６に示すコンピュータ５００は、入力装置５０１と、表示装置５０２と、外部Ｉ／Ｆ５０３と、通信Ｉ／Ｆ５０４と、プロセッサ５０５と、メモリ装置５０６とを有する。これらの各ハードウェアは、それぞれがバス５０７により通信可能に接続される。
　入力装置５０１は、例えば、キーボードやマウス、タッチパネル等である。表示装置５０２は、例えば、ディスプレイ等である。なお、コンピュータ５００は、例えば、入力装置５０１及び表示装置５０２のうちの少なくとも一方を有していなくてもよい。
　外部Ｉ／Ｆ５０３は、記録媒体５０３ａ等の外部装置とのインタフェースである。コンピュータ５００は、外部Ｉ／Ｆ５０３を介して、記録媒体５０３ａの読み取りや書き込み等を行うことができる。なお、記録媒体５０３ａとしては、例えば、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤメモリカード（Secure Digital memory card）、ＵＳＢ（Universal Serial Bus）メモリカード等が挙げられる。
　通信Ｉ／Ｆ５０４は、コンピュータ５００を通信ネットワークに接続するためのインタフェースである。プロセッサ５０５は、例えば、ＣＰＵ等の各種演算装置である。メモリ装置５０６は、例えば、ＨＤＤやＳＳＤ、フラッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の各種記憶装置である。
　本実施形態に係る端末１０及びサーバ２０は、図６に示すハードウェア構成を有することにより、上述した認証連携及び鍵交換処理を実現することができる。なお、図６に示すハードウェア構成は一例であって、コンピュータ５００は、例えば、複数のプロセッサを有していたり、複数のメモリ装置を有していたりしてもよく、様々なハードウェア構成を有していてもよい。
　本発明は、具体的に開示された上記の実施形態に限定されるものではなく、請求の範囲の記載から逸脱することなく、種々の変形や変更、既知の技術との組み合わせ等が可能である。
　１　　　　鍵交換システム
　１０　　　端末
　２０　　　サーバ
　３０　　　ＩＤプロバイダ
　１０１　　認証連携部
　１０２　　鍵ペア生成部
　１０３　　暗号化部
　１０４　　復号部
　１０５　　長期秘密ストリング生成部
　１０６　　記憶部
　２０１　　認証連携部
　２０２　　鍵ペア生成部
　２０３　　暗号化部
　２０４　　復号部
　２０５　　記憶部
　Ｎ　　　　通信ネットワーク

Claims (6)

  1. 　鍵交換を行う複数の端末と、前記端末の認証と前記鍵交換の仲介とを行うサーバとが含まれる鍵交換システムであって、
    　前記サーバは、
    　前記端末との間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスを生成するノンス生成部と、
    　トークン制御暗号の公開鍵と秘密鍵とを生成する鍵生成部と、
    　前記ノンスと、前記公開鍵とを前記端末に送信する第１の送信部と、
    　前記秘密鍵と、前記端末から受信したトークンとを用いて、前記端末から受信した暗号文を復号する復号部と、を有し、
    　前記端末は、
    　前記公開鍵と、前記ノンスから生成されたトークンとを用いて、所定のデータを暗号化した暗号文を生成する暗号化部と、
    　前記暗号文を前記サーバに送信する第２の送信部と、
    　前記ノンスを用いて、前記鍵交換で使用する長期秘密ストリングを生成する長期秘密ストリング生成部と、
    　を有する鍵交換システム。
  2. 　前記長期秘密ストリング生成部は、
    　前記ノンスを入力とする鍵導出関数又は疑似ランダム関数により前記長期秘密ストリングを生成する、請求項１に記載の鍵交換システム。
  3. 　鍵交換を行う他の端末と、各端末の認証と前記鍵交換の仲介とを行うサーバとに通信ネットワークを介して接続される端末であって、
    　トークン制御暗号の公開鍵であって、かつ、前記サーバで生成された公開鍵と、前記サーバとの間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスから生成されたトークンとを用いて、所定のデータを暗号化した暗号文を生成する暗号化部と、
    　前記暗号文を前記サーバに送信する送信部と、
    　前記ノンスを用いて、前記鍵交換で使用する長期秘密ストリングを生成する長期秘密ストリング生成部と、
    　を有する端末。
  4. 　鍵交換を行う複数の端末と通信ネットワークを介して接続され、前記端末の認証と前記鍵交換の仲介とを行うサーバであって、
    　前記端末との間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスを生成するノンス生成部と、
    　トークン制御暗号の公開鍵と秘密鍵とを生成する鍵生成部と、
    　前記ノンスと、前記公開鍵とを前記端末に送信する送信部と、
    　前記秘密鍵と、前記端末から受信したトークンとを用いて、前記端末から受信した暗号文を復号する復号部と、
    　を有するサーバ。
  5. 　鍵交換を行う複数の端末と、前記端末の認証と前記鍵交換の仲介とを行うサーバとが含まれる鍵交換システムに用いられる鍵交換方法であって、
    　前記サーバが、
    　前記端末との間でＯｐｅｎＩＤ　Ｃｏｎｎｅｃｔによる認証連携によって前記認証を行う際に用いられるノンスを生成するノンス生成手順と、
    　トークン制御暗号の公開鍵と秘密鍵とを生成する鍵生成手順と、
    　前記ノンスと、前記公開鍵とを前記端末に送信する第１の送信手順と、
    　前記秘密鍵と、前記端末から受信したトークンとを用いて、前記端末から受信した暗号文を復号する復号手順と、を実行し、
    　前記端末が、
    　前記公開鍵と、前記ノンスから生成されたトークンとを用いて、所定のデータを暗号化した暗号文を生成する暗号化手順と、
    　前記暗号文を前記サーバに送信する第２の送信手順と、
    　前記ノンスを用いて、前記鍵交換で使用する長期秘密ストリングを生成する長期秘密ストリング生成手順と、
    　を実行する鍵交換方法。
  6. 　コンピュータを、請求項１又は２に記載の鍵交換システムに含まれる端末又はサーバとして機能させるためのプログラム。
PCT/JP2021/019017 2021-05-19 2021-05-19 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム Ceased WO2022244151A1 (ja)

Priority Applications (3)

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

Applications Claiming Priority (1)

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

Publications (1)

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

Family

ID=84141428

Family Applications (1)

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

Country Status (3)

Country Link
US (1) US20240129111A1 (ja)
JP (1) JP7619446B2 (ja)
WO (1) WO2022244151A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115883066A (zh) * 2022-11-30 2023-03-31 陕西师范大学 抗密钥泄露的分布式身份基加密方法

Citations (4)

* 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 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
WO2019198516A1 (ja) * 2018-04-11 2019-10-17 日本電信電話株式会社 鍵配信システム、端末装置、鍵配信方法、及びプログラム
JP2020520017A (ja) * 2017-05-15 2020-07-02 アマゾン テクノロジーズ インコーポレイテッド 汎用入退管理装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2128781A1 (en) * 2008-05-27 2009-12-02 Benny Kalbratt Method for authentication
CN108206739A (zh) * 2016-12-16 2018-06-26 乐视汽车（北京）有限公司 密钥生成方法及装置
US10764273B2 (en) * 2018-06-28 2020-09-01 Oracle International Corporation Session synchronization across multiple devices in an identity cloud service

Patent Citations (4)

* 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 キヤノン株式会社 情報処理システムと、その制御方法とプログラム
WO2019198516A1 (ja) * 2018-04-11 2019-10-17 日本電信電話株式会社 鍵配信システム、端末装置、鍵配信方法、及びプログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115883066A (zh) * 2022-11-30 2023-03-31 陕西师范大学 抗密钥泄露的分布式身份基加密方法

Also Published As

Publication number Publication date
US20240129111A1 (en) 2024-04-18
JP7619446B2 (ja) 2025-01-22
JPWO2022244151A1 (ja) 2022-11-24

Similar Documents

Publication Publication Date Title
US12155757B2 (en) Systems and methods for deployment, management and use of dynamic cipher key systems
US20220385644A1 (en) Sharing encrypted items with participants verification
CN106416123B (zh) 基于密码的认证
CN108352015B (zh) 用于基于区块链的系统结合钱包管理系统的安全多方防遗失存储和加密密钥转移
US20240356730A1 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
CN106664202A (zh) 提供多个设备上的加密的方法、系统和计算机程序产品
Agarwal et al. A survey on cloud computing security issues and cryptographic techniques
US11528127B2 (en) Computer-implemented system and method for highly secure, high speed encryption and transmission of data
KR20200055672A (ko) 순열그룹 기반의 암호화 기술을 적용한 암호화시스템 및 방법
CN119995863B (zh) 一种抗量子计算的通信实现方法、系统和计算机设备
Natarajan et al. Secure user authentication and data sharing for mobile cloud computing using BLAKE2 and Diffie-Hellman key exchange
JP7619446B2 (ja) 鍵交換システム、端末、鍵交換方法、及びプログラム
Braga Integrated technologies for communication security on mobile devices
JP5643251B2 (ja) 秘密情報通知システム、秘密情報通知方法、プログラム
JP7626212B2 (ja) 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム
Paverd et al. Omnishare: Encrypted cloud storage for the multi-device era
FI131933B1 (en) Arrangement and method for securely enabling group communication
Tsai et al. Cloud encryption using distributed environmental keys
CN120151114B (zh) 应用于区块链网络系统的数据传输控制方法及装置
Zhang et al. Security Enhancement Method for MQTT Based on TEE
Soler et al. Qerberos: A protocol for secure distribution of QRNG keys
Chen et al. The comparisons between public key and symmetric key cryptography in protecting storage systems
Divya et al. Security in data forwarding through elliptic curve cryptography in cloud
KR102145679B1 (ko) Https 프로토콜에서 mitm 공격을 회피하는 방법
Bharathi et al. Development of a secure file storage system leveraging hybrid cryptographic techniques

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: 21940767

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023522087

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18555610

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: 21940767

Country of ref document: EP

Kind code of ref document: A1