JP2011003020A - Computer system and program starting method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technology to safely start a program.SOLUTION: An OS program is encrypted or given an electronic signature and stored in a storage of a client device, and the program is obtained from a server device by a boot program which is executed when starting a terminal. The program obtained from the server device is a verification program which decrypts or verifies a signature of an execution object program, and the program is executed after the safety of the OS program is checked by the verification program. When updating the OS program, the server device transmits the reboot program to the client device after downloading the update program. If the safety of the server device is secured, the OS program can be safely started only by securing the safety of communication between client servers without providing a special device to the client device.

Description

  The present invention relates to a computer system and a program starting method that can safely execute a program.

  With the spread of computer systems, the importance of security assurance is increasing. In order to protect the software code itself that functions as a program, a method of protecting the work area by physically or virtually dividing it is considered (Patent Document 1). The TCG (Trusted Computing Group) has formulated a security chip standard called TPM (Trusted Platform Module). By using the TPM, security can be ensured by starting the program after continually verifying that there is no hardware alteration or software alteration.

  In a system that executes software, functions can be corrected or added by updating the software even after the product is shipped. In such a case, a corrected program is acquired via the network, but it is necessary to verify that the acquired program has not been tampered with. There has been proposed a method for realizing acquisition and execution of a secure program by using an electronic certificate and hiding it from an application residing in a terminal (Patent Document 2).

Japanese Patent Laid-Open No. 2004-199693 Special table 2007-528064 gazette JP 2002-24175 A

However, when special hardware is introduced into a terminal as in the method described in Patent Document 1, the introduction cost is increased in a system in which many terminals exist. For example, automobiles are equipped with a large number of ECUs (Electronic Control Units), and the number of ECUs to be mounted is expected to increase in the future. Introducing special hardware to all of such a large number of ECUs is not desirable from the viewpoint of cost.

  In addition, the method described in Patent Document 2 assumes download for a computer with scarce resources, but it is intended for a program having a certain size, so it is desired to shorten download time such as immediate response. It is difficult to meet the requirements.

  The present invention has been made in consideration of such problems, and an object of the present invention is to provide a technique for safely starting a program in a computer at a low cost.

  In order to achieve the above object, according to the present invention, when the client device is activated, the validity of the execution target program is verified based on information obtained from the server device, and then the program is executed. This makes it possible to determine whether or not the execution target program has been tampered with.

<First embodiment>
The computer system according to the first aspect of the present invention is a computer system including a client device and a server device that can communicate with each other. The client device includes a first storage unit that stores a boot program that is a program executed when the device is activated, and a second storage unit that stores a program to be executed. The server device has storage means for storing a verification program for verifying and starting the execution target program. Here, the boot program includes processing for acquiring and executing the program from the server device. In addition, the server device transmits a verification program to the client device in response to a request from the boot program of the client device, and the client device verifies the execution target program using the acquired verification program and succeeds in verification. Run the program.

  As a method for verifying the validity of the execution target program stored in the client device, a method using a decryption process and a method using a digital signature can be cited.

  The first method of program verification is a method in which the execution target program is stored in the second storage means in an encrypted state, and the verification program decrypts the program. When the execution target program is encrypted and saved, it can be determined that the program has not been tampered with when the execution target program is correctly decrypted. If the data is altered by a third party, the data cannot be decrypted correctly, so that the alteration can be detected. Furthermore, the execution target program can be concealed from a third party.

  In order to guarantee the safety of the boot program, a storage means that cannot be rewritten or difficult to rewrite may be employed as the first storage means. On the other hand, as the second storage means for storing the execution target program, it is preferable to adopt a rewritable storage means for enabling program update or the like.

  In order to verify the validity of the program acquired from the server device, it is preferable to use secret communication or signed communication for communication between the client and the server. It is possible to verify the legitimacy of a program or the like transmitted from the server device by such secret communication or signed communication. In addition, it is preferable to employ communication with a signature by a public key cryptosystem for communication from the server device to the client device. In this case, it is only necessary to store the public key of the server device in the client device, and since it is not necessary to conceal the public key, it is sufficient to store it in a mask chrome that cannot be tampered with. That is, there is an advantage that no special device is required on the client device side. However, when secret communication is performed using a common key encryption method, or communication using a public key encryption method that requires the secret key of the client device (secret communication from the server to the client and communication with a signature from the client to the server) Needs to be provided with a security chip (tamper resistant device) on the client device side, but the present invention does not exclude such a method.

In the first method, since the execution target program is encrypted and stored in the client device, there is an advantage that the contents cannot be known by a third party. However, a verification program (hereinafter referred to as a decryption processing program) for decrypting the encryption program is communicated between the client and the server. If this communication is performed in plain text, a third party can acquire the decryption processing program, and the encryption program can be decrypted. Therefore, in order to keep the execution target program secret from a third party, it is preferable to change the encryption key or the encryption algorithm of the execution target program after obtaining the decryption processing program by communication. For this purpose, the client device acquires a program to be executed, which is encrypted using a different encryption algorithm or a different encryption key from the program stored in the second storage means, from the server device, and stores it in the second storage. It is preferable to have a function of storing in the means.
Further, the server device stores an encryption algorithm and an encryption key for decrypting the execution target program transmitted to the client device, and then when a program request is received from the boot program of the client device, It is preferable to transmit a verification program corresponding to the execution target program stored in the client device to the client device. In this case, it is preferable from the viewpoint of processing load that acquisition of the encryption program by the new encryption method is performed at the end of execution of the client device.

  Further, when changing the encryption key or encryption algorithm of the execution target program as described above, the server device must transmit a decryption processing program corresponding to the encryption method to the client device. Therefore, the server device stores an encryption algorithm and an encryption key for decrypting the execution target program transmitted to the client device. When a program request is received from the boot program of the client device, a decryption processing program corresponding to the execution target program stored in the client device is transmitted to the client device.

  When the execution target program is updated, the server device may transmit the update work program to the client device when the boot program of the client device requests the server device for the program. Here, the update work program is a program that acquires a new execution target program by communication, stores it in the second storage means, and then restarts the program. Since the boot program of the client device executes the program acquired from the server device, the processing included in the update work program, that is, update and restart are executed in the client device. Also, here, the server device transmits an update work program in response to a program request to the server device by the boot program, but a program (stop processing program) executed when the client device is terminated sends a program to the server device. The server apparatus may send an update work program in response to this request. The method of updating before starting has a merit that a new program can be executed when there is an update, but has a demerit that it takes time to start the program. The method of updating before stopping has a merit that the program is started earlier, but has a demerit that an old program is executed when there is an update. Therefore, it is also preferable to switch whether to perform the update process before starting or stopping according to the importance of updating.

  The second method of program verification is a method in which an execution target program is stored in a second storage unit with an electronic signature attached, and the verification program verifies the signature. When a signature is assigned to the execution target program, it can be determined that the program has not been tampered with when the authentication code calculated from the program body matches the assigned signature. The first method of encrypting and storing an execution target program and performing a decryption process at the time of execution requires a relatively long time to start the program. On the other hand, this method based on signature verification has the advantage that verification processing can be performed at a higher speed, although the execution target program is stored in a plain text state so that a third party can know the contents. .

The second method includes two verification operations: verification for a verification program acquired from the server device and verification for an execution target program stored in the second storage unit. Here, the verification process for the verification program cannot be changed because it is stored in the first storage means of the client device. Therefore, in order to operate for a long period of time, it is necessary to use a robust program such as increasing the key length, and the processing speed is relatively slow. On the other hand, the execution target program is verified by a verification program sent from the server device and can be changed. Therefore, it is preferable to use a high-speed encryption algorithm at that time. Since the verification program is smaller in size than the execution target program, the overall time required for the verification process is shortened by using a low-speed algorithm for verification of the verification program and using a high-speed algorithm for the execution target program. be able to.

  Also in the second method, a rewritable storage means is employed as the first storage means for storing the boot program, and a rewritable storage means is used as the second storage means for storing the execution target program. It is preferable to adopt. As for the communication between the client and the server, similarly to the first method, it is preferable to use a secret communication or a signed communication.

  Also in the second method, it is preferable to update the execution target program by the same method as described in the first method. Also in this method, the update process may be performed at various timings as in the case of the first method. However, since the second method aims to start the program at a high speed, it is preferable to perform the update process by obtaining the update work program from the server device when the execution of the client device is completed.

<Second embodiment>
In the second aspect of the present invention, the server device requests a hash value for an arbitrary address of the execution target program, and determines that the execution target program is correct when this is a correct hash value. It is preferable to provide management means for managing the state of the program stored in the second storage means of the client device so that the server device can grasp the correct hash value.

  In the second aspect, even when the update process of the execution target program fails, the normal operation is enabled. If the update process is terminated abnormally, a part of the execution target program stored in the second storage means has been rewritten, and part of the program remains old. Even if a verification operation such as decryption processing or signature verification is performed in such a state, the verification does not pass and the client apparatus cannot be activated by the method according to the first aspect. Therefore, as in this method, the server device side manages the update status of the program of the client device, and requests the client device for a hash value for the address whose contents are known. As described above, since the update status is managed on the server device side and the program verification using the hash value is performed, it is possible to verify the validity of the client device even when the update processing ends abnormally.

  In this aspect, when the execution target program is updated, the server device divides the new execution target program into a predetermined size and transmits the program to the client device one by one. When rewriting of the storage means is completed, it is preferable to notify the server device to that effect. Then, it is preferable that the management unit of the server device manages to which part the update of the execution target program is completed in the client device based on the rewrite completion notification from the client device. In other words, the management means includes an address area that has been updated in the client device (an address area that has transmitted the update program and has received a rewrite completion notification), an address area that has not been updated yet (an address area that has not transmitted the update program) It is preferable to manage the address area where the completion / uncompletion of the update is unknown (the address area where the update program is transmitted but the rewrite completion notification is not received). By adopting such a configuration, it is possible to know to what part the execution target program in the client device has been updated and which part has not been updated. In addition, it can be seen which part of the update was abnormally terminated. Thus, the server device can request a hash value from the client device by designating an address that can be determined to be update completion or incomplete. Note that it is preferable that the hash value calculation target address is determined at random from addresses for which update is recognized as being completed or not completed.

In the client device, if the update processing of the execution target program is not completed (if interrupted in the middle), the server device restarts the update processing after the verification based on the hash value for the specified address is successful. Is preferred. On the other hand, when the update process of the execution target program is normally completed, after the verification is successful, an instruction to execute the execution target program is transmitted from the server apparatus to the client apparatus.

  In this manner, in the second aspect, even when the execution target program update process ends abnormally, the execution target program stored in the client device can be verified. In addition, as a countermeasure for the abnormal termination of the update process in the middle, there is a method of doubling the storage means and rolling back when the update fails, but a lot of computer resources are required. In this aspect, there is an advantage that many computer resources are not required.

  The present invention can be understood as a computer system having at least a part of the above means. The present invention can also be understood as a program starting method including at least a part of the above processing or a program for executing the method. Each of the above means and processes can be combined with each other as much as possible to constitute the present invention.

  According to the present invention, safe program activation in a computer can be realized at low cost.

1 is a diagram showing a schematic configuration of a computer system according to a first embodiment. The figure explaining the function which each program in a 1st embodiment has. 3 is a flowchart showing an overall processing flow from start to stop of a client terminal according to the first embodiment. The flowchart which shows the flow of the process which the server apparatus in 1st Embodiment performs. The flowchart which shows the flow of the process which the client apparatus in 1st Embodiment performs at the time of terminal activation. The flowchart which shows the flow of the process which the client apparatus in 1st Embodiment performs when a terminal stops. The figure which shows schematic structure of the computer system which concerns on 2nd Embodiment. The figure explaining the function which each program in a 2nd embodiment has. 9 is a flowchart showing an overall processing flow from start to stop of a client device according to the second embodiment. The flowchart which shows the flow of the process which the server apparatus in 2nd Embodiment performs. The flowchart which shows the flow of the process which the client apparatus in 2nd Embodiment performs at the time of terminal activation. The flowchart which shows the flow of the process which the client apparatus in 2nd Embodiment performs when a terminal stops. The figure which shows schematic structure of the computer system which concerns on 3rd Embodiment. The figure explaining the function which each program in a 3rd embodiment has. An example of the table for memorize | storing the update condition of the client apparatus which the update program management part in 3rd Embodiment has. The figure which shows the flow of a process at the time of the client apparatus stop in 3rd Embodiment. The figure which shows the flow of a process at the time of the client apparatus starting in 3rd Embodiment.

  Exemplary embodiments of the present invention will be described in detail below with reference to the drawings.

(First embodiment)
<Constitution>
FIG. 1 is a diagram showing a schematic configuration of a computer system according to the present embodiment. The computer system according to this embodiment includes a plurality of client devices 100 and a server device 200. Each client device 100 is configured to be able to communicate with the server device 200. When this system is applied to an in-vehicle system, the client device 100 corresponds to each ECU (Electronic Control Unit), and the client device 10
0 is a device with scarce computer resources. Since only one server device 200 is required in the system, the server device 200 can be configured as a device having abundant computer resources and ensuring security. The server device 200 may be added as a new device to an existing in-vehicle system, but may be implemented as one function of a device that performs general-purpose processing such as a car navigation device. Note that the computer system according to the present embodiment can be applied not only to the in-vehicle system but also to any other system.

  The client device 100 and the server device 200 are composed of a CPU (Central Processing Unit), a RAM, a ROM, a storage device, a network interface device, and the like from the viewpoint of hardware. As will be described later, it is preferable to employ a non-rewritable mask ROM as the ROM in order to prevent tampering. As the storage device, a flash memory, an HDD (Hard Disk Drive), an SSD (Solid State Drive), or the like can be adopted. Further, since the client device 100 accesses the server device 200 at the time of booting as will be described later, the client device 100 is configured to be network bootable. For example, a network interface device may be loaded with a program compliant with PXE (Preboot eXcution Environment). The server device 200 may operate as a TFTP server that distributes an appropriate program to the client device and a DHCP server (or BOOTP server) that assigns an address to the client device.

  The client device 100 is configured using as little special equipment as possible in order to reduce costs. In order to ensure security, a secure boot function may be used using a security chip having hardware tamper resistance such as TPM, but in an environment where there are a large number of client devices, it is costly to introduce special hardware to each client. Becomes higher. In the present embodiment, secure program execution and secure program update of the client device are realized without introducing hardware such as a security chip on the client device side. Since only one server device 200 is required in the system, a configuration in which security is ensured by a TPM module or the like is adopted.

  Each functional unit of the client device 100 and the server device 200 described below is realized by the CPU executing a program stored in the ROM or the storage device. However, some of these functions may be configured by dedicated hardware.

The client device 100 includes an activation program storage unit 101, an end program storage unit 102, a public key storage unit 103, an external communication unit 104, a download program development / execution unit 105, and an OS storage unit 106. The startup program storage unit 101 stores a startup program (boot program) that is executed when the client apparatus 100 is powered on. The end program storage unit 102 stores a program that is executed when the client apparatus 100 ends. The public key storage unit 103 stores the public key of the server device 200. Each of these storage units is actually mascarp. The external communication unit 104 is a functional unit that communicates with the server device 200 via a network. The download program expansion / execution unit 105 is a functional unit that verifies the signature of a program acquired (downloaded) from the server device, expands it in the RAM, and executes it. The external communication unit 104 and the download program development / execution unit 105 are realized by the CPU executing a program stored in the mask ROM.

  The OS storage unit 106 stores a system program (OS: operating system) executed by the client device 100. The OS storage unit 106 is an actual storage device. In the present embodiment, an OS program is encrypted and stored in the OS storage unit 106. In this embodiment, an example is described in which the program to be safely executed by the client apparatus is an OS program. However, the execution target program does not need to be the OS and may be an arbitrary program.

  The server apparatus 200 includes an external communication unit 201, an upload program selection unit 202, an upload program storage unit 203, an update program storage unit 206, an encryption unit 207, and an encryption method storage unit 208. The external communication unit 201 is a functional unit that communicates with the client device 100 via a network. In this embodiment, communication from the server device 200 to the client device 100 is performed by communication with an electronic signature using a public key cryptosystem. The upload program selection unit 202 is a functional unit that selects which program is transmitted to the client device 100 when a program is requested from the client device 100. The upload program storage unit 203 stores a program transmitted to the client device 100, and stores a normal boot program 204 and an update work program 205. The normal boot program 204 is a program for verifying and executing the OS program stored in the OS storage unit 106 in the client device 100. The update work program 205 is a program for acquiring a new OS program in the client apparatus 100 and storing it in the OS storage unit 106. The update program storage unit 206 stores the latest version of the OS program of the client device 100. In order to store a new version of the OS program in the update program storage unit 206, the server device 200 needs to acquire a new OS program from an external device through secure communication, but it is possible to use an authentication technique such as an electronic signature. You can achieve it. The encryption unit 207 encrypts the update program stored in the update program storage unit 206 by applying a predetermined encryption algorithm and encryption key. As the encryption method, any method such as a common key encryption method such as AES or Triple DES or a public key encryption formula such as RSA or elliptic curve encryption may be used. However, considering that the decryption process is performed before the OS program of the client device is executed, it is preferable to adopt a higher-speed common key encryption method. The encryption method storage unit 208 stores the encryption algorithm and encryption key of the encrypted OS stored in the OS storage unit 106 of the client device 100. Since the encryption algorithm and the like are different for each client device, the encryption method storage unit 208 stores the encryption algorithm and the like for the client device.

  FIG. 2 is a diagram for explaining functions of various programs in the present embodiment. FIG. 2A is a diagram for explaining functions of a program stored in the client device 100. The activation program stored in the activation program storage unit 101 has a program request function 101a, a signature verification function 101b, and an expansion program execution function 101c. The program request function 101a requests the server device 200 for a program. This program request is accompanied by a client terminal identifier (ID) and a notification that it is a program request at startup. The signature verification function 101 b verifies the signature attached to the program acquired from the server device 200 using the public key of the server device 200 stored in the public key storage unit 103. The expansion program execution function 101c is a function for expanding a program acquired from the server device 200 into a RAM and executing the program. Of course, the program is executed only when the signature verification of the acquired program is successful.

  The termination program stored in the termination program storage unit 102 has a program download function 102a, a signature verification function 102b, and an OS storage unit update function 102c. The program download function 102 a is a function for acquiring from the server device 200 an OS program encrypted with an encryption algorithm or encryption key different from the encrypted OS program stored in the OS storage unit 106. The signature verification function 102 b verifies the signature attached to the data (encrypted OS program) acquired from the server device 200 using the public key of the server device 200 stored in the public key storage unit 103. The OS storage unit update function 102c updates the OS storage unit 106 with the OS program newly acquired from the server device 200 when the signature verification is successful.

  FIG. 2B is a diagram for explaining functions of a program stored in the server device 200. The normal boot program 204 stored in the upload program storage unit 203 has an OS decryption function 204a, a program development function 204b, and a development program execution function 204c. The OS decryption function 204a is a function for decrypting the encrypted OS program stored in the OS storage unit 106 of the client apparatus 100. The OS decryption function 204a needs to correspond to the encryption algorithm and encryption key stored in the OS storage unit 106. If the decryption process is successful by the OS decryption function 204a, it can be seen that the OS program stored in the OS storage unit 106 has not been tampered with. The program expansion function 204b is a function for expanding the decrypted OS program into the RAM. The expanded program execution function 204c is a function for executing the OS program expanded on the RAM. As described above, by executing the normal boot program on the client device 100, verification and execution of the OS program stored in the OS storage unit 106 can be realized.

  The update work program 205 stored in the upload program storage unit 203 has a program download function 205a, an OS storage unit update function 205b, and a restart function 205c. The program download function 205a is a function for requesting an updated OS program from the server apparatus 200. The OS storage unit update function 205 b updates the OS storage unit 106 with the OS program newly acquired from the server device 200. The restart function 205 c is a function for restarting the client device 100.

<Operation>
Overall Process A process flow in the first embodiment will be described. First, the overall processing flow will be described with reference to the flowchart of FIG.

  When the power of the client device 100 is turned on (S101), the startup program is executed to request the server device 200 for the program (S102). The program transmitted from the server apparatus 200 to the client apparatus 100 varies depending on the situation. When there is no update program, the normal boot program 204 is transmitted, and when there is an update program, the update work program 205 is transmitted. .

  When the client device 100 acquires the update work program 205 from the server device 200 (S103), the client device 100 executes the update work program 205 to update the OS (S104). Since the computer is restarted after the update is completed (S105), the program is requested to the server again after the restart (S102).

When the OS program of the client device 100 is the latest, the normal boot program 204 is transmitted from the server device 200 to the client device (S106). The client apparatus 100 executes the normal boot program 204 to execute the OS storage unit 1
The OS program in 06 is decrypted (S107). If the decryption is successful, the OS program is executed (S108).

  When the execution of the OS program is terminated, the termination program is executed, and an OS program encrypted by a method different from that stored in the OS storage unit 106 is acquired from the server device (S109). The client device 100 stores the acquired encrypted OS in the OS storage unit 106 (S110), and ends the processing of the terminal (S111).

Processing of Server Device Hereinafter, each processing performed by the client device 100 and the server device 200 will be described in more detail. First, processing performed by the server device 200 will be described with reference to the flowchart of FIG.

  The server apparatus 200 basically repeats the process of transmitting an appropriate program in response to a program request from the client apparatus 100. When receiving the program request from the client device 100 (S201), the upload program selection unit 202 of the server device 200 determines the type of request (S202). That is, the upload program selection unit 202 determines whether the program request is for when the client terminal is activated or when the client terminal is stopped. If the program request is for starting up the terminal, the upload program selection unit 202 determines whether there is an update program (S203). If there is no update program, the normal boot program 204 having a decryption processing function for decrypting the encrypted OS stored in the requesting client terminal with reference to the encryption method storage unit 208 is stored in the client device 100. Transmit (S204). An electronic signature is assigned to the normal boot program 204 to be transmitted. On the other hand, if there is an update program as determined in step S203, the upload program selection unit 202 transmits the update work program 205 to the client device 100 (S205). An electronic signature is given to the update work program to be transmitted. Then, it waits for an update program request from the client terminal (S206). When this request is received, the latest OS program is encrypted by the encryption unit 207 (S207). The encryption method (encryption algorithm and encryption key) at this time is stored in the encryption method storage unit 208 in association with the identifier of the client terminal. The upload program selection unit 202 further transmits the encrypted program to the client terminal (S208). If it is determined in step S202 that the request type is that when the client terminal is stopped, the process proceeds to step S207, and the latest OS program is encrypted with a different encryption method and transmitted to the client terminal.

Processing of client device Next, processing performed by the client device 100 will be described. First, processing (corresponding to steps S101 to S105 and S101 to S108 in FIG. 3) performed by the client device 100 at startup will be described with reference to the flowchart in FIG.

When the power of the client device 100 is turned on (S301), first, the activation program stored in the mask is executed (S302), and a program request is made to the server device 200 by the program request function 101a (S303). The client device 100 verifies the program received from the server device 200 by the signature verification function 101b of the activation program (S304). Here, if the signature verification is not passed (S305: NO), the acquired program is not from the server device 200 or may have been tampered with, so execution of the program is stopped (S306). Note that the operation when verification fails is not particularly defined in the present invention. It may be executed again after a while or a process of notifying the administrator may be performed. If it is determined by signature verification that the acquired program is valid (S305: YES), the acquired program is expanded in the RAM and executed by the expanded program execution function 101c of the activation program (S307).

  If the program received from the server device 200 is the update work program 205, the program download function 205a requests the server device 200 for an update program (S308). Then, the new version of the OS program received from the server device 200 is stored in the OS storage unit 106 by the OS storage unit update function 205b (S309). Thereafter, the client terminal is restarted by the restart function 205c (S310). After the restart, the process returns to step S302, and the normal boot program 204 is obtained from the server device 200 in the next program acquisition.

  If the program received from the server device 200 in step S207 is the normal boot program 204, the OS decrypting function 204a decrypts the encrypted OS program in the OS storage unit 106 (S311). The decrypted OS program is expanded in the RAM by the program expansion function 204b (S312), and the expanded OS program is executed by the expansion program execution function 204c (S313). If the OS program in the OS storage unit 106 has been tampered with, the decryption process is not completed normally and tampering can be detected. Of course, if alteration is detected, the OS program is not executed. In this way, the legitimacy of the OS program to be executed can be ensured.

  Next, a process (corresponding to steps S109 to S111 in FIG. 3) performed by the client apparatus 100 at the end will be described with reference to the flowchart in FIG.

  In the client device 100, when the execution of the OS program ends (S401), the end program in the end program storage unit 102 is executed (S402). A request for the encrypted OS program is made to the server device 200 by the program download function 102a of the end program (S403). The program received from the server device 200 is verified by the signature verification function 102b (S404). Here, if the signature verification is not passed (S405: NO), the acquired program may not be from the server device 200 or may have been altered, so the update processing of the OS storage unit 106 is performed. The process ends without performing it (S406). When an illegal program is received, the program may be requested again or notified to the administrator. On the other hand, when it is determined that the acquired cryptographic OS program is valid by the signature verification (S406: YES), the program received by the OS storage unit update function 102c is stored in the OS storage unit 106.

<Operation and effect of the embodiment>
According to the present embodiment, the OS program stored in the OS storage unit can be safely executed without introducing a special device such as a security chip on the client device side. In addition, the OS program of the client device can be updated safely. Therefore, it is possible to prevent the altered program from being executed in the client device.

  The reason why safety is ensured when the client device is activated will be described in order. First, since the startup program executed when the power is turned on is stored in mass chrome and cannot be tampered with, the safety of the startup program is ensured. Therefore, there is no threat in the period from power-on to program acquisition processing (S101 to S102 in FIG. 3). Next, the program acquired from the server apparatus 200 is attached with an electronic signature of a public key cryptosystem, and is verified with the public key of the server apparatus, so that it is guaranteed that the acquired program has not been tampered with. It is assumed that the security of server device 200 is ensured. This ensures that the program acquired from the server device 200 is safe. That is, no threat exists until steps S103 and S106 in FIG.

  When starting the encrypted OS stored in the OS storage unit 106, the decryption process is performed by the normal boot program obtained from the server device 200, and the OS program is executed only when the decryption is successful. Yes. Therefore, the legitimacy of this OS program is also guaranteed (safe from S106 to S108 in FIG. 3).

  Note that the verification process for the encrypted OS acquired by the update work program is not performed. Therefore, there is a possibility that the encrypted OS that has been tampered with is stored in the OS storage unit 106 of the client device 100. However, also in this case, since the alteration can be detected when the decryption process of the encrypted OS is performed by the normal boot program, the security of the client device is ensured. Of course, it is also preferable that the update work program 205 is provided with a signature verification function so that the altered OS program is not stored in the OS storage unit 106 and the signature verification for the encrypted OS acquired from the server device 200 is performed. . However, in the present embodiment, the update process is performed when the client device is activated. Therefore, if the signature verification process is included, there is a demerit that it takes time until activation when there is an update operation. Therefore, it is only necessary to appropriately design whether or not to include a signature verification operation in consideration of security requirements and performance requirements.

  In this embodiment, since the OS program stored in the OS storage unit 106 is encrypted, the contents can be concealed from a third party. However, the normal boot program 204 including the OS decryption function 204a is communicated between the client and the server in a plain text state. Therefore, when a third party eavesdrops on the normal boot program 204, the encrypted OS stored in the OS storage unit 106 can be decrypted to know the contents. Therefore, when the client device 100 is terminated, an OS program encrypted with a different encryption algorithm or encryption key is acquired and stored in the OS storage unit 106 so that the third party can know the contents when the power is turned off. I can't.

(Second Embodiment)
In the first embodiment, since the decryption process or update process of the OS program is performed when the client device is activated, the time required for activation may become long and the request may not be satisfied. Therefore, in the present embodiment, a configuration for starting up at higher speed is provided. The biggest difference between the present embodiment and the first embodiment is that the system program (OS program) stored in the client apparatus is stored in the storage apparatus with an electronic signature attached without being encrypted. It is. The present embodiment is also different from the first embodiment in that the OS program update process is performed when the client apparatus is not started but when the client apparatus is started.

<Constitution>
FIG. 7 is a diagram showing a schematic configuration of a computer system according to the present embodiment. The computer system according to this embodiment includes a plurality of client devices 100 and a server device 200. In FIG. 7, the same reference numerals are given to the components corresponding to those in the first embodiment.

As described above, the OS storage unit 106 of the client device 100 is different from the first embodiment in that an electronic signature is added to a plain text OS program and stored. The client device 100 is also different from the first embodiment in that a communication verification unit 107 realized by a security chip (tamper resistant device) such as a TPM module is provided. In this embodiment, the communication between the client and the server is subjected to cryptographic processing so that tampering and spoofing can be prevented. Here, as the communication between the server and the client, a communication with a signature using a message authentication code (MAC) based on a common key cryptosystem is adopted. Of course, for communication between the server and the client, secret communication using a common key method or communication with a signature using a public key encryption method may be employed. Since this common key (secret key in the case of the public key method) needs to be concealed, a security chip is used for the communication verification unit 107. Although the description will be made assuming that the encryption algorithm is also stored in the security chip (in addition to the public key in the case of the public key method), the encryption algorithm may be stored in the mask ROM as long as it is not falsified.

  The server device 200 is basically the same as that of the first embodiment, but the encryption unit 207 and the encryption method storage unit 208 are omitted because the OS program is not encrypted. The upload program storage unit 203 stores a stop program 209.

  FIG. 8 is a diagram for explaining functions of various programs in the present embodiment. FIG. 8A is a diagram for explaining the function of a program stored in the client apparatus 100. The activation program stored in the activation program storage unit 101 has a program request function 101d and a program execution function 101e. The program request function 101d requests the server device 200 for a program. This program request is accompanied by a client terminal identifier (ID) and a notification that it is a program request at startup. The program execution function 101e is a function for executing a program acquired from the server device 200.

  The termination program stored in the termination program storage unit 102 has a program request function 102d and a program execution function 102e. The termination program basically has the same function as the startup program, but differs in that the program is requested to the server device 200 by notifying that the program is requested when the terminal is stopped.

  FIG. 8B is a diagram for explaining functions of a program stored in the server device 200. The normal boot program 204 stored in the upload program storage unit 203 has an OS verification function 204d and a program execution function 204e. The OS verification function 204d is a function for verifying the signature of the OS program stored in the OS storage unit 106 of the client apparatus 100. The program execution function 204e is a function for instructing execution of an OS program stored in the OS storage unit 106.

  The update work program 205 stored in the upload program storage unit 203 has a program download function 205d, an OS storage unit update function 205e, and an OS verification function 205f. The program download function 205d is a function for acquiring an updated OS program from the server device 200. The OS storage unit update function 205e is a function of storing the acquired OS program in the OS storage unit 106. The OS verification function 205f is a function for verifying the signature of the acquired OS program and determining whether the OS program is valid.

  The stop program 209 stored in the upload program storage unit 203 is a program that performs substantially no processing.

Note that there are two cases as signature verification operations. One is signature verification for a program acquired from the server device by the communication verification unit 107 of the client device 100. The other is signature verification for the OS program in the OS storage unit 106 by the normal boot program 204. The signature verification operation by the communication verification unit 107 cannot be changed because it is burned in a ROM (security chip). Therefore, a highly versatile cryptographic algorithm is adopted, and a long key length is set for long-term operation. Therefore, the verification process by the communication verification unit 107 is an algorithm with a relatively low speed. On the other hand, since the signature verification for the OS program is included in the program acquired from the server device, it can be arbitrarily changed. Therefore, a high-speed encryption algorithm may be selected at that time.

<Operation>
Overall Process A process flow in the second embodiment will be described. First, the overall processing flow will be described with reference to the flowchart of FIG.

  When the client apparatus 100 is powered on (S501), the startup program is executed, and a boot program is requested and acquired from the server apparatus 200 (S502). The signature of the OS program is verified by the obtained boot program (S503), and if the verification is passed, the execution of the OS program is started (S504). When the client device 100 is terminated (when the OS program is terminated), the termination program is executed to request the server device for the program (S505). If the OS program is not updated, a stop processing program is transmitted from the server device, and the client device 100 terminates without performing any further processing. On the other hand, if there is an update of the OS program, a program for update work is transmitted from the server (S507). The client apparatus 100 updates the OS program using this update work program (S508), and stops the execution when the update is completed normally (S509: YES). If the update has failed (S509: NO), the OS is updated again.

  As described above, in the present embodiment, the OS program is verified by digital signature verification when the client device is activated, and the OS program update operation is performed when the client device is stopped.

Processing of Server Device Hereinafter, each processing performed by the client device 100 and the server device 200 will be described in more detail. First, processing performed by the server apparatus 200 will be described with reference to the flowchart of FIG.

  The server device 200 basically repeats the process of receiving a program request from the client device 100 and transmitting an appropriate program. When receiving the program request from the client device 100 (S601), the upload program selection unit 202 of the server device 200 determines the type of request (S602). If the program request from the client device is a request for a boot program, that is, a program request when starting the client device, the upload program selection unit 202 transmits the normal boot program 204 to the client device 100 (S603). The normal boot program 204 is sent with an electronic signature to the client apparatus 100. On the other hand, when the program request from the client apparatus 100 is an update program request, that is, a client apparatus stop program request, the upload program selection unit 202 determines whether there is an update program (S604). If there is no update program, the upload program selection unit 202 transmits the stop program 209 to the client device 100 (S605). On the other hand, if there is an update program, the update work program 205 is transmitted to the client apparatus 100 (S606). After the update work program 205 is transmitted, it waits for an update program transmission request from the client apparatus 100 (S607), and receives the request and transmits the update program to the client apparatus 100 (S608).

Processing of client device Next, processing performed by the client device 100 will be described. First, processing (corresponding to steps S501 to S504 in FIG. 9) that the client device 100 performs at startup will be described with reference to the flowchart in FIG.

  When the client apparatus 100 is powered on (S701), first, the activation program stored in the mask is executed (S702), and a program request is made to the server apparatus 200 by the program request function 101d (S703). Since the program request at the time of starting the client device requests the normal boot program 204, the client device 100 acquires the normal boot program 204 from the server device. In order to verify the validity of the acquired normal boot program 204, the communication verification unit 107 performs signature verification (S704). If the signatures do not match and there is a risk of falsification or impersonation (S705: NO), the execution of the program is stopped (S706). Note that the operation when verification fails is not particularly defined in the present invention. It may be executed again after a while or a process of notifying the administrator may be performed. When it is determined that the acquired program is valid by the signature verification (S705: YES), the normal boot program 204 acquired by the program execution function 101e is executed (S707).

  When the normal boot program 204 is executed, signature verification of the OS program stored in the OS storage unit 106 is performed by the OS verification function 204d (S708). If the signature verification is not passed (S709: NO), the OS program in the OS storage unit 106 may be falsified, and the process is terminated without executing the program (S710). On the other hand, if the signature verification is passed (S709: YES), the OS program in the OS storage unit 106 is executed by the program execution function 204e included in the normal boot program 204 (S711).

  Next, processing (corresponding to steps S505 to 510 in FIG. 9) performed by the client device 100 at the end will be described with reference to the flowchart in FIG.

  In the client device 100, when the execution of the OS program ends (S801), the end program in the end program storage unit 102 is executed (S802). A program request is made to the server device 200 by the program request function 102d of the end program (S803). For the program received from the server apparatus 200, the communication verification unit 107 performs signature verification processing (S804). If verification of the received program fails (S805: NO), there is a possibility of falsification or impersonation, and the program is terminated without executing it (S806). On the other hand, when the received program has been successfully verified (S805: YES), the program is executed by the program execution function 102e (S806).

  If it is not necessary to update the OS program, a stop program 209 that does not perform any processing is sent from the server device 200, so that the client device 100 terminates without performing any processing. (S812).

  On the other hand, when the OS program needs to be updated, an update work program 205 is transmitted from the server device 200. When this program is executed, a new OS program is requested to the server apparatus 200 by the program download function 205d included in the update work program 205 (S807). The client device 100 stores the received OS program in the OS storage unit 106 by the OS storage unit update function 205e (S808), and verifies the signature of the program in the OS storage unit 106 by the OS verification function 205f (S809). If the OS program has been tampered with and the verification has failed (S810: NO), the server apparatus 200 is requested again for an update program. On the other hand, if the verification of the OS program is successful (S810: YES), the process is terminated as it is (S811).

<Operation and effect of the embodiment>
This embodiment can also be executed while guaranteeing the legitimacy of the OS program. First, since the startup program that is executed when the power is turned on is stored in mass chrome and cannot be tampered with, safety up to this point is guaranteed. The boot program obtains a normal boot program from the server device, but since the signature is verified by the communication verification unit, there is no possibility of spoofing or tampering with communication with the server. Note that the communication verification unit itself is safe because it is composed of a security chip, and the server device is also secure on the premise. Therefore, the validity of the acquired normal boot program is guaranteed. Since the signature of the OS program is verified by the normal boot program for which the validity is guaranteed, and the verification is successful, the OS program is executed, the validity of the OS program to be executed is also guaranteed.

  In this embodiment, since the OS program is verified by signature verification, the OS can be started at a higher speed than in the first embodiment in which decryption processing is performed. Since the OS program update process is also performed when the client apparatus is stopped, the client can be started up at high speed.

  The signature verification process is performed on the program obtained from the server device and on the OS program in the OS storage unit. Here, since the signature verification processing for the program obtained from the server device is burned in a ROM (security chip) and cannot be changed and needs to be operated for a long period of time, the algorithm is highly versatile and the key length is increased. In other words, the verification process for the acquired program requires an algorithm with a relatively low speed. However, since the signature verification process of the OS program is included in the normal boot program obtained from the server device, a high-speed algorithm can be selected at that time. Of the boot program and OS program acquired from the server device, the OS program generally has a larger capacity. Since a high-speed algorithm can be applied to a large-sized OS program, the overall verification time becomes shorter.

(Third embodiment)
In the first and second embodiments, the OS program update process is performed, but if this update process ends abnormally, the program in the storage unit is partially rewritten and partly remains inconsistent. It becomes. When such a situation occurs, it is determined that the OS program is inspected by decryption processing or signature verification, and the program cannot be started. In order to cope with such a situation, it is conceivable to store the old program by doubling the storage of the client device, but it requires a lot of computer resources and the cost increases. Therefore, in this embodiment, without requiring a large amount of computer resources in the client device, it is possible to start up safely (resume the update process) even when the update process of the OS program fails.

<Constitution>
FIG. 13 is a diagram showing a schematic configuration of a computer system according to the present embodiment. Since this embodiment has a configuration similar to that of the first and second embodiments, different portions will be mainly described. The computer system according to the present embodiment includes a plurality of client devices 300 and a server device 400. Each client device 300 is configured to be able to communicate with the server device 400.

The client device 300 includes a start program storage unit 301, an end program storage unit 302, an external communication unit 304, an update program development unit 305, an OS storage unit 306, an OS inspection unit 308, and an encryption processing unit 307. The start program storage unit 301 and the end program storage unit 302 store a start program and an end program, which are programs executed when the client device 300 is started and stopped, respectively. These storage units are actually machrome. The OS storage unit 306 is a storage device and stores an OS program. In this embodiment, the OS program is stored in the OS storage unit 306 in a plain text state without being encrypted or digitally signed. The external communication unit 304 is a functional unit that communicates with the server device 400 via a network. The update program expansion unit 305 expands the new OS program acquired from the server device 400 in the OS storage unit 306. The OS inspection unit 308 has a function of obtaining a hash value of a predetermined address in the OS storage unit 306. The external communication unit 304, the update program development unit 305, and the OS inspection unit 308 are realized by the CPU executing a program stored in the mask. The encryption processing unit 307 is realized by a security chip (tamper resistant device) such as a TPM module, and performs secret communication with the server apparatus 400. In this embodiment, communication between the client and the server is performed by secret communication using a common key method.

  Note that it is not necessary to configure all of the cryptographic processing unit 307 with a tamper resistant device. Shared key (private key if public key cryptosystem is adopted) must be concealed and must be stored in a tamper-resistant device, but encryption algorithm (and public key if public key cryptosystem is adopted) Since it is sufficient if it is not altered, it is sufficient to store it in a mask ROM. By adopting such a configuration, it is possible to minimize the introduction of a tamper resistant device and suppress an increase in cost.

  FIG. 14 is a diagram for explaining the functions of the start program and the end program stored in the start program storage unit 301 and the end program storage unit 302 of the client device 300. The activation program address inquiry function 301a is a function for inquiring the server apparatus 400 about the OS program inspection target address (address for obtaining a hash value). The hash value calculation function 301 b is a function unit that calculates a hash value for an address acquired from the server device 400 using the OS inspection unit 308. The hash value transmission function 301 c is a function for transmitting the calculated hash value to the server device 400. The OS execution function 301d is a function for acquiring a response to the hash value transmission from the server device 400 and executing the OS program in the OS storage unit 306 when it is determined that the hash value is correct.

  The program download function 302 a for the end program is a function for acquiring an updated version of the OS program from the server device 400. The OS storage unit update function 302 b is a function that stores an updated OS program acquired from the server device 400 in the OS storage unit 306. As will be described later, since the updated OS program is divided from the server device 400 and transmitted in units of blocks, the client device 300 also performs acquisition / update processing in units of blocks. The update completion notification function 302c is a function for notifying that the update of the OS storage unit 306 is completed in units of blocks.

  The server device 400 includes an external communication unit 401, an update program management unit 402, an examination site determination unit 403, an update program storage unit 404, a client program storage unit 405, and an encryption processing unit 406. The external communication unit 401 is a functional unit that communicates with the client device 300 via a network. Communication with the client device 300 is concealed by the encryption processing unit 406. The update program management unit 402 is a functional unit that performs OS program update processing and update status management (grasping) for the client device 300. The update program storage unit 404 stores the latest version of the OS program when the OS program executed in the client device 300 is updated. The client program storage unit 405 stores the OS program before update. The server device 400 is configured using a security chip or the like as a whole to ensure security.

  The update program management unit 402 will be described in more detail. The update program management unit 402 divides the update program into sizes that can be received by the client device 300 at a time and transmits the update program. Further, the update program management unit 402 manages completion / uncompletion of rewriting of each block in the client device 300. FIG. 14 is an update status table held by the update program management unit 402. The update program management unit 402 stores the update status of the client device 300 using the update status table. In this update status table, for each block ID 402a, the address 402b in the corresponding update program storage unit, the sent field 402c indicating whether or not the update program has been transmitted from the server device to the client device, and the rewritten from the client device A rewritten field 402d indicating whether or not a notification has been received is included. It is understood that the block in which both the sent field 402c and the rewritten field 402d are “completed” has been updated in the client device, and a new program is stored in this block in the OS storage unit 306. . On the contrary, it can be seen that the update is incomplete in the client apparatus in the block in which both are “not implemented”, and the old program is stored in this block in the OS storage unit 306. With respect to a block in which the sent field 402c is “completed” and the rewritten field 402d is “not implemented”, it is impossible to grasp whether or not the block has been updated in the client device. The examination site determination unit 403 is a functional unit that determines which address of the hash value is requested from the client device 300 based on the update status obtained from the update program management unit 402. The examination site determination unit 403 randomly determines an address of a hash value calculation target from the addresses of the client device 300 whose contents can be grasped by the server device 400. The examination site determination unit 403 refers to the update program storage unit 404 and the client program storage unit 405 to calculate a correct hash value at the specified address.

<Operation>
-When the client is stopped (update processing)
The flow of processing in the third embodiment will be described. First, update processing at the end of the client device will be described with reference to FIG.

  When the execution of the OS program ends in the client device 300 (S901), the end program in the end program storage unit 302 is executed, and the server device 400 is inquired of the server device 400 by the program download function 302a (S902). . Upon receiving this request, the update program management unit 402 of the server device 400 determines whether there is an update program to be transmitted to the client device 300 (S903). If there is no update program (S903: NO), the client device 300 is notified of this, and the client device 300 stops without performing any further processing (S904).

When there is an update program (S903: YES), the update program management unit 402 encrypts a part of the update program divided into blocks and transmits it to the client device 300 (S905). When the transmission is completed, the update program management unit 402 sets the transmission completed field 402c of the transmitted block to “completed” and stores the transmission to the client device. The client apparatus 300 receives the update program and updates the OS storage unit 306 by the OS storage unit update function 302b of the end program (S906). When the update of the OS storage unit 306 is completed, the update completion notification function 302c encrypts the fact that the block has been updated and transmits it to the server device 400 (S907). Upon receiving this update completion notification, the update program management unit 402 sets the rewritten field of this block to “completed” and stores that the update has been completed in the client device (S908). The update program management unit 402 determines whether or not the update has been completed for all the blocks of the update program. If there is an unprocessed block (S909: NO), the transmission is repeated.
When the update of all the blocks is completed (S909: YES), the client apparatus 300 is notified that the update process is completed (S910). The client device 300 stops upon receiving this notification (S911, S912).

  In this way, the update program is divided into block units and transmitted to the client apparatus 300, and the process proceeds while confirming the update completion by the update completion notification. Therefore, the client apparatus 300 may be powered off during the update process. Even if it occurs, the server apparatus 400 can grasp to which address update processing has been completed. For example, a case where the update status table of the update program management unit 402 is shown in FIG. 15 will be described as an example. Regarding the block IDs 0x0001 and 0x0002, since both the sent field 402c and the rewritten field 402d are “completed”, it can be seen that the update program is transmitted to the client device and the OS storage unit 306 is actually updated. . For the block ID 0x0003, the sent field 402c is “completed”, but the rewritten field 402d is “not implemented”. Regarding this block, the server device cannot determine the state in the OS storage unit 306 of the client device. There may be a situation where the OS storage unit 306 is not updated, and there may be a case where the OS storage unit 306 has been updated but an update completion notification has not been transmitted. For block ID 0x0004 and later, since the sent field 402c is “not implemented”, it can be seen that the OS storage unit 306 of the client device 300 is in a state before update. In this way, by referring to the update status table, it is possible to grasp whether or not all the update operations have been normally completed for each client device, and to what block the update has been completed if not all have been completed. .

-When the client is started (program execution / update process restart)
Next, processing when the client device 300 is activated will be described with reference to the flowchart of FIG.

  When the client device 300 is activated (S1001), the activation program is executed, and the address inquiry function 301a inquires the server device 400 which address in the OS storage unit 306 is to be inspected (S1002). Upon receiving this request, the update program management unit 402 of the server device 400 refers to the update status table, randomly selects an inspectable address, and notifies the client device 300 of it (S1003). The address that can be inspected is an address (block) whose state is known by the server device. More specifically, both the sent field 402c and the rewritten field 402d are “completed” or both in the update status table. The address is “not implemented”.

The client device 300 calculates a hash value using the OS checking unit 308 for the address specified by the server device 400, and transmits the hash value to the server device 400 (S1004). The server device 400 that has received the hash value calculated in the client device 300 verifies whether or not the hash value matches the assumed value, and verifies the validity of the client device 300 (S1005). Since the update program management unit 402 knows the state of the OS storage unit 306 of the client device 300, a correct hash value can be calculated for the designated address. If the hash value transmitted from the client device 300 is different from the assumed value (S1006: NG), the client device 300 determines that the client device 300 is an unauthorized terminal and notifies that authentication has failed (S1007). On the other hand, if the value matches the value transmitted from the client device 300 (S1006: OK), it can be determined that the client device is valid. At this time, the update program management unit 402 refers to the update status table to determine whether there is an incomplete part of the update process in the client device (S1008). If there is no incomplete part (S1008: NO), the server device 400 transmits a notification of successful authentication and a notification that the OS program in the OS storage unit 306 should be executed to the client device 300 (S1009). ). On the other hand, if there is an incomplete part in the update process, that is, if the update process is in progress (S1008: YES), the server apparatus 400 resumes the authentication success notification and update process to the client apparatus 300. A notification to the effect is transmitted (S1010).

The client device 300 receives the authentication result from the server device 400 (S1011). If the authentication fails (S1012: NG), the program execution is stopped (S1013). When the authentication is successful (S1012: OK), the operation according to the instruction from the server device 400, that is, the execution of the OS program or the resumption of the update work is performed (S1014).
<Operation and effect of the embodiment>
In this embodiment, the validity of the client device is determined by verifying the hash value of the OS program in the client device 300. When the OS program is falsified in the client device 300, the hash value is different from the assumed value, so that falsification can be detected. Since the hash value calculation target address is determined at random, an attack in which the communication between the client and the server is eavesdropped and the same value as the hash value included therein can be prevented can be prevented.

  Furthermore, in the present embodiment, even if the update operation of the OS program of the client device is interrupted in the middle, the update status is grasped on the server device side, so that the validity can be verified by the hash value. is there. That is, even when the update operation is interrupted, the validity of the client device can be verified and the update process can be resumed.

DESCRIPTION OF SYMBOLS 100,300 Client apparatus 200,400 Server apparatus 101,301 Startup program storage part 102,302 End program storage part 106,306 OS storage part 202 Upload program selection part 203 Upload program storage part 204 Normal boot program 205 Update work program 308 OS inspection unit 402 Update program management unit 403 Inspection site determination unit

Claims (17)

A computer system composed of a client device and a server device that can communicate with each other,
The client device includes a first storage unit that stores a boot program that is a program that is executed when the device is started, and a second storage unit that stores a program to be executed.
The server device has storage means for storing a verification program for verifying the execution target program,
The boot program includes processing for acquiring and executing a program from a server device,
In response to a request from the client device boot program, the server device transmits the verification program to the client device,
The client system verifies the execution target program using the acquired verification program, and executes the program after the verification is successful. The execution target program is stored in the second storage means in an encrypted state,
The computer system according to claim 1, wherein the verification program includes a process of decoding a program to be executed. When the execution of the execution target program ends, the client device stores the execution target program encrypted using a different encryption algorithm or different encryption key from the execution target program stored in the second storage unit. Having a function of acquiring from the server device and storing in the second storage means;
The server device stores an encryption algorithm and an encryption key for decrypting an execution target program transmitted to the client device, and then when a program request is received from the boot program of the client device, the client device The computer system according to claim 2, wherein a verification program corresponding to an execution target program stored in the apparatus is transmitted to the client apparatus. When updating the program to be executed,
The server device, when requested by the boot program of the client device, transmits a program for restarting after storing a new execution target program in the second storage means to the client device. The computer system according to claim 2 or 3. The execution target program is stored in the second storage unit with an electronic signature added thereto,
The computer system according to claim 1, wherein the verification program includes a process of verifying an electronic signature of a program to be executed. The client device has a stop processing program including a function of requesting a program to the server device at the end of execution of the execution target program;
When the server device updates the execution target program when a program request is received from the stop processing program of the client device, the server device restarts after storing the new execution target program in the second storage unit The computer system according to claim 5, wherein a program for performing is transmitted to the client device. The server device adds an electronic signature to the verification program and sends it to the client device,
The computer system according to claim 1, wherein the boot program includes a process of verifying an electronic signature of the acquired verification program. The first storage means is a non-rewritable nonvolatile memory,
The computer system according to claim 1, wherein the second storage unit is a rewritable nonvolatile memory. A computer system composed of a client device and a server device that can communicate with each other,
The client device includes a first storage unit that stores a boot program that is a program that is executed when the device is started, and a second storage unit that stores a program to be executed.
The server device is a management unit that manages the state of the program stored in the second storage unit of the client device, and that the client device requests a hash value for a predetermined address from the client device and is correct that can be determined from the management unit A determination unit that determines whether or not the hash value matches, and notifies the client device;
The boot program has a function of acquiring a target address for calculating a hash value from the server device, obtaining a hash value for the acquired address, and transmitting the hash value to the server device. A computer system that executes an execution target program stored in the second storage means after receiving the data.   The computer system according to claim 9, wherein the communication between the client device and the server device is performed by secret communication or communication with a signature. When updating the program to be executed,
The server device divides a new execution target program and sends it to the client device one by one,
When the client device completes rewriting of the second storage means with the acquired update program, the client device notifies the server device of a completion notification indicating that,
The management unit of the server apparatus manages an address area in which update is completed in the client apparatus, an address area in which update is not completed, and an address area in which update completion / uncomplete is unknown. 10. The computer system according to 10.   12. The determination unit according to claim 11, wherein the determination unit randomly determines an address for which a hash value is to be calculated, from an address area that is known to be updated or not updated by the management unit. Computer system. When the server device determines that the update processing of the execution target program in the client device is incomplete when it is determined that the hash value transmitted from the client device is correct, the server device updates The computer system according to claim 12, wherein the processing is resumed. In a computer system composed of a client device and a server device that can communicate with each other, a program starting method for starting an execution target program stored in storage means of a client device,
The client device acquires a program from the server device by a boot program executed when the device is started,
The server device transmits a program for verifying the execution target program to the client device in response to the program request from the client device,
A client apparatus verifies an execution target program by using an acquired verification program, and executes the execution target program after the verification is successful. The execution target program is stored in the storage means in an encrypted state,
The program starting method according to claim 14, wherein the verification program includes a process of decoding the execution target program. The execution target program is stored in a storage unit with an electronic signature added thereto,
The program activation method according to claim 14, wherein the verification program includes a process of verifying an electronic signature of an execution target program. In a computer system composed of a client device and a server device that can communicate with each other, a program starting method for starting an execution target program stored in storage means of a client device,
The server device manages the state of the program stored in the storage means of the client device,
The client device acquires a target address for calculating a hash value from the server device by a boot program executed at the time of starting the device, calculates a hash value of the address, and transmits the hash value to the server device.
The server device determines whether or not the hash value transmitted from the client device matches the correct hash value, and notifies the client device,
The client apparatus executes a program to be executed after receiving a notification from the server apparatus that the hash value is correct.

Images