DATA PROCESSING ORDER AND PROCEDURES TO ENSURE THE INTEGRITY OF THE EXECUTION OF A COMPUTER PROGRAM

The ISS, combined with dual processing elements, addresses the protection of dynamic branches by updating signatures based on branch conditions, ensuring the integrity of the entire computer program's execution by detecting manipulation.

DE102014115411B4Active Publication Date: 2026-01-29INFINEON TECHNOLOGIES AG
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
DE102014115411
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2013-10-23
Filing Date
2014-10-22
Publication Date
2026-01-29
Estimated Expiration
2034-10-22

AI Technical Summary

Technical Problem

Existing methods for ensuring the integrity of a computer program's execution fail to protect dynamic parts, such as indirect and conditional branches, from manipulation.

Method used

Implementing an Instruction Stream Signature (ISS) that incorporates branch information and using dual processing elements to ensure the integrity of both static and dynamic parts of a computer program's flow by updating the signature based on branch conditions and jump addresses, and comparing it to predefined reference signatures.

Benefits of technology

Effectively protects the entire instruction stream, including dynamic parts, from manipulation by detecting anomalies through signature verification, ensuring the integrity of the program's execution.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

Data processing arrangement (100), comprising: a processor (101) designed to execute a computer program that includes multiple program instructions; a signature detection arrangement (102) designed to detect a signature of the program instructions executed by the processor (101); a memory (103) that stores a reference signature predetermined for the computer program; wherein the processor (101) is designed, when executing a program instruction of the multiple program instructions which is a conditional branch into a branch and specifies the next program instruction of the multiple program instructions to be executed, to provide the signature detection arrangement (102) with information about the specification; the signature determination order (102) is designed to take the information into account when determining the signature where the information about the indication is the information that the branch is to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of taking the branch or where the information regarding the indication is the information that the branch is not to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of not taking the branch; and a detector (104) designed to check whether the determined signature is equal to the reference signature when part of the computer program has been executed or when the computer program has been fully executed.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The present disclosure relates to data processing arrangements and procedures for ensuring the integrity of the execution of a computer program.

[0002] Manipulation of an executing instruction stream of a computer program can be detected by implementing a security functionality known as an Instruction Stream Signature (ISS). The Instruction Stream Signature typically provides strong integrity protection for static parts of a computer program's flow. For example, an Instruction Stream Signature can strongly protect the execution of any critical static part of a computer program from manipulation by physical and logical attacks.

[0003] In addition to protecting static parts of a computer program's flow, it is desirable to also protect dynamic parts of a computer program's flow from manipulation.

[0004] Publication US 2006 / 0156005A1 describes a method for the safe execution of a computer program, characterized in that it comprises: a first step consisting of calculating and storing a first signature representing the expected execution of an instruction set before the execution of the computer program; a second step consisting of calculating and storing a second signature representing the execution of the instruction set during the execution of the instruction set; and a step consisting of detecting an anomaly in the execution of the instruction set based on the first and second signatures.

[0005] Publication US 2012 / 0233446A1 describes a signature module that, during the execution of a program by a central processing unit (CPU), calculates a signature based on program instructions sent to the CPU and stores the signature in a signature register of the signature module. The signature module comprises: a computation unit configured to generate a signature value based on program instructions executed on the CPU; and an instruction information interface configured to receive at least one instruction information entry from the CPU indicating whether an instruction currently being executed by the CPU was invoked indirectly or directly.

[0006] According to one embodiment, a data processing arrangement is provided in accordance with independent claim 1.

[0007] Further embodiments are described in the dependent claims.

[0008] According to a further embodiment, a method for ensuring the integrity of the execution of a computer program according to independent claim 14 is provided.

[0009] In the drawings, generally identical reference numerals denote the same parts. The drawings are not necessarily to scale; instead, the emphasis is generally on illustrating the principles of the invention. The following description describes various aspects with reference to the following drawings. They show: Fig. 1 a data processing arrangement according to one embodiment. Fig. 2. A flowchart of a procedure for ensuring the integrity of the execution of a computer program. Fig. 3 a data processing arrangement according to one embodiment. Fig. 4. Signature detection in a program flow without branching according to one embodiment. Fig. 5. Signature determination in a program flow with conditional branching according to one embodiment. Fig. 6. Signature determination in a program flow with indirect branching according to one embodiment. Description

[0010] The following detailed description refers to the accompanying drawings, which illustrate specific details and aspects of the present disclosure in which the invention can be implemented. Other aspects may be used, and structural, logical, and electrical modifications may be made without altering the scope of protection of the invention. The various aspects of the present disclosure are not necessarily mutually exclusive, as certain aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0011] The following describes embodiments that allow the protection of the dynamic parts of a computer program's flow from manipulation. For example, indirect branches, which include a corresponding instruction call, and conditional branches, which include a corresponding instruction call, can be protected from manipulation. According to various embodiments described below, the entity that determines the instruction stream signature for an executing computer program, also referred to as the signature determination mechanism, is coupled to the data path. In other words, the signature determination mechanism receives results of the program instruction processing, such as a jump address (e.g., the address of an indirect branch) or information about whether a branch is taken, e.g., the evaluation of a branch condition, and incorporates these into the signature determination.This allows for the protection of dynamic parts of the instruction stream, in other words, the computer program. The instruction stream can be protected by the instruction stream signature, and the data operation (such as determining a jump address or evaluating a branch condition) can be protected by additional redundancy, such as dual processing elements (like dual CPUs or ALUs) that execute the data operation. Considering the results of the processing during signature determination allows for the protection of the interoperation between the data path and the instruction stream, in other words, the dependence of the instruction stream on the results of the data operations, for example, conditional and indirect branches. Instruction stream signatures can thus be used, for example, as an integrity protection concept for smart cards or other secure components.

[0012] The following describes a data processing arrangement that can, for example, provide protection against manipulation of indirect branches or conditional branches.

[0013] Fig. Figure 1 shows a data processing arrangement of 100.

[0014] The data processing arrangement 100 comprises a processor 101 designed to execute a computer program comprising multiple program instructions, a signature determination arrangement 102 designed to determine a signature of the program instructions executed by the processor, and a memory 103 storing a reference signature predetermined for the computer program.

[0015] The processor is designed, when executing a program instruction of the set of program instructions that specifies the next program instruction of the set of program instructions to be executed, to provide information about the specification to the signature detection arrangement.

[0016] The Signature Determination Order 102 is designed to take the information into account when determining the signature.

[0017] The data processing arrangement further includes a detector 104, which is designed to check, when a part of the computer program has been executed or when the computer program has been fully executed, whether the determined signature is equal to the reference signature.

[0018] In other words, the result of a program instruction (such as an indirect branch or a conditional branch), which specifies the next program instruction to be executed (namely in the form of the jump address or an indication of whether the branch should be taken), is fed back to the signature determination entity, which determines the signature based on this information. This can be done in such a way that the effect of considering the information during signature determination (e.g., changing the signature by a certain value) is equal to the difference in the signature due to the path taken to the program.For example, if an instruction is executed because a specific conditional branch was taken, and is therefore included in the signature, considering the information about the taken branch results in the same signature as if the instruction had not been executed (and thus not included in the signature). Therefore, the combination of the (correct) branch information and the (correct) instruction again results in a valid signature. Alternatively, multiple valid reference signatures can be predefined, and considering the information during signature determination, combined with signature updates according to the correct instructions (i.e., the instructions to be executed according to the information), results in one of the predetermined reference signatures for every possible path through the computer program, i.e., every jump address and every branch taken or skipped.

[0019] For example, the program instruction of several program instructions that specifies the next program instruction of several program instructions to be executed is a conditional branch.

[0020] The information regarding the specification in this case includes, for example, information about whether the branch should be taken or not.

[0021] As another example, the program instruction of several program instructions that specifies the next program instruction of several program instructions to be executed is an indirect jump.

[0022] The information provided in this case includes, for example, the memory address of the next program instruction to be executed.

[0023] According to one embodiment, the signature detection arrangement is designed to update the signature for each of the multiple program instructions executed by the processor, starting from an initial value when the first program instruction is executed.

[0024] For example, the signature determination order is designed to update the signature for each program instruction based on the program instruction.

[0025] The signature determination order, for example, is designed to update the signature for each program instruction based on a representation of the program instruction.

[0026] For example, the signature determination order is designed to update the signature for each program instruction based on an opcode of the program instruction.

[0027] According to one embodiment, the signature detection arrangement is designed to take the information into account in such a way that the detected signature is independent of the information when part of the computer program has been executed or when the computer program has been fully executed, provided that the next program instruction has been executed by the processor as specified.

[0028] It should be noted that the computer program can be a part of a larger computer program. In other words, after a part of a larger computer program has run, a check can be performed to determine whether the determined signature is correct (i.e., equal to a pre-determined reference signature); that is, it can be an intermediate check with reference to the larger computer program after a part of the (larger) computer program has been executed.

[0029] According to one embodiment, the signature detection arrangement is designed to take the information into account in such a way that the detected signature is equal to the reference signature when part of the computer program has been executed, or when the computer program has been fully executed, when the next program instruction has been executed by the processor as specified, and when the rest of the computer program has been executed correctly.

[0030] According to one embodiment, the memory stores several reference signatures pre-determined for the computer program, and the detector is designed to check, when a part of the computer program has been executed or when the computer program has been fully executed, whether the determined signature is equal to any of the reference signatures.

[0031] According to one embodiment, the signature detection arrangement is designed to update the signature for at least one program instruction based on the program instruction itself and on the memory address of the program instruction. For example, the representation of the program instruction (e.g., the opcode) can be linked to the address of the program instruction, e.g., by an XOR operation or by a specific other operation. This can be done for some or all of the (executed) program instructions of the computer program.For example, the information about the memory address of the next program instruction to be executed is provided, and the signature determination arrangement is designed to take the information into account such that taking the information into account negates the effect of the memory address of the program instruction on updating the signature for the at least one program instruction if the memory address of the next program instruction to be executed is equal to the memory address of the at least one program instruction.

[0032] According to one embodiment, the program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed is a conditional branch, and the information about the specification is the information that the branch is to be taken, and the signature detection arrangement is designed to take the information into account, such that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or are executed as a result of taking the branch.

[0033] According to one embodiment, the program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed is a conditional branch, and the information about the specification is the information that the branch is not to be taken, and the signature detection arrangement is designed to take the information into account, such that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed due to the branch not being taken.

[0034] The signature is, for example, an Instruction Stream Signature (ISS).

[0035] According to one embodiment, the processor comprises a first program flow determiner designed to provide the processor with information about the specification for a program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed, and a second program flow determiner designed to provide information about the specification for the program instruction of the signature detection arrangement.

[0036] For example, the first program flow determiner is designed to provide information about the specification of an instruction retrieval unit of the processor.

[0037] The first program flow analyzer and the second program flow analyzer, for example, are designed to determine a value independently of each other.

[0038] For example, the first program flow detector is a first arithmetic logic unit (ALU), and the second program flow detector is a second arithmetic logic unit. The components of the data processing arrangement can be implemented using one or more circuits. In one embodiment, a "circuit" can be understood as any type of logical implementation entity, which may be a specific circuit or a processor that executes software stored in memory, firmware, or any combination thereof. Thus, in one embodiment, a "circuit" can be a hard-wired logic circuit or a programmable logic circuit, such as a programmable processor, e.g., a microprocessor (e.g., a CISC (Complex Instruction Set Computer) processor or a RISC (Reduced Instruction Set Computer) processor).A "circuit" can also be a processor that executes software, e.g., any type of computer program, such as a computer program that uses virtual machine code like Java. Any other type of implementation of the respective functions, which are described in more detail below, can also be considered a "circuit" according to an alternative embodiment.

[0039] The data processing order, for example, implements a procedure as described in Fig. 2 shown.

[0040] Fig. Figure 2 shows a flowchart of 200.

[0041] Flowchart 200 shows a procedure for ensuring the integrity of the execution of a computer program.

[0042] At 201, a reference signature pre-determined for the computer program is stored.

[0043] At 202, a computer program is executed that contains several program instructions.

[0044] In section 203, a signature of the program instructions to be executed by the processor is determined. If a program instruction is executed that specifies the next program instruction to be executed, information about this specification is taken into account when determining the signature. In section 204, if a portion of the computer program has been executed or if the computer program has been fully executed, it is checked whether the determined signature is equal to the reference signature.

[0045] It should be noted that according to one embodiment, 203 is executed in parallel with 204, i.e., the signature is determined during the execution of the computer program (e.g., successively updated according to the executed program instructions).

[0046] It should be noted that the embodiments described in the context of the data processing arrangement 100 are analogous for the one in Fig. The two described methods apply and vice versa. Furthermore, the features of the embodiments described in the context of data processing arrangement 100 can be used in any combination.

[0047] The following sections describe the various embodiments in more detail.

[0048] Fig. Figure 3 shows a data processing order 300 according to one embodiment.

[0049] The data processing order 300 includes a memory 301 that stores several program instructions 302 of a computer program.

[0050] The program instruction 302, which is the next one to be executed by the data processing arrangement 300, is retrieved by an instruction retrieval unit 303 and forwarded to an instruction decoder 304. The instruction decoder 304 decodes the program instruction 302 and controls a processing unit 305 accordingly. For example, it generates control signals according to the program instruction 302 for the processing unit such that the processing unit 305 executes the program instruction 302. In doing so, for example, data to be processed can be retrieved from memory 301 and data resulting from the processing can also be written back to memory 301. The processing unit 305 is, for example, an execution unit. The processing unit 305 comprises (at least) two processing elements 306, e.g., ALUs (arithmetic logic units). In other words, the processing unit is, for example, a dual aluminum execution unit.

[0051] The result of executing a program instruction 302 can determine the next program instruction 302 to be executed, for example, if the program instruction 302 is a conditional branch, an indirect branch, or a jump. In such a case, information about the next program instruction 302 to be executed, for example, a memory address that addresses the next program instruction 302 to be executed in memory 301, is fed back to the instruction retrieval unit 303.

[0052] Furthermore, in such a case, information 307 about which next program instruction was specified is provided to a signature determiner 308.

[0053] Furthermore, information 309 about the instructions is provided to the signature determiner 308, which is retrieved from the memory 301 by the instruction retrieval unit 303.

[0054] For each instruction retrieved by the instruction retrieval unit 303, the signature determiner 308 updates a signature (starting from a specified initial value) for the executed computer program. When execution is complete, it compares the determined signature with a reference signature of the computer program (or with more than one allowed reference signature). If the determined signature is equal to the reference signature (or any of the allowed reference signatures), the integrity of the program execution is confirmed.

[0055] One or more reference signatures are determined in advance, for example by a software tool, or in other words, for example by an offline tool.

[0056] The following refers to Fig. 4. An example of how to determine a signature is given.

[0057] Fig. Figure 4 shows signature detection in a program flow without branching.

[0058] In this example, the computer program comprises six instructions i1 to i6. Signature determination begins with an initial value S0. For the first program instruction i1, the signature determiner 308 determines an updated signature S1 based on the previous signature S0 and information 309 about the instruction i1 (e.g., its binary representation in memory 301, e.g., its opcode instruction_opcode_i1) according to a pre-determined signature determination function Sig, i.e., S1 = Sig(S0, i1) = Sig(S0, instruction_opcode_i1).

[0059] Similarly, for the second instruction i2, an updated signature S2 is determined based on the previous signature S1 and information 309 about the instruction i2 according to the function Sig, i.e., S2 = Sig (S1, i2).

[0060] This process continues until the sixth signature update S6 for the sixth instruction i6 is determined according to S6 = Sig(S5, i6). This value S6 can then be compared to the reference signature to determine if the program executed correctly (or can be updated further if more instructions follow).

[0061] It is assumed that the total update from S1 to S5 is a determined value Δ, i.e., that S5 = S1 + Δ.

[0062] In the following, it is assumed that the second statement i2 is a conditional branch that can branch to i6 if a certain condition is met. In this case, the example of Fig. 4 is considered the case where the branch is not taken, i.e., the condition is not met. The case where the branch is taken is in Fig. 5 shown.

[0063] Fig. Figure 5 shows signature detection in a program flow with conditional branching. In this case, it is assumed that the branch to i6 is taken as a consequence of i2. Accordingly, the processing unit 305 provides this information to the instruction retrieval unit 303, so that the instruction retrieval unit 303 then retrieves i6 next. Furthermore, the information that the branch has been taken is passed to the signature detector 308 as information 307 about the specified next program instruction (in this case, i6). Fig. The information referred to as branch_taken is taken into account by signature investigator 308. Specifically, for the second instruction i2, signature investigator 308 determines the signature S2 based on S1, i2 and the branch_taken information, i.e., S2 = Sig(S1, i2, branch_taken).

[0064] This means that Sig(S1, i2, branch_taken) is defined, for example, predetermined by a software tool, such that Sig(S1, i2, branch_taken) = S1 + Δ. For example, a software tool determines Δ as in the case of Fig. 4 occurs, i.e., from the updates according to i2, i3, i4, and i5 (in other words, from information about the branch path), and defines Sig(S1, i2, branch_taken) to add this Δ to the previous signature S1. It should be noted that the software tool can also insert a corresponding instruction into the program, e.g., an instruction that is executed when the branch is taken, and according to which signature determiner 308 increments the signature by Δ.

[0065] The state of the signature before instruction i6 is therefore both in the Fig. 4 case as well as in the one in Fig. In the case shown in section 5, S1 + Δ is equal to the signature. Therefore, the signature before instruction i6 is valid if... - the branching condition was not met (i.e., no branch_taken input to signature determiner 308) and i3, i4, i5 were executed correctly. - the condition was met (i.e. branch_taken input to signature determiner 308) and i3, i4, i5 were correctly skipped.

[0066] For example, if an attacker manages to manipulate the branch so that it is executed incorrectly, i.e., the branch condition was not met, but i3, i4, i5 were still skipped, the signature will generally not have the correct value, since the signature determiner 308 S2 determines S2 = Sig(S1, i2), which is not further modified up to i6.

[0067] Alternatively, Sig(S1, i2, branch_taken) can be defined differently from S1 + Δ. Furthermore, Sig(S1, i2, branch_taken) can be defined differently from Sig(S1, i2), so that, in other words, the branch_taken information is explicitly included in the signature determination. Since Sig(S1, i2, branch_taken) is different from S1 + Δ, in this case the signature at the end of the computer program execution will generally depend on whether the branch was taken or not.Accordingly, two reference signatures can be predefined, one for the case that the branch is taken and one for the case that the branch is not taken, so that the case where the signature for i2 was calculated as Sig(S1, i2, branch_taken) and instructions i3 to i5 were skipped leads to one of the predefined reference signatures (provided the rest of the computer program was executed correctly), and the case where the signature for i2 was calculated as Sig(S1, i2) and instructions i3 to i5 were not skipped leads to another of the predefined reference signatures (provided the rest of the computer program was executed correctly).

[0068] Other implementations can also be used, such as that Sig(S1, i2, branch_taken) is different from Sig(S1, i2) (or a signature value Sig(S1, i2, branch_not_taken), where the information about not taking the branch is explicitly included in the signature) and is different from S1 + Δ, and that the skipped branch includes an additional instruction that has a signature update, such that for both paths (branch taken or branch not taken) the determined signature is the same (if the program has been executed correctly).

[0069] It should be noted that in the Fig. In the embodiment shown in Figure 3, the branch condition is determined with redundancy by means of two processing elements 306. That is, one of the processing elements 306 evaluates the branch condition of i2 and accordingly controls the instruction retrieval unit 303 to retrieve the instruction that is next according to the evaluation, and the other of the processing elements 306 evaluates the branch condition of i2 and provides the information 307 about the instruction that is next according to the evaluation to the signature determiner 308. Thus, the risk of an attacker being able to manipulate both the branch (i.e., manipulate which instruction is executed next) and the signature determination is reduced.

[0070] It should be noted that instead of modifying the signature according to the `branch_taken` information if the branch is taken, the signature can also be modified (additionally or alternatively) according to the `branch_not_taken` information (delivered as information 307 to the signature determiner 308) if the branch condition is not met. For this purpose, the respective signature updates are chosen such that valid combinations (i.e., condition not met and i2 to i5 executed, and condition met and i2 to i5 skipped) result in the same signatures shortly before i6, while invalid combinations (such as condition not met and i2 to i5 skipped) result in a different signature before i6.

[0071] Accordingly, the software tool, e.g., an offline statement signature generation tool that calculates the signature update value Δ and the signature reference values ​​(and subsequently the intermediate signature reference values ​​S1, ... S5), considers the additional condition signature information branch_taken, branch_not_taken. In the case of Fig. In step 5, the tool examines the signature information `branch_taken` in the branch path to calculate signature reference and update values. If manipulation occurs, the offline calculated reference information (i.e., the signature reference determined in advance) will generally not match the online signature value (i.e., the signature determined during program execution), and the signature verification at the end of program execution will fail. In this case, a warning message may be generated for the user.

[0072] In the following, it is assumed that the second instruction i2 is an indirect branch. For example, instruction i2 is a jump instruction whose jump address is given by the contents of a register of processing unit 305.

[0073] Fig.Figure 6 shows signature determination in a program flow with indirect branching. For example, from i2, the program can jump to any one of three instructions i3, i4, and i5. It is assumed that any of S3 = Sig(S2, i3), S4 = Sig(S2, i4), and S5 = Sig(S2, i5) are valid intermediate signature values ​​that ultimately lead to a valid signature value at the end of the program. This can be achieved, for example, by including (e.g., using a software tool in advance) an instruction in each of the three branches entered by i3, i4, and i5, respectively, that balances the differences in signatures between the three branches, for example, at a point where the three branches converge back into a single branch. Alternatively, there can be multiple valid signature values ​​at the end of the program.

[0074] The following describes an embodiment that makes it possible to ensure that the instruction addressed by the jump address of i2 has been executed, i.e., that it can be detected, for example, that i5 has been executed, even though the jump address of i2 addresses i3.

[0075] For this purpose, the instruction retrieval unit 303 and the signature detector 308 are given information about the jump address as information 307 about which next program instruction has been specified. As above, this can be done using redundancy, i.e., for example, one of the processing elements 306 determines the jump address provided to the instruction retrieval unit 303, and the other of the processing elements 306 determines the jump address provided to the signature detector 308.

[0076] Furthermore, instructions 302 are stored in memory 301, so that for each instruction 302, its memory address is stored in addition to (e.g., in combination with) its representation (e.g., its opcode). For example, for an instruction, the data stored in memory 301 is given as `memory_data = instruction_opcode xor f[instruction_address]`. where f can be a specific function. This could be, for example, the identity or a specific function to bring the instruction_address for the xor operation to the same bit length as the opcode.

[0077] Accordingly, for an instruction retrieved by the instruction retrieval unit 303, the retrieved data includes information about its opcode and its memory address, e.g., as above, an XOR operation of the opcode and a specific function of its memory address.

[0078] In this example, the decoder is designed to remove the added memory address information (e.g., by performing another xor operation on memory_data with f[instruction_address], resulting in the opcode), so that it decodes correctly.

[0079] The signature detector 308 determines the updated signature value (Sx with x=4, 5, 6) as a function of the old signature value (S2) and the memory data of the instruction ix (designated as memory_data_ix corresponding to memory_data as given above) and the information 307 (which in this example is the instruction address designated as instruction_address_ix).

[0080] This is done in such a way that, in the case of correct execution, the updated version negates the effect of the address information in the memory data on the signature, e.g., by another XOR operation, e.g., according to Sx=Sig(S2, update_information) where update_information = g(memory_data_ix, f(instruction_address_ix)) = memory_data_ix xor f(instruction_address_ix) = instruction_opcode_ix such that Sx=Sig(S2, instruction_opcode_ix) Thus, if instruction retrieval unit 303 retrieves the next instruction from an address in memory 301 as specified by information 307, a valid signature is generated. However, if instruction retrieval unit 303 retrieves the next instruction from an address in memory 301 that differs from the address specified by information 307, the resulting signature is generally invalid because the difference in the XORed addresses will be reflected in the signature. The signature check at the end of program execution will therefore fail, and a warning message may be generated for the user.

[0081] It should be noted that the above XOR operation of the memory data with the instruction address, as contained in information 307, can take place according to function g before the input to the instruction retrieval unit 303 (naturally, instead of within the signature detector, which would only receive the instruction opcode as input). In this case, the address information will already be removed before input to the signature detector 308 and the decoder 304 (if the memory addresses determined by the processing elements 306 are the same). A corresponding XOR operator at the input of the instruction retrieval unit 303 can be considered part of a signature detection circuit that also includes the signature detector 308.

[0082] As an alternative to the approach described above, where instructions 302 are stored in memory 301 such that for each instruction 302 its memory address is stored in addition to its representation by means of an xor operation and an xor operation of the memory data with the instruction address is performed as described above, signature determination in a program flow with indirect branching can be carried out as follows.

[0083] The signature investigator can include the jump address in the signature investigation, for example according to S3=Sig(S2,i3, memory address of i3) if the flow jumps to instruction i3, or S4=Sig(S2,i4, memory address of i4) if the flow jumps to instruction i4.

[0084] For each of the signatures possible in this way, a valid reference signature is predefined.

[0085] If manipulation occurs in this case, such that, for example, S3=Sig(S2,i3, memory address xyz) If a specific instruction other than i3 is executed with a memory address xyz, or with Sxyz=Sig(S2,ixyz, target address i3), this can be detected because these signatures will not result in a valid reference signature. Although specific aspects have been described, it is understandable to those skilled in the art that various changes in form and detail can be made without deviating from the concept and scope of protection of the aspects of the present disclosure as defined by the appended claims. The scope of protection is thus specified by the appended claims, and all changes that fall within the meaning and equivalence of the claims are therefore intended to be included.

Claims

[1] Data processing arrangement (100), comprising: a processor (101) designed to execute a computer program that includes multiple program instructions; a signature detection arrangement (102) designed to detect a signature of the program instructions executed by the processor (101); a memory (103) that stores a reference signature predetermined for the computer program; wherein the processor (101) is designed, when executing a program instruction of the multiple program instructions which is a conditional branch into a branch and specifies the next program instruction of the multiple program instructions to be executed, to provide information about the specification to the signature detection arrangement (102); the signature determination order (102) is designed to take the information into account when determining the signature where the information about the indication is the information that the branch is to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of taking the branch or where the information regarding the indication is the information that the branch is not to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of not taking the branch; and a detector (104) designed to check whether the determined signature is equal to the reference signature when part of the computer program has been executed or when the computer program has been fully executed. [2] Data processing arrangement (100) according to claim 1, where the program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed is a conditional branch; where optionally the information about the specification is information about whether the branch should be taken or not. [3] Data processing arrangement (100) according to claim 1 or 2, wherein the program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed is an indirect jump, wherein optionally the information about the specification is the memory address of the next program instruction to be executed. [4] Data processing arrangement (100) according to any one of claims 1 to 3, wherein the signature detection arrangement (102) is designed to update the signature for each of the multiple program instructions executed by the processor (101), starting from an initial value when the first program instruction is executed. [5] Data processing arrangement (100) according to claim 4, wherein the signature determination arrangement (102) is designed to update the signature for each program instruction based on the program instruction; where optionally the signature determination arrangement (102) is designed to update the signature for each program instruction based on a representation of the program instruction; where optionally the signature determination arrangement (102) is designed to update the signature for each program instruction based on an opcode of the program instruction. [6] Data processing arrangement (100) according to any one of claims 1 to 4, wherein the signature detection arrangement (102) is designed to take the information into account in such a way that the detected signature is independent of the information when part of the computer program has been executed or when the computer program has been fully executed, when the next program instruction has been executed by the processor (101) as specified. [7] Data processing arrangement (100) according to any one of claims 1 to 6, wherein the signature determination arrangement (102) is designed to take the information into account in such a way that the determined signature is equal to the reference signature when part of the computer program has been executed or when the computer program has been fully executed, when the next program instruction has been executed by the processor (101) as specified, and when the rest of the computer program has been executed correctly. [8] Data processing arrangement (100) according to any one of claims 1 to 7, wherein the memory (103) stores several reference signatures pre-determined for the computer program and wherein the detector (104) is designed to check, when a part of the computer program has been executed or when the computer program has been fully executed, whether the determined signature is equal to any of the reference signatures. [9] Data processing arrangement (100) according to any one of claims 1 to 8, wherein the signature determination arrangement (102) is designed to update the signature for at least one program instruction based on the program instruction and based on a memory address of the program instruction; where optionally the information is the memory address of the next program instruction to be executed and the signature determination arrangement (102) is designed to take the information into account in such a way that taking the information into account negates the effect of the memory address of the program instruction on updating the signature for the at least one program instruction if the memory address of the next program instruction to be executed is equal to the memory address of the at least one program instruction. [10] Data processing arrangement (100) according to any one of claims 1 to 9, wherein the signature is an instruction stream signature. [11] Data processing arrangement (100) according to any one of claims 1 to 10, wherein the processor (101) comprises a first program flow detector, which is configured to provide the processor (101) with information about the specification of a program instruction of the multiple program instructions that specifies the next program instruction of the multiple program instructions to be executed, and a second program flow detector, which is configured to provide information about the specification of the signature detection arrangement (102); wherein optionally the first program flow detector is configured to provide the information about the specification of an instruction retrieval unit of the processor (101). [12] Data processing arrangement (100) according to 11, wherein the first program flow detector and the second program flow detector are designed to detect the information independently of each other. [13] Data processing arrangement (100) according to claim 10 or 12, wherein the first program flow detector is a first arithmetic logic unit and the second program flow detector is a second arithmetic logic unit. [14] Methods for ensuring the integrity of the execution of a computer program, comprising: Storing a reference signature pre-determined for the computer program; Executing a computer program that contains multiple program instructions; Determining a signature of the program instructions executed by the processor (101), wherein, when a program instruction of the multiple program instructions is executed which is a conditional branch into a branch and specifies the next program instruction of the multiple program instructions to be executed, information about the specification is taken into account when determining the signature. where the information about the indication is the information that the branch is to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of taking the branch or where the information regarding the indication is the information that the branch is not to be taken, and the signature determination order (102) is designed to take the information into account in such a way that taking the information into account negates the difference in the updates of the signature because the program instructions are skipped or executed as a result of not taking the branch; and Check whether the determined signature is the same as the reference signature when part of the computer program has been executed or when the computer program has been fully executed.

Citation Information

Patent Citations

  • Method and device for making secure execution of a computer programme

    US20060156005A1

  • Program-Instruction-Controlled Instruction Flow Supervision

    US20120233446A1