Method and means for securing or verifying respectively a program that can be executed in a data processing unit
The invention relates to a method of securing or verifying respectively a program that can be executed in a data processing unit, in particular in a central arithmetic unit, which program is formed by a number of commands. The invention furthermore relates to an apparatus for creating a security measure for a program that can be executed in a data processing unit, in particular in a central arithmetic unit, which program is formed by a number of commands. The invention furthermore relates to a data processing unit, in particular a central arithmetic unit, for securely running and executing an executable program, and also to a data carrier comprising such a data processing unit.
A method of securing or verifying respectively programs that can be executed in a data processing unit, in particular in a central arithmetic unit, is known for example from patent document EP-A 0 977 160. In this known method and this known data processing unit or data processing arrangement for securely executing such a program, it is to be assumed that the content of a program memory is verified in each case after a sequence of commands forming the program has been carried out and following a request, triggered by software for example, at predefined points during the running of the program, wherein this known method aims to protect program parts, prior to execution of the program, against manipulation of the program. A disadvantage of this known method and the known data processing arrangement ■ is that it is only possible to detect manipulations of a program prior to execution of a program in the data processing unit, said program being stored for example in a ROM. In this way only a whole program or whole program parts or program sections are secured or securable. Moreover, it is known to use error detection codes, for example to ensure the integrity of data. Such data may be data within the context of a database entry, for example a piece of music on a CD, or else a program code of a given program, as it is the case in the abovementioned patent document EP-A 0 977 160. In connection with virus checking, a verification value is calculated for each program or each data record, so that it is subsequently possible to ascertain, during a verification, whether a certain data content or
program code has been changed. In connection with a possible attack on or possible manipulation of data or a program or an item of software, an attempt may be made to alter or remove respectively individual program constituents, wherein in the case of an item of commercial software the aim is for example to remove program elements or program codes which verify a valid license. In order to ascertain such a manipulation, the error detection code of the program or of the data can be verified before the program is executed, as proposed for example in the abovementioned patent document EP-A 0 977 160. It is furthermore known that a manipulation of data or program codes respectively may be attempted or carried out immediately prior to execution of a program in a data processing unit, in particular in a central arithmetic unit, and in particular following a verification for example in a memory. Such a manipulation may be carried out by physical means outside a data processing unit, wherein such a manipulation cannot be detected if it takes place immediately prior to execution of the program in the data processing unit and thus after any verification in a memory that may have taken place.
It is an object of the invention to provide a method of the type mentioned above and an apparatus of the type mentioned above and a data processing unit of the type mentioned above, in which the abovementioned difficulties are avoided and in particular a verification of commands of a program that can be executed in a data processing unit, in particular in a central arithmetic unit, can be carried out immediately prior to the execution of executable commands of a program. In order to achieve the abovementioned objects, in a method of securing or verifying respectively a program that can be executed in a data processing unit, in particular a central arithmetic unit, which program is formed by a number of commands, it is provided that an error code or check code respectively is generated for each command and the check code is added to each command and, immediately prior to the execution of a command in the data processing unit, a verification of the check code is carried out in the data processing unit and, once the authenticity of the executable command has been confirmed, the command is executed in the data processing unit. In order to achieve the abovementioned objects, in an apparatus for creating a security measure for a program that can be executed in a data processing unit, in particular in a central arithmetic unit, which program is formed by a number of commands, it is provided that the apparatus comprises a device for generating the commands of the program that can
be executed in the data processing unit, in particular in a central arithmetic unit, and a device for generating at least one error code or at least one check code for each command of the program and for adding the at least one check code to the respective command. In order to achieve the abovementioned objects, in a data processing unit, in particular in a central arithmetic unit, for securely running and executing an executable program, which program is formed by a number of commands, it is provided that the data processing unit comprises a device for executing executable commands that are fed to it, and also a device for verifying and confirming at least one check code, which at least one check code is added to each executable command of a program. In order to achieve the abovementioned objects, a data carrier comprising such a data processing unit is designed as a smart card which comprises a chip that contains the data processing unit. Providing the features according to the invention of the method according to the invention means that each command of a large number of executable commands of a program is provided with an error code or check code, wherein the check code which is added to each command is verified by and prior to execution of said command in said data processing unit, and said command is executed in the data processing unit only once the authenticity of the command that is to be executed has been confirmed. Even if a manipulation is carried out for example during the transmission of an executable command from a memory, in particular to a program memory, to a data processing unit, in particular a central arithmetic unit, this manipulation or attack respectively can be detected since a verification of the added check code is carried out in the data processing unit immediately prior to execution of this command. It is to be assumed that it is sufficient to do with a small number of bits of a check code that are to be added to an executable command, so that the memory space additionally required to store or accommodate the check code can be kept small. Moreover, by virtue of the verification of the check code directly in the data processing unit prior to execution of the command that is to be executed, proposed by the invention, such a verification of the check code can be carried out by the data processing unit so that no additional time is required. Such a verification in the data processing unit requires only slight alterations or additions to a processor contained in a data processing unit, so that also the costs in this respect are not increased by the use of the method according to the invention. The invention thus also provides a simple data processing unit, in particular a simple central arithmetic unit, for verifying and executing secure executable commands of a
program. A data carrier comprising such a data processing unit is in this case designed in a simple and advantageous manner as a smart card. Moreover, it is possible to make do with a simple apparatus according to the invention for creating a security measure for the commands of a program that can be executed in a data processing unit, since for example the apparatus according to the invention may be formed by a compiler or linker in which the check code for each command is automatically generated and at the same time added during translation of the program from a programming language into so-called machine instructions. The apparatus according to the invention for creating a security measure for commands of a program that can be executed in a data processing unit, in particular in a central arithmetic unit, is thus likewise very simple and does not entail any disadvantageous effects, caused by the generation and adding of a check code to each command that is to be executed, in terms of the performance and handling or usability by a user. According to the measures of claim 2, the advantage is obtained that, using simple method steps, a reliable verification and verification of the check code can be carried out in the data processing unit, in particular in a central arithmetic unit. It is furthermore ensured that the command that is to be executed is executed in the data processing unit only once the authenticity of the command has been confirmed by its comparison with the additional check code, which check code is generated in the data processing unit in a manner corresponding to the generation of the check code in the compiler or linker or the apparatus for creating a security measure for the executable command. According to the measures of claim 3, the advantage is obtained that a respective command-specific check code is generated in a simple manner and independently of the content of the executable command, so that, in the case where a manipulation is carried out on a command or parts of a command, this manipulation can immediately be detected on account of the fact that a confirmation of the authenticity of the command that is to be executed is not received in the data processing unit since coincidence or verification of the check code could not be achieved. Instead of generating the check code by gating individual bits of an executable command, use could be made of modified generation methods for generating check codes, for example for a CRC (Cyclic Redundancy Check), although these generation codes may possibly not be generated in a command-specific manner. Even with such check codes which may possibly not be command-specific, it is possible to achieve a certain degree of security since it is to be assumed that in each case all the bits of an attacked command are changed for
example in the event of an attack or manipulation by physical means on an executable command, or the bits of an attacked command are changed in a randomly distributed manner. It is thus to be assumed that the bits of a check code that are added to an executable command are subject to such a complete or partial random change, so that manipulations only on the executable command without affecting the check code are not possible or are rarely possible. In this way it is sufficient to do with non-command-specific check codes or codes which are not generated directly from gating individual bits of an executable command. According to the measures of claims 4 and 8, a further improvement in the securing of executable commands of a program is made possible since, even if it should be possible during a manipulation of the command, in the case of command-specific codes, also to change the check code at the same time in accordance with the generation algorithm used during generation of the check code and verification of the same, an encryption code is additionally taken into account, which encryption code cannot be affected when a manipulation is carried out. According to the measures of claims 5 and 10, if an encryption is provided in order to increase security when check codes are generated for each executable command of a program, a corresponding decryption or new encryption for generating an additional check code for confirming the authenticity in the data processing unit, in particular in the central arithmetic unit, immediately prior to executing the executable command is made possible in a simple manner.
The invention will be further described with reference to an example of embodiment shown in the drawings to which, however, the invention is not restricted. Fig. 1 shows a flowchart relating to the essential steps of the method according to the invention for securing or verifying respectively commands of a program that can be executed in a data processing unit. Fig. 2 shows a flowchart relating to the method steps according to the invention for verifying the check code of an executable command. Fig. 3 schematically shows, in the form of a block diagram, part of a data processing unit according to the invention.
Fig. 4 shows a block diagram and a flowchart relating to the verification of the check code of an executable command, said verification being carried out in the data processing unit according to the invention.
Fig. 3 shows part of a data processing unit 1, in particular a central arithmetic unit, in which a method for transmitting and verifying executable commands is carried out. An instruction to generate an address of a next executable command is delivered to an address generator 4 from a sub-area 2 of the data processing unit 1 via a connection 3. This address is generated and delivered to a memory 6 via a connection 5, wherein the memory 6 receives the address and transmits the data stored at this address or the executable command stored at this address to the data processing unit 1 via a connection 7. The executable commands stored in the memory 6 are in each case provided with a first check code, as explained below with reference to Fig. 1. The executable command passes from the memory 6, via the connection 7, to a device 8 for verifying and confirming the first check code or error code respectively, as explained in more detail below with reference to Fig. 4. If a verification in the device 8 confirms the authenticity of the executable command, execution takes place in a sub-area or device 9 respectively of the data processing unit 1. Besides the devices 8 and 9, the data processing unit 1 also comprises other components or elements which are not shown in detail. A program is executed in the data processing unit 1 as shown in the flowchart shown in Fig. 1, wherein a conversion of commands of a program existing in a programming language into executable machine instructions or machine commands which can be executed in the data processing unit 1 is carried out for example by means of a compiler or linker in a block Bl and therein a sub-block Bl A. At the same time, generation of the first check code for each executable command generated in area B 1 A is carried out in block B 1 and therein a sub-block BIB, wherein the generated first check code is immediately added to the executable command. Where necessary, an encryption may also be carried out in a block BIC or else a key can be added in block BIC during determination or generation of the first check code. One example of the generation of a first check code for each command that is to be executed will be described below in the case of both with and without encryption. Following generation of the executable command in machine language and adding of the first check code in block Bl, in a block B2 storage takes place in a memory for
example, as has already been explained with reference to Fig. 3. In order to execute a program or individual executable commands of the program, in block B3 the commands are transmitted to the data processing unit 1, and then in a block B4 a verification of the first check code is carried out, as shown in detail in Fig. 2. Once authenticity of the executable command has been confirmed, the executable command is executed in the data processing unit 1 according to a block B5. A first check code or error code respectively is generated for example in that generation of the first check code is carried out as a function of the content of an executable command, which is to be secured and subsequently verified immediately prior to execution in the data processing unit 1, on the basis of the bits of the executable command or machine instructions, as described below. In the example described below, it is assumed that the executable command consists of 32 bits, wherein the 32 bits are subdivided into eight (8) groups of four (4) bits each. Moreover, it is assumed that the first check code has a predefined length of four (4) bits. In order to generate the first check code or error code respectively, the eight (8) groups of four (4) bits each are in each case gated in accordance with an XOR function, giving the following result: b31 b30 b29 b28 XOR b27 b26 b25 b24 XOR b23 b22 b21 b20 XOR bl9 bl8 bl7 bl6 XOR bl5 bl4 bl3 bl2 XOR bll blO b09 b08 XOR b07 b06 b05 b04 XOR b03 b02 bOl bOO c03 c02 cOl cOO
The resulting first check code or the resulting checksum thus contains the four (4) bits c03, c02, cOl and cOO. Once an executable command has been transmitted to the data processing unit 1, as has been explained with reference to Fig. 3, the first check code is removed from the executable command in a block B6 in order to verify the authenticity of the executable command by verifying the first check code as shown in the flowchart in Fig. 2, whereupon according to a block B7 generation of an additional second check code, which is independent of the first check code, takes place in the data processing unit 1 immediately prior to execution of the command, in accordance with the rules for generating the first check code used in block B 1. Depending on whether a key is or is not provided in block B 1 C, an encryption code or key for generating the second check code is removed according to a block B7C, which corresponds to block BIC. Following generation of the second check code according to block B7, in a block B8 the second check code generated according to block B7 is compared with the first check code which was originally generated by the compiler or linker respectively and was removed in block B6, wherein, if according to block B8 coincidence is ascertained between the original first check code and the second check code generated in the data processing unit, further execution of the executable command is carried out according to block B5, as shown in the flowchart of Fig. 4. The generation of the second check code according to in block B7 is carried out analogously to the abovementioned gating example for generating the first check code, which consists of the bits c03, c02, cOl and cOO. As mentioned above, in order to increase security, a key or encryption may additionally be provided according to block BIC. Assuming that a command once again consists of 32 bits which are subdivided into eight (8) groups of four (4) bits each, and providing a key with four (4) bits kOl, k02, k03 and k04 in block BIC, using the above gating rule for generating the first check code the following result is obtained:
b31 b30 b29 b28 XOR b27 b26 b25 b24 XOR b23 b22 b21 b20 XOR bl9 bl8 bl7 bl6 XOR bl5 bl4 bl3 bl2 XOR bll blO b09 b08 XOR b07 b06 b05 b04 XOR b03 b02 bOl bOO XOR kOl k02 k03 k04 c03 c02 cOl cOO
In order to confirm the authenticity of the executable command, as explained with reference to Fig. 2, following removal of the first check code the second check code is determined in the data processing unit 1 using the key kOl, k02, k03 and k04 in block B7C in accordance with the above gating rule. Fig. 4 schematically shows that verification of the first check code is carried out according to a block BIO on account of an executable command read from the memory (not shown in any more detail) and fed to the device 8 via the connection 7, wherein this verification takes place for example by carrying out the method steps shown in Fig. 2. According to a block Bl 1, the authenticity or validity of the first check code is verified for example by means of a comparison between a second check code that is additionally generated and the first check code originally added to the command, as shown in Fig. 2. If a positive or "yes" check result is obtained, that is to say the authenticity of the first check code and thus of the overall executable command is confirmed, in a block B 12 the executable command is transmitted to the downstream execution apparatus or device 9 for
executing the executable command. If a negative or "no" result is obtained in block Bl 1, that is to say if in block B 12 the authenticity or validity of the first check code is not confirmed, further operation of the data processing unit 1 is interrupted in block B 13 and possibly reset. Instead of the abovementioned defining of the fixed length of the check code to four (4) bits, such a check code may have a varying length, wherein it is possible to determine, particularly at the start, for example on account of a command part or a coding of the executable command, how many bits make up the executable command, so that a division into the executable command and the respectively added check code and simple removal of the latter can be carried out. It may furthermore be mentioned that, instead of the simple key mentioned in the above example of embodiment, which consists of four (4) bits, a correspondingly longer key may be provided in order to increase the security. Such an increase in the security by increasing the length of the key may possibly have disadvantageous effects in terms of the performance and size of the overall program code or the overall length of the data that are to be stored, including the executable command and the check code. It may furthermore be mentioned that, instead of the abovementioned gating to determine or generate a command-specific check code, it is also possible to use for example a Cyclic Redundancy Check (CRC). It may furthermore be mentioned that a data processing unit 1 as described above may be contained in a so-called "smart card".