WO2022244151A1 - 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム - Google Patents
鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム Download PDFInfo
- 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
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)
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US18/555,610 US20240129111A1 (en) | 2021-05-19 | 2021-05-19 | Key exchange system, terminal, server, key exchange method, and program |
| PCT/JP2021/019017 WO2022244151A1 (ja) | 2021-05-19 | 2021-05-19 | 鍵交換システム、端末、サーバ、鍵交換方法、及びプログラム |
| JP2023522087A JP7619446B2 (ja) | 2021-05-19 | 2021-05-19 | 鍵交換システム、端末、鍵交換方法、及びプログラム |
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 (https=) |
| JP (1) | JP7619446B2 (https=) |
| WO (1) | WO2022244151A1 (https=) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115883066A (zh) * | 2022-11-30 | 2023-03-31 | 陕西师范大学 | 抗密钥泄露的分布式身份基加密方法 |
Citations (4)
| 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)
| 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 |
-
2021
- 2021-05-19 JP JP2023522087A patent/JP7619446B2/ja active Active
- 2021-05-19 US US18/555,610 patent/US20240129111A1/en not_active Abandoned
- 2021-05-19 WO PCT/JP2021/019017 patent/WO2022244151A1/ja not_active Ceased
Patent Citations (4)
| 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)
| 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 |
| JPWO2022244151A1 (https=) | 2022-11-24 |
| JP7619446B2 (ja) | 2025-01-22 |
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 | |
| Natarajan et al. | Secure user authentication and data sharing for mobile cloud computing using BLAKE2 and Diffie-Hellman key exchange | |
| CN119995863B (zh) | 一种抗量子计算的通信实现方法、系统和计算机设备 | |
| 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 | |
| JP2026512403A (ja) | 信頼できない分散型対称暗号化のためのシステム及び方法 |
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 |