JP5136012B2 - Data sending method - Google Patents

Description

The present invention relates to techniques for sending data to the electronic device, in particular, the electronic apparatus having no communication function to the Internet, relates to a data delivery how to send data securely over the Internet It is.

  In various aspects, data is sent to electronic devices via the Internet. For example, when it is necessary to update the firmware of the electronic device, an update firmware or a firmware update program is sent from the vendor of the electronic device to the electronic device.

  Since data sent to electronic devices via the Internet includes confidential data such as the firmware described above, ensuring its safety is an important issue.

  In addition, the electronic device has a communication function to the Internet, that is, an electronic device such as a PC (personal computer) that can be directly connected to the Internet, and has no communication function to the Internet, that is, a direct connection to the Internet. There are electronic devices such as peripheral devices that cannot be used.

  As prior art documents that describe a technique for sending data to an electronic device on the premise of an electronic device that can be directly connected to the Internet, there are, for example, Patent Document 1 and Patent Document 2. Patent Document 1 describes a technology for supplying a home appliance control program by performing device authentication, key exchange, and the like. Japanese Patent Application Laid-Open No. 2005-228561 describes a technique for upgrading firmware by connecting an image processing apparatus itself to a network without using a PC and using apparatus-specific data as an encryption key.

Further, for example, Patent Literature 3 describes a technique for chaining trust among devices, intermediaries, and updaters. However, the technique described in Patent Document 3 does not function in a situation where the mediator may be operated by a malicious third party.
JP 2003-111170 A JP 2007-011944 A JP 2004-318838 A

  Here, consider updating firmware in electronic equipment after sales as an example. The firmware contains confidential information such as corporate know-how and security-related information, and it is necessary to prevent the contents of the firmware from being disclosed. In addition, from the viewpoint of product warranty and security, it is necessary to prevent installation of anything other than genuine firmware from electronic device vendors.

Based on this situation, methods for updating the firmware of electronic devices after sales include, for example:
(A) A method in which the vendor collects the electronic device from the user and updates the firmware on the vendor side,
(B) A method of recording update firmware or a firmware update program on a medium such as a CD-ROM, distributing it to the user of the electronic device, and having the user update the firmware,
(C) A method may be considered in which an electronic device is connected to the Internet and communicates directly with a vendor to perform authentication, download updated firmware or firmware update program, and update firmware.

  In the method (A), there is a problem that the user needs to physically send the electronic device to the vendor, and the cost is high and the procedure is complicated. Depending on the frequency of firmware updates and the number of electronic devices sold, this is not a very realistic method.

  In the method (B), the update firmware and firmware update program can be safely distributed by making the update firmware or firmware update program difficult to disassemble, or by using a common key in advance on the vendor side and the electronic device side. A method of encrypting the update firmware and firmware update program using a common key encryption method can be considered.

  However, with the technical capabilities, disassembly is not impossible at all, and there is a problem that information about firmware is leaked, and anyone can tamper with firmware. When the common key cryptosystem is used, it is necessary for the vendor side to hold / manage all the common keys registered in each electronic device. For example, if the number of types of common keys is increased, such as preparing a separate common key for each electronic device, the management cost becomes enormous and unrealistic. In addition, modern ciphers are computationally safe if the number of types of common keys is reduced, for example, the same common key is prepared for each electronic device model, or a single common key is prepared for all electronic devices. Because it is based on sex, there is a high possibility that the key will be broken, and the damage at that time will be enormous.

  As described above, the method (B) has various problems in terms of safety, and further has problems such as the cost of the medium for distributing data to each user and the transportation cost.

  In the method (C), there is no problem of transportation cost like the method (A) and the method (B), and security technology such as SSL is prepared in terms of safety. However, since the electronic device needs to be directly connected to the Internet in order to execute the method (C), it is limited to an electronic device that can be directly connected to the Internet. Conventionally, an electronic device that cannot be directly connected to the Internet cannot securely exchange keys with a vendor's device, and thus cannot establish a secure path with the vendor's device.

  When updating the firmware of an electronic device such as a peripheral device that is not directly connected to the Internet, for example, connect the peripheral device to an electronic device that has a communication function to the Internet, such as a PC, and download the firmware update program from the vendor to the PC. It is necessary to download and execute the firmware update program for the peripheral device on the PC. In this case, since key exchange is performed between the PC and the vendor apparatus, a secure communication path is established between the PC and the vendor apparatus. Therefore, confidential data may be leaked from the PC. There is a good possibility that a user who uses an electronic device connected to a PC is a competitor of the vendor.

  In order to solve the above problems, the present invention establishes a safe communication path between an electronic device that does not have a communication function to the Internet and a device of the vendor of the electronic device, and provides a communication function to the Internet. The purpose is to provide a technology for safely sending data via the Internet from electronic device vendor equipment to electronic devices that do not have one.

  By exchanging keys based on public key cryptography between an electronic device that does not have a communication function to the Internet and a device of an electronic device vendor (hereinafter referred to as device vendor) that sends data to the electronic device. Establish a secure communication path. Device vendors can include not only electronic device manufacturers, but also all vendors involved in electronic device manufacturing and after-sales support, such as electronic device vendors and electronic device firmware developers.

  A device vendor, prior to shipping, to an electronic device that does not have a communication function to the Internet, the electronic device public key (hereinafter referred to as a second public key) and a private key (hereinafter referred to as a second private key). ), Register the device vendor's public key (hereinafter referred to as the first public key). At this time, the device vendor signs the second public key. The second public key and the second secret key are a pair of keys.

  A user who uses an electronic device connects the electronic device to a host having a communication function to the Internet. The host can access the device vendor's device via the Internet.

  When it is necessary to send data from the device vendor's device to the electronic device, the user operates the host and accesses the device vendor's device via the Internet. In response to a request from the host, the electronic device passes the signed second public key held by itself to the host. The signed second public key is sent to the device vendor device via the host communication function.

  The device of the device vendor verifies the validity of the received second public key with the signature, and if the validity is confirmed, encrypts the data to be sent to the electronic device using the received second public key. Turn into. Also, the encrypted data is signed using a device vendor's private key (hereinafter referred to as the first private key). The first secret key is a key that is paired with the first public key held in the electronic device. The encrypted and signed data is sent to the electronic device via the Internet and the host.

  It should be noted that the expression of using the second public key for data encryption includes encrypting the data with a common key, encrypting the common key with the second public key, and converting the data into the data encrypted with the common key. Of course, the attached hybrid method is also included.

  The electronic device receives the encrypted and signed data from the device vendor device via the host, and verifies the validity of the received data using the first public key held by itself. If the validity is confirmed, the data is decrypted using the second secret key held by itself.

  In this way, the device vendor attempts to prevent impersonation by verifying the validity of the second public key that is signed and registered in the electronic device. Further, the electronic device attempts to prevent impersonation by verifying the signature of the received data with a first public key registered in advance. The host mediates between the electronic device and the device vendor, but does not have the second secret key, so it cannot decrypt the data sent from the device vendor device to the electronic device. .

  As a result, a key is exchanged between an electronic device that does not have a communication function to the Internet and a device vendor device that sends data to the electronic device, and a secure communication path is established. Data can be sent safely to the device.

  If the data sent from the device vendor apparatus to the electronic device is the firmware update program of the electronic device or the firmware to be updated by the electronic device, it is possible to prevent leakage of confidential information of the firmware. Further, it is possible to prevent the firmware of the electronic device from being updated with firmware other than genuine.

  The device vendor may generate the second secret key and the second public key in the electronic device instead of registering the second secret key and the second public key in the electronic device. In this case, the security chip needs to be mounted on the host to which the electronic device is connected. The security chip includes a security chip private key (hereinafter referred to as a third private key) and a security chip public key (hereinafter referred to as a third public key) signed by the security chip vendor. Is called a key). The third secret key and the third public key are a pair of keys.

  When it is necessary to send data from the device vendor's device to the electronic device, the user operates the host and accesses the device vendor's device via the Internet, and the electronic device generates it according to the request from the host. Pass the second public key to the security chip.

  The security chip signs the received second public key with the third private key held by itself. The signed second public key is sent to the device vendor's device by the host communication function together with the signed third public key held in the security chip.

  The device vendor apparatus verifies the validity of the received signed second public key and signed third public key using a PKI certificate authority or the like. The flow after the validity of the second public key is confirmed by the device vendor is the same as when the second private key and the second public key are registered in advance in the electronic device by the device vendor.

  This makes it possible for the electronic device to update the second private key and the second public key, so there is a danger of using the same second private key and second public key for a long time. Can be avoided.

  Since it becomes possible to perform secure key exchange based on public key cryptography between an electronic device having no communication function to the Internet and a device of the electronic device vendor, the electronic device and the electronic device A secure communication path can be established with the vendor's device via the Internet. As a result, data can be safely sent from the device of the electronic device vendor to the electronic device via the Internet.

  Hereinafter, the present embodiment will be described with reference to the drawings.

[Embodiment 1]
FIG. 1 is a diagram illustrating a configuration example of an electronic device according to the first embodiment. The electronic device 10 is an information device that does not have a function of communicating with the Internet 90 and is connected to a host 20 that is a computer having a function of communicating with the Internet 90.

  The electronic device 10 includes a device public key certificate transmission unit 11, a data reception unit 12, a signature verification unit 13, and a data decryption unit 14. The electronic device 10 also holds a device vendor public key certificate 300, a device public key certificate 100, and a device private key 102. The device vendor public key certificate 300, the device public key certificate 100, and the device private key 102 are information registered by the vendor of the electronic device 10 (hereinafter referred to as device vendor) before shipment.

  The device public key certificate transmission unit 11 sends the held device public key certificate 100 to the device on the device vendor side via the host 20. The data receiving unit 12 receives data sent from the device vendor side device via the host 20. The signature verification unit 13 verifies the signature of the device vendor included in the data sent from the device on the device vendor side. If the signature included in the data sent from the device vendor side device is valid, the data decryption unit 14 decrypts the data sent from the device vendor side device with the device secret key 102.

  The device vendor public key certificate 300 includes a device vendor public key 301 and a device vendor signature 303. The device vendor signature 303 is obtained by encrypting the hash value of the device vendor public key 301 with the device vendor private key. The device vendor private key held by the device vendor and the device vendor public key 301 are a pair of keys. When the signature verification unit 13 verifies the signature of the device vendor included in the data sent from the device on the device vendor side, the device vendor public key 301 included in the device vendor public key certificate 300 is used.

  The device public key certificate 100 includes a device public key 101 and a device vendor signature 103. The device vendor signature 103 is obtained by encrypting the hash value of the device public key 101 with the device vendor private key. The device public key 101 and the device secret key 102 are a pair of keys.

  FIG. 2 is a flowchart of processing by the electronic apparatus according to the first embodiment. The example of the processing shown in FIG. 2 is an example in which the host 20 accesses the device vendor side via the Internet 90 and downloads the data distributed to the electronic device 10 by the device vendor side to the electronic device 10. .

  First, in response to a request from the host 20, the electronic device 10 transmits the held device public key certificate 100 to the device vendor side via the host 20 (step S10).

  At this time, the device vendor side verifies the device public key certificate 100 received from the electronic device 10, and if the device public key certificate 100 is valid, the device public key 101 included in the device public key certificate 100. Is used to encrypt data to be sent to the electronic device 10. Further, the encrypted data is signed with the device vendor private key. Specifically, the hash value of the encrypted data is calculated, and the calculated hash value encrypted with the device vendor secret key is attached to the encrypted data. The device vendor side sends the encrypted data to the electronic device 10.

  When the electronic device 10 receives data sent from the device vendor via the host 20 (step S11), the electronic device 10 verifies the signature attached to the received data (step S12). Specifically, the signature attached to the received data is decrypted with the device vendor public key 301 included in the device vendor public key certificate 300 to obtain a hash value, and the hash value of the received data body is calculated. If both hash values match, it is assumed that the signature is valid.

  If the signature is valid (step S13), the received data is decrypted with the stored device secret key 102 (step S14). If the signature is not valid (step S13), an error is notified (step S15).

  In the following, an example of technology for safely sending data from the device vendor side to the electronic device 10 side will be described by taking an example of updating the firmware of the electronic device 10 that does not have a communication function to the Internet.

  FIG. 3 is a diagram illustrating a configuration example of the information system according to the first embodiment. In the information system shown in FIG. 3, an electronic device 10 that is an information device that does not have a function of communicating with the Internet 90 (not shown in FIG. 3) is connected to a host 20 that is a computer operated by a user. The device vendor device 30 is an information device on the device vendor side that sold the electronic device 10. The host 20 can access the device vendor apparatus 30 via the Internet 90.

  The device vendor apparatus 30 holds a device vendor public key 301, a device vendor private key 302, and a firmware update program 304. The device vendor public key 301 and the device vendor private key 302 are a pair of keys. The firmware update program 304 is a program for updating the firmware of the electronic device 10.

  The device vendor registers the device public key certificate 100, the device private key 102, and the device vendor public key certificate 300 in the electronic device 10 before shipping the electronic device 10. The device public key certificate 100 includes a device public key 101 and a device vendor signature 103 obtained by encrypting the hash value of the device public key 101 with the device vendor private key 302. The device public key 101 and the device secret key 102 are a pair of keys. The device vendor public key certificate 300 includes a device vendor public key 301 and a device vendor signature 303 obtained by encrypting the hash value of the device vendor public key 301 with the device vendor private key 302.

  The user operates the host 20 to access the device vendor apparatus 30 in order to download the firmware update program 304 to the electronic device 10. The electronic device 10 transmits the device public key certificate 100 to the device vendor apparatus 30 via the host 20 in accordance with a request from the host 20.

  In the device vendor apparatus 30, the validity of the device public key certificate 100 received from the electronic device 10 is verified.

  FIG. 4 is a diagram for explaining the verification of the validity of the device public key certificate according to the first embodiment. The device public key certificate 100 held in advance in the electronic device 10 is information that is issued and registered by the device vendor before the electronic device 10 is shipped. The device vendor apparatus 30 verifies whether the device public key certificate 100 received from the electronic device 10 is the device public key certificate 100 issued by the device vendor itself.

  As shown in FIG. 4, the device public key certificate 100 includes a device vendor signature 103. The device vendor signature 103 is obtained by encrypting the hash value of the device public key 101 with the device vendor private key 302. That is, if the device vendor signature 103 included in the device public key certificate 100 received from the electronic device 10 is correctly decrypted by the device vendor public key 301, it is encrypted by the device vendor private key 302. Thus, it is proved that the device public key certificate 100 received from the electronic device 10 is the device public key certificate 100 issued by the device vendor itself.

  When the device public key certificate 100 received from the electronic device 10 is verified, first, the device vendor signature 103 included in the device public key certificate 100 is decrypted with the device vendor public key 301 to obtain a hash value. Further, the hash value of the device public key 101 included in the device public key certificate 100 received from the electronic device 10 is calculated. The hash value obtained by decryption is compared with the calculated hash value, and if both match, the validity of the device public key certificate 100 received from the electronic device 10 is recognized.

  As described above, since the device vendor signature 103 correctly decrypted with the device vendor public key 301 is encrypted with the device vendor private key 302, the validity of the device public key certificate 100 is confirmed. Thus, it is proved that the device public key certificate 100 sent from the electronic device 10 is the device public key certificate 100 issued by the device vendor itself. Therefore, it is possible to determine that the electronic device 10 that has transmitted the device public key certificate 100 issued by the device vendor itself is a legitimate electronic device 10.

  As described above, in the first embodiment, the device public key certificate 100 sent from the electronic device 10 is the device public key certificate 100 issued by the device vendor itself. The electronic device 10 that is the transmission source is trusted.

  In FIG. 3, when it is determined that the device public key certificate 100 is valid, the device vendor apparatus 30 encrypts the firmware update program 304 with the device public key 101 included in the device public key certificate 100. The hash value of the encrypted firmware update program 304 is calculated, and the calculated hash value is signed in the encrypted firmware update program 304 using the device vendor private key 302. The device vendor apparatus 30 sends the encrypted firmware update program 304 to the electronic device 10 via the host 20.

  Upon receiving the encrypted firmware update program 304, the electronic device 10 verifies the signature of the received encrypted firmware update program 304. When the validity of the encrypted firmware update program 304 is proved, the encrypted firmware update program 304 is decrypted with the device secret key 102.

  The firmware update program 304 encrypted with the device public key 101 can be decrypted only with the device secret key 102 held by the electronic device 10. Therefore, even when the encrypted firmware update program 304 is acquired by the host 20 or the like in the process of sending the encrypted firmware update program 304 from the device vendor apparatus 30 to the electronic device 10, the encrypted firmware update program 304 is encrypted. The firmware update program 304 cannot be decrypted.

  The electronic device 10 updates the firmware of the electronic device 10 itself by executing the decrypted firmware update program 304.

  In the example shown in FIG. 3, the firmware update program 304 is downloaded to the electronic device 10 and the firmware update program 304 is executed to update the firmware of the electronic device 10. The firmware may be updated by a firmware update function provided in the electronic device 10.

  In the example shown in FIGS. 3 and 4, the signature of the device vendor signature 103 included in the device public key certificate 100 registered in advance in the electronic device 10, and the public / private key pair used for verification. The signature of the encrypted data sent from the device vendor apparatus 30 to the electronic device 10 and the public / private key pair used for verification are both a device vendor public key 301 / device vendor private key 302 pair. However, the public key / private key pair used for signature and verification of the device vendor's signature 103 is different from the public key / private key pair used for signature and verification of the encrypted data. You may make it use the pair of.

  FIG. 5 is a diagram for explaining the flow of encryption / decryption of the firmware update program. The firmware update program 304 is encrypted on the device vendor side and decrypted on the electronic device 10 side.

  On the device vendor side, the firmware update program 304 is encrypted with the device public key 101 included in the device public key certificate 100. The hash value 305 of the encrypted firmware update program 304 is calculated, the hash value 305 is encrypted with the device vendor secret key 302, and this is used as the signature of the encrypted firmware update program 304. The signed and encrypted firmware update program 304 is transmitted to the electronic device 10 side.

  Upon receiving the signed and encrypted firmware update program 304, the electronic device 10 decrypts the encrypted (signed) hash value 305 with the device vendor public key 301 included in the device vendor public key certificate 300. , The hash value 305 is acquired. Also, the hash value 306 of the encrypted firmware update program 304 is calculated. The hash value 305 obtained by decryption is compared with the calculated hash value 306, and if both match, the validity of the received data, that is, the validity of the encrypted firmware update program 304 is proved. . On the electronic device 10 side, the validity of the received data is proved by the device vendor public key 301 held in advance, thereby trusting that the received data is valid data sent from the device vendor side.

  The encrypted firmware update program 304 is decrypted with the device secret key 102, and an executable firmware update program 304 is obtained.

  In the description so far, the public key cryptosystem is used for data encryption. However, in order to shorten the processing time, a hybrid scheme of the common key cryptosystem and the public key cryptosystem may be used. In practice, when the data size of the data to be sent is large, it is common to encrypt the data by the hybrid method. As for the signature, since a hash value having a small data size is encrypted, a public key cryptosystem is generally used.

  FIG. 6 is a diagram for explaining the hybrid system. FIG. 6A shows data encryption by a public key cryptosystem. In the public key encryption method, data (plain text) 350 having a large data size is directly encrypted with the public key 360 to generate encrypted data (cipher text) 351. In this case, a long time is spent on the encryption process.

  FIG. 6B shows data encryption by the hybrid method. In the hybrid method, data (plaintext) 350 having a large data size is encrypted with a common key 370 having a relatively short processing time (common key encryption method), and encrypted data (ciphertext) 351 is generated. Further, the common key 370 having a small data size is encrypted with the public key 360 (public key cryptosystem), and the encrypted common key 371 is attached to the data (ciphertext) 351.

  By using such a hybrid system, it is possible to shorten the encryption processing time and to send data safely.

  According to the first embodiment, a safe key exchange between the electronic device 10 and the device vendor apparatus 30 is possible, and a safe communication path between the electronic device 10 and the device vendor apparatus 30 can be established. Become.

[Embodiment 2]
In the first embodiment described above, the device public key 101 and the device secret key 102 registered in advance in the electronic device 10 are used without being changed. Therefore, once the key is broken, the electronic device 10 It becomes impossible to establish a safe communication path with the device vendor apparatus 30.

  In the second embodiment described below, the device public key 101 and the device secret key 102 can be changed, thereby establishing a secure communication path between the electronic device 10 and the device vendor apparatus 30. To be able to keep the period.

  The second embodiment is an example in which a security chip is used as a technique for safely sending data from the device vendor side to the electronic device side. In the second embodiment, it is assumed that a TPM (Trusted Platform Module) standardized by TCG (Trusted Computing Group) is used as a security chip.

  FIG. 7 is a diagram illustrating a configuration example of an electronic device according to the second embodiment. The electronic device 10 ′ is an information device that does not have a function of communicating with the Internet 90, and is connected to a host 20 ′ that is a computer having a function of communicating with the Internet 90.

  A security chip (TPM) 40 is mounted on the host 20 '. The security chip (TPM) 40 has tamper resistance and is usually a chip directly attached to a motherboard such as a PC. In the security chip (TPM) 40, secure storage of encryption keys and hash values is performed.

  The electronic device 10 ′ includes a device public key transmission unit 15, a data reception unit 12, a signature verification unit 13, a data decryption unit 14, and a key generation unit 16. In addition, the electronic device 10 ′ holds a device vendor public key certificate 300 registered by the device vendor before the shipment. Note that a pair of the device public key 101 and the device secret key 102 is generated in the electronic device 10 ′ as necessary.

  The data receiving unit 12, the signature verifying unit 13, the data decrypting unit 14, and the device vendor public key certificate 300 are the same as those in the above-described first embodiment, and thus description thereof is omitted here. The device public key transmission unit 15 sends the device public key 101 to the security chip (TPM) 40. The key generation unit 16 generates a pair of the device public key 101 and the device secret key 102 as necessary.

  FIG. 8 is a flowchart of processing performed by the electronic apparatus according to the second embodiment. In the example of the processing shown in FIG. 8, for example, the host 20 'accesses the device vendor side via the Internet 90, and the device vendor side downloads data distributed to the electronic device 10' to the electronic device 10 '. It is an example.

  The electronic device 10 'generates a device public key 101 and a device secret key 102 (step S20). A secure method based on authentication of the generated device public key 101 in response to a request from the host 20 'with the security chip (TPM) 40 with respect to the security chip (TPM) 40 mounted on the host 20'. (Step S21).

  At this time, the security chip (TPM) 40 signs the device public key 101 received from the electronic device 10 ′ with the TPM private key (the private key of the security chip (TPM) 40), thereby obtaining the device public key certificate. And the generated device public key certificate and the TPM public key certificate (including the public key of the security chip (TPM) 40 and the public key certificate of the security chip (TPM) 40) of the host 20 ′. Send to device vendor via communication function.

  The device vendor verifies the received device public key certificate and TPM public key certificate using a PKI certificate authority, etc., and if the device public key certificate is valid, it is included in the device public key certificate. The data to be sent to the electronic device 10 ′ is encrypted using the device public key 101. Further, the encrypted data is signed with the device vendor private key. Specifically, the hash value of the encrypted data is calculated, and the calculated hash value encrypted with the device vendor secret key is attached to the encrypted data. The device vendor sends the encrypted data to the electronic device 10 '.

  When the electronic device 10 'receives the data sent from the device vendor via the host 20' (step S22), the electronic device 10 'verifies the signature attached to the received data (step S23). Specifically, the signature attached to the received data is decrypted with the device vendor public key 301 included in the device vendor public key certificate 300 to obtain a hash value, and the hash value of the received data body is calculated. If both hash values match, it is assumed that the signature is valid.

  If the signature is valid (step S24), the received data is decrypted with the generated device secret key 102 (step S25). If the signature is not valid (step S24), an error is notified (step S26).

  In the following, as in the first embodiment, data is safely sent from the device vendor side to the electronic device 10 ′ side, taking as an example firmware update of the electronic device 10 ′ that cannot be directly connected to the Internet. An example of the technology will be described.

  FIG. 9 is a diagram illustrating a configuration example of an information system according to the second embodiment. In the information system shown in FIG. 9, an electronic device 10 'that is an information device that does not have a function of communicating with the Internet 90 (not shown in FIG. 9) is connected to a host 20' that is a computer operated by a user. The device vendor device 30 is an information device on the device vendor side that sold the electronic device 10 '. The host 20 ′ can access the device vendor apparatus 30 via the Internet 90.

  The device vendor apparatus 30 holds a device vendor secret key 302 and a firmware update program 304. The firmware update program 304 is a program for updating the firmware of the electronic device 10 ′.

  The device vendor registers the device vendor public key certificate 300 for the electronic device 10 ′ before shipping the electronic device 10 ′. The device vendor public key certificate 300 includes a device vendor public key 301 and a device vendor signature 303 obtained by encrypting the hash value of the device vendor public key 301 with the device vendor private key 302 (see FIG. 7). The device vendor public key 301 included in the device vendor public key certificate 300 and the device vendor private key 302 held by the device vendor apparatus 30 are a pair of keys.

  A security chip (TPM) 40 is mounted on the host 20 '. In the security chip (TPM) 40, a TPM public key certificate 400 and a TPM private key 402 are registered by a TPM vendor (a vendor of the security chip (TPM) 40) at the time of manufacture. The security chip (TPM) 40 generates a device public key certificate 100 ′ by signing the device public key 101 received from the electronic device 10 ′ with the TPM private key 102.

  The TPM vendor registers a TPM vendor public key (TPM vendor public key) in advance in a certification authority (CA). The certificate authority generates a TPM vendor public key certificate 500 by signing the registered TPM vendor public key, and issues the TPM vendor public key certificate 500 in response to a request from the device vendor.

  FIG. 10 is a diagram illustrating examples of a TPM public key certificate, a device public key certificate, and a TPM vendor public key certificate according to the second embodiment. As shown in FIG. 10A, the TPM public key certificate 400 includes a TPM public key 401 and a signature 403 of the TPM vendor. The TPM public key 401 included in the TPM public key certificate 400 and the TPM private key 402 held by the security chip (TPM) 40 are a pair of keys. Also, as shown in FIG. 10B, the device public key certificate 100 ′ includes a device public key 101 and a TPM signature 104. As shown in FIG. 10C, the TPM vendor public key certificate 500 includes a TPM vendor public key 501 and a certificate authority signature 502.

  In the TPM public key certificate 400 shown in FIG. 10A, the signature 403 of the TPM vendor is encrypted with the hash value of the TPM public key 401 by the private key of the TPM vendor (the key paired with the TPM vendor public key 501). It has been done. In the device public key certificate 100 ′ shown in FIG. 10B, the TPM signature 104 is obtained by encrypting the hash value of the device public key 101 with the TPM private key 402. In the TPM vendor public key certificate 500 shown in FIG. 10C, the signature 502 of the certificate authority is obtained by encrypting the hash value of the TPM vendor public key 501 with the secret key of the certificate authority.

  In FIG. 9, the user operates the host 20 'to access the device vendor apparatus 30 in order to download the firmware update program 304 to the electronic device 10'. The electronic device 10 ′ generates a pair of the device public key 101 and the device private key 102, and based on authentication with the security chip (TPM) 40 with respect to the security chip (TPM) 40 mounted on the host 20 ′. The device public key 101 is transmitted in a secure manner.

  The security chip (TPM) 40 generates a device public key certificate 100 ′ by signing the device public key 101 received from the electronic device 10 ′ with the TPM private key 402, and the device public key certificate 100 ′. And the TPM public key certificate 400 held by itself to the device vendor apparatus 30 via the communication function of the host 20 ′.

  In the device vendor apparatus 30, the validity of the received device public key certificate 100 'is verified.

  FIG. 11 is a diagram for explaining the verification of the validity of the device public key certificate according to the second embodiment. The received device public key certificate 100 ′ is information that has been signed by a security chip (TPM) 40 manufactured by a TPM vendor. The device vendor apparatus 30 verifies whether the received device public key certificate 100 'is information signed by a valid security chip (TPM) 40 manufactured by a valid TPM vendor.

  As shown in FIG. 11, the device public key certificate 100 ′ includes a TPM vendor signature 104 in which the hash value of the device public key 101 is encrypted with the TPM private key 402. The TPM public key certificate 400 includes a TPM vendor signature 403 in which the hash value of the TPM public key 401 is encrypted with the TPM vendor private key. The TPM vendor public key certificate 500 includes a certificate authority signature 502 in which the hash value of the TPM vendor public key 501 is encrypted with the secret key of the certificate authority. If all of these signatures are correctly decrypted step by step, the received device public key certificate 100 'is a device public key whose signature is received by a valid security chip (TPM) 40 manufactured by a valid TPM vendor. Certificate 100 'is proved.

  First, the device public key certificate 100 'is verified. The TPM signature 104 included in the device public key certificate 100 ′ is decrypted with the TPM public key 401 included in the TPM public key certificate 400 to obtain a hash value. Also, the hash value of the device public key 101 included in the device public key certificate 100 'is calculated. The hash value obtained by decryption is compared with the calculated hash value, and if both match, the received device public key certificate 100 ′ has issued the TPM public key certificate 400, and the security chip (TPM) It is recognized that the information is signed by 40.

  Next, the TPM public key certificate 400 is verified. On the device vendor side, the TPM vendor public key certificate 500 is acquired from the certificate authority. The signature 403 of the TPM vendor included in the TPM public key certificate 400 is decrypted with the TPM vendor public key 501 included in the TPM vendor public key certificate 500 to obtain a hash value. Further, the hash value of the TPM public key 401 included in the TPM public key certificate 400 is calculated. When the hash value obtained by decryption is compared with the calculated hash value and the two values match, the received TPM public key certificate 400 is recognized as information signed by the TPM vendor.

  Next, the TPM vendor public key certificate 500 is verified. On the device vendor side, the public key 601 of the certificate authority is acquired by a proper means. The public key 601 of the certificate authority is a key that is paired with the secret key of the certificate authority used for signing the TPM vendor public key 501. The certificate authority signature 502 included in the TPM vendor public key certificate 500 is decrypted with the certificate authority public key 601 to obtain a hash value. Further, the hash value of the TPM vendor public key 501 included in the TPM vendor public key certificate 500 is calculated. When the hash value obtained by decryption is compared with the calculated hash value and the two values match, it is recognized that the TPM vendor public key certificate 500 is information signed by the certificate authority.

  The validity of the TPM vendor public key certificate 500 is proved by the certificate authority, and the validity of the TPM public key certificate 400 is indirectly verified by the validity of the TPM vendor public key certificate 500. The device public key certificate 100 ′ is proved indirectly by verifying the validity of the TPM public key certificate 400.

  As described above, in the second embodiment, a legitimate security in which the received device public key certificate 100 ′ is manufactured by a legitimate TPM vendor by using step-by-step certification using an existing infrastructure such as PKI. Trust that the information is signed by the chip (TPM) 40.

  In FIG. 9, when it is determined that the device public key certificate 100 ′ is valid, the device vendor apparatus 30 encrypts the firmware update program 304 with the device public key 101 included in the device public key certificate 100 ′. . The hash value of the encrypted firmware update program 304 is calculated, and the calculated hash value is signed in the encrypted firmware update program 304 using the device vendor private key 302. The device vendor apparatus 30 sends the encrypted firmware update program 304 to the electronic device 10 'via the host 20'.

  When the electronic device 10 ′ receives the encrypted firmware update program 304, the electronic device 10 ′ verifies the signature of the received encrypted firmware update program 304. When the validity of the encrypted firmware update program 304 is proved, the encrypted firmware update program 304 is decrypted with the device secret key 102.

  The firmware update program 304 encrypted with the device public key 101 can be decrypted only with the device secret key 102 generated and held by the electronic device 10 ′. Therefore, even if the firmware update program 304 encrypted by the relay host 20 ′ or the like is acquired in the process of sending the firmware update program 304 encrypted from the device vendor apparatus 30 to the electronic device 10 ′, the encryption The converted firmware update program 304 cannot be decrypted.

  The electronic device 10 ′ updates the firmware of the electronic device 10 ′ itself by executing the decrypted firmware update program 304.

  Since the flow of encryption / decryption of the firmware update program according to the second embodiment is the same as that of the first embodiment, description thereof will be omitted. Also in the second embodiment, as in the case of the first embodiment, it is naturally possible to use a hybrid method for data encryption.

  According to the second embodiment, by using the security chip (TPM) 40, the device vendor can check the validity of the device public key 101 generated by the electronic device 10 ′ using a certificate authority or the like. Therefore, the device public key 101 and the device secret key 102 can be updated, and the communication path between the electronic device 10 ′ and the device vendor apparatus 30 can be kept safe for a long time.

  Although Embodiments 1 and 2 have been described above, the present invention is not limited to these embodiments. For example, in the first and second embodiments described above, an example in which a firmware update program is sent as an example of sending data from a device vendor to an electronic device has been described. However, the sent data need not be a firmware update program. For example, when music data is downloaded from a portable music player vendor (corresponding to a device vendor) to a portable music player (corresponding to the electronic device 10) using a PC (corresponding to the host 20) or the like, The data sent to the type music player is music data.

It is a figure which shows the structural example of the electronic device by this Embodiment 1. FIG. 4 is a flowchart of processing performed by the electronic device according to the first embodiment. It is a figure which shows the structural example of the information system by this Embodiment 1. FIG. It is a figure explaining verification of the validity of the apparatus public key certificate by this Embodiment 1. FIG. It is a figure explaining the flow of encryption / decryption of a firmware update program. It is a figure explaining a hybrid system. It is a figure which shows the structural example of the electronic device by this Embodiment 2. FIG. It is a flowchart of the process by the electronic device of this Embodiment 2. It is a figure which shows the structural example of the information system by this Embodiment 2. FIG. It is a figure which shows the example of the TPM public key certificate by this Embodiment 2, a device public key certificate, and a TPM vendor public key certificate. It is a figure explaining verification of the validity of the apparatus public key certificate by this Embodiment 2. FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10,10 'Electronic device 11 Device public key certificate transmission part 12 Data reception part 13 Signature verification part 14 Data decryption part 15 Equipment public key transmission part 16 Key generation part 20, 20' Host 30 Equipment vendor apparatus 40 Security chip (TPM )
90 Internet 100, 100 ′ device public key certificate 101 device public key 102 device private key 103 device vendor signature 104 TPM signature 300 device vendor public key certificate 301 device vendor public key 302 device vendor private key 303 device vendor signature 304 Firmware Update Program 400 TPM Public Key Certificate 401 TPM Public Key 402 TPM Private Key 403 TPM Vendor Signature 500 TPM Vendor Public Key Certificate 501 TPM Vendor Public Key 502 Certificate Authority Signature

Claims (2)

An electronic device that does not have a communication function to the Internet, a host that is connected to the electronic device, has a communication function to the Internet, has a security chip, and is accessible from the host via the Internet. A data sending method by an information processing system comprising equipment of a vendor equipment vendor,
The electronic device has a first public key registered in advance by the device vendor,
In the security chip, a third secret key and a third public key paired with the third secret key signed by the security chip vendor are registered in advance by the security chip vendor. ,
The electronic device generating a second secret key and a second public key paired with the second secret key;
The electronic device transmitting the second public key to the security chip;
The security chip using the third private key to sign the received second public key;
The host sending the signed second public key and the signed third public key to the device vendor's device;
The device vendor apparatus verifying the received signed second public key and the signed third public key;
The device vendor device encrypts data to be transmitted to the electronic device using at least the second public key when the validity of the signed second public key is confirmed by the verification. When,
The device vendor device signing the encrypted data using a first private key paired with the first public key;
The device vendor's device transmitting the signed and encrypted data to the electronic device via the host;
The electronic device verifying the received signed and encrypted data with the first public key;
The electronic device has a step of decrypting the encrypted data using the second secret key when the validity of the signed and encrypted data is confirmed by verification. How to send data. The data transmission method according to claim 1, wherein the data is a firmware update program of the electronic device executed by the electronic device or firmware to be updated by the electronic device.

Images