JP2024051151A - Cryptographic communication system, secure element, device, and cryptographic communication method - Google Patents

Abstract

[Problem] To provide a cryptographic communication system, secure element, device, and cryptographic communication method that do not require prior sharing of keys. [Solution] The secure element comprises a secure element key generation unit that generates a secure element public key and a secure element private key, and a secure element output unit that outputs the generated secure element public key to a server, the server comprises a server registration unit that obtains and registers the secure element public key, a server key generation unit that generates a server public key and a server private key, and a server output unit that outputs the generated server public key to the secure element, and the secure element further comprises a secure element registration unit that obtains and registers the server public key. [Selected Figure] Figure 1

Description

The present invention relates to a cryptographic communication system, a secure element, a device, and a cryptographic communication method.

In the Internet of Things (IoT), a wide variety of devices are being connected to the network, creating new added value. On the other hand, as the number of such devices connected to the Internet increases, security issues are gradually becoming apparent.

Patent Document 1 discloses a communication system in which a first key is used to perform authentication processing between a server device and an IoT device, and a third key is sent and received between the server device and the IoT device through encrypted communication using a second key to share the key.

Japanese Patent No. 6408536

However, in the communication system of Patent Document 1, the first key and the second key must be stored in advance before the third key is shared between the server device and the IoT device, so that the first key and the second key are shared in advance. This requires that a specific fixed key be prepared in advance between the server device and the IoT device, and there is a risk that the confidentiality of the communication path may be weakened due to the leakage of such a fixed key.

The present invention has been made in consideration of the above circumstances, and aims to provide a cryptographic communication system, secure element, device, and cryptographic communication method that do not require prior sharing of keys.

The cryptographic communication system according to an embodiment of the present invention is a cryptographic communication system including a server and a device equipped with a secure element, the secure element including a secure element key generation unit that generates a secure element public key and a secure element private key, and a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device, the server including a server registration unit that acquires and registers the secure element public key output from the secure element output unit, a server key generation unit that generates a server public key and a server private key, and a server output unit that outputs the server public key generated by the server key generation unit to the secure element via the device, the secure element further including a secure element registration unit that acquires and registers the server public key output from the server output unit, the server performs cryptographic communication based on the registered secure element public key, and the secure element performs cryptographic communication based on the registered server public key.

A secure element according to an embodiment of the present invention is a secure element mounted on a device that performs cryptographic communication with a server, and includes a secure element key generation unit that generates a secure element public key and a secure element private key, a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device, and a secure element registration unit that acquires and registers the server public key output by the server, and uses the server public key registered by the secure element registration unit for cryptographic communication between the secure element and the server.

The device according to the embodiment of the present invention is equipped with the above-mentioned secure element and can perform encrypted communication with a specified server.

The server according to an embodiment of the present invention is a server that performs cryptographic communication with a device equipped with a secure element, and includes a server key generation unit that generates a server public key and a server private key, a server output unit that outputs the server public key generated by the server key generation unit to the secure element via the device, and a server registration unit that obtains and registers the secure element public key output by the secure element, and uses the secure element public key registered by the server registration unit for cryptographic communication with the secure element.

A computer program according to an embodiment of the present invention causes a computer to execute a process of generating a server public key and a server private key, a process of outputting the generated server public key to a secure element mounted on a device, a process of acquiring and registering a secure element public key output by the secure element, and a process of performing cryptographic communication with the secure element using the registered secure element public key.

The cryptographic communication method according to an embodiment of the present invention is a cryptographic communication method between a server and a device equipped with a secure element, in which the secure element generates a secure element public key and a secure element private key, and outputs the secure element public key generated via the device to the server, the server obtains and registers the secure element public key output from the secure element, generates a server public key and a server private key, and outputs the server public key generated via the device to the secure element, the secure element further obtains and registers the server public key output from the server, the server performs cryptographic communication based on the registered secure element public key, and the secure element performs cryptographic communication based on the registered server public key.

According to the present invention, there is no need to pre-share the key.

1 is a block diagram showing an example of a configuration of an encrypted communication system according to an embodiment of the present invention; FIG. 2 is an explanatory diagram showing an example of generation of an asymmetric key pair and exchange of a public key. FIG. 11 is an explanatory diagram illustrating an example of generation of a device common key. FIG. 11 is an explanatory diagram showing an example of public key exchange using a certificate authority; FIG. 11 is an explanatory diagram showing an example of revoking a public key signature and discarding a device common key. FIG. 11 is an explanatory diagram illustrating an example of device authentication using a device certificate. FIG. 11 is an explanatory diagram showing an example of dynamic regeneration of a key. FIG. 11 is an explanatory diagram showing an example of common key generation when a shared secret is added to an input. FIG. 11 is an explanatory diagram showing an example of updating a shared secret; FIG. 11 is an explanatory diagram showing an example of adding a key generation algorithm. 13 is a flowchart illustrating an example of a procedure for a public key exchange process performed by a server. 11 is a flowchart showing an example of a procedure for a public key exchange process performed by a secure element. 10 is a flowchart illustrating an example of a procedure for a process of generating a device common key by a server. 10 is a flowchart showing an example of a procedure for a process of generating a device common key by a secure element.

Below, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing an example of the configuration of a cryptographic communication system according to this embodiment. The cryptographic communication system includes a server 10 that performs key management, and a device 70. The device 70 is a device that is subject to encryption key management by the server 10, and includes a device (also referred to as an electronic device) that corresponds to a "thing" in the "Internet of Things" (IoT). The device 70 is also referred to as an IoT device, and includes a secure element 50 and a memory unit 71. That is, the device 70 is equipped with the secure element 50, and the parts of the device 70 other than the secure element 50 are referred to as the device main body.

The secure element 50 is tamper-resistant and physically independent of the device 70. The secure element 50 stores a key for communicating with the server 10, and supplies a key that it generates to the device 70. The secure element 50 may be a hardware element or a software element (software component). In the case of a software component, this corresponds to an independent security environment such as a Trusted Execution Environment (TEE) and an application that runs in that environment. This allows an appropriate secure element 50 to be installed in the device 70 depending on the type of device, etc.

The server 10 is a server that manages the keys of the device 70 together with the secure element 50. Encrypted communication can be performed between the server 10 and the device 70 via the interface 1. The interface 1 can be established by opening a network connection such as TCP/IP on a physical interface such as Ethernet (registered trademark) or Wifi (registered trademark).

The device 70 and the secure element 50 are connected via an interface 2. If the secure element 50 is an IC card, the interface 2 is, for example, ISO7816, and if the secure element 50 is other than an IC card, the interface 2 is a physical communication path such as SPI/I2C. If the secure element 50 is a software component, the interface 2 is assumed to be an API (Application Programming Interface) or the like. When the secure element 50 communicates with the server 10, this can be done via an interface 1 between the device 70 and the server 10.

The server 10 can be connected to the certificate authority server 100 via interface 4. The device 70 can be connected to the certificate authority server 100 via interface 3. The interface 3 can have the same configuration as the interface 1.

The certificate authority server 100 is a server that certifies the validity of public keys held by other entities (servers and secure elements) and is also called a CA (Certificate Authority, Certification Authority) server. The certificate authority server 100 issues a signature in response to a CSR (Certificate Signing Request: signature generation request) to prove the validity of the entity that provides the public key. The certificate authority server 100 also receives inquiries about the revocation of a public key and returns the revocation status to the source of the inquiry.

The secure element 50 comprises a memory unit 51, a server public key store 52, a key pair generation unit 53, a random number generation unit 54, a signature verification unit 55, a common key generation unit 56, a shared secret update unit 57, and a key validity confirmation unit 58. The common key generation unit 56 contains algorithms for key generation, and is equipped with SHA-1 (59) and SHA-256 (60).

The storage unit 51 stores values such as the SCID, shared secret, SC private key, SC public key, and device public key. The SCID is also called secure element identification information and is an ID uniquely assigned to each secure element. The shared secret is also called shared information and is secret information shared in advance between the server 10 and the secure element 50, and can be secret information that is not disclosed to anyone other than the server 10 and the secure element 50. The SC private key is also called the secure element private key and is a private key included in the asymmetric key pair generated by the secure element 50. The SC public key is also called the secure element public key and is a public key included in the asymmetric key pair generated by the secure element 50. The device public key is a key for verifying the authenticity of a device certificate when the device 70 provides the certificate.

The server public key store 52 functions as a secure element registration unit and is a database for registering a server public key within the secure element 50. When a server public key is registered, the server ID (server identification information) and the server public key are stored in association with each other.

The key pair generation unit 53 functions as a secure element key generation unit, and generates a key pair (SC public key and SC private key) for asymmetric key cryptography (such as RSA) within the secure element 50.

The random number generation unit 54 generates random numbers within the secure element 50.

The shared key generation unit 56 has a function as a secure element shared key generation unit, and generates a shared key within the secure element 50 according to input information and a predetermined algorithm. The shared key generation unit 56 can, for example, perform a predetermined hash calculation on the input data string and output the hash value obtained by the hash calculation. The shared key generation unit 56 has multiple hash calculation algorithms, and it is decided in advance which hash calculation algorithm will be used.

The shared secret update unit 57 operates when updating the shared secret from outside.

The key validity confirmation unit 58 confirms the validity of the asymmetric key generated by the server 10. The key validity confirmation unit 58 queries the certificate authority server 100 about the validity of the asymmetric key and determines the validity of the key held by the server 10.

The storage unit 71 of the device body stores a device ID and a device certificate. The device ID is a unique ID assigned to each device. The device certificate is a certificate written by the device manufacturer when the device 70 is manufactured. A digest signature is applied to information including at least the device ID using a device private key held by the device manufacturer, and the signature is attached.

The server 10 comprises a memory unit 11, an SC public key store 12, a key pair generation unit 13, a random number generation unit 14, a signature verification unit 15, a common key generation unit 16, a shared secret update unit 17, and a key validity confirmation unit 18. The common key generation unit 16 contains algorithms for key generation, and is equipped with SHA-1 (19) and SHA-256 (20).

The memory unit 11 stores values such as a server ID, a shared secret, a server private key, and a server public key. The server ID is also called server identification information, and is an ID that is uniquely assigned to each server. The shared secret is also called shared information, and is secret information that is shared in advance between the server 10 and the secure element 50, and can be secret information that is not disclosed to anyone other than the server 10 and the secure element 50. The server private key is a private key included in an asymmetric key pair generated by the server 10. The server public key is a public key included in an asymmetric key pair generated by the server 10.

The SC public key store 12 functions as a server registration unit and is a database for registering an SC public key within the server 10. When registering an SC public key, the SCID and the SC public key are stored in association with each other.

The key pair generation unit 13 functions as a server key generation unit and generates a key pair (server public key and server private key) for asymmetric key cryptography (e.g., RSA) within the server 10.

The random number generation unit 14 generates random numbers within the server 10.

The shared key generation unit 16 has a function as a server shared key generation unit, and generates a shared key in the server 10 according to input information and a predetermined algorithm. The shared key generation unit 16 can, for example, perform a predetermined hash calculation on the input data string and output the hash value obtained by the hash calculation. The shared key generation unit 16 has multiple hash calculation algorithms, and it is decided in advance which hash calculation algorithm will be used.

The shared secret update unit 17 operates when updating the shared secret from outside.

The key validity confirmation unit 18 confirms the validity of the asymmetric key generated by the secure element 50. The key validity confirmation unit 18 queries the certificate authority server 100 about the validity state of the asymmetric key and determines the validity of the key of the secure element 50 that it holds.

The certificate authority server 100 includes a public key revoked list 101, a signature generated list 102, a signature generation unit 103, a CA public key, and a CA private key.

The CA public key is a public key held by the certification authority server 100. When verifying a signature generated by the certification authority server 100, the entity wishing to verify obtains and uses the CA public key.

The CA private key is a private key held by the certification authority server 100. When a public key generation entity requests signature generation by the CSR, the certification authority server 100 generates a signature using the CA private key.

The signature generation unit 103 generates a signature using the CA private key for the generated public key in response to a request from the public key generation entity.

The signature generated list 102 is a list of public keys and signature target IDs for which signatures have been generated. It is added when the certificate authority server 100 signs a public key.

The revoked public key list 101 is a list of signed public keys whose signatures have been revoked at the discretion of the certificate authority server 100.

Next, we will explain the operation of the cryptographic communication system and the cryptographic communication method of this embodiment.

Figure 2 is an explanatory diagram showing an example of the generation of an asymmetric key pair and the exchange of public keys. In order to perform encrypted communication, it is first necessary to exchange public keys between the server 10 and the secure element 50. The processes indicated by symbols P1 to P13 are explained below.

P1 (SC-side key pair generation instruction): The device 70 instructs the secure element 50 to generate an asymmetric key pair and exchange a public key via the interface 2 between the device 70 and the secure element 50.

P2 (SC-side asymmetric key pair generation): The secure element 50 uses the key pair generation unit 53 to internally generate a key pair for asymmetric key cryptography. Here, SC private key 1 and SC public key 1 are generated as key values.

P3 (encryption of SCID): The secure element 50 functions as a secure element second encryption unit and encrypts the value of its own SCID with the generated SC private key.

P4 (transmission of SC public key and encrypted SCID): The secure element 50 functions as a secure element output unit, and transmits the SC public key and encrypted SCID to the server 10 via the device 70.

P5 (Decryption of encrypted SCID): Server 10 has the function of a server second decryption unit and decrypts the received encrypted SCID using the received SC public key (SC public key 1).

P6 (Verifying SCID): The server 10 checks the value of the decrypted SCID. For example, the server 10 verifies the SCID by checking whether a public key has already been registered with the same SCID in the SC public store 12. If a public key has already been registered, the public key registration process is deemed to have failed, and the process is interrupted here.

P7 (Registration in SC public key store): If the value of the decrypted SCID is checked and found to be problem-free, the server 10 associates the SCID with the SC public key and stores them in the SC public key store 12. Here, SCID: SC012345 and SC public key 1 are stored in association with each other. This makes it possible to determine the validity of the acquired SC public key before registering it.

P8 (server-side key pair generation instruction): The server 10 uses the key pair generation unit 13 to internally generate a key pair for asymmetric key cryptography. Here, a server private key 1 and a server public key 1 are generated as key values.

P9 (encryption of server ID): The server 10 functions as a server second encryption unit and encrypts the value of its own server ID with the generated server private key.

P10 (transmission of server public key and encrypted server ID): The server 10 functions as a server output unit and transmits the server public key and encrypted server ID to the secure element 50 via the device 70.

P11 (Decryption of encrypted server ID): The secure element 50 has the function of a secure element second decryption unit, and decrypts the received encrypted server ID using the received server public key (server public key 1).

P12 (Verifying server ID): The secure element 50 checks the value of the decrypted server ID. The server ID is verified, for example, by checking whether a public key has already been registered with the same server ID in the server public key store 52. If it has already been registered, the public key registration process is deemed to have failed, and the process is interrupted here.

P13 (Registration in server public key store): If the value of the decrypted server ID is checked and there is no problem, the secure element 50 associates the server ID with the server public key and stores them in the server public key store 52. Here, the server ID: KeyManagement.com and server public key 1 are stored in association with each other. This makes it possible to determine the authenticity of the acquired server public key before registering it.

As described above, the server 10 can obtain and register the SC public key output from the secure element 50. This allows the server 10 to share the SC public key with the secure element 50. In other words, there is no need to prepare the SC public key in advance and store it in the server 10 like a fixed key, and there is no risk of the confidentiality of the communication path being weakened due to leakage of the fixed key, etc. Furthermore, since the SC public key is dynamically generated by the secure element 50, it does not have the property of being a specific fixed key, ensuring freedom in key setting.

The secure element 50 can also obtain and register the server public key output from the server 10. This allows the secure element 50 to share the server public key with the server 10. In other words, there is no need to prepare the server public key in advance and store it in the secure element 50 like a fixed key, and there is no risk of the confidentiality of the communication path being weakened due to leakage of the fixed key, etc. Furthermore, since the server public key is dynamically generated by the server 10, it does not have the property of being a specific fixed key, ensuring freedom in key setting.

Then, as described below, the server 10 can perform cryptographic communication based on the registered SC public key, and the secure element 50 can perform cryptographic communication based on the server public key registered in the secure element 50. This means that the server 10 and the secure element 50 do not need to share keys in advance. In addition, since an SC public key corresponding to the SC private key is registered in the server 10, a communication path capable of one-way encryption from the server 10 to the secure element 50 can be secured between the server 10 and the secure element 50. In addition, since a server public key corresponding to the server private key is registered in the secure element 50, a communication path capable of one-way encryption from the secure element 50 to the server 10 can be secured between the server 10 and the secure element 50.

In the example of FIG. 2, a key generation instruction is first issued to the secure element 50 via the device 70, but the execution order may be reversed, and the server 10 may first generate an asymmetric key pair and transmit it to the secure element 50.

When registering an SC public key, the SCID is verified, and when registering a server public key, the server ID is verified by checking whether the public key (the value itself) to be registered has already been registered, as described above, or by checking whether registration of the SCID and server ID is prohibited.

Figure 3 is an explanatory diagram showing an example of generating a device common key. After a public key pair is shared by the process shown in Figure 2, a device common key is generated for performing encrypted communication between the server 10 and the device 70. The processes indicated by symbols P31 to P42 are described below.

P31 (key generation instruction): The device 70 instructs the secure element 50 to generate a device common key via the interface 2 between the device 70 and the secure element 50.

P32 (Generation of SC side random number): The secure element 50 uses the random number generation unit 54 to generate an SC side random number as specified secure element information.

P33 (encryption of SC side random number): The secure element 50 has the function of a secure element first encryption unit, and encrypts the generated SC side random number using the server public key that has already been registered.

P34 (transmission of encrypted SC side random number): The secure element 50 transmits the encrypted SC side random number to the server 10 via the device 70.

P35 (Decryption of encrypted SC side random number): The server 10 has a function as a server first decryption unit, decrypts the received encrypted SC side random number with a server private key that it holds, and retains the decrypted SC side random number. This allows the server 10 to share the SC side random number generated by the secure element 50 with the secure element 50.

P36 (Generation of server-side random numbers): The server 10 uses the random number generation unit 14 to generate server-side random numbers as specified server information.

P37 (Encryption of server-side random number): The server 10 has the function of a server first encryption unit, and encrypts the generated server-side random number using the already registered SC public key.

P38 (transmission of encrypted server-side random number): The server 10 transmits the encrypted server-side random number to the secure element 50 via the device 70.

P39 (Decryption of encrypted server-side random number): The secure element 50 has a function as a secure element first decryption unit, decrypts the received encrypted server-side random number with the SC private key that it holds, and retains the decrypted server-side random number. This allows the secure element 50 to share the server-side random number generated by the server 10 with the server 10. The server 10 and the secure element 50 can then share the SC-side random number and the server-side random number, and can share information used when generating a device shared key.

P40 (generation of device common key): The server 10 and secure element 50 use the exchanged SC side random number and server side random number as input to obtain output from the common key generation units 16, 56. Here, it is assumed that the server 10 and secure element 50 have agreed in advance to use, for example, SHA-256 as the algorithm to be used for key generation. Therefore, a SHA-256 operation is performed using the same SC side random number and server side random number as input, and the server 10 and secure element 50 can obtain the same data string as output. This data string is used as the device common key.

P41 (Extracting the common key to the device): The device 70 instructs the secure element 50 to extract the device common key, and obtains the device common key from the secure element 50.

P42 (Establishment of encrypted communication using device common key): From then on, the server 10 and the device 70 establish a symmetric key encrypted communication path based on the same device common key, and perform encrypted communication.

As described above, the device target key value itself is not exchanged between the server 10 and the secure element 50. In other words, with the above configuration, there is no need to exchange the common key via a communication path between the server 10 and the device 70, and since the common key is not on the communication path, the common key cannot be generated unless the details of the common key generation algorithm are known. Furthermore, even if the secure element information (e.g., SC side random number) and server information (e.g., server side random number) used to generate the common key are leaked, the common key cannot be generated unless the details of the common key generation algorithm are known. This ensures that the encrypted communication between the server 10 and the device 70 is not compromised.

In the above example, random numbers are used as the secure element information and server information, but this is not limited to this. Data other than random numbers can also be used as the secure element information and server information.

In this embodiment, the specific method of selecting the public key used to encrypt the random number is to simply select the SC public key and server public key used in the most recent key exchange, but it is also possible to select from multiple SC public keys and server public keys.

Next, we will explain use cases for handling asymmetric keys.

Figure 4 is an explanatory diagram showing an example of public key exchange using a certification authority. In the example shown in Figure 2, the server 10 and the secure element 50 each generate their own keys, but simply generating the keys individually does not guarantee the legitimacy of the generated keys. In other words, even if information exchange using a public key is successful, the party with which the information is exchanged is not necessarily a legitimate server or secure element, and there is a possibility of communication with an unauthorized party. In the example of Figure 4, as a method of preventing unauthorized communication, the legitimacy of the generated public key is increased by cooperating with a public key certification authority (certification authority server 100). The processes indicated by symbols P51 to P71 will be described below.

P51 (SC side key pair generation instruction): The device 70 instructs the secure element 50 to generate an asymmetric key pair and exchange a public key via the interface 2 between the device 70 and the secure element 50.

P52 (SC-side asymmetric key pair generation): The secure element 50 uses the key pair generation unit 53 to internally generate a key pair for asymmetric key cryptography. Here, SC private key 1 and SC public key 1 are generated as key values.

P53 (signature request to the certificate authority): The secure element 50 functions as a secure element authentication request unit, and requests the certificate authority server 100 to sign the generated SC public key. At least the SC public key is sent from the secure element 50 to the certificate authority server 100 via the device 70.

P54 (returning signature to SC public key): The certificate authority server 100 checks the signature request from the secure element 50. Here, the certificate authority server 100 checks whether the SCID of the secure element 50 that requested the signature is included in the signature generated list 102 held by the certificate authority server 100. If the SCID is not included, the certificate authority server 100 determines that there is no problem, generates a CA signature for the SC public key using the CA private key held by the certificate authority server 100, and returns the generated CA signature to the secure element 50 via the device 70. After verifying that the secure element 50 that requested the signature is a trustworthy entity, the certificate authority server 100 signs the SC public key using the CA private key, thereby indicating that the SC public key is trustworthy. The secure element 50 has a function as a secure element acquisition unit, and acquires the CA signature for the SC public key. The certificate authority server 100 records the SCID in the signature generated list 102.

P55 (Encrypt SCID): The secure element 50 encrypts the value of its own SCID with the generated SC private key.

P56 (sending SC public key and encrypted SCID): The secure element 50 sends the SC public key, the CA signature on the SC public key, and the encrypted SCID to the server 10 via the device 70. This makes it possible to establish the validity of the SC public key generated by the secure element 50.

P57 (CA public key request): The server 10 requests the certification authority server 100 to send the CA public key.

P58 (Verification of CA signature on SC public key): The certification authority server 100 sends the CA public key to the server 10. The server 10 uses the received CA public key to verify the CA signature on the received SC public key. If the verification reveals a problem, the public key registration process is deemed to have failed and processing is interrupted here. If the verification reveals no problem, subsequent processing continues. This reduces the risk of performing key exchange and communication with an untrusted fraudulent entity.

P59 (Decryption of encrypted SCID): The server 10 decrypts the received encrypted SCID using the received SC public key (SC public key 1).

P60 (Verifying SCID): The server 10 checks the value of the decrypted SCID. For example, the server 10 verifies the SCID by checking whether a public key has already been registered with the same SCID in the SC public store 12. If a public key has already been registered, the public key registration process is deemed to have failed, and the process is interrupted here.

P61 (Register in SC public key store): If the value of the decrypted SCID is checked and there is no problem, the server 10 associates the SCID with the SC public key and stores them in the SC public key store 12.

P62 (server-side key pair generation instruction): The server 10 uses the key pair generation unit 13 to internally generate a key pair for asymmetric key cryptography. Here, a server private key 1 and a server public key 1 are generated as key values.

P63 (signature request to certification authority): The server 10 functions as a server authentication request unit and requests the certification authority server 100 to sign the generated server public key. At least the server public key is sent from the server 10 to the certification authority server 100.

P64 (return of signature to server public key): The certification authority server 100 checks the signature request from the server 10. Here, the certification authority server 100 checks whether the server ID of the server 10 that requested the signature is included in the signature generated list 102 held by the certification authority server 100. If the server ID is not included, the certification authority server 100 assumes that there is no problem, generates a CA signature for the server public key using the CA private key held by the certification authority server 100, and returns the generated CA signature to the server 10. After confirming that the secure element 50 that requested the signature is a trustworthy entity, the certification authority server 100 uses the CA private key to sign the server public key, thereby indicating that the server public key is trustworthy. The server 10 has a function as a server acquisition unit and acquires the CA signature for the server public key. The certification authority server 100 records the server ID in the signature generated list 102.

P65 (Encryption of server ID): The server 10 encrypts the value of its own server ID with the generated server private key.

P66 (sending server public key and encrypted server ID): The server 10 sends the server public key, the CA signature on the server public key, and the encrypted server ID to the secure element 50 via the device 70. This makes it possible to establish the validity of the server public key generated by the server 10.

P67 (CA public key request): The secure element 50 requests the certificate authority server 100 to transmit the CA public key via the device 70.

P68 (Verification of CA signature on server public key): The certificate authority server 100 sends the CA public key to the secure element 50 via the device 70. The secure element 50 uses the received CA public key to verify the CA signature on the received server public key. If the verification shows a problem, the public key registration process is deemed to have failed and the process is interrupted here. If the verification shows no problem, the process continues.

P69 (Decryption of encrypted server ID): The secure element 50 decrypts the received encrypted server ID using the received server public key.

P70 (Verifying server ID): The secure element 50 checks the value of the decrypted server ID. The server ID is verified, for example, by checking whether a public key has already been registered with the same server ID in the server public key store 52. If it has already been registered, the public key registration process is deemed to have failed, and the process is interrupted here.

P71 (Registration in server public key store): If the value of the decrypted server ID is checked and found to be problem-free, the secure element 50 associates the server ID with the server public key and stores them in the server public key store 52. This reduces the risk of communicating through key exchange with an untrusted unauthorized entity.

In the example of Figure 4, compared to the example of Figure 2, (1) immediately after generating a public key, a signature on the generated public key is requested from the certification authority, and the returned signature is then attached and sent to the other party, and (2) immediately after receiving the public key, a CA public key is requested from the certification authority, and the received CA public key is used to verify the signature. In a public key infrastructure, the certification authority verifies that the entity requesting the signature is a trustworthy entity, and then signs the requesting entity's public key with its own private key, thereby indicating that the public key is trustworthy. Therefore, if signature verification fails on the public key receiving side, the public key indicates that the trust asserted by the certification authority is invalid. This reduces the risk of performing key exchange and communicating with an untrusted and fraudulent entity.

In this embodiment, for convenience, the certificate authority checks whether the ID of the signature requesting entity is present in the list of generated signatures to simply determine whether or not to grant a signature request. However, the certificate authority can use an appropriate method in accordance with the certificate authority's security policy to actually verify the signature requesting entity.

Figure 5 is an explanatory diagram showing an example of revoking a public key signature and discarding a device common key. There may be cases where it is desired to revoke a public key that was once shared and block cryptographic communication using the device common key in the event of a private key leak or for lifecycle management of the device 70 or server 10. In such cases, for example, the trigger can be the revocation process of the public key by the certification authority. The processes indicated by symbols P81 to P87 are described below.

P81 (Add to revoked public key list): The certificate authority server 100 writes the ID of the public key to be revoked to the revoked public key list 101. Here, this information is added to revoke SC public key 1 with SCID: SC012345.

P82 (encrypted communication between server and device): The server 10 and the device 70 perform encrypted communication using a device common key that has already been generated.

P83 (Server-side key verification process): Before decrypting the encrypted communication on the device 70 side, the encryption communication unit 21 of the server 10 requests the key validity confirmation unit 18 to verify the validity of the public key.

P84 (request to send revoked list): The key validity verification unit 18 requests the certificate authority server 100 to send the revoked public key list 101.

P85 (obtaining and verifying revoked key list): The certificate authority server 100 returns the revoked public key list 101 to the key validity verification unit 18. The key validity verification unit 18 checks the revoked public key list 101 returned and verifies that the SC public key of the device 70, with which it is currently communicating, has been revoked.

P86 (End of cryptographic communication): The key validity verification unit 18 determines that the trust relationship based on the public key between the currently communicating device 70 and secure element 50 has been lost, and ends the currently opened cryptographic communication session.

P87 (discarding public key and device common key): The key validity verification unit 18 discards the public key and device common key for SCID: SC012345 registered in the SC public key store 12.

As described above, the key validity confirmation unit 18 has the function of a server determination unit, and can determine whether a registered SC public key has been revoked at a required timing. The required timing can be, for example, the start of encrypted communication, each time a specified number of communications have been performed, or when an external request is received, but is not limited to these. The revocation of the SC public key can be determined, for example, based on the result of the public key revocation process performed by the certification authority server 100 (the revoked public key list 101).

The key validity confirmation unit 18 has a function as a server invalidation processing unit, and can invalidate a registered SC public key if it is determined that the SC public key has expired. This makes it possible to realize the need to invalidate a public key that has been shared once in order to prevent the leakage of a private key or for the life cycle management of a device or server.

The key validity verification unit 18 can also invalidate the common key generated by the server 10. This makes it possible to block encrypted communication using the common key.

In the example of FIG. 5, the revocation status of the public key is queried from the server 10, but this is not limited thereto, and the same process may be performed from the device 70 and the secure element 50. In this case, the key validity confirmation unit 58 of the secure element 50 has a function as a secure element determination unit, and can determine whether the registered server public key has been revoked at a required timing. The required timing can be, for example, the start of encrypted communication, each time a predetermined number of communications have been performed, or when an external request is made, but is not limited thereto. The revocation of the server public key can be determined, for example, based on the result of the public key revocation process by the certification authority server 100 (the revoked public key list 101).

The key validity confirmation unit 58 has a function as a secure element invalidation processing unit, and can invalidate a registered server public key if it is determined that the server public key has expired. This makes it possible to realize the need to invalidate a public key that has been shared once in order to prevent the leakage of a private key or for the life cycle management of a device or server.

The key validity verification unit 58 can also invalidate the common key generated by the secure element 50. This makes it possible to block encrypted communication using the common key.

In this embodiment, a certificate revocation list (CRL) is used as a means for sending and receiving revocation information, but revocation information may be confirmed by other means such as the online certificate status protocol (OCSP).

Next, we will explain use cases related to handling shared keys.

Figure 6 is an explanatory diagram showing an example of device authentication using a device certificate. The processes indicated by symbols P91 to P104 are explained below.

P91 (key generation instruction): The device 70 instructs the secure element 50 to generate a device common key via the interface 2 between the device 70 and the secure element 50.

P92 (Generation of SC side random number): The secure element 50 uses the random number generation unit 54 to generate an SC side random number.

P93 (Encryption of SC side random number): The secure element 50 encrypts the generated SC side random number using the server public key that has already been registered.

P94 (transmission of encrypted SC side random number): The secure element 50 transmits the encrypted SC side random number to the server 10 via the device 70.

P95 (Decryption of encrypted SC side random number): The server 10 decrypts the received encrypted SC side random number with the server private key that it holds, and retains the decrypted SC side random number. This allows the server 10 to share the SC side random number generated by the secure element 50 with the secure element 50.

P96 (Generation of server-side random numbers): The server 10 uses the random number generation unit 14 to generate server-side random numbers as specified server information.

P97 (Encryption of server-side random number): The server 10 encrypts the generated server-side random number using the already registered SC public key.

P98 (sending encrypted server-side random number): The server 10 sends the encrypted server-side random number to the secure element 50 via the device 70.

P99 (Decryption of encrypted server-side random number): The secure element 50 decrypts the received encrypted server-side random number with the SC private key that it holds, and retains the decrypted server-side random number. This allows the secure element 50 to share the server-side random number generated by the server 10 with the server 10. The server 10 and the secure element 50 can then share the SC-side random number and the server-side random number, and can share information used when generating the device shared key.

P100 (generation of device common key): The server 10 and secure element 50 receive the exchanged SC side random number and server side random number as input and obtain an output from the common key generation units 16, 56. Here, it is assumed that the server 10 and secure element 50 have agreed in advance to use, for example, SHA-256 as the algorithm to be used for key generation. Therefore, a SHA-256 operation is executed using the same SC side random number and server side random number as input, and the server 10 and secure element 50 can obtain the same data string as output.
This data string is used as the device common key.

P101 (input of device certificate and device ID): The secure element 50 requests input of the device certificate and device ID as a prerequisite for outputting the device common key. The device 70 transmits the device certificate and device ID to the secure element 50.

P102 (Verification of device certificate): The secure element 50 functions as a device authentication unit and verifies the contents of the received device certificate using the device public key stored internally. Specifically, it decrypts the encrypted device ID in the device certificate with the device public key and compares it with the plaintext device ID received separately. If the verification fails, the secure element 50 interrupts the process here and does not output the device common key to the outside. If the verification is successful, it performs the subsequent processes.

P103 (Extracting the common key to the device): The device 70 instructs the secure element 50 to extract the device common key, and obtains the device common key from the secure element 50.

P104 (Establishment of encrypted communication using device common key): From then on, the server 10 and the device 70 establish a symmetric key encrypted communication path based on the same device common key, and perform encrypted communication.

As described above, the secure element 50 has a device authentication unit that authenticates the device (device body) to which the secure element 50 (itself) is connected. Note that device authentication is performed using a certificate in which the device ID is encrypted with an asymmetric key, but is not limited to this algorithm and any appropriate method can be used.

If the device body is authenticated, the secure element 50 outputs the generated common key to the device body. This makes it possible to confirm that an appropriate secure element is connected to the intended (genuine) device.

Figure 7 is an explanatory diagram showing an example of dynamic regeneration of a key. In this embodiment, the server 10 side can generate a key within a component that it can control, but the device 70 side relies on the secure element 50 for key generation, and the handling authority of the key is asymmetric between the server 10 and the device 70. This feature allows the security of the device 70 side to be subordinated to the secure element 50, making the key management of the device 70 stronger. In other words, if the keys of the server 10 and the secure element 50 are dynamically updated based on a certain regularity, the device 70 will not be able to correctly execute subsequent encrypted communication unless it receives the updated key from the secure element 50. This is synonymous with dynamic verification that the device 70 is operating under the appropriate management of the secure element 50, and means that the security of the device 70 can be verified continuously, not just at the time of startup such as secure boot or at the time of key generation. Below, the processes indicated by the symbols P111 to P118 will be described.

P111 (Preparation of device common key): Based on the process illustrated in FIG. 3, a first generation key (device common key 1) is provided to each of the server 10 and the device 70.

P112 (Establishment of cryptographic session and encrypted communication): The server 10 and the device 70 perform cryptographic communication based on the device common key 1 until a trigger for key updating occurs. The trigger for key updating can be, for example, when a certain number of data transfers have been performed, but is not limited to this.

P113 (Device common key update): When a key update is triggered during encrypted communication, the server 10 and secure element 50 update the device common key 1 in accordance with a specified algorithm. The algorithm for generating the key during update, for example, uses the current key as input to the common key generation units 16, 56, and uses the value obtained by SHA-256 hash output as the new key. In other words, the SHA-256 hash value for the device common key 1 is used as the device common key 2. Note that the algorithm for generating the key during update is not limited to this, and any appropriate method can be used.

P114 (Device retrieves key after update): In this situation, even if the device 70 attempts encrypted communication, it cannot communicate properly because the key on the server 10 side has been updated. Therefore, the device 70 again requests the secure element 50 to output the device common key 2. The secure element 50 supplies the updated device common key 2 to the device 70.

P115 (Establishment of cryptographic session and encrypted communication): The server 10 and the device 70 perform cryptographic communication based on the device common key 2 until an opportunity to update the key occurs.

P116 (Device shared key update): When a key update is triggered during encrypted communication, the server 10 and the secure element 50 update the device shared key 2 according to a specified algorithm. In other words, the SHA-256 hash value of the device shared key 2 becomes the device shared key 3.

P117 (Device retrieves key after update): In this situation, even if the device 70 attempts encrypted communication, it cannot communicate properly because the key on the server 10 side has been updated. Therefore, the device 70 again requests the secure element 50 to output the device common key 3. The secure element 50 supplies the updated device common key 3 to the device 70.

P118 (Establishment of cryptographic session and encrypted communication): The server 10 and the device 70 perform cryptographic communication based on the device common key 3 until a key update trigger occurs.

As described above, each of the common key generating units 16 and 56 can update the common key that it has generated at a predetermined opportunity. The predetermined opportunity can be, for example, when the number of encrypted communications performed using the same common key reaches a predetermined number, or when an update instruction is given from outside to the server or secure element, but is not limited to this.

As described above, the device 70 relies on the secure element 50 to generate the shared key, so the security of the device 70 is subordinate to the secure element 50, making the shared key management of the device 70 even stronger.

In other words, if the shared key of the server 10 and the secure element 50 is dynamically updated based on a certain regularity, the device 70 cannot correctly execute encrypted communication after the shared key is updated unless the device 70 receives the updated shared key from the secure element 50. This allows the security of the device 70 to be verified continuously.

The key update algorithm is not limited to the one mentioned above. To enhance security, it is also possible to apply a one-time password generation algorithm such as TOTP (Time-based One-Time Password) or HOTP (HMAC-based One-Time Password) defined in the RFC.

In the example of FIG. 7, if the device 70 attempts to communicate using the old device common key without extracting the updated device common key, the server 10 will not be able to correctly decrypt the received data. In this case, the server 10 can perform various appropriate processes according to the security policy.

In other words, if the shared key does not match between the server 10 and the device 70, the server 10 can execute processing to deal with the abnormality of the device 70. Processing to deal with the abnormality of the device 70 includes, for example, processing to cut off currently established encrypted communication, processing to invalidate an exchanged public key pair, processing to reject public key registration using the SCID of the secure element 50 and processing to treat it as an unauthorized device, etc.

Figure 8 is an explanatory diagram showing an example of common key generation when a shared secret is added to the input. In the above example, all inputs from which the device common key is generated depend on the information exchanged between the server 10 and the secure element 50. Even in this state, it is possible to perform appropriate key generation, but depending on the security policy, there may be a need to perform key generation that depends on secret information held by the secure element 50. The processes indicated by symbols P121 to P132 are described below.

P121 (Writing the shared secret and sharing it with the server): The manufacturer of the secure element 50 writes the shared secret into the secure element 50 in advance and shares the shared secret with the administrator of the server 10 in advance.

P122 (key generation instruction): The device 70 instructs the secure element 50 to generate a device common key via the interface 2 between the device 70 and the secure element 50.

P123 (Generation of SC side random number): The secure element 50 uses the random number generation unit 54 to generate an SC side random number as specified secure element information.

P124 (Encryption of SC side random number): The secure element 50 encrypts the generated SC side random number using the server public key that has already been registered.

P125 (transmission of encrypted SC side random number): The secure element 50 transmits the encrypted SC side random number to the server 10 via the device 70.

P126 (Decryption of encrypted SC side random number): The server 10 decrypts the received encrypted SC side random number with the server private key that it holds, and retains the decrypted SC side random number. This allows the server 10 to share the SC side random number generated by the secure element 50 with the secure element 50.

P127 (Generation of server-side random numbers): The server 10 uses the random number generation unit 14 to generate server-side random numbers as specified server information.

P128 (Encryption of server-side random number): The server 10 encrypts the generated server-side random number using the already registered SC public key.

P129 (sending encrypted server-side random number): The server 10 sends the encrypted server-side random number to the secure element 50 via the device 70.

P130 (Decryption of encrypted server-side random number): The secure element 50 decrypts the received encrypted server-side random number with the SC private key that it holds, and retains the decrypted server-side random number. This allows the secure element 50 to share the server-side random number generated by the server 10 with the server 10. The server 10 and the secure element 50 can then share the SC-side random number and the server-side random number, and can share information used when generating the device shared key.

P131 (generation of device common key): The server 10 and secure element 50 obtain an output from the common key generation units 16, 56 using the exchanged SC side random number, server side random number, and shared secret as input. Here, it is assumed that the server 10 and secure element 50 have agreed in advance to use, for example, SHA-256 as the algorithm to be used for key generation. Therefore, a SHA-256 operation is performed using the same SC side random number and server side random number as input, and the server 10 and secure element 50 can obtain the same data string as output. This data string is used as the device common key.

P132 (Extracting the common key to the device): The device 70 instructs the secure element 50 to extract the device common key, and obtains the device common key from the secure element 50.

P133 (Establishment of encrypted communication using device common key): From then on, the server 10 and the device 70 establish a symmetric key encrypted communication path based on the same device common key, and perform encrypted communication.

As described above, the server 10 and the secure element 50 each have a memory unit 11, 51 as a storage unit that stores a predetermined shared secret (shared information). The shared secret can be, for example, shared secret information that is not disclosed to anyone other than the server 10 and the secure element 50.

Each of the shared key generating units 16, 56 can further use the shared secret to generate a device shared key. This makes it possible to further increase the security of the encrypted communication between the server 10 and the device 70, since even if an attacker illegally obtains and understands the SC side random number and the server side random number, the attacker cannot generate a device shared key unless he knows the shared secret.

Figure 9 is an explanatory diagram showing an example of updating a shared secret. Below, the processes indicated by symbols P141 to P148 are explained.

P141 (generation of device common key): Based on the process illustrated in FIG. 3, the server 10 and the device 70 are each provided with a device common key (old) generated based on the value before the shared secret was updated.

P142 (Establishment of an encrypted session and encrypted communication): The server 10 and the device 70 open an encrypted communication path based on the device common key (old).

P143 (Server-side shared secret update): The server 10 updates the shared secret it holds.

P144 (execution of SC-side shared secret update command): The server 10 instructs the secure element 50 via the device 70 to execute the shared secret update unit 17 by including the updated shared secret in the input. A typical implementation can use a shared secret update command/API implemented in the secure element 50.

P145 (updating the SC-side shared secret): The shared secret update unit 57 of the secure element 50 updates the SC-side shared secret with the received updated shared secret value.

P146 (Regeneration of device shared key): The server 10 and secure element 50 generate a new device shared key (new) using the SC side random number, the server side random number, and the updated shared secret as input.

P147 (retrieval of key after update by device): The device 70 again requests the secure element 50 to output the device common key. The secure element 50 supplies the updated device common key (new) to the device 70.

P148 (Establishment of an encrypted session and encrypted communication): The server 10 and the device 70 establish a new encrypted communication path based on the device common key (new).

In the above example, after updating the shared secret, the device shared key is generated again without updating other information (random numbers). However, to ensure high security, the device shared key may be generated again after updating other information such as random numbers.

Figure 10 is an explanatory diagram showing an example of adding a key generation algorithm. In this embodiment, predetermined algorithms such as SHA-1 and SHA-256 are pre-stored as key generation algorithms, but if the secure element 50 is in an environment where a trusted application such as JavaCard (registered trademark) or TEE can be installed, it is possible to dynamically add or delete key generation algorithms. Below, an example of adding SHA-3 as an algorithm used by the common key generation units 16 and 56 is described. Below, the processes indicated by symbols P151 to P159 are described.

P151 (Adding a server-side symmetric key generation algorithm): The server 10 adds an implementation (program code) of the symmetric key generation algorithm SHA-3 (22) to its own symmetric key generation unit 16.

P152 (Encryption of implementation): The server 10 encrypts the implementation of the algorithm to be added with the registered SC public key.

P153 (Creating a server-side signature): The server 10 signs the implementation of the algorithm to be added with its own server private key and attaches it to the encrypted implementation.

P154 (sending encryption implementation and signature): The server 10 sends the generated encryption implementation and the generated signature together to the secure element 50 via the device 70.

P155 (Decryption of encrypted implementation): The secure element 50 decrypts the received encrypted implementation using the SC private key that it holds.

P156 (signature verification): The secure element 50 verifies the received signature using the registered server public key. It verifies that the result of decryption using the server public key corresponds to the implementation decrypted in P155 and is a valid signature created using the server private key. If the signature is not valid, it interrupts the process here and notifies the server 10 of an error termination.

P157 (Adding SC-side shared key generation algorithm): After verifying the validity of the signature, the secure element 50 adds the implementation of the received algorithm to its own shared key generation unit 56.

P158 (changing the SC-side shared key generation algorithm): The secure element 50 switches the algorithm currently being used for shared key generation. In this embodiment, a policy is applied to immediately enable newly added algorithms, so the newly added SHA-3 (62) is immediately enabled and the settings are changed so that the previously used SHA-256 (60) is not used. If this process ends normally, the secure element 50 notifies the server 10 of this fact via the device 70.

P159 (changing the server-side shared key generation algorithm): The server 10 confirms from the secure element 50 that the process of P158 has been completed successfully, and changes the algorithm used in its own shared key generation unit 16. Here, the same policy as that of the secure element 50 is applied, and the newly added SHA-3 (22) is immediately enabled, and the settings are changed so that the previously used SHA-256 (20) is not used. Thereafter, the server 10 and the secure element 50 generate a device shared key using the newly added and enabled SHA-3.

As described above, each of the common key generating units 16, 56 can change the algorithm for generating the device common key at a predetermined timing. The predetermined timing can be, for example, each time a predetermined number of communications have been performed, or when an external request is received, but is not limited to these. Changing the algorithm includes adding, deleting, or switching algorithms. This can further improve the security of the encrypted communication between the server 10 and the device 70.

In the above example, the newly added algorithm is immediately enabled, but this is not limited and the algorithm may be enabled at any time. Also, in the above example, the symmetric key generation algorithm is added based on the exchanged public key, but this is not limited and for example, the symmetric key generation algorithm may be added or deleted by applying a separate technology such as the GlobalPlatform specification or the JavaCard specification.

Figure 11 is a flowchart showing an example of the procedure for the public key exchange process by the server 10. The server 10 receives the SCID encrypted with the secure element private key (SC private key) and the secure element public key (SC public key) (S11), and decrypts the encrypted SCID with the secure element public key (S12).

The server 10 verifies the SCID (S13) and registers the secure element public key (S14). The server 10 generates a server public key and a server private key (S15), and encrypts the server ID with the server private key (S16).

The server 10 transmits the server public key and the encrypted server ID to the secure element 50 via the device 70 (S17) and ends the process.

Figure 12 is a flowchart showing an example of the procedure for public key exchange processing by the secure element 50. The secure element 50 generates a secure element public key and a secure element private key (S21), and encrypts the secure element ID (SCID) with the secure element private key (S22).

The secure element 50 transmits the secure element public key and the encrypted secure element ID to the server 10 via the device 70 (S23). The secure element 50 receives the server ID and server public key encrypted with the server private key (S24), and decrypts the encrypted server ID with the server public key (S25).

The secure element 50 verifies the server ID (S26), registers the server public key (S27), and ends the process.

Figure 13 is a flowchart showing an example of the procedure for the process of generating a device common key by the server 10. The server 10 generates a server-side random number (S41) and encrypts the server-side random number using the registered secure element public key (S42).

The server 10 transmits the encrypted server-side random number to the secure element 50 via the device 70 (S43). The server 10 receives the encrypted secure element-side random number (S44) and decrypts the received secure element-side random number with the server private key (S45). The server 10 generates a device common key using a predetermined common key generation algorithm with the decrypted secure element-side random number and server-side random number as input (S46), and ends the process.

Figure 14 is a flowchart showing an example of the procedure for generating a device common key by the secure element 50. The secure element 50 generates a secure element side random number (S51) and encrypts the secure element side random number using the registered server public key (S52).

The secure element 50 transmits the encrypted secure element side random number to the server 10 via the device 70 (S53). The secure element 50 receives the encrypted server side random number (S54) and decrypts the received server side random number with the server private key (S555). The secure element 50 generates a device common key using a predetermined common key generation algorithm with the decrypted server side random number and secure element side random number as input (S56), and ends the process.

The server 10 is configured as a computer including a CPU, RAM, ROM, etc., and a computer program that defines the processing procedures as shown in Figures 11 and 13 is loaded into the RAM, and the computer program is executed by the CPU (processor), thereby enabling each process of the server 10 to be realized by the computer program.

The cryptographic communication system according to this embodiment is a cryptographic communication system including a server and a device equipped with a secure element, the secure element including a secure element key generation unit that generates a secure element public key and a secure element private key, and a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device, the server including a server registration unit that acquires and registers the secure element public key output from the secure element output unit, a server key generation unit that generates a server public key and a server private key, and a server output unit that outputs the server public key generated by the server key generation unit to the secure element via the device, the secure element further including a secure element registration unit that acquires and registers the server public key output from the server output unit, the server performs cryptographic communication based on the registered secure element public key, and the secure element performs cryptographic communication based on the registered server public key.

The secure element according to this embodiment is a secure element mounted on a device that performs cryptographic communication with a server, and includes a secure element key generation unit that generates a secure element public key and a secure element private key, a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device, and a secure element registration unit that acquires and registers the server public key output by the server, and uses the server public key registered by the secure element registration unit for cryptographic communication between the secure element and the server.

The device according to this embodiment is equipped with the above-mentioned secure element and can perform encrypted communication with a specified server.

The server according to this embodiment is a server that performs cryptographic communication with a device equipped with a secure element, and includes a server key generation unit that generates a server public key and a server private key, a server output unit that outputs the server public key generated by the server key generation unit to the secure element via the device, and a server registration unit that acquires and registers the secure element public key output by the secure element, and uses the secure element public key registered by the server registration unit for cryptographic communication with the secure element.

The computer program according to this embodiment causes a computer to execute the following processes: generating a server public key and a server private key; outputting the generated server public key to a secure element mounted on a device; acquiring and registering a secure element public key output by the secure element; and performing cryptographic communication with the secure element using the registered secure element public key.

The cryptographic communication method according to this embodiment is a cryptographic communication method between a server and a device equipped with a secure element, in which the secure element generates a secure element public key and a secure element private key, and outputs the secure element public key generated via the device to the server, the server obtains and registers the secure element public key output from the secure element, generates a server public key and a server private key, and outputs the server public key generated via the device to the secure element, the secure element further obtains and registers the server public key output from the server, the server performs cryptographic communication based on the registered secure element public key, and the secure element performs cryptographic communication based on the registered server public key.

The device is equipped with a secure element. The secure element is tamper-resistant and is physically independent from the device. The secure element includes a secure element key generation unit, a secure element output unit, and a secure element registration unit.

The secure element key generation unit generates a secure element public key and a secure element private key. The secure element public key means the public key on the secure element side, and the secure element private key means the private key on the secure element side. The generated public key and private key can be said to be an asymmetric key pair, and for example, RSA cryptography has the characteristic that it is difficult to create a private key from a public key, but easy to create a public key from a private key.

The secure element output unit outputs the generated secure element public key of the generated asymmetric key pair to the server via the device.

The server has a server registration unit, a server key generation unit, and a server output unit.

The server registration unit obtains and registers the secure element public key output from the secure element output unit. This allows the server to share the secure element public key. In other words, there is no need to prepare the secure element public key in advance and store it in the server like a fixed key, and there is no risk of the confidentiality of the communication path being weakened due to leakage of the fixed key, etc. Furthermore, since the secure element public key is dynamically generated by the secure element, it does not have the property of being a specific fixed key, ensuring freedom in key setting.

The server key generation unit generates a server public key and a server private key. The server public key means the public key on the server side, and the server private key means the private key on the server side. The generated public key and private key can be said to be an asymmetric key pair, and for example, in RSA cryptography, it is difficult to create a private key from a public key, but it is easy to create a public key from a private key.

The server output unit outputs the generated server public key from the generated asymmetric key pair to the secure element via the device.

The secure element registration unit obtains and registers the server public key output from the server output unit. This allows the secure elements to share the server public key. In other words, there is no need to prepare the server public key in advance and store it in the secure element like a fixed key, and there is no risk of the confidentiality of the communication path being weakened due to leakage of the fixed key, etc. Furthermore, since the server public key is dynamically generated by the server, it does not have the property of being a specific fixed key, ensuring flexibility in key setting.

The server performs cryptographic communication based on the registered secure element public key, and the secure element performs cryptographic communication based on the registered server public key. This eliminates the need for the server and the secure element to share keys in advance. In addition, since the secure element public key corresponding to the secure element private key is registered in the server, a communication path capable of one-way encryption from the server to the secure element can be secured between the server and the secure element. In addition, since the secure element has a server public key corresponding to the server private key registered in the secure element, a communication path capable of one-way encryption from the secure element to the server can be secured between the server and the secure element.

In the cryptographic communication system according to this embodiment, the secure element includes a secure element first encryption unit that encrypts specific secure element information using a registered server public key, the secure element output unit outputs the secure element information encrypted by the secure element first encryption unit to the server, the server includes a server first decryption unit that decrypts the encrypted secure element information using the server private key and a server first encryption unit that encrypts specific server information using the registered secure element public key, the server output unit outputs the server information encrypted by the server first encryption unit to the secure element, and the secure element further includes a secure element first decryption unit that decrypts the encrypted server information using the secure element private key.

The secure element includes a secure element first encryption unit and a secure element first decryption unit. The server includes a server first encryption unit and a server first decryption unit.

The secure element first encryption unit encrypts the specified secure element information using the registered server public key. The specified secure element information may be a random number generated by the secure element, or may be information other than a random number.

The secure element output unit outputs the secure element information encrypted by the secure element first encryption unit to the server.

The server first decryption unit decrypts the encrypted secure element information using the server private key. This allows the server to share information, such as random numbers generated by the secure element, with the secure element.

The server first encryption unit encrypts the specified server information using the registered secure element public key. The specified server information may be a random number generated by the server, or may be information other than a random number.

The server output unit outputs the server information encrypted by the server first encryption unit to the secure element.

The secure element first decryption unit decrypts the encrypted server information using the secure element private key. This allows the secure element to share information, such as a random number generated by the server, with the server. This allows the server and the secure element to share specific secure element information and specific server information, and to share information used when generating a shared key between the server and the secure element.

In the cryptographic communication system according to this embodiment, the server includes a server common key generation unit that generates a common key using the secure element information decrypted by the server first decryption unit and the server information, the secure element includes a secure element common key generation unit that generates a common key using the server information decrypted by the secure element first decryption unit and the secure element information, and outputs the common key generated by the secure element common key generation unit to the device, and the server and device perform cryptographic communication based on the common key.

The server has a server shared key generation unit. The secure element has a secure element shared key generation unit.

The server common key generation unit generates a common key using the secure element information and server information decrypted by the server first decryption unit. The secure element common key generation unit generates a common key using the server information and secure element information decrypted by the secure element first decryption unit. That is, the server common key generation unit and the secure element common key generation unit generate a common key using common secure element information and server information. For example, by using the secure element information and server information as input data and, for example, a predetermined hash function as an algorithm for generating a common key, it is possible to obtain the same data string as output, and this data string can be used as the common key. The secure element outputs the common key generated by the secure element common key generation unit to the device.

The server and device perform encrypted communication based on the generated common key. With the above-mentioned configuration, there is no need to transmit and receive the common key via a communication path between the server and the device, and since the common key is not transmitted over the communication path, the common key cannot be generated unless the details of the common key generation algorithm are known. Furthermore, even if the secure element information and server information used to generate the common key are leaked, the common key cannot be generated unless the details of the common key generation algorithm are known. This ensures that the encrypted communication between the server and the device is not compromised.

In the cryptographic communication system according to this embodiment, the secure element includes a secure element second encryption unit that encrypts secure element identification information using the secure element private key, the secure element output unit outputs the secure element identification information encrypted by the secure element second encryption unit to the server, the server includes a server second decryption unit that decrypts the encrypted secure element identification information using the acquired secure element public key, and the server registration unit determines whether or not the acquired secure element public key can be registered based on the secure element identification information decrypted by the server second decryption unit.

The secure element includes a secure element second encryption unit. The server includes a server second decryption unit.

The secure element second encryption unit encrypts the secure element identification information using the secure element private key. The secure element identification information can be, for example, an ID (SCID) that is uniquely assigned to each secure element.

The secure element output unit outputs the secure element identification information encrypted by the secure element second encryption unit to the server.

The server second decryption unit decrypts the encrypted secure element identification information using the acquired secure element public key.

The server registration unit determines whether the acquired secure element public key can be registered based on the secure element identification information decrypted by the server second decryption unit. Whether the secure element public key can be registered can be determined, for example, by verifying whether the decrypted secure element identification information is legitimate. For example, if the decrypted secure element identification information is already registered secure element identification information, it is deemed not legitimate and registration of the secure element public key is not executed. Also, if the decrypted secure element identification information is not registered secure element identification information, it is deemed legitimate and registration of the secure element public key is executed. In this way, the authenticity of the acquired secure element public key can be determined before it is registered.

In the cryptographic communication system according to this embodiment, the server includes a server second encryption unit that encrypts server identification information using the server private key, the server output unit outputs the server identification information encrypted by the server second encryption unit to the secure element, the secure element includes a secure element second decryption unit that decrypts the encrypted server identification information using the acquired server public key, and the secure element registration unit determines whether or not the acquired server public key can be registered based on the server identification information decrypted by the secure element second decryption unit.

The server includes a server second encryption unit. The secure element includes a secure element second decryption unit.

The server second encryption unit encrypts the server identification information using the server private key. The server identification information can be, for example, an ID (server ID) that is uniquely assigned to each server, and can be, for example, the URL of the server.

The server output unit outputs the server identification information encrypted by the server second encryption unit to the secure element.

The secure element second decryption unit decrypts the encrypted server identification information using the acquired server public key.

The secure element registration unit determines whether the acquired server public key can be registered based on the server identification information decrypted by the secure element second decryption unit. Whether the server public key can be registered can be determined, for example, by verifying whether the decrypted server identification information is legitimate. For example, if the decrypted server identification information is already registered server identification information, it is deemed invalid and registration of the server public key is not executed. On the other hand, if the decrypted server identification information is not registered server identification information, it is deemed valid and registration of the server public key is executed. In this way, the authenticity of the acquired server public key can be determined before it is registered.

In the cryptographic communication system according to this embodiment, the secure element includes a secure element authentication request unit that requests a certificate authority server to authenticate the secure element public key generated by the secure element key generation unit, and the secure element output unit outputs the secure element public key to the server when authentication by the certificate authority server is obtained.

The secure element has a secure element authentication request unit. The secure element authentication request unit requests the certification authority server to authenticate the secure element public key generated by the secure element key generation unit. The certification authority server is a server that verifies the legitimacy of public keys held by other entities (servers and secure elements). Authentication by the certification authority server can prove the legitimacy of the entity providing the public key.

If authentication by the certificate authority server is obtained, the secure element output unit outputs the secure element public key to the server. This makes it possible to establish the legitimacy of the secure element public key generated by the secure element.

In the cryptographic communication system according to this embodiment, the secure element includes a secure element acquisition unit that acquires a certificate authority signature generated by the certificate authority server when authentication by the certificate authority server is obtained, the secure element output unit outputs the certificate authority signature acquired by the secure element acquisition unit to the server, and the server registration unit determines whether or not the acquired secure element public key can be registered based on the result of verifying the certificate authority signature.

The secure element includes a secure element acquisition unit. When authentication by the certificate authority server is obtained, the secure element acquisition unit acquires the certificate authority signature generated by the certificate authority server. The certificate authority server generates a certificate authority signature (CA signature) for the secure element public key using a private key (CA private key) that it holds, and can transmit the generated certificate authority signature to the secure element via the device. The certificate authority server verifies that the secure element that requested the signature is a trustworthy entity, and then signs the secure element public key using the CA private key, thereby indicating that the secure element public key is trustworthy. The secure element output unit outputs the certificate authority signature acquired by the secure element acquisition unit to the server.

The server registration unit determines whether or not the acquired secure element public key can be registered based on the verification result of the certificate authority signature. The certificate authority signature can be verified, for example, by obtaining a public key (CA public key) held by the certificate authority server and using the obtained CA public key to verify the CA signature on the secure element public key. If there is no problem with the verification result, the acquired secure element public key is registered, and if there is a problem with the verification result, the acquired secure element public key is not registered. This reduces the risk of performing key exchange and communicating with an untrusted fraudulent entity.

In the cryptographic communication system according to this embodiment, the server includes a server authentication request unit that requests a certification authority server to authenticate the server public key generated by the server key generation unit, and the server output unit outputs the server public key to the secure element when authentication by the certification authority server is obtained.

The server has a server authentication request unit. The server authentication request unit requests the certification authority server to authenticate the server public key generated by the server key generation unit. The certification authority server is a server that verifies the legitimacy of public keys held by other entities (servers and secure elements). Authentication by the certification authority server can prove the legitimacy of the entity providing the public key.

If authentication by the certificate authority server is obtained, the server output unit outputs the server public key to the secure element. This makes it possible to establish the validity of the server public key generated by the server.

In the cryptographic communication system according to this embodiment, the server includes a server acquisition unit that acquires a certificate authority signature generated by the certificate authority server when authentication by the certificate authority server is obtained, the server output unit outputs the certificate authority signature acquired by the server acquisition unit to the secure element, and the secure element registration unit determines whether or not the acquired server public key can be registered based on the result of verifying the certificate authority signature.

The server has a server acquisition unit. When authentication by the certification authority server is obtained, the server acquisition unit acquires the certification authority signature generated by the certification authority server. The certification authority server can generate a certification authority signature (CA signature) for the server public key using its own private key (CA private key) and transmit the generated certification authority signature to the server. The certification authority server verifies that the server that requested the signature is a trustworthy entity, and then signs the server public key using the CA private key, thereby indicating that the server public key is trustworthy. The server output unit outputs the certification authority signature acquired by the server acquisition unit to the secure element.

The secure element registration unit determines whether or not to register the acquired server public key based on the verification result of the certificate authority signature. The certificate authority signature can be verified, for example, by obtaining a public key (CA public key) held by the certificate authority server and using the obtained CA public key to verify the CA signature on the server public key. If there is no problem with the verification result, the acquired server public key is registered, and if there is a problem with the verification result, the acquired server public key is not registered. This reduces the risk of performing key exchange and communicating with an untrusted fraudulent entity.

In the cryptographic communication system according to this embodiment, the server includes a server determination unit that determines whether a registered secure element public key has expired at a required timing, and a server invalidation processing unit that invalidates the registered secure element public key if the server determination unit determines that the public key has expired. The secure element includes a secure element determination unit that determines whether a registered server public key has expired at a required timing, and a secure element invalidation processing unit that invalidates the registered server public key if the secure element determination unit determines that the public key has expired.

The server has a server determination unit and a server invalidation processing unit. The secure element has a secure element determination unit and a secure element invalidation processing unit.

The server determination unit determines whether a registered secure element public key has been revoked at a required timing. The required timing can be, for example, the start of encrypted communication, each time a specified number of communications have been performed, or when an external request is received, but is not limited to these. Revocation of a secure element public key can be determined, for example, based on the result of public key revocation processing by the certification authority server (a revoked public key list).

The server invalidation processing unit invalidates the registered secure element public key if the server determination unit determines that the key has been revoked. This makes it possible to realize the need to invalidate a public key that has been shared once, in order to prevent the leakage of private keys or for the purpose of managing the life cycle of a device or server.

The secure element determination unit determines whether a registered server public key has been revoked at a required timing. The required timing can be, for example, at the start of encrypted communication, after a specified number of communications have been performed, or when an external request is received, but is not limited to these. Revocation of the server public key can be determined, for example, based on the result of the public key revocation process performed by the certification authority server (a revoked public key list).

The secure element invalidation processing unit invalidates the registered server public key if the secure element determination unit determines that the public key has been revoked. This makes it possible to realize the need to invalidate a public key that has been shared once, in order to prevent the leakage of private keys or for the purpose of managing the life cycle of devices or servers.

In the cryptographic communication system according to this embodiment, the server invalidation processing unit further invalidates the common key generated by the server common key generation unit, and the secure element invalidation processing unit further invalidates the common key generated by the secure element common key generation unit.

The server invalidation processing unit further invalidates the common key generated by the server common key generation unit, and the secure element invalidation processing unit further invalidates the common key generated by the secure element common key generation unit. This makes it possible to block encrypted communication using the common key.

In the cryptographic communication system according to this embodiment, the server shared key generation unit and the secure element shared key generation unit each update the shared key they have generated at a predetermined opportunity.

The server shared key generation unit and the secure element shared key generation unit each update the generated shared key at a specific opportunity. The specific opportunity can be, for example, when the number of encrypted communications performed using the same shared key reaches a specific number, or when an update instruction is given to the server or secure element from outside, but is not limited to this.

As mentioned above, the device (the device itself) relies on the secure element to generate the shared key, so the security of the device is subordinate to the secure element, making the device's shared key management even stronger.

In other words, if the shared key of the server and the secure element is dynamically updated based on a certain regularity, the device will not be able to correctly perform encrypted communication after the shared key is updated unless it receives the updated shared key from the secure element. This is equivalent to dynamic verification that the device is operating under the appropriate management of the secure element, and means that the security of the device can be verified continuously, not just at startup (such as during secure boot) or when generating keys.

In the cryptographic communication system according to this embodiment, the device outputs a request to the secure element to obtain a common key in response to the predetermined trigger, and the secure element supplies the device with the common key updated by the secure element common key generation unit.

In response to a specified trigger, the device outputs a request to obtain a shared key to the secure element. The secure element supplies the updated shared key to the device. This allows the device to perform encrypted communication with the server using the updated shared key supplied by the secure element installed in the device, even if the shared key on the server side is updated.

In the encrypted communication system according to this embodiment, if the shared key does not match between the server and the device, the server executes a process to deal with the abnormality in the device.

If the shared key does not match with the device, the server executes processing to deal with the device abnormality. The processing to deal with the device abnormality can be various appropriate processing according to the server's security policy. For example, it can include processing to block currently established encrypted communication, processing to invalidate an exchanged public key pair, processing to reject public key registration using the SCID of the secure element and to treat it as an unauthorized device, etc.

In the cryptographic communication system according to this embodiment, the server shared key generation unit and the secure element shared key generation unit each change the algorithm for generating a shared key at a predetermined timing.

The server shared key generation unit and the secure element shared key generation unit each change the algorithm for generating the shared key at a predetermined timing. The predetermined timing can be, for example, each time a predetermined number of communications have been performed or when an external request is received, but is not limited to these. Changing the algorithm includes adding, deleting, and switching algorithms. This can further increase the security of the encrypted communication between the server and the device.

In the cryptographic communication system according to this embodiment, the secure element includes a device authentication unit that authenticates the device main body to which the secure element is connected, and when the device main body is authenticated by the device authentication unit, the secure element common key generation unit outputs the generated common key to the device main body, and the server and device perform cryptographic communication based on the common key.

The secure element has a device authentication unit that authenticates the device body to which the secure element (itself) is connected. The authentication of the device body can be performed using any suitable method.

If the device authentication unit authenticates the device itself, the secure element shared key generation unit outputs the generated shared key to the device itself. This makes it possible to confirm that the appropriate secure element is connected to the intended (genuine) device.

In the cryptographic communication system according to this embodiment, the server and the secure element each include a storage unit that stores predetermined shared information, and the server shared key generation unit and the secure element shared key generation unit each further use the shared information to generate a shared key.

The server and the secure element each have a storage unit that stores predetermined shared information. The shared information can be, for example, shared secret information that is not disclosed to anyone other than the server and the secure element.

The server shared key generation unit and the secure element shared key generation unit each further use the shared information to generate a shared key. That is, in addition to the secure element information and server information, the shared information is further used as the information from which the shared key is generated. This means that even if an attacker illegally obtains and understands the secure element information and server information, he or she cannot generate a shared key unless he or she knows the shared information, thereby further enhancing the security of the encrypted communication between the server and the device.

In the encrypted communication system according to this embodiment, the shared information stored in the storage unit can be updated.

For example, the shared information stored in the storage unit of the secure element can be updated from an external server. This further enhances the security of the encrypted communication between the server and the device, since the shared information is not fixed information but is information that can be updated.

In the cryptographic communication system according to this embodiment, the secure element is composed of a hardware element or a software element.

A secure element is composed of a hardware element or a software element. This allows a device to be equipped with an appropriate secure element depending on the type of device, etc.

As described above, according to this embodiment, the security and flexibility of key sharing in a device (e.g., an IoT device) can be dramatically improved, and the reliability of the encrypted communication in the device and the device itself can be further improved. In other words, there is no need to share a common key in advance, and the confidentiality of the communication channel does not depend on a specific fixed key. In addition, the freedom of key setting can be ensured, and the risk of hacking, etc. can be reduced. Furthermore, since the key value is not transmitted over the communication channel, an attacker cannot generate a key even if he or she illegally obtains the information on which the key is generated, unless he or she knows the details of the key generation. This ensures that the encrypted communication between the server and the device is not compromised.

LIST OF SYMBOLS 10 SERVER 11 MEMORY UNIT 12 SC PUBLIC KEY STORE 13 KEY PAIR GENERATION UNIT 14 RANDOM NUMBER GENERATION UNIT 15 SIGNATION VERIFICATION UNIT 16 SIMILAR KEY GENERATION UNIT 17 SHARED SECRET UPDATE UNIT 18 KEY AUTHORITY CONFIRMATION UNIT 21 CRYPTOGRAPHIC COMMUNICATION UNIT 50 SECURE ELEMENT 51, 71 MEMORY UNIT 52 SERVER PUBLIC KEY STORE 53 KEY PAIR GENERATION UNIT 54 RANDOM NUMBER GENERATION UNIT 55 SIGNATION VERIFICATION UNIT 56 SIMILAR KEY GENERATION UNIT 57 SHARED SECRET UPDATE UNIT 58 KEY AUTHORITY CONFIRMATION UNIT 61 CRYPTOGRAPHIC COMMUNICATION UNIT 70 DEVICE 100 CERTIFICATION AUTHORITY SERVER 101 PUBLIC KEY REVOKED LIST 102 SIGNATION GENERATED LIST

Claims (20)

A cryptographic communication system including a server and a device equipped with a secure element,
The secure element comprises:
a secure element key generation unit for generating a secure element public key and a secure element private key;
a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device,
The server,
a server registration unit that acquires and registers the secure element public key output from the secure element output unit;
a server key generation unit for generating a server public key and a server private key;
a server output unit that outputs a server public key generated by the server key generation unit to the secure element via the device,
The secure element further comprises:
a secure element registration unit that acquires and registers the server public key output from the server output unit,
The server,
Performs encrypted communication based on the registered secure element public key,
The secure element comprises:
Encryption is performed based on the registered server public key.
The secure element comprises:
a secure element first encryption unit that encrypts predetermined secure element information using a registered server public key;
The secure element output unit
outputting the secure element information encrypted by the secure element first encryption unit to the server;
The server,
a server first decryption unit that decrypts the encrypted secure element information using the server private key;
a server first encryption unit that encrypts predetermined server information using a registered secure element public key;
The server output unit is
outputting the server information encrypted by the server first encryption unit to the secure element;
The secure element further comprises:
a secure element first decryption unit that decrypts the encrypted server information by using the secure element private key;
The server,
a server common key generation unit that generates a common key by using the secure element information decrypted by the server first decryption unit and the server information;
The secure element comprises:
a secure element common key generation unit that generates a common key by using the server information and the secure element information decrypted by the secure element first decryption unit,
outputting the common key generated by the secure element common key generation unit to the device;
The server and the device
A cryptographic communication system that performs cryptographic communication based on the common key. The secure element comprises:
a secure element second encryption unit that encrypts secure element identification information using the secure element private key;
The secure element output unit
outputting the secure element identification information encrypted by the secure element second encryption unit to the server;
The server,
a server second decryption unit that decrypts the encrypted secure element identification information by using the acquired secure element public key;
The server registration unit
2. The cryptographic communication system according to claim 1, further comprising: determining whether or not the acquired secure element public key can be registered based on the secure element identification information decrypted by the server second decryption unit. The server,
a server second encryption unit that encrypts server identification information by using the server private key;
The server output unit is
outputting the server identification information encrypted by the server second encryption unit to the secure element;
The secure element comprises:
a second decryption unit of a secure element that decrypts the encrypted server identification information by using the acquired server public key;
The secure element registration unit
3. The cryptographic communication system according to claim 1, further comprising: determining whether or not an acquired server public key can be registered based on the server identification information decrypted by the second decryption unit of the secure element. The secure element comprises:
a secure element authentication request unit that requests an authentication authority server to authenticate the secure element public key generated by the secure element key generation unit;
The secure element output unit
4. The cryptographic communication system according to claim 1, wherein, when authentication by the certificate authority server is obtained, the secure element public key is output to the server. The secure element comprises:
a secure element acquisition unit that acquires a certificate authority signature generated by the certificate authority server when authentication by the certificate authority server is obtained,
The secure element output unit
outputting the certificate authority signature acquired by the secure element acquisition unit to the server;
The server registration unit
The cryptographic communication system according to claim 4 , wherein a determination is made as to whether or not the acquired secure element public key can be registered based on a result of the verification of the certificate authority signature. The server,
a server authentication request unit that requests an authentication authority server to authenticate the server public key generated by the server key generation unit;
The server output unit is
6. The cryptographic communication system according to claim 1, wherein, when authentication by the certificate authority server is obtained, the server public key is output to the secure element. The server,
a server acquisition unit that acquires a certificate authority signature generated by the certificate authority server when authentication by the certificate authority server is obtained,
The server output unit is
outputting the certificate authority signature acquired by the server acquisition unit to the secure element;
The secure element registration unit
7. The cryptographic communication system according to claim 6, wherein whether or not the acquired server public key can be registered is determined based on a result of the verification of the certificate authority signature. The server,
a server determination unit that determines whether or not a registered secure element public key has been revoked at a required timing;
a server invalidation processing unit that invalidates the registered secure element public key when the server determination unit determines that the secure element public key has been revoked;
The secure element comprises:
a secure element determination unit that determines whether a registered server public key has been revoked at a required timing;
8. The cryptographic communication system according to claim 1, further comprising: a secure element invalidation processing unit that invalidates the registered server public key when the secure element determination unit determines that the server public key has been revoked. The server invalidation processing unit:
Furthermore, the common key generated by the server common key generation unit is invalidated,
The secure element revocation processing unit,
The cryptographic communication system according to claim 8 , further comprising: invalidating the common key generated by the secure element common key generation unit. Each of the server common key generation unit and the secure element common key generation unit
10. The cryptographic communication system according to claim 1, wherein the generated common key is updated at a predetermined opportunity. The device comprises:
outputting a request for acquiring a common key to the secure element in response to the predetermined trigger;
The secure element comprises:
The cryptographic communication system according to claim 10 , wherein the common key updated by the secure element common key generation unit is supplied to the device. The server,
The encryption communication system according to claim 10 or 11, wherein, when the common key does not match with the device, a process for dealing with an abnormality in the device is executed. Each of the server common key generation unit and the secure element common key generation unit
13. The cryptographic communication system according to claim 1, wherein an algorithm for generating a common key is changed at a predetermined timing. The secure element comprises:
a device authentication unit that authenticates a device main body to which the secure element is connected,
The secure element common key generation unit
If the device main body is authenticated by the device authentication unit, the generated common key is output to the device main body;
The server and the device
The cryptographic communication system according to claim 1 , wherein the cryptographic communication is performed based on the common key. The server and the secure element each include
A storage unit that stores predetermined shared information,
Each of the server common key generation unit and the secure element common key generation unit
The cryptographic communication system according to claim 1 , further comprising: a common key generating unit that generates a common key by further using the shared information. The cryptographic communication system according to claim 15, wherein the shared information stored in the storage unit is updatable. The secure element comprises:
17. The cryptographic communication system according to claim 1, which is configured with hardware elements or software elements. A secure element mounted on a device that performs cryptographic communication with a server,
a secure element key generation unit for generating a secure element public key and a secure element private key;
a secure element output unit that outputs the secure element public key generated by the secure element key generation unit to the server via the device;
a secure element registration unit that acquires and registers a server public key output by the server,
a server public key registered in the secure element registration unit is used for cryptographic communication between the secure element and the server;
a secure element first encryption unit that encrypts predetermined secure element information using a registered server public key;
The secure element output unit
outputting the secure element information encrypted by the secure element first encryption unit to the server;
The secure element further comprises a first decryption unit for decrypting server information encrypted by the server using the secure element private key, and a common key generation unit for generating a common key using the server information and the secure element information decrypted by the first decryption unit,
outputting the common key generated by the secure element common key generation unit to the device;
A secure element configured to perform cryptographic communication based on the common key between the server and the device. A device equipped with the secure element described in claim 18 and capable of performing encrypted communication with a specified server. A method for cryptographic communication between a server and a device equipped with a secure element, comprising:
The secure element comprises:
generating a secure element public key and a secure element private key;
outputting the secure element public key generated via the device to the server;
The server,
Obtaining and registering a secure element public key output from the secure element;
Generate a server public key and a server private key;
outputting a server public key generated via the device to the secure element;
The secure element further comprises:
Obtaining and registering a server public key output from the server;
The server,
Performs encrypted communication based on the registered secure element public key,
The secure element comprises:
Encryption is performed based on the registered server public key.
The secure element comprises:
Encrypting predetermined secure element information using the registered server public key;
outputting the encrypted secure element information to the server;
The server,
decrypting the encrypted secure element information using the server private key;
Encrypting predetermined server information using the registered secure element public key,
outputting the encrypted server information to the secure element;
The secure element comprises:
decrypting the encrypted server information using the secure element private key;
The server,
generating a common key using the decrypted secure element information and the server information;
The secure element comprises:
generating a common key using the decrypted server information and the secure element information;
Outputting the generated common key to the device;
The server and the device
A cryptographic communication method for performing cryptographic communication based on the common key.

Images