JP6387908B2 - Authentication system - Google Patents

Description

  The present invention relates to an authentication system that prevents unauthorized use of a maintenance device.

  In recent years, with the advancement of software, it has become common to install maintenance functions such as a debug function and an update function in an embedded device such as a mobile phone or an in-vehicle computer. The debug function is used for the purpose of verifying the operation of the device during development and for analyzing the failed device. The update function is used when software or firmware is updated to correct a defect or improve the function.

These maintenance functions are functions that are not used by general users, and are often restricted so that the users cannot access them. In particular, an in-vehicle computer (Engine Control Unit, hereinafter referred to as ECU) is in charge of controlling an automobile, so that an easy change in parameters may lead to a failure or an accident. For this reason, in order to access the maintenance function, a dedicated device (hereinafter referred to as a maintenance device) is required, and a general user cannot easily touch the maintenance function.

However, if a malicious user obtains the maintenance device, the maintenance function may be used illegally. For example, when the maintenance device is implemented as software that operates on a personal computer, there is a possibility that the ECU may be accessed using software copied illegally.
As a technique for preventing this, there is an invention described in Patent Document 1, for example. In the system described in Patent Literature 1, the maintenance device indicates that it is a valid device with respect to the management server, and obtains a certificate from the management server. Then, the proof is transmitted to the ECU, and the ECU determines whether or not updating is possible. By doing so, unauthorized use of the maintenance device can be prevented.

Japanese Unexamined Patent Publication No. 2014-048800 JP 2012-104049 A JP 2010-023556 A JP2013-141948A

According to the invention described in Patent Document 1, the maintenance function is not effective unless the management server confirms that the maintenance device is valid.
However, even if the maintenance device is valid, it cannot be prevented when a malicious user attempts to update the ECU using unauthorized software that has been modified.

  That is, in order to prevent such use, an authentication system that performs both confirmation of the validity of the maintenance device (entity authentication) and confirmation of the validity of the data transmitted to the ECU (data authentication). Need to build.

The present invention has been made in consideration of the above-described problems, and an object thereof is to prevent unauthorized use of a maintenance device for maintaining a computer.

  An authentication system according to a first aspect of the present invention is applied to a first computer that controls software update of a connected computer, a second computer that is a target of software update, and the second computer. And a management server that provides the update software, wherein the second computer authenticates the validity of the update software.

  The first computer is a device for performing maintenance of the second computer. For example, the first computer is a combination of a personal computer and maintenance software, but may be dedicated hardware or the like. The second computer is a device for which software is updated, and is, for example, an embedded device or an in-vehicle computer (ECU).

More specifically, in the authentication system according to the first aspect of the present invention, the management server performs entity authentication of the first computer based on the configuration certification data transmitted from the first computer. When the first computer is legitimate, the electronic signature is added to the first data including the update software corresponding to the second computer and the data including the digest corresponding to the update software. Providing means for transmitting the second data, which is the processed data, to the first computer.
In addition, the first computer acquires configuration proof data, which is data indicating its own validity, and acquires the first and second data from the management server, and self-certification means that transmits the configuration proof data to the management server. And transfer means for transferring to the second computer.
Further, the second computer uses the public key corresponding to the management server to verify the electronic signature included in the second data, and uses the digest included in the second data, Updating means for verifying the update software and performing software update when all the validity is confirmed by the two types of verification.

The first computer in the present invention requests software for updating the second computer from the management server. At this time, the first computer transmits data (configuration certification data) indicating that it is valid to the management server, and the management server performs entity authentication. The entity authentication may be performed by any method as long as the validity of the first computer can be confirmed. For example, the hardware or software hash of the first computer may be transmitted using public key cryptography.
When the management server determines that the first computer is valid, the management server verifies the first data including software (update software) for updating the second computer and the first data. The second data is generated, and the first data and the second data are transmitted to the first computer.
The second data is data obtained by adding the electronic signature of the management server to data including a digest corresponding to the update software. The digest is information for confirming the validity of the update software. For example, the digest is a hash value of the update software. However, the digest is not limited to this as long as it is one-way.

  The two data transmitted to the first computer are transferred to the second computer, for example, at the timing when the first computer and the second computer are connected.

The second computer that has received the data first (1) verifies the electronic signature included in the second data using the public key corresponding to the management server, and (2) is included in the second data. The updated software is verified using the digest. With these two types of verification, the second computer can confirm that the update software is a legitimate one created by the management server.

  With this configuration, the second computer can confirm the validity of the updated software. In addition, since the update software is not generated unless the first computer is valid, both the entity and the data can be ensured.

  Further, the self-certifying means included in the first computer generates a digest corresponding to the platform configuration of the self-device, transmits data to which the electronic signature is added to the management server as configuration certification data, and The server may perform the entity authentication of the first computer by verifying the electronic signature and the digest.

  The configuration certification data is data for indicating that the platform of the first computer is valid, and is, for example, a hash value of software or hardware, but is not limited thereto. The target software may be, for example, only maintenance software or may include an operating system library, kernel, middleware, and the like. Moreover, all the software memorize | stored in the disk apparatus may be sufficient.

  With this configuration, even if an attacker analyzes the protocol of legitimate communication software and creates maintenance software for attack, maintenance data cannot be received from the management server. Further, if the configuration proof data generation target includes not only the communication software but also the kernel and library of the operating system, it is possible to deal with a case where the legitimate communication software is illegally copied. In other words, since the authentication cannot be obtained if the kernel or library of the computer used for the attack is slightly different from the legitimate computer, fraud can be prevented.

  Further, the self-certifying means included in the first computer may be realized by a tamper resistant device.

A tamper-resistant device is a device that has a defense against taking out information or altering information. For tamper resistant devices, for example, TPM (Trusted Platform Module)
) Can be used. The TPM is a tamper-resistant security chip standardized by TCG (Trusted Computing Group), and can store a private key, generate a hash, generate an electronic signature, and the like alone. Since the generation of the hash and the electronic signature performed inside the TPM cannot be involved from the outside, the data cannot be falsified or an illegal electronic signature cannot be generated. In addition, if data or a secret key is physically extracted, self-destruction occurs, so it cannot be separated from hardware. That is, unless the first computer is legitimate, correct configuration certification data cannot be obtained, and an update program cannot be obtained from the management server.

  The first computer further includes update control means for instructing the second computer to update software, and the second data corresponds to the digest and the first computer. The first public key, which is a public key, and data obtained by adding the electronic signature of the management server, and the updating means is included in the second data when both of the two types of verification are successful The first public key is used to encrypt a session key used for the secret communication with the first computer, and the encrypted session key is transmitted to the first computer. The session key used for the secret communication is obtained by decrypting with the secret key, and the secret communication with the second computer is performed.

The first public key corresponds to the first computer authenticated by the management server. That is, when the connected first computer is illegal, the first computer cannot extract the session key, and subsequent communication is impossible.
With this configuration, the entity authentication of the first computer can be performed even at the timing when the first computer and the second computer are connected.

The session key may be a pseudo random number.
Since the pseudo random number changes every time, even if the attacker intercepts the communication contents, an effect that the replay attack cannot be performed is obtained.

  An authentication system according to a second aspect of the present invention includes a first computer that controls software update of a connected computer, and a second computer that is a target of software update, the second computer Is a system for authenticating the first computer and the update software.

  Specifically, the first computer includes first data including update software corresponding to the second computer, a first digest corresponding to the update software, and a platform of the first computer. And second data that is data obtained by adding the first electronic signature that is the electronic signature of the update software provider to the data that includes the corresponding second digest. The transfer means for transferring, the self-certification means for acquiring the configuration proof data, which is data indicating its own validity, and transmitting it to the second computer, and the second computer correspond to the provider of the update software The first digital signature included in the second data is verified using the public key to be used, and the first signature included in the second data is verified. The update software was verified using a digest, and the configuration proof data was verified using a second digest included in the second data, and the validity was confirmed by the three types of verification. In some cases, it has an update means for performing software update.

The authentication system according to the second aspect of the present invention does not authenticate the first computer when receiving the update software. For example, the data generated in advance by the management server is input to the first computer offline.
In such a form, the second computer needs to confirm the authenticity of the first computer. Therefore, in this embodiment, when the update software provider generates the second data, the second digest corresponding to the platform of the first computer is included. Further, the first computer transmits the configuration certification data to the second computer, and the second computer matches these to authenticate the first computer.
According to such a configuration, since the software can be updated only on the first computer assumed by the provider of the update software, the security can be ensured as in the first embodiment.

  In addition, this invention can be specified as an authentication system containing at least one part of the said means. It can also be specified as an authentication method performed by the authentication system. The above processes and means can be freely combined and implemented as long as no technical contradiction occurs.

  According to the present invention, unauthorized use of a maintenance device that performs computer maintenance can be prevented.

It is a system outline figure in a first embodiment. 1 is a system configuration diagram of a vehicle according to a first embodiment. It is a system configuration figure of the maintenance device concerning a first embodiment. It is a system configuration figure of the management server concerning a first embodiment. It is an example of the update package produced | generated by the management server. It is a process flowchart of the maintenance apparatus in 1st embodiment. It is a process flowchart of the management server in 1st embodiment. It is a processing flowchart of vehicles in a first embodiment. It is an example of the update package in 2nd embodiment. It is a process flowchart of the maintenance apparatus in 2nd embodiment. It is a process flowchart of the vehicle in 2nd embodiment. It is a figure explaining the object range of composition certification in a third embodiment.

(First embodiment)
An overview of the authentication system in the first embodiment will be described with reference to FIG. The first embodiment is an authentication system including a vehicle 10, a maintenance device 20 for performing maintenance on a computer (ECU) mounted on the vehicle 10, and a management server 30. The maintenance device 20 is the first computer in the present invention, and the ECU mounted on the vehicle 10 is the second computer in the present invention.

The maintenance device 20 is a personal computer in which software for performing data analysis and program update on an ECU mounted on the vehicle operates. This software is referred to as communication software in this embodiment.
The maintenance device 20 in the first embodiment requests the management server 30 for software for updating the ECU of the vehicle 10.
At this time, the maintenance device 20 generates configuration certification data and transmits it to the management server together with the electronic signature. The configuration certification data is data indicating the validity of the software included in the computer, and in this embodiment, is a hash value corresponding to the software stored in the computer. The management server verifies the digital signature to confirm that the transmitted data is legitimate (that is, sent from a legitimate computer and not forged), and checks whether the hash value is correct. By verifying, it is confirmed that the software stored in the computer has not been forged or altered.

If the computer and the software stored in the computer are valid, the management server generates an update package. The update package is a set of data necessary for updating the ECU of the vehicle 10. The update package is transferred to the vehicle 10 via the maintenance device 20, and the ECU that receives the update package determines whether or not the update package is valid, and only when the validity can be confirmed, the maintenance device. A notification of permission is issued to start maintenance work.
With this configuration, it is possible to ensure that both the update software and the maintenance device are valid. Specific data contents and processing methods will be described later.

<System configuration>
Details of the embodiment for realizing the functions described above will be described.
The configuration of the authentication system according to the first embodiment will be described with reference to FIGS. 2 is a system configuration diagram of the vehicle 10, FIG. 3 is a system configuration diagram of the computer 20, and FIG. 4 is a system configuration diagram of the management server 30.

  First, the vehicle 10 will be described. The vehicle 10 is an automobile equipped with a plurality of vehicle control ECUs. The vehicle 10 includes a plurality of ECUs according to functions such as an engine, a power train, a brake, and vehicle control. Each ECU is connected to the maintenance device 20 through the in-vehicle network, so that the program can be updated and data can be analyzed. Note that FIG. 2 illustrates only a means for acquiring the update package and confirming its validity, and the ECU is not illustrated.

  The communication unit 11 is means for communicating with the maintenance device 20. Specifically, an update package is received from the maintenance device 20, and a command for updating software (hereinafter referred to as a maintenance command) is received. The automobile is equipped with a standard communication port called OBD2, and the communication unit 12 makes a wired connection with the maintenance device 20 using the port.

  The center public key storage unit 12 is a means for storing a center public key that is a public key corresponding to the management server 30. All vehicles using this system store the corresponding center public key.

The package verification unit 13 is means for verifying the validity of the update package transferred by the maintenance device 20. Specifically, by verifying information (electronic signature or hash) included in the update package, it is confirmed that the update package is a genuine one generated by the management server 30. A detailed verification method will be described later.
The command execution unit 14 is a means for executing a maintenance command transmitted from the maintenance device 20 and executing maintenance work (for example, data analysis or program update) on the target ECU.
The above means may be realized by an embedded computer having an arithmetic processing unit (CPU) and a storage device (ROM), or may be realized by a dedicated electronic circuit.

The maintenance device 20 is a general-purpose personal computer on which communication software for communicating with the ECU mounted on the vehicle 10 operates.
The communication unit 21 is a communication unit having the above-described OBD2 standard connector. For example, it is realized by an interface card mounted on an expansion bus of a personal computer.
The communication unit 22 is means for performing communication with the management server 30 and is realized by a communication module using a mobile communication network or multi-channel access radio. The communication with the management server 30 may be wireless communication or wired communication, but it is preferable to use a secure communication path.
The control unit 23 is a unit that controls the maintenance device 20. For example, the control unit 23 generates and transmits a maintenance command for an ECU mounted on the vehicle 10 and an update package acquired from the management server 30 to the vehicle 10. Perform the function.
The maintenance command is an instruction for performing data analysis and software update, and is generated based on an operation received from a user through an input / output unit (not shown) such as a touch panel or a keyboard.

  Reference numeral 200 represents an area protected by the TPM. As described above, the TPM is a one-chip module that is built in a computer and has various functions related to cryptographic operations. The module is mounted directly on the computer main board.

The TPM control unit 201 is a means for controlling the functions of the TPM. In the present embodiment, operations for generating software configuration certification data and generating an electronic signature using public key cryptography are controlled. Further, the TPM control unit 201 stores a secret key (first secret key in the present invention) unique to the maintenance device 20. The first private key is stored in software and hardware-protected non-volatile memory and can be used to generate electronic signatures, etc., but access from outside, physical memory retrieval, etc. Can not do.
The configuration proof generation unit 202 is means for generating configuration proof data. Specifically, it is a means for calculating a hash value of software installed in the maintenance device 20 by an algorithm such as SHA-1 or SHA-256. The calculated hash value is the configuration certification data in the present invention. A specific example of generating the configuration proof data will be described later.

  In the maintenance device 20, the above means is realized by an arithmetic processing unit (CPU), a storage device (ROM), a TPM, and other hardware.

The management server 30 is a server device that communicates with the maintenance device 20.
The communication unit 31 is means for transmitting and receiving data using the same protocol as the communication unit 22. In this embodiment, the configuration certification data is received from the maintenance device 20 and the generated update package is transmitted to the maintenance device 20.
The maintenance device public key storage unit 32 is a means for storing a public key corresponding to the maintenance device 20 (hereinafter referred to as maintenance device public key, the first public key in the present invention). In this embodiment, the maintenance device public key is different for each maintenance device, and the management server 30 stores all the public keys for each maintenance device. The maintenance device public key may be common among a plurality of maintenance devices.

The configuration certification verification unit 33 is a means for confirming the validity of the configuration certification data transmitted from the maintenance device 20. Specifically, by using the maintenance device public key, the electronic signature attached to the configuration certification data is verified, the source is confirmed, and the configuration certification data is verified and stored in the maintenance device 20. Confirm that the software is valid.
For this reason, the configuration proof verification unit 33 stores a hash value (hereinafter referred to as an ideal state) corresponding to software included in a valid maintenance device.

The package generation unit 34 is a unit that generates an update package to be transmitted to the vehicle.
Here, the structure of the update package will be described with reference to FIG. In the first embodiment, the update package includes first data and second data.
The first data is a binary file (update software in the present invention; hereinafter, update binary) used to update the software of the target ECU. The second data is data obtained by adding the electronic signature of the management server to the maintenance device public key corresponding to the maintenance device 20 that requested the update package and the hash value of the updated binary. The hash value of the update binary uses a value calculated by an algorithm such as SHA-1 or SHA-256. Further, the package generation unit 34 generates and adds an electronic signature using its own private key stored in the center private key storage unit 35.
In this embodiment, X. An electronic certificate according to 509v3 is used as the second data. This standard is suitable for this embodiment because it has an extension area and can store hash values of updated binaries.

The center secret key storage unit 35 is a means for storing a center secret key that is a secret key unique to the management server 30.
The above configuration is preferably configured by a computer having an arithmetic processing unit (CPU) and a storage unit (ROM), but may be realized by dedicated hardware.

<Processing flow>
Next, processing in which the maintenance device 20 requests an update package from the management server 30 will be described. 6 is a flowchart of processing performed by the maintenance device 20, and FIG. 7 is a flowchart of processing performed by the management server 30.

When the maintenance device 20 obtains an instruction to update the target ECU from the user, the process shown in FIG. 6 is started.
First, in step S <b> 11, the TPM control unit 201 generates configuration certification data corresponding to its own device through the configuration certification generation unit 202.

The configuration certification data generated in this step will be described in detail.
The TPM has a register called a PCR (Platform Configuration Register) used for measuring the platform configuration. In the PCR, a hash value for the current platform is written each time the platform is activated. The PCR is protected by hardware and cannot be rewritten to an arbitrary value by the user. In other words, platform tampering can be detected by comparing the hash value recorded in the PCR with the hash value corresponding to the valid platform configuration. The hash value recorded in the PCR is the configuration certification data in the present invention. An electronic signature is added to the configuration certification data using a secret key (first secret key) stored in the TPM. This operation is called “Attestation” and is a function that the TPM has as a standard. Since the configuration certification data generated by the TPM and attached with the electronic signature cannot be modified from the outside, the validity of the platform can be confirmed by a third party verifying it.
In the first embodiment, the platform to be verified refers to all software stored in the maintenance device 20. That is, communication software, other applications, system libraries, operating system kernels, and the like are included.

  When the configuration certification data and the electronic signature are generated by the process of step S11, the control unit 23 transmits the data to the management server 30 via the communication unit 22 (S12). At this time, information for identifying the ECU to be updated may be transmitted simultaneously.

  Here, the processing performed by the management server 30 will be described with reference to FIG. When receiving the configuration certification data and the electronic signature through the communication unit 31, the management server 30 acquires a public key corresponding to the maintenance device 20 from the maintenance device public key storage unit 32 (step S21). As described above, the maintenance device public key storage unit 32 stores a public key corresponding to each maintenance device, and can acquire a public key corresponding to the received electronic signature.

  Then, the configuration certification verification unit 33 verifies the electronic signature attached to the configuration certification data (step S22). Specifically, the electronic signature included in the received data is decrypted using the acquired public key, and it is confirmed whether or not it matches the hash value obtained from the received data. If the verification of the electronic signature is successful, it can be confirmed that the received configuration certification data is transmitted from the corresponding maintenance device 20 and has not been tampered with. If verification of the electronic signature fails, the operation is terminated (S22-No).

Subsequently, it is confirmed whether the hash value (software hash value of the maintenance device) included in the configuration certification data matches the hash value (that is, ideal state) corresponding to the software of the valid maintenance device (step) S23). If they match, it can be confirmed that the software stored in the maintenance device 20 is valid (S23-Yes). If the hash values do not match, the operation ends (S23-No).
That is, if both the results of steps S22 and S23 are Yes, it can be confirmed that the maintenance device 20 is valid.

When the validity of the computer is confirmed, the package generation unit 34 generates an update package for updating the ECU (step S24).
In step S24, first, an update binary to be transmitted to the maintenance device is selected and set as first data. Next, a hash value corresponding to the updated binary is obtained. Next, a maintenance device public key corresponding to the target maintenance device 20 is acquired, data including a hash value and a public key is generated, and an electronic signature is generated and added using its own private key. The structure of the generated data is as shown in FIG. In the first embodiment, the entire data generated in this way is an update package.
The generated update package is transmitted to the maintenance device 20 via the communication unit 31 (step S25).

Returning to the description of the processing performed by the maintenance device 20 (FIG. 6), the description will be continued from step S13. The maintenance device 20 attempts to receive the update package after transmitting the configuration certification data to the management server 30 (step S13). At this time, when the update package is received within a predetermined time, the update package is transferred to the vehicle 10 through the communication unit 21 (step S14). When the response from the management server times out (S13-No), the process is terminated.
When step S14 is completed, verification of the update package by the vehicle is performed, and during that time, the maintenance device 20 enters a waiting state.

Here, with reference to FIG. 8, the process which the vehicle 10 performs is demonstrated.
When the vehicle 10 receives the update package, the package verification unit 13 decrypts the electronic signature included in the update package using the center public key stored in the center public key storage unit 12 and verifies the electronic signature. (Step S31). If the verification fails (S32-No), the process is terminated. If the verification of the electronic signature is successful (S32-Yes), it can be confirmed that the second data included in the update package has been transmitted from the management server 30 and has not been tampered with.
Next, the hash value of the updated binary is acquired in step S33, and it is confirmed that it matches the hash value included in the second data. Here, if the hash values do not match, it is suspected that only the updated binary has been rewritten, so the processing is terminated (S33-No). If the hash values match (S33-Yes), it can be seen that the received "update binary" and "maintenance device public key" are both valid.

In step S <b> 34, the package verification unit 13 generates a session key used for communication with the maintenance device 20. An arbitrary numerical value or character string may be used as the session key, but it is preferable to use a pseudo-random number generated for each session in order to prevent a replay attack.
In step S35, the generated session key is encrypted with the acquired maintenance device public key and transmitted to the maintenance device 20. In this way, the message can be decrypted only by the maintenance device corresponding to the maintenance device public key included in the update package. In other words, unless the maintenance device recognized by the management server and the maintenance device connected to the vehicle are the same, communication cannot be performed, thereby preventing maintenance work using an unauthorized maintenance device. Can do.

Returning to the description of the processing performed by the maintenance device 20 (FIG. 6), the description will be continued from step S15.
In step S15, an encrypted session key is obtained from the vehicle 10, and a session key is obtained by decrypting the encrypted session key using its own secret key. In step S16, a command (maintenance command) for executing maintenance work is generated, and communication with the vehicle is started. The communication is a secret communication using the acquired session key.
Further, the vehicle 10 is in a state of accepting the maintenance command transmitted from the maintenance device until the connection with the maintenance device 20 is released.

<Effect of the first embodiment>
As described above, in this embodiment, first, the maintenance device transmits the configuration certification data to the management server, and the management server authenticates the maintenance device. Since the TPM is used to generate the configuration certification data, the attacker cannot send false information to the management server. That is, the entity authentication of the maintenance device can be performed.
Second, the vehicle verifies the update package transmitted from the management server and confirms the validity. As a result, unauthorized use due to replacement of update packages can be prevented.
Third, the maintenance package public key is included in the update package, and the session key is transmitted using the public key. For this reason, unless it is a maintenance device that has been authenticated by the management server, communication with the vehicle cannot be performed, so that entity authentication can be performed even during connection.
As described above, in the first embodiment, unauthorized maintenance work can be prevented by performing data authentication and entity authentication repeatedly.

(Second embodiment)
In the first embodiment, the maintenance device 20 and the management server 30 are connected online, and the update package is generated after the management server authenticates the maintenance device.
In contrast, the second embodiment is an embodiment in which an update package generated in advance by the management server is taken offline.

  In the second embodiment, the management server specifies the maintenance device 20 used for software update, and then generates an update package in advance. FIG. 9 is a diagram showing the structure of the update package generated in the second embodiment. In the second embodiment, the “ideal state” in the first embodiment, that is, a hash value obtained by authenticating the configuration of the authentic maintenance device is added to the second data.

  FIG. 10 is a process flowchart of the maintenance device 20 in the second embodiment. In addition, about the step which performs the process similar to 1st embodiment, it shows with a dotted line and abbreviate | omits description.

After generating the configuration certification data in step S11, in step S41, the update package generated by the management server 30 is taken into the maintenance device 20 via, for example, an external storage device.
In step S42, the update package and the configuration certification data generated in step S11 are transmitted to the vehicle.

FIG. 11 is a process flowchart of the vehicle 10 in the second embodiment. In the second embodiment, the vehicle 10 confirms that the configuration proof data is authentic before executing step S34 (step S51). Specifically, after verifying the source of the obtained configuration certification data using the maintenance device public key contained in the second data, the "ideal state" contained in the update package and the obtained configuration certification data And confirm whether they match.
Here, if the two do not match, the software of the maintenance device 20 may not be authentic, so the processing is terminated.
The processes after step S34 and step S15 are the same as those in the first embodiment.

  As described above, in the second embodiment, the “ideal state” is included in the update package, and the vehicle confirms the validity of the maintenance device 20. If the ideal state is tampered with, the verification performed in step S51 fails, and the configuration proof data is generated in the TPM module and cannot be tampered with. That is, as in the first embodiment, it can be confirmed that the maintenance device is valid.

(Third embodiment)
In the first and second embodiments, all software stored in the maintenance device 20 is the target of configuration certification. However, the processor possessed by the TPM is slower than an arithmetic processing unit used in a computer, and there is a drawback that it takes time to process if there are a large number of configuration verification targets. The third embodiment is an embodiment in which the processing time of step S11 is shortened by narrowing down the target of configuration certification.

FIG. 12 is a diagram illustrating a range of software to be subject to configuration certification. The range indicated by the dotted line is the target range of the configuration proof in each form. In the first embodiment, since the target of the configuration proof is all software stored in the computer, the range is as shown in FIG.
On the other hand, if it is sufficient to confirm that only the communication software is valid, the configuration proof target can be set as shown in FIG. If it is desired to check the validity of the system library and the kernel in addition to the communication software, the configuration certification target may be set as shown in FIG.

Also, software that detects software tampering may be used. Software that monitors changes in stored software is called an observer.
The observer shown in FIG. 12D is an application that detects a change in the user application. The observer maintains a list of applications that are allowed to be executed, and can immediately detect when an application has been changed or tampered with. A technique for detecting that an execution file of an application has been changed is known, and is used in, for example, white list type anti-virus software. Then, by making the target of configuration certification the observer, the system library, and the kernel, it is possible to detect a change in all the software stored in the maintenance device 20. That is, the same effect as the configuration proof is performed for the range of FIG. Of course, the object of the configuration proof may be only the observer.

  In the first and second embodiments, there is a drawback that it takes time to generate the configuration proof data. However, according to the third embodiment, the generation of the configuration proof data can be completed in a short time.

(Modification)
The above embodiment is merely an example, and the present invention can be implemented with appropriate modifications within a range not departing from the gist thereof.
For example, in each embodiment, the configuration proof is performed using the TPM. However, if the first secret key can be stored and the hash value of the software can be generated, it is not always necessary to use the TPM. For example, any secure device may be used. In addition to this, the validity of the software may be confirmed by other than the hash value.

  Further, in each embodiment, the management server holds the maintenance device public key, the vehicle holds the center public key, and performs authentication by electronic signature. The method may be used. For example, the public key may be transmitted each time using a public key certificate.

In the second embodiment, an example in which an update package is acquired offline has been described. However, an update package may be transmitted online.
In each embodiment, the maintenance device public key is included in the update package and the session key is transmitted using the public key. However, the maintenance device public key is not necessarily included in the update package, and the session key Use is not essential.
Further, the processing of steps S34 to S35 may be omitted, and the software may be updated independently when the vehicle 10 completes the authentication.

DESCRIPTION OF SYMBOLS 10 Vehicle 11, 21, 22, 31 Communication part 12 Center public key memory | storage part 13 Package verification part 14 Command execution part 20 Maintenance apparatus 23 Control part 200 TPM module 201 TPM control part 202 Configuration certificate generation part 30 Management server 32 Maintenance apparatus release Key storage unit 33 Configuration verification verification unit 34 Package generation unit 35 Center secret key storage unit

Claims (10)

A first computer that controls software update of a connected computer; a second computer that is a target for software update; and a management server that provides update software applied to the second computer, The second computer is an authentication system for authenticating the validity of the updated software,
The management server is
Based on the configuration certification data transmitted from the first computer, entity authentication of the first computer is performed, and when the first computer is valid, the update corresponding to the second computer Providing means for transmitting to the first computer, first data including software, and second data which is data including a digest corresponding to the updated software and having its electronic signature added thereto. Have
The first computer is
Self-certification means for acquiring configuration certification data, which is data indicating the validity of the self, and transmitting the data to the management server;
Transfer means for acquiring the first and second data from the management server and transferring them to the second computer;
The second computer is
The electronic signature included in the second data is verified using a public key corresponding to the management server, the update software is verified using a digest included in the second data, and the second Updating means for performing software update when all the correctness can be confirmed by the type of verification;
Authentication system. The self-certifying means included in the first computer generates a digest corresponding to the platform configuration of its own device, and transmits data to which the electronic signature is added to the management server as configuration certification data.
The management server performs entity authentication of the first computer by verifying the electronic signature and digest.
The authentication system according to claim 1. The self-certifying means included in the first computer is realized by a tamper-resistant device.
The authentication system according to claim 2. The first computer further includes update control means for instructing the second computer to update software,
The second data is data obtained by adding an electronic signature of the management server to the digest and a first public key that is a public key corresponding to the first computer.
The update means encrypts a session key used for secret communication with the first computer using the first public key included in the second data when both of the two types of verification succeed. To the first computer
The update control means obtains a session key used for secret communication by decrypting the encrypted session key with its own secret key, and performs secret communication with the second computer.
The authentication system according to any one of claims 1 to 3. The session key is a pseudo-random number;
The authentication system according to claim 4. A first computer that controls software update of a connected computer; and a second computer that is a target for software update, wherein the second computer authenticates the first computer and the update software. An authentication system,
The first computer is
Data including first data including update software corresponding to the second computer, a first digest corresponding to the update software, and a second digest corresponding to the platform of the first computer. Transfer means for obtaining and transferring the second data, which is the data to which the first electronic signature that is the electronic signature of the update software provider is added, to the second computer;
Self-certification means for obtaining configuration proof data, which is data indicating the validity of the self, and transmitting the data to the second computer;
The second computer is
Using the public key corresponding to the provider of the updated software, verifying the first electronic signature included in the second data, and using the first digest included in the second data, The updated software is verified, and the configuration certification data is verified using the second digest included in the second data. When all the validity is confirmed by the three types of verification, the software update is performed. Having update means to perform,
Authentication system. The second data is data obtained by adding an electronic signature of a software provider to the first digest and the second digest,
The self-certifying means possessed by the first computer generates a third digest corresponding to the platform configuration of the self-device, and adds data to which the second electronic signature, which is its own electronic signature, is added as the configuration certification data. Send to the second computer,
The updating means performs entity authentication of the first computer by verifying the second electronic signature and confirming the identity of the second digest and the third digest.
The authentication system according to claim 6. The self-certifying means included in the first computer is realized by a tamper-resistant device.
The authentication system according to claim 7. The first computer further includes update control means for instructing the second computer to update software,
In the second data, an electronic signature of a provider of the update software is added to the first and second digests and a first public key that is a public key corresponding to the first computer. Data,
The update means encrypts a session key used for secret communication with the first computer using the first public key included in the second data when all of the three types of verification are successful. To the first computer
The update control means obtains a session key used for secret communication by decrypting the encrypted session key with its own secret key, and performs secret communication with the second computer.
The authentication system according to claim 6. The session key is a pseudo-random number;
The authentication system according to claim 9.

Images