SYSTEM AND METHOD FOR PROTECTING A DEVICE AGAINST ATTACKS ON PROCESSING FLOW USING A CODE POINTER COMPLEMENT

Abstract

A system, method and computer-readable storage medium with instructions for operating a processor of an electronic device to protect against unauthorized manipulation of the code pointer by maintaining and updating a code pointer complement against which the code pointer may be verified. Other systems and methods are disclosed.

Claims

1. A method for operating a processor to protect a software code pointer from attacks, comprising: setting a fixed initial value of the software code pointer complement; setting the software code pointer complement to the initial value of the software code pointer complement; updating the software code pointer complement to a value which is a function of the software code pointer value; and performing a verification calculation using a function that accepts both the software code pointer and the software code pointer complement to produce a verification result indicative of a correct update of the software code pointer.

2. The method for operating a processor to protect a software code pointer from attacks of claim 1, further comprising: taking a corrective action if the verification calculation is indicative of a manipulation of the software code pointer.

3. The method for operating a processor to protect a software code pointer from attacks of claim 2 wherein the corrective action includes taking one or more actions selected from the set including alerting of a potential attack, disabling the processor, halting operation of the processor, and resetting the code pointer to a safe location.

4. The method of claim 1, further comprising: wherein the updating of the software code pointer complement comprises updating software code pointer complement with an equal but opposite offset to the offset added to the software code pointer; and wherein the performing of a verification calculation comprises adding the software code pointer complement and software code pointer and verifying that the result corresponds to the fixed initial value of the software code pointer complement.

5. The method of claim 1, further comprising setting the code pointer complement to a value with an irregular bit pattern.

6. The method of claim 1, wherein the code pointer is updated using a first operation and the code pointer complement is updated using a second operation distinct from the first operation.

7. An electronic device with a mechanism for protecting a software code pointer maintained by the electronic device, comprising: a processor programmed to: set a fixed initial value of the software code pointer complement; set the software code pointer complement to the initial value of the software code pointer complement; update a software code pointer complement to a value which is a function of the software code pointer value; and perform a verification calculation using a function that accepts both the software code pointer and the software code pointer complement to produce a verification result indicative of a correct update of the software code pointer.

8. The electronic device with a mechanism for protecting a software code pointer maintained by the electronic device according to the previous claim, wherein the processor is further programmed to: take a corrective action if the verification calculation indicates manipulation of the software code pointer.

9. The electronic device with a mechanism for protecting a software code pointer maintained by the electronic device according to claims 7, wherein the processor is further programmed to: set a fixed initial value of the software code pointer complement; set the software code pointer complement to the initial value of the software code pointer complement; wherein the processor updates the software code pointer complement by updating software code pointer complement with an equal but opposite offset to the offset added to the software code pointer; and wherein the processor performs a verification calculation comprises taking an exclusive-OR of the software code pointer complement and software code pointer and verifying that the result corresponds to the fixed initial value of the software code pointer complement.

10. The electronic device with a mechanism for protecting a software code pointer maintained by the electronic device according to claim 8, wherein the processor is further programmed to: set a fixed initial value of the software code pointer complement; set the software code pointer complement to the initial value of the software code pointer complement; wherein the processor updates the software code pointer complement by updating software code pointer complement with an equal but opposite offset to the offset added to the software code pointer; and wherein the processor performs a verification calculation comprises taking an exclusive-OR of the software code pointer complement and software code pointer and verifying that the result corresponds to the fixed initial value of the software code pointer complement.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a schematic illustration of a telephony network in which a mobile electronic device is connected to other mobile electronic devices and to data servers.

[0009] FIG. 2 is a schematic illustration of a high-level architecture of a mobile electronic device.

[0010] FIG. 3 is a schematic illustration of programs stored in a memory of the mobile electronic device of FIG. 2.

[0011] FIG. 4 is a schematic illustration of a section of program code and associated updates to the code pointer and a code pointer complement according to the invention.

[0012] FIG. 5 is a flow-chart illustrating the steps of computing a code pointer complement and using the code pointer complement to verify a code pointer during the execution of a program.

DETAILED DESCRIPTION OF THE INVENTION

[0013] In the following detailed description, reference is made to the accompanying drawings that show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0014] In an embodiment of the invention, a technology is provided that enables electronic devices, such as smart cards and mobile telephones, to be used to protect a code pointer against attacks that alter processing flow. The technology allows for such protection without modification to application programs.

[0015] FIG. 1 is a schematic illustration of a network 111 connecting a mobile device 103 with a portable security device 109, e.g., a smart card, connected thereto, to one or more remote servers 113. For illustrative purposes, we describe the technology presented herein as it may be used in a portable security device 109. However, the technology presented is applicable to any programmable electronic device subject to attacks against flow-of-control associated with procedure calls.

[0016] The mobile device 103 is operated by a user 101 who may interact with one of the servers 113 over the network. Certain critical operations, e.g., cryptographic and authentication operations may be deferred by the mobile device 103 to the security device 109.

[0017] FIG. 2 is a schematic illustration of a security device 109. The security device 109 may include a processor 201 connected via a bus 202 to a random access memory (RAM) 203, a read-only memory (ROM) 204, and a non-volatile memory (NVM) 205. The security device 109 further includes an input/output interface 207 for connecting the processor 201, again typically via the bus 202, to a connector 211 by which the security device 109 may be connected to a host computer or peripheral devices.

[0018] The ROM 204 and/or NVM 205 may include computer programs 301 as is illustrated in FIG. 3. While it is here depicted that the computer programs 301 are all co-located in the ROM 204 or the NVM 205, in actual practice there is no such restriction as programs may be spread out over multiple memories and even temporarily installed in RAM 203. Furthermore, the security device 109 may include multiple ROMs or NVMs. The programs 301 include operating system programs as well as application programs loaded on to the security device 109. The NVM 205 or ROM 204 may also contain private data, such as a private key 209 or a shared secret key 210, stored either in its basic form or in derived quantities, as well as other user-private information 212 such as account numbers.

[0019] The security device 109 programs 301 may include a cryptography module 213, a user authentication module 215, a communications module 217, and the operating system OS 219.

[0020] FIG. 4 is an illustration of an example of a section of program code 401 which may be processed according to the invention. The program 401 includes a number of sequential instructions beginning at memory location 0x0000 followed by a branch at instruction 0x0028 to another section of code beginning at memory location 0x1028. When the processor 201 executes the code section, a code pointer (CP) points to the next instruction to be executed by the processor 201. At the outset, illustrated by reference numeral 403, the CP has the value 0x0000 indicating that the processor is to next execute the instruction at 0x0000.

[0021] According to an embodiment of the technology presented herein, the processor 201 also maintains a code processor complement (CPC). FIG. 5 is a flow-chart illustrating the updating and verification of the CP and CPC.

[0022] The CPC is given an initial value (Initial CPC or ICPC). Thus, first the ICPC is given a value, step 501. This value may be predetermined or dynamically assigned, for example, upon the loading of an application for execution. The ICPC may be given a value that has an irregular or unpredictable bit pattern, e.g., 0x5A5A as in the example of FIG. 4. Irregular or unpredictable bit pattern is intended to mean a sequence of bits that do not have a distinct pattern. While such an irregular bit pattern ICPC may be desirable to avoid attacks against the present mechanism, the mechanism operates with any ICPC value.

[0023] The CPC is initially set to the ICPC, step 503.

[0024] Loop 505 illustrates how the processor executes instructions to implement the present technology. Thus, it is an illustration not of the flow of an application program but how the operating system or virtual machine executes instructions. The loop 505 loops over the instructions of the program following the process flow dictated by the program being executed or interpreted by the processor 201 until the program ends.

[0025] For each iteration of the loop 505, the instruction pointed to by the code pointer (CP) is executed, step 506.

[0026] Next the CP is advanced by an increment, an offset, or to a new location determined from the type of instruction, step 507. For example, for a non-branching instruction, the next instruction is the next instruction in a sequence and the increment to CP is simply the length of an instruction. This is illustrated in FIG. 4 at reference numeral 405. There, in the illustrated example, an instruction is 8 bytes long, so the next instruction is 0x0008. For a branching instruction, the next instruction may be specified as an offset from the current instruction or by a specific address that would cause an increment (or decrement) of the code pointer by a particular amount. The branch situation is illustrated in FIG. 4 at reference numerals 407 and 409. At 407 the CP is 0x0028 and the CPC is 0x5A32. The branch at that location causes an increment of CP by 0x1000 to 0x1028.

[0027] Returning to FIG. 5, code pointer (CP) is incremented by the determined offset from the current CP, step 509, which is simply adding the offset to CP:

CP=CP+Offset

[0028] Thus, for example, from instruction 0x0000 to instruction 0x0008 the CP is advanced to 0x0008 and from instruction 0x0028 to instruction 0x1028, the offset being 0x1000, the CP is advanced to O00x1028.

[0029] Next (or in parallel to Step 509) the code pointer complement (CPC) is updated by the same offset by an opposite instruction, step 511, e.g.:

CPC=CPC−Offset

[0030] Thus, continuing with the example of FIG. 4, at 0x0008 (reference numeral 405), the CPC is calculated from the previous CPC (0x5A5A) to 0x5A52:

CPC=0x5A5A−0x0008=0x5A52

[0031] At the branch instruction at 0x0028, the CPC, after a sequence of advancements of the CP and CPC, is 0x5A32 (reference numeral 407. Then with the branch offset being 0x1000, the new CPC is calculated to be 0x4A32 (reference numeral 409):

CPC=0x5A32−0x1000=0x4A32

[0032] The CP and CPC should be updated using different operations so that an attack against one of the operations does not effect the other; an attacker would have to provide offsetting attacks to foil the attack defense described herein.

[0033] At various points during the execution or interpretation of a program, the code pointer may be verified against the code pointer complement. Whether to check the CP is depicted in FIG. 5 by decision box 513. There are many different criteria that can be used to decide whether the CP should be checked, for example:

[0034] In the extreme, every instruction could be followed by the verification of the CP

[0035] The CP could be checked periodically, e.g., after every n instructions or after a specified time increment

[0036] The CP could be checked after certain instructions, e.g., upon making or returning from a procedure call

[0037] Randomly

[0038] By embedding special instructions in the program

[0039] The verification is performed by adding the CP to the CPC and comparing the result against the initial CPC (ICPC) by XORing the two, step 515:

(CP ADD CPC) XOR ICPC

[0040] If the verification results in zero, i.e., if the condition

(CP ADD CPC) XOR ICPC=0

is true, the CP has been verified as not having been manipulated because the CPC is a correct complement of the CPC. In that case, execution or interpretation may continue.

[0041] Otherwise, step 517, a flag is raised that the CP has been corrupted or some corrective action could be taken. Corrective actions may include, for example:

[0042] Alerting the user that the secure device 109 may have been subject to some form of attack

[0043] Alerting the issuer of the secure device 109 that the device may have been subject to an attack

[0044] Disabling the secure device 109

[0045] Immediately halting the operation with the secure device 109

[0046] A combination of the above corrective actions

[0047] An advantage of the technology described hereinabove in conjunction with FIGS. 4 and 5 is that the technology may be used in applications where a corrupted code pointer can produce safety hazards regardless of whether the code pointer was deliberately manipulated or corrupted through some technical problem. For example, an electrical power glitch may cause a register value to change. If that register is the code pointer register, a program would likely execute incorrectly. In safety-critical applications such as those used in the medical, aeronautical, industrial automation, and military fields, the problems created by incorrect program flow could be dangerously magnified. Thus, in step 517, i.e., when code pointer corruption has been detected, the corrective action may be to reset the executing program to a known safe point and provide some warning messages, signal a fault, log the corruption event, and/or freeze further execution.

[0048] The technology for protecting a processor against attacks which manipulate the code pointer may be implemented in software or firmware instructions, for example, in a virtual machine interpreting programs for the security device or in the operating system of the security device. The instructions may be stored in the NVM 205 or in the ROM 204. Alternatively, the verification of the CPC may be implemented in hardware, for example, by being built into the processor 201 as a combination of XOR and AND gates.

[0049] Hereinabove a technology is described that protects a programmable device, e.g., a security device such as a smart card, from manipulation of a code pointer. Thus, the technique provides an anti-tampering method that prevents attacks that alter program control flow.

[0050] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.