TERMINAL, SERVER, METHOD AND PROGRAM

Abstract

A terminal for performing authentication through TLS 1.3 with a server connected via a communication network. The terminal includes a memory and a processor configured to execute transmitting, to the server, a ClientHello message including a first identifier and a first short-term public key, which are needed to generate a shared key for encrypting a message during a handshake in the TLS 1.3, through key exchange with mutual authentication using ID-based encryption; receiving, from the server, a ServerHello message including a second identifier and a second short-term public key, which are needed to generate the shared key; and generating the shared key using the first identifier, the first short-term public key, the second identifier, and the second short-term public key.

Claims

1. A terminal for performing authentication through TLS 1.3 with a server connected via a communication network, the terminal comprising: a memory; and a processor configured to execute transmitting, to the server, a ClientHello message including a first identifier and a first short-term public key, which are needed to generate a shared key for encrypting a message during a handshake in the TLS 1.3, through key exchange with mutual authentication using ID-based encryption; receiving, from the server, a ServerHello message including a second identifier and a second short-term public key, which are needed to generate the shared key; and generating the shared key using the first identifier, the first short-term public key, the second identifier, and the second short-term public key.

2. The terminal according to claim 1, wherein the first identifier is identification information for identifying the terminal, and the second identifier is identification information for identifying the server, and the first short-term public key is generated based on a first short-term private key generated by the terminal and a generator of a subgroup on an elliptic curve, and the second short-term public key is generated based on a second short-term private key generated by the server and a generator of a subgroup on an elliptic curve.

3. A server for performing authentication through TLS 1.3 with a terminal connected via a communication network, the server comprising: a memory; and a processor configured to execute receiving, from the terminal, a ClientHello message including a first identifier and a first short-term public key, which are needed to generate a shared key for encrypting a message during a handshake in the TLS 1.3, through key exchange with mutual authentication using ID-based encryption; transmitting, to the terminal, a ServerHello message including a second identifier and a second short-term public key, which are needed to generate the shared key; and generating the shared key using the first identifier, the first short-term public key, the second identifier, and the second short-term public key.

4. The server according to claim 3, wherein the first identifier is identification information for identifying the terminal, and the second identifier is identification information for identifying the server, and the first short-term public key is generated based on a first short-term private key generated by the terminal and a generator of a subgroup on an elliptic curve, and the second short-term public key is generated based on a second short-term private key generated by the server and a generator of a subgroup on an elliptic curve.

5. A method to be executed by a terminal including a memory and a processor for performing authentication through TLS 1.3 with a server connected via a communication network, the method comprising: transmitting, to the server, a ClientHello message including a first identifier and a first short-term public key, which are needed to generate a shared key for encrypting a message during a handshake in the TLS 1.3, through key exchange with mutual authentication using ID-based encryption; receiving, from the server, a ServerHello message including a second identifier and a second short-term public key, which are needed to generate the shared key; and generating the shared key using the first identifier, the first short-term public key, the second identifier, and the second short-term public key.

6. (canceled)

7. A non-transitory computer-readable recording medium having computer-readable instructions stored thereon, which when executed, cause a computer including a memory and a processor to execute processing as the terminal according to claim 1.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0009] FIG. 1 is a diagram showing an example of an overall configuration of an authentication system according to the present embodiment.

[0010] FIG. 2 is a diagram showing an example of a hardware configuration of a terminal according to the present embodiment.

[0011] FIG. 3 is a diagram showing an example of a hardware configuration of a server according to the present embodiment.

[0012] FIG. 4 is a diagram showing an example of a functional configuration of a terminal and a server according to the present embodiment.

[0013] FIG. 5 is a sequence diagram showing an example of authentication processing in Working Example 1.

[0014] FIG. 6 is a sequence diagram showing an example of authentication processing in Working Example 2.

[0015] FIG. 7 is a sequence diagram showing an example of authentication processing in Working Example 3.

DESCRIPTION OF EMBODIMENTS

[0016] Hereinafter, embodiments of the present invention will be described. In the present embodiment, an authentication system 1 that implements TLS 1.3 to which key exchange with mutual authentication using ID-based encryption is applied will be described.

[0017] As mentioned above, the specification of TLS 1.3 is different from that of TLS 1.2. Specifically, as described in Reference Document 1 below, in TLS 1.2, two rounds of communication are performed before the handshake is encrypted, whereas in TLS1.3, only one round of communication (i.e., ClientHello and ServerHello) is performed before the handshake is encrypted.

[0018] Reference Document 1 [0019] “SSL/TLS Encryption Setting Guidelines ˜For a Secure Website (Encryption Setting Countermeasure Edition)˜”, Internet <URL: https://www.ipa.go.jp/security/ipg/documents/ipa-cryptrec-gl-3001-2.0.pdf>

[0020] For this reason, in order to apply key exchange with mutual authentication using ID-based encryption to TLS 1.3, it is necessary to exchange the information needed for key exchange in one round. For example, in a key exchange protocol with mutual authentication using ID-based encryption called an MB scheme, 1.5 rounds are needed to exchange the information needed for key exchange. This is because the MB scheme requires an identifier (ID) of a communication partner in order to generate a short-term public key. Regarding the MB scheme, refer to Reference Document 2 below.

[0021] Reference Document 2 [0022] N. McCullagh and P. S. L. M. Barreto, “A New Two-Party Identity-Based Authenticated Key Agreement”, CT-RSA 2005, LNCS 3376, pp. 262-274, Springer-Verlag, 2005.

[0023] Accordingly, in order to implement TLS 1.3 to which key exchange with mutual authentication using ID-based encryption is applied, a key exchange protocol with mutual authentication using ID-based encryption in which the information needed for key exchange can be exchanged in one round, needs to be applied to TLS 1.3.

[0024] In view of this, in the authentication system 1 according to the present embodiment, a key exchange protocol with mutual authentication using ID-based encryption in which the information needed for key exchange can be exchanged in one round, is applied to TLS 1.3. As a result, authentication and key exchange using ID-based encryption are performed in the specification of TLS 1.3, and the key obtained through this key exchange can be used to encrypt messages after ClientHello and ServerHello.

[0025] Note that even with the above-described MB scheme, for example, if the identifier (ID) of the communication partner is obtained in advance, or the like, it is possible to exchange the information needed for key exchange in one round, but in the present embodiment, it is assumed that the identifier of the communication partner cannot be obtained in advance (i.e., before communication is started). This is because, in many cases, the identifier of the communication partner cannot be obtained in advance, and even if it is obtained, the communication partner does not always use the same identifier.

[0026] Overall Configuration

[0027] First, an overall configuration of the authentication system 1 according to the present embodiment will be described with reference to FIG. 1. FIG. 1 is a diagram showing an example of the overall configuration of the authentication system 1 according to the present embodiment.

[0028] As shown in FIG. 1, the authentication system 1 according to the present embodiment includes one or more terminals 10 and a server 20. Also, the terminals 10 and the server 20 are connected to each other so as to be able to communicate with each other via a communication network N such as the Internet.

[0029] The terminals 10 are, for example, various IoT devices such as various sensor devices, embedded devices, wearable devices, digital home appliances, monitoring cameras, lighting devices, medical devices, and industrial devices. That is, it is assumed that the terminals 10 are IoT devices having limited hardware resources (e.g., processor processing performance, memory capacity, communication performance, etc.) compared to a general PC or the like. However, the devices are not limited to these, and the present embodiment can be similarly applied even if the terminal 10 is a device other than an IoT device (e.g., a PC, a smartphone, a tablet terminal, etc.).

[0030] The server 20 is, for example, a computer or a computer system that performs data communication with the terminals 10. Examples of the server 20 include a computer that, if the terminal 10 is a sensor device, collects sensing data from the terminal 10.

[0031] A case will be described in which key exchange for encryption through a key exchange protocol with mutual authentication using ID-based encryption is performed in the authentication system 1 according to the present embodiment when performing authentication and encrypted communication through TLS 1.3 between the terminal 10 and the server 20. However, this embodiment can be similarly applied to the case where authentication and encrypted communication through TLS 1.3 are performed between different terminals 10.

[0032] Note that the configuration of the authentication system 1 shown in FIG. 1 is an example, and other configurations may be adopted. For example, the authentication system 1 may also include a device or system that functions as a key generation center (KGC).

[0033] Hardware Configuration

[0034] Next, the hardware configuration of the terminal 10 and the server 20 according to this embodiment will be described.

[0035] Terminal 10

[0036] Hereinafter, the hardware configuration of the terminal 10 according to the present embodiment will be described with reference to FIG. 2. FIG. 2 is a diagram showing an example of the hardware configuration of the terminal 10 according to the present embodiment.

[0037] As shown in FIG. 2, the terminal 10 according to the present embodiment includes a communication I/F 11, a processor 12, and a memory device 13. Each of these pieces of hardware is communicably connected via a bus 14.

[0038] The communication I/F 11 is an interface for connecting the terminal 10 to the communication network N. The terminal 10 can perform data communication with the server 20, other terminals 10, and the like via the communication I/F 11.

[0039] The processor 12 is, for example, an MPU (Micro Processing Unit), a CPU (Central Processing Unit), or the like, and is a computation device that reads programs and data from the memory device 13 and executes various types of processing.

[0040] The memory device 13 is, for example, a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory, or the like, and is a storage device for storing various types of data, programs, and the like.

[0041] By having the hardware configuration shown in FIG. 2, the terminal 10 according to the present embodiment can implement later-described authentication processing. Note that the hardware configuration shown in FIG. 2 is an example, and the terminal 10 may have another hardware configuration. For example, the terminal 10 may include a plurality of processors 12 and may include a plurality of memory devices 13.

[0042] Server 20

[0043] Hereinafter, the hardware configuration of the server 20 according to the present embodiment will be described with reference to FIG. 3. FIG. 3 is a diagram showing an example of the hardware configuration of the server 20 according to the present embodiment.

[0044] As shown in FIG. 3, the server 20 according to the present embodiment includes an input device 21, a display device 22, an external I/F 23, a communication I/F 24, a processor 25, and a memory device 26. These pieces of hardware are connected so as to be able to communicate via the bus 27.

[0045] The input device 21 is, for example, a keyboard, a mouse, a touch panel, or the like, and is used to input various operations to the server 20. The display device 22 is, for example, a display or the like, and is used to display various processing results of the server 20 or the like. The server 20 need not include at least one of the input device 21 and the display device 22.

[0046] The external I/F 23 is an interface with an external device. The external device includes a recording medium 23a and the like. The server 20 can read and write from and to the recording medium 23a and the like via an external I/F. Note that examples of the recording medium 23a include a CD (Compact Disk), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0047] The communication I/F 24 is an interface for connecting the server 20 to the communication network N. The server 20 can perform data communication with the terminal 10 and the like via the communication I/F 24.

[0048] The processor 25 is, for example, a CPU or the like, and is a computation device that reads programs and data from the memory device 26 and executes various types of processing.

[0049] The memory device 26 is, for example, a RAM, a ROM, a flash memory, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or the like, and is a storage device for storing various types of data, programs, and the like.

[0050] By having the hardware configuration shown in FIG. 3, the server 20 according to the present embodiment can implement later-described authentication processing. Note that the hardware configuration shown in FIG. 3 is an example, and the server 20 may also have another hardware configuration. For example, the server 20 may also include a plurality of processors 25, and may also include a plurality of memory devices 26.

[0051] Functional Configuration

[0052] Next, a functional configuration of the terminal 10 and the server 20 according to the present embodiment will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of the functional configuration of the terminal 10 and the server 20 according to the present embodiment.

[0053] Terminal 10

[0054] As shown in FIG. 4, the terminal 10 according to the present embodiment includes an authentication processing unit 101 and a storage unit 102. The authentication processing unit 101 is implemented through processing for causing the processor 12 to execute one or more programs installed in the terminal 10. Also, the storage unit 102 can be implemented by using, for example, the memory device 13 or the like.

[0055] The authentication processing unit 101 performs authentication and encrypted communication through TLS 1.3 with the server 20. At this time, the authentication processing unit 101 performs key exchange for encryption with the server 20 using a key exchange protocol with mutual authentication using ID-based encryption.

[0056] The storage unit 102 stores various types of data. Examples of the data stored in the storage unit 102 include the identifier of the terminal 10 and the user private key. Temporary data used when performing authentication and encrypted communication through TLS 1.3 with the server 20 is also stored in the storage unit 102.

[0057] Note that any identifier can be used as the identifier of the terminal 10. For example, a user ID, a name, an e-mail address, a telephone number, a manufacturing unique number of the terminal 10, an IP (Internet Protocol) address, a physical address, or the like can be used as the identifier of the terminal 10.

[0058] Server 20

[0059] As shown in FIG. 4, the server 20 according to the present embodiment has an authentication processing unit 201 and a storage unit 202. The authentication processing unit 201 is implemented through processing for causing the processor 25 to execute one or more programs installed on the server 20. Also, the storage unit 202 can be implemented using, for example, a memory device 26 or the like. Note that the storage unit 202 may also be implemented by using, for example, a storage device connected to the server 20 via the communication network N or the like.

[0060] The authentication processing unit 201 performs authentication and encrypted communication through TLS 1.3 with the terminal 10. At this time, the authentication processing unit 201 performs key exchange for encryption with the terminal 10 using a key exchange protocol with mutual authentication using ID-based encryption.

[0061] The storage unit 202 stores various types of data. Examples of the data stored in the storage unit 202 include the identifier of the server 20 and the user private key. Temporary data for performing authentication and encrypted communication through TLS 1.3 with the terminal 10 is also stored in the storage unit 202.

[0062] Note that any identifier can be used as the identifier of the server 20. For example, a manufacturing unique number, an IP address, a physical address, a website name, an e-mail address, a telephone number, or the like of the server 20 can be used as the identifier of the server 20.

[0063] Details of Processing

[0064] Next, the details of the processing of the authentication system 1 according to the present embodiment will be described. In this embodiment, Working Examples 1 to 3 of the authentication processing through TLS 1.3 to which key exchange with mutual authentication using ID-based encryption is applied will be described. The security level of Working Examples 1 to 3 is substantially the same, but the calculation efficiency is the best in Working Example 3. Note that in addition to the methods described in Working Examples 1 to 3, a key exchange protocol with mutual authentication using ID-based encryption, in which information needed for key exchange can be exchanged in one round, can be applied to TLS 1.3.

[0065] Definition of Symbols

[0066] First, symbols used commonly in the following working examples are defined as follows.

[0067] ID.sub.A: Identifier of terminal 10

[0068] ID.sub.B: Identifier of server 20

[0069] k: Security parameter

[0070] p, q: Prime numbers that satisfy p≠q

[0071] G.sub.1: Subgroup of group E(F.sub.p) on elliptic curve E.sub.1, where E.sub.1 is an elliptic curve on a finite field F.sub.p

[0072] G.sub.2: Group on elliptic curve E.sub.2, where E.sub.2 is an elliptic curve on a k-th extension field of a finite field F.sub.p

A subgroup of

E(F.sub.p.sub.k)  [Math. 1]

[0073] g.sub.1: Generator of G.sub.1

[0074] g.sub.2: Generator of G.sub.2

[0075] e: Pairing defined on G.sub.1×G.sub.2

[0076] Z.sub.q: Coset modulo q

[0077] ∥: Concatenation of character strings

[0078] H: Key derivation function

[0079] K: Shared key

Authentication Processing (Working Example 1)

[0080] Hereinafter, Working Example 1 of the authentication processing performed using TLS 1.3 to which key exchange with mutual authentication using ID-based encryption is applied will be described with reference to FIG. 5. FIG. 5 is a sequence diagram showing an example of authentication processing in Working Example 1.

[0081] In Working Example 1, assume that the master private key of a key generation center is zϵZ.sub.q, and the master public keys are Z.sub.1=zg.sub.1 and Z.sub.2=zg.sub.2; the user private key of the terminal 10 is D.sub.A,1=zQ.sub.A,1=zH.sub.1(ID.sub.A)ϵG.sub.1, and the user private key of the server 20 is D.sub.B,2=zQ.sub.B,2=zH.sub.2(ID.sub.B)ϵG.sub.2. Here, H.sub.1 is a function that generates an element on G.sub.1 from a character string, and H.sub.2 is a function that generates an element on G.sub.2 from a character string. H.sub.1 and H.sub.2 are public information. Note that the user private keys D.sub.A,1 and D.sub.B,2 are generated by the key generation center and are respectively distributed to the terminal 10 and the server 20 using any method.

[0082] The authentication processing unit 101 of the terminal 10 randomly selects a short-term private key x.sub.AϵZ.sub.q and then generates short-term public keys X.sub.A,1=x.sub.Ag.sub.1ϵG.sub.1 and X.sub.A,2=x.sub.Ag.sub.2ϵG.sub.2 (step S101). Note that the short-term private key x.sub.A and the short-term public keys X.sub.A,1 and X.sub.A,2 are stored in the storage unit 102.

[0083] The authentication processing unit 201 of the server 20 randomly selects a short-term private key x.sub.BϵZ.sub.q and then generates short-term public keys X.sub.B,1=x.sub.Bg.sub.1ϵG.sub.1 and X.sub.B,2=x.sub.Bg.sub.2ϵG.sub.2 (step S102). Note that the short-term private key x.sub.B and the short-term public keys X.sub.B,1 and X.sub.B,2 are stored in the storage unit 202.

[0084] Next, the authentication processing unit 101 of the terminal 10 transmits a ClientHello to the server 20 (step S103). At this time, the authentication processing unit 101 transmits a ClientHello including the identifier ID.sub.A of the terminal 10 and the short-term public keys X.sub.A,1 and X.sub.A,2 to the server 20. Here, the identifier ID.sub.A and the short-term public keys X.sub.A,1 and X.sub.A,2 can be stored in, for example, the extension area (Extension field) of the ClientHello.

[0085] Next, the authentication processing unit 201 of the server 20 transmits a ServerHello to the terminal 10 (step S104). At this time, the authentication processing unit 201 transmits a ServerHello including the identifier ID.sub.B of the server 20 and the short-term public keys X.sub.B,1 and X.sub.B,2 to the terminal 10. Here, the identifier ID.sub.B and the short-term public keys X.sub.B,1 and X.sub.B,2 can be stored in, for example, an extension area (Extension field) of the ServerHello.

[0086] The information needed for key exchange (i.e., the identifier of the communication partner and the short-term public key) is exchanged through the above steps S103 to S104. That is, the information needed for key exchange is exchanged in one round.

[0087] Next, the authentication processing unit 101 of the terminal 10 confirms that X.sub.B,1 and X.sub.B,2 are points on elliptic curves E.sub.1 and E.sub.2, respectively, and that e(X.sub.B,1, g.sub.2)=e(g.sub.1, X.sub.B,2) is satisfied (step S105).

[0088] Note that in step S105 above, if at least one of “X.sub.B,1 is not a point on the elliptic curve E.sub.1”, “X.sub.B,2 is not a point on the elliptic curve E.sub.2”, and “e(X.sub.B,1, g.sub.2)≠e(g.sub.1, X.sub.B,2)” is satisfied, the authentication processing is considered to have failed, and the processing is ended or restarted from step S101 above. Thereafter, it is assumed that it was confirmed that X.sub.B,1 and X.sub.B,2 are points on the elliptic curves E.sub.1 and E.sub.2, respectively, and that e(X.sub.B,1, g.sub.2)=e(g.sub.1, X.sub.B,2).

[0089] Similarly, the authentication processing unit 201 of the server 20 confirms that X.sub.A,1 and X.sub.A,2 are points on elliptic curves E.sub.1 and E.sub.2, respectively, and that e(X.sub.A,1, g.sub.2)=e(g.sub.1, X.sub.A,2) is satisfied (step S106).

[0090] In step S106 above, if at least one of “X.sub.A,1 is not a point on the elliptic curve E.sub.1”, “X.sub.A,2 is not a point on the elliptic curve E.sub.2”, and “e(X.sub.A,1, g.sub.2)≠e(g.sub.1, X.sub.A,2)” is satisfied, the authentication processing is considered to have failed, and the processing is ended or restarted from step S101 above. Thereafter, it is assumed that it was confirmed that X.sub.A,1 and X.sub.A,2 are points on the elliptic curves E.sub.1 and E.sub.2, respectively, and that e(X.sub.A,1, g.sub.2)=e(g.sub.1, X.sub.A,2) is satisfied.

[0091] Next, the authentication processing unit 101 of the terminal 10 calculates shared values σ.sub.1, σ.sub.2, σ.sub.3, and σ.sub.4 as follows (step S107).

σ.sub.1=e(D.sub.A,1,Q.sub.B,2)

σ.sub.2=e(D.sub.A,1+x.sub.AZ.sub.1,Q.sub.B,2+X.sub.B,2)

σ.sub.3=x.sub.AX.sub.B,1

σ.sub.4=x.sub.AX.sub.B,2

[0092] Similarly, the authentication processing unit 201 of the server 20 calculates shared values σ.sub.1, σ.sub.2, σ.sub.3, and σ.sub.4 as follows (step S108).

σ.sub.1=e(Q.sub.A,1,D.sub.B,2)

σ.sub.2=e(Q.sub.A,1+X.sub.A,1,D.sub.B,2+x.sub.BZ.sub.2)

σ.sub.3=x.sub.BX.sub.A,1

σ.sub.4=x.sub.BX.sub.A,2

[0093] Next, the authentication processing unit 101 of the terminal 10 calculates an sid as follows (step S109). Note that “sid” means “session ID”.

sid=(ID.sub.A∥ID.sub.B∥X.sub.A,1∥X.sub.A,2∥X.sub.B,1∥X.sub.B,2)

[0094] Similarly, the authentication processing unit 201 of the server 20 calculates an sid as follows (step S110).

sid=(ID.sub.A∥ID.sub.B∥X.sub.A,1∥X.sub.A,2∥X.sub.B,1∥X.sub.B,2)

[0095] Also, the authentication processing unit 101 of the terminal 10 calculates a shared key K as follows (step S111).

K=H(σ.sub.1∥σ.sub.2∥σ.sub.3∥σ.sub.4∥sid)

[0096] Note that the shared key K is stored in the storage unit 102.

[0097] Similarly, the authentication processing unit 201 of the server 20 calculates a shared key K as follows (step S112).

K=H(σ.sub.1∥σ.sub.2∥σ.sub.3∥σ.sub.4∥sid)

[0098] Note that the shared key K is stored in the storage unit 202.

[0099] As a result, the terminal 10 and the server 20 can perform TLS 1.3 processing by encrypting subsequent messages (that is, messages after the ClientHello and ServerHello) using the shared key K (step S113).

Authentication Processing (Working Example 2)

[0100] Hereinafter, Working Example 2 of the authentication processing performed using TLS 1.3 to which the key exchange with mutual authentication using ID-based encryption is applied will be described with reference to FIG. 6. FIG. 6 is a sequence diagram showing an example of the authentication processing in Working Example 2.

[0101] In Working Example 2, assume that the master private keys of the key generation center are yϵZ.sub.q and zϵZ.sub.q, and the master public keys are Y.sub.1=yg.sub.1, Y.sub.2=yg.sub.2, Z.sub.1=zg.sub.1, and Z.sub.2=zg.sub.2; the user private key of the terminal 10 is D.sub.A,1=zQ.sub.A,1=zH.sub.1(ID.sub.A)ϵG.sub.1, and the user private key of the server 20 is D.sub.B,2=zQ.sub.B,2=zH.sub.2(ID.sub.B)ϵG.sub.2. Here, H.sub.1 is a function that generates an element on G.sub.1 from a character string, and H.sub.2 is a function that generates an element on G.sub.2 from a character string. H.sub.1 and H.sub.2 are public information. Note that the user private keys D.sub.A,1 and D.sub.B,2 are generated by the key generation center and are respectively distributed to the terminal 10 and the server 20 using any method.

[0102] The authentication processing unit 101 of the terminal 10 randomly selects a short-term private key x.sub.AϵZ.sub.q and then generates a short-term public key X.sub.A,1=x.sub.Ag.sub.1ϵG.sub.1 (step S201). The short-term private key x.sub.A and the short-term public key X.sub.A,1 are stored in the storage unit 102.

[0103] The authentication processing unit 201 of the server 20 randomly selects a short-term private key x.sub.BϵZ.sub.q and then generates a short-term public key X.sub.B,2=x.sub.Bg.sub.2ϵG.sub.2 (step S202) Note that the short-term private key x.sub.B and the short-term public key X.sub.B,2 are stored in the storage unit 202.

[0104] Next, the authentication processing unit 101 of the terminal 10 transmits a ClientHello to the server 20 (step S203). At this time, the authentication processing unit 101 transmits a ClientHello including the identifier ID.sub.A of the terminal 10 and the short-term public key X.sub.A,1 to the server 20. Here, the identifier ID.sub.A and the short-term public key X.sub.A,1 can be stored in the extension area (Extension field) of the ClientHello, for example.

[0105] Next, the authentication processing unit 201 of the server 20 transmits a ServerHello to the terminal 10 (step S204). At this time, the authentication processing unit 201 transmits a ServerHello including the identifier ID.sub.B of the server 20 and the short-term public key X.sub.B,2 to the terminal 10. Here, the identifier ID.sub.B and the short-term public key X.sub.B,2 can be stored in the extension area (Extension field) of the ServerHello, for example.

[0106] The information needed for key exchange (i.e., the identifier of the communication partner and the short-term public key) is exchanged through steps S203 and S204 described above. That is, the information needed for key exchange is exchanged in one round.

[0107] Next, the authentication processing unit 101 of the terminal 10 calculates shared values σ.sub.1, σ.sub.2, and σ.sub.3 as follows (step S205).

σ.sub.1=e(D.sub.A,1,Q.sub.B,2)

σ.sub.2=e(D.sub.A,1+x.sub.AZ.sub.1,Q.sub.B,2+X.sub.B,2)

σ.sub.3=e(Z.sub.1+x.sub.AY.sub.1,X.sub.B,2)

[0108] Similarly, the authentication processing unit 201 of the server 20 calculates shared values σ.sub.1, σ.sub.2, and σ.sub.3 as follows (step S206).

σ.sub.1=e(Q.sub.A,1,D.sub.B,2)

σ.sub.2=e(Q.sub.A,1+X.sub.A,1,D.sub.B,2+x.sub.BZ.sub.2)

σ.sub.3=e(X.sub.A,1,Z.sub.2+x.sub.BY.sub.2)

[0109] Then, the authentication processing unit 101 of the terminal 10 calculates a shared key K as follows (step S207).

K=H(σ.sub.1,σ.sub.2,σ.sub.3,ID.sub.A,ID.sub.B,X.sub.A,1,X.sub.B,2)

[0110] Note that the shared key K is stored in the storage unit 102.

[0111] Similarly, the authentication processing unit 201 of the server 20 calculates a shared key K as follows (step S208).

K=H(σ.sub.1,σ.sub.2,σ.sub.3,ID.sub.A,ID.sub.B,X.sub.A,1,X.sub.B,2)

[0112] Note that the shared key K is stored in the storage unit 202.

[0113] As a result, the terminal 10 and the server 20 can perform TLS 1.3 processing by encrypting subsequent messages (that is, messages after the ClientHello and ServerHello) using the shared key K (step S209).

Authentication Processing (Working Example 3)

[0114] Hereinafter, Working Example 3 of the authentication processing performed using TLS 1.3 to which the key exchange with mutual authentication using ID-based encryption is applied will be described with reference to FIG. 7. FIG. 7 is a sequence diagram showing an example of the authentication processing in Working Example 3.

[0115] In Working Example 3, assume that the master private key of the key generation center is zϵZ.sub.q, and the master public key is Z=zg.sub.1; the user private key of the terminal 10 is D.sub.A=zQ.sub.A=ZH.sub.3(ID.sub.A)ϵG.sub.2, and the user private key of the server 20 is D.sub.B=zQ.sub.B=zH.sub.3(ID.sub.B)ϵG.sub.2. Here, H.sub.3 is a function that generates an element on G.sub.2 from a character string, and is public information. The user private keys D.sub.A and D.sub.B are generated by the key generation center and are respectively distributed to the terminal 10 and the server 20 using any method.

[0116] The authentication processing unit 101 of the terminal 10 randomly selects r.sub.AϵZ.sub.q, generates a short-term private key X.sub.A=H.sub.4(D.sub.A∥r.sub.A), and generates a short-term public key X.sub.A=x.sub.Ag.sub.1ϵG.sub.1 (step S301). Here, H.sub.4 is a function that generates an element on Z.sub.q from a character string, and is public information. Note that the short-term private key x.sub.A and the short-term public key X.sub.A are stored in the storage unit 102.

[0117] The authentication processing unit 201 of the server 20 randomly selects r.sub.BϵZ.sub.q, generates a short-term private key x.sub.B=H.sub.4(D.sub.B r.sub.B), and generates a short-term public key X.sub.B=x.sub.Bg.sub.1ϵG.sub.1 (step S302). Note that the short-term private key x.sub.B and the short-term public key X.sub.B are stored in the storage unit 202.

[0118] Next, the authentication processing unit 101 of the terminal 10 deletes the short-term private key x.sub.A from the storage unit 102 (step S303). Similarly, the authentication processing unit 201 of the server 20 deletes the short-term private key x.sub.B from the storage unit 202 (step S304).

[0119] The short-term private key x.sub.A is deleted from the storage unit 102 in step S303 above, but this is for preventing a situation in which the short-term private key x.sub.A leaks in the period before the identifier ID.sub.B and the short-term public key X.sub.B are received from the server 20. Similarly, the short-term private key x.sub.B is deleted from the storage unit 202 in step S304 above in order to prevent a situation in which the short-term private key x.sub.B is leaked before the identifier ID.sub.A and the short-term public key X.sub.A are received from the terminal 10.

[0120] Next, the authentication processing unit 101 of the terminal 10 transmits a ClientHello to the server 20 (step S305). At this time, the authentication processing unit 101 transmits a ClientHello including the identifier ID.sub.A of the terminal 10 and the short-term public key X.sub.A to the server 20. Here, the identifier ID.sub.A and the short-term public key X.sub.A can be stored in the extension area (Extension field) of the ClientHello, for example.

[0121] Next, the authentication processing unit 201 of the server 20 transmits the ServerHello to the terminal 10 (step S306). At this time, the authentication processing unit 201 transmits a ServerHello including the identifier ID.sub.B of the server 20 and the short-term public key X.sub.B to the terminal 10. Here, the identifier ID.sub.B and the short-term public key X.sub.B can be stored in the extension area (Extension field) of the ServerHello, for example.

[0122] The information needed for key exchange (that is, the identifier of the communication partner and the short-term public key) is exchanged in steps S305 and S306 described above. That is, the information needed for key exchange is exchanged in one round.

[0123] Subsequently, the authentication processing unit 101 of the terminal 10 regenerates the short-term private key x.sub.A=H.sub.4 (D.sub.A∥r.sub.A) (step S307). Note that the short-term private key x.sub.A is stored in the storage unit 102.

[0124] Similarly, the authentication processing unit 201 of the server 20 regenerates the short-term private key x.sub.B=H.sub.4(D.sub.B∥r.sub.B) (step S308). Note that the short-term private key x.sub.B is stored in the storage unit 202.

[0125] Next, the authentication processing unit 101 of the terminal 10 calculates shared values σ.sub.1, σ.sub.2, and σ.sub.3 as follows (step S309).

σ.sub.1=e(X.sub.B,D.sub.A)

σ.sub.2=e(x.sub.AZ,Q.sub.B)

σ.sub.3=x.sub.AX.sub.B

[0126] Similarly, the authentication processing unit 201 of the server 20 calculates shared values σ.sub.1, σ.sub.2, and σ.sub.3 as follows (step S310).

σ.sub.1=e(x.sub.BZ,Q.sub.A)

σ.sub.2=e(X.sub.A,D.sub.B)

σ.sub.3=x.sub.BX.sub.A

[0127] Next, the authentication processing unit 101 of the terminal 10 calculates an sid as follows (step S311).

sid=(ID.sub.A∥ID.sub.B∥X.sub.A∥X.sub.B)

[0128] Similarly, the authentication processing unit 201 of the server 20 calculates an sid as follows (step S312).

sid=(ID.sub.A∥ID.sub.B∥X.sub.A∥X.sub.B)

[0129] Then, the authentication processing unit 101 of the terminal 10 calculates a shared key K as follows (step S313).

K=H(σ.sub.1∥σ.sub.2∥σ.sub.3∥sid)

[0130] Note that the shared key K is stored in the storage unit 102.

[0131] Similarly, the authentication processing unit 201 of the server 20 calculates a shared key K as follows (step S314).

K=H(σ.sub.1∥σ.sub.2∥σ.sub.3∥sid)

[0132] Note that the shared key K is stored in the storage unit 202.

[0133] As a result, the terminal 10 and the server 20 can perform TLS 1.3 processing by encrypting subsequent messages (that is, messages after the ClientHello and ServerHello) using the shared key K (step S315).

[0134] Evaluation

[0135] Finally, evaluation of the authentication processing (authentication processing performed using TLS 1.3 to which key exchange with mutual authentication using ID-based encryption is applied) executed by the authentication system 1 according to the present embodiment will be described. As an example, the authentication processing described in Working Example 3 above was compared with conventional TLS. TLS 1.3-X25519-Ed25519, which has a relatively small amount of communication among existing encryption suites, was adopted as a target of comparison.

[0136] Table 1 below shows the results of observing the packet size of each message during the TLS handshake, and the total. Note that in Table 1, the data size of the identifier used for ID-based encryption is 20 bytes. Table 1 also lists the packet size of each message in TLS 1.3-P256-RSA and the total for reference.

TABLE-US-00001 TABLE 1 TLS1.3- TLS1.3- P256-RSA X25519- Working (Reference) Ed25519 Example 3 ClientHello 226 193 280 ServerHello 182 149 236 EncryptedExtensions 82 82  82 CertificateRequest 97 97 — Certificate.sup.(s) 1275 687 — CertificateVerify.sup.(s) 340 148 — Finished.sup.(s) 112 112 112 Certificate.sup.(c) 1319 693 — CertificateVerify.sup.(c) 340 148 — Finished.sup.(c) 112 112 112 Total 4085 2421 822 .sup.(s)Server-side transmitted message .sup.(c)Terminal-side transmitted message

[0137] As shown in Table 1 above, it can be understood that Working Example 3 can reduce the amount of communication to about 34% compared to TLS 1.3-X25519-Ed25519. For this reason, it can be understood that Working Example 3 is effective also in the case where TLS is used in, for example, RoLaWAN, Sigfox, and the like, which are communication standards for IoT devices.

[0138] The present invention is not limited to the above-described embodiments that are specifically disclosed, and various modifications and changes can be made without departing from the description of the claims.

REFERENCE SIGNS LIST

[0139] 1 Authentication system [0140] 10 Terminal [0141] 20 Server [0142] 101 Authentication processing unit [0143] 102 Storage unit [0144] 201 Authentication processing unit [0145] 202 Storage unit [0146] N Communication network