System and method for obfuscating opcode commands in a semiconductor device

Abstract

A method for protecting an integrated circuit chip includes obtaining a first value from a first storage area in the chip, obtaining a second value from a second storage area in the chip, generating a third value based on the first value and the second value, and converting a first opcode command obfuscated as a second opcode command to an unobfuscated form of the first opcode command based on the third value. The first value corresponds to a physical unclonable function (PUF) of the chip. The second value is a key that includes information indicating a type of obfuscation performed to obfuscate the first opcode command as the second opcode command. The third value can be an inverse flag indicating the type of obfuscation performed to obfuscate the first opcode command as the second opcode command.

Description

Technical Field

[0001] The example embodiments disclosed herein relate to protection measures for semiconductor devices. Background Technology

[0002] Preventing unauthorized access to integrated circuits by hackers is a key focus for chip designers. Some hacking techniques attempt to reverse engineer the chip's netlist. A netlist indicates the logical and / or physical connectivity of components in the electronic circuitry on a chip, which can be indicated, for example, by instances, nodes, connection points, wires, and attributes of circuit components. Once access is gained, hackers may attempt to use the netlist to copy the chip's hardware to steal proprietary secrets or sell counterfeit chips. Other hacking techniques attempt to access the chip's software to insert malware, Trojans, or software backdoors, or to find existing software backdoors for further intrusion. Still other techniques focus on copying the chip's software. Existing countermeasures against these and other hacking techniques have significant drawbacks and have proven unsuccessful in reducing financial and reputational losses and adequately protecting the proprietary rights of semiconductor device manufacturers. Summary of the Invention

[0003] According to one or more embodiments, a method for protecting a semiconductor device includes: receiving a first opcode command for a chip; obfuscating the first opcode command into a second opcode command; generating a key based on a Physically Unclonable Function (PUF) of the chip; and controlling the transmission of the first opcode command obfuscated into the second opcode command and the key for storage in the chip, wherein the first opcode command obfuscated into the second opcode command has the same syntax as the second opcode command but performs a different function than the second opcode command, and wherein the key includes a value indicating the type of obfuscation performed when obfuscating the first opcode command into the second opcode command. This method represents a solution to the problem of how to make it more difficult for malicious attackers to reverse engineer code.

[0004] Generating the key may include: logically combining a first value and a second value, wherein the first value corresponds to the value of the PUF, and wherein the second value is based on the value indicating that the first opcode command is obfuscated into the obfuscation type performed by the second opcode command. The first opcode command may be a first conditional branch command, and the second opcode command may be a second conditional branch command. The second conditional branch command may be the inversion of the first conditional branch command. The first opcode command may be a Not-Equal-Branch (BNE) command, and the second opcode command may be an Equal-Branch (BEQ) command. The obfuscation type may be inversion.

[0005] Generating the key may include: generating an inversion flag corresponding to the inverted value; and logically combining the inversion flag and the value of the PUF. The inversion flag and the value of the PUF may be logically combined based on an XOR operation. The method may include: storing the value of the PUF in a storage location; and controlling the transmission of an instruction pointer to the chip, wherein the instruction pointer indicates a location in a storage area within the chip, where the key can be retrieved for converting a first opcode command obfuscated as a second opcode command into an unobfuscated form of the first opcode command for execution.

[0006] According to one or more embodiments, a method for controlling an integrated circuit chip includes: obtaining a first value from a first memory region in the chip; obtaining a second value from a second memory region in the chip; generating a third value based on the first value and the second value; and converting a first opcode command obfuscated as a second opcode command into an unobfuscated form of the first opcode command for execution based on the third value, wherein the first value corresponds to a Physically Unclonable Function (PUF) of the chip, and wherein the second value is a key including information indicating the type of obfuscation performed when the first opcode command is obfuscated as the second opcode command, the first opcode command obfuscated as the second opcode command having the same syntax as the second opcode command but performing a different function than the second opcode command. This method represents an alternative solution to the problem of how to make it more difficult for malicious attackers to reverse engineer code.

[0007] Generating the third value may include: logically combining the first value and the second value, wherein the logical combination of the first value and the second value recovers the key, the key being used to convert the first opcode command obfuscated as the second opcode command into an unobfuscated form of the first opcode command. The first opcode command may be a first conditional branch command, and the second opcode command may be a second conditional branch command. The second conditional branch command may be the inversion of the first conditional branch command. The first opcode command may be a Not-Equal-Branch (BNE) command, and the second opcode command may be an Equal-Branch (BEQ) command. The obfuscation type may be inversion. The logical combination may include an XOR operation. Obtaining the second value may include: retrieving the key from a first storage area on the chip, the first storage area corresponding to an instruction pointer indicated by a controller that generates the first opcode command obfuscated as the second opcode command.

[0008] According to one or more embodiments, an integrated circuit chip includes: a memory configured to store instructions; and a processor configured to execute the instructions to: obtain a first value from a first storage region in the chip; obtain a second value from a second storage region in the chip; generate a third value based on the first value and the second value; and convert a first opcode command obfuscated as a second opcode command into an unobfuscated form of the first opcode command for execution based on the third value, wherein the first value corresponds to a Physically Unclonable Function (PUF) of the chip, and wherein the second value is a key including information indicating the type of obfuscation performed when the first opcode command is obfuscated as the second opcode command, the first opcode command obfuscated as the second opcode command having the same syntax as the second opcode command and performing a different function than the second opcode command.

[0009] The processor can: generate the third value based on a logical combination of the first value and the second value, wherein the logical combination of the first value and the second value can recover the key, and the key is used to convert the first opcode command, which is obfuscated as a second opcode command, into an unobfuscated form of the first opcode command for execution. The first opcode command can be a first conditional branch command, and the second opcode command can be a second conditional branch command. Attached Figure Description

[0010] Additional objectives and features of the invention will become more apparent from the following detailed description and appended claims, taken in conjunction with the drawings. Although several exemplary embodiments are shown and described, in each drawing, the same reference numerals identify the same parts, in which:

[0011] Figure 1 An embodiment of a system for providing protection for a semiconductor device is shown;

[0012] Figure 2 An embodiment of opcode conversion logic in a semiconductor device is shown;

[0013] Figure 3 An embodiment of a method for providing protection for a semiconductor device is shown;

[0014] Figure 4 An embodiment of an integrated circuit chip including switching logic is shown;

[0015] Figure 5 An embodiment for generating and storing protection information is shown;

[0016] Figure 6 An example of opcode command conversion according to an embodiment is shown;

[0017] Figure 7 Examples of opcode command conversion according to one or more embodiments are shown;

[0018] Figure 8 An example of an instruction pointer lookup table is shown;

[0019] Figure 9 An example of logic for selectively controlling opcode command conversion is shown;

[0020] Figure 10 An embodiment of a method for converting opcode commands in a protected semiconductor device is shown; and

[0021] Figure 11 An embodiment of opcode conversion logic in a semiconductor device is shown. Detailed Implementation

[0022] It should be understood that the accompanying drawings are schematic only and not drawn to scale. It should also be understood that the same reference numerals are used throughout the drawings to indicate the same or similar parts.

[0023] The descriptions and figures illustrate the principles of various exemplary embodiments. Therefore, it will be understood that those skilled in the art will be able to design various arrangements, which, although not explicitly described or illustrated herein, embody the principles of the invention and are included within its scope. Furthermore, all examples cited herein are primarily intended for illustrative purposes to aid the reader in understanding the principles of the invention and the concepts provided by the inventors to deepen the understanding of the art, and all examples should be considered as not being limited to such specific cited examples and conditions. Additionally, unless otherwise indicated (e.g., “or additionally” or “or in an alternative”), the term “or” as used herein means non-exclusive or (i.e., and / or). Furthermore, the various exemplary embodiments described herein are not necessarily mutually exclusive, as some exemplary embodiments can be combined with one or more other exemplary embodiments to form new exemplary embodiments. For example, descriptive terms such as “first,” “second,” and “third” do not imply limitation on the order of the elements discussed, are used to distinguish one element from the next, and are generally interchangeable. Values ​​such as maximum or minimum values ​​can be predetermined and can be set to different values ​​based on the application.

[0024] The example embodiments relate to a system and method for performing hardware and / or software obfuscation on a semiconductor device. In one embodiment, the system and method are implemented to obfuscate the inverted state of one or more conditional branch commands in the operational code (opcode) of an integrated circuit chip. Inverting the state of one or more conditional branch commands effectively transforms the opcode into another version that is syntactically similar but semantically contains some inversions. That is, the opcode program produces different outputs. The original semantics are restored only when the hardware is modified to compensate for the inversions at their insertion points. The purpose of this transformation is to render the code incomprehensible to a hacker who is unaware of where the hardware compensates for the inversions, thereby making it more difficult for malicious attackers to reverse engineer the code.

[0025] Figure 1 An embodiment of a system is illustrated for generating obfuscated opcodes for a semiconductor device, such as an integrated circuit chip. The system includes a controller 10 for generating obfuscated opcodes and associated protection information for a chip 20. The controller may be included as part of configuration logic used by the chip manufacturer to program (or otherwise configure) the chip via instructions to implement the customer's intended application.

[0026] refer to Figure 1 The controller 10 includes a storage area 11, a processor 12, a lookup table 13, and logic 14. The storage area 11 stores opcodes for the chip in an unobfuscated form, for example, generated by a chip manufacturer. The unobfuscated opcodes may include a number of instructions, including, for example, conditional branch commands. For illustrative purposes, unobfuscated opcodes are discussed as having a first conditional branch command and a second conditional branch command; it should be understood that in another embodiment, the opcode may include a different number of branch commands or other types of instructions that can be obfuscated.

[0027] The first conditional branch command can be an if-equal-if (BEQ) branch command, and the second branch command can be an if-not-equal-if (BNE) branch command. A BEQ command is a machine language instruction that branches (or "jumps") to a specified address (or performs a specific function) when the condition is met. Conversely, a BNE command is a machine language instruction that branches (or "jumps") to a specified address (or performs a specific function) when the condition is not met. Therefore, BEQ and BNE branch commands can be considered as inverses of each other.

[0028] Processor 12 includes a converter 15 that performs the conversion of unobfuscated opcodes in storage region 11 into obfuscated opcodes. This conversion can be performed, for example, by obfuscating at least one of a first conditional branch command or a second conditional branch command in a predetermined manner. In one embodiment, the unobfuscated opcodes in storage region 11 can be obfuscated by converting at least one of a BEQ command or a BNE command into one or more predetermined commands. For example, one or more BNE commands in the unobfuscated opcodes can be obfuscated in such a way that, when loaded into the chip, the BNE commands appear to be BEQ commands. In one implementation, each BNE command in the unobfuscated opcodes can be converted into a BEQ command in the obfuscated opcodes. In another implementation, only a predetermined number of BNE commands can be converted, while other BNE commands in the unobfuscated opcodes may not be converted, resulting in BNE commands appearing in the obfuscated opcodes. Due to this obfuscation, a malicious attacker may be confused because the opcodes appear logically flawed. Even if an attacker suspects that the opcodes have been obfuscated, the attacker will not be able to determine which conditional branch command is the real BEQ command, and will not be able to determine which conditional branch command is disguised as a BEQ command but actually corresponds to an unobfuscated BNE command. Processor 12 (including converter 15) can perform the operations described herein based on instructions stored in memory 18, which can be one of various types of non-transitory computer-readable media.

[0029] To allow the chip's processor 21 to recover unobfuscated code, the converter 12 can generate control information that the chip processor can use to determine which opcode commands have been obfuscated and which have not. In one embodiment, the control information may include an inversion flag. When the inversion flag has a first logic value, the chip's processor 21 can determine that the corresponding branch command has not been inverted, for example, the branch command is not obfuscated. When the inversion flag has a second logic value, the chip's processor can determine that the corresponding branch command has been inverted, for example, the branch command has been obfuscated relative to its original unobfuscated form stored in, for example, the memory area 11 of the controller.

[0030] Therefore, for example, for an unobfuscated branch command BEQ, converter 15 can set a first inversion flag to a logic 0 value to indicate that the branch command BEQ (stored in the chip) is an unobfuscated command. For an unobfuscated branch command BNE, converter 15 can set a second inversion flag to a logic 1 value to indicate that the obfuscated branch command (stored in the chip) is inverted relative to its unobfuscated branch command. Converter 15 can generate one or more inversion flags 16 for the opcode to input to logic 14, and can output the obfuscated opcode 17 to the chip for storage. The term "obfuscated opcode" does not necessarily mean that every instruction or command in the opcode is obfuscated, but rather that the opcode includes at least one command or instruction that has been obfuscated in a manner indicated by its associated inversion flag.

[0031] Lookup table 13 stores information corresponding to one or more Physically Unclonable Functions (PUFs) of the chip, which may have been determined by the manufacturer through factory testing, for example. A Physically Unclonable Function can act as a digital fingerprint, which can be used as a basis for uniquely identifying chip 20. This digital fingerprint can be based on one or more physical and / or electrical characteristics of the chip. In some cases, these characteristics may arise from variations in feature size and / or doping concentration that occur during the chip manufacturing process. In other cases, these characteristics may result in one or more initial values ​​in the flip-flops, registers, and / or memory locations (e.g., random access memory (RAM) values) of chip 20 upon power-up. Because the variations and characteristics are uncontrollable (even by the manufacturer), the resulting characteristics can be used to form a digital fingerprint that uniquely identifies the device. In this way, the device fingerprint can be considered unclonable.

[0032] In one embodiment, each PUF of chip 20 may correspond to one or more bit values ​​generated by the characteristics and variations of chip 20. The manufacturer knows the PUFs and can obtain them through testing and keep them confidential to protect the chip's security. In one example, the lookup table 13 indicates one or more PUFs based on power-on values ​​(e.g., logic one or logic zero) loaded into the flip-flops each time chip 20 is powered on. Because chip variations and characteristics are constant, the same logic value can be stored in the same flip-flops for each power-on operation. Therefore, the chip can be uniquely identified by this power-on value, either alone or in combination with one or more other PUFs. Register and memory locations of chip 20 can similarly store logic power-on values, which can also be used as PUFs of chip 20.

[0033] The information stored in lookup table 13 indicates the logic value corresponding to the PUF of chip 20, and is used by the chip's processor to recover (e.g., convert back to unobfuscated form) one or more opcode commands or instructions that were obfuscated by the controller's converter 15 before the chip was sold or otherwise made publicly available.

[0034] Logic 14 combines the logic value of the PUF stored in the lookup table with the logic value of the inverted flag generated by the converter 15 for the corresponding conditional branch command of the chip opcode. Logic 14 may include XOR logic for performing the logic combination. In another embodiment, the XOR logic may be combined with additional logic, or logic 14 may perform a logic combination different from the XOR combination.

[0035] In one embodiment, the processor 12 of the controller generates an instruction pointer (IP) value 19 that allows a PUF value stored in a lookup table 13 to be associated with a corresponding inversion flag assigned to an opcode command. In some embodiments, the lookup table 13 may store multiple PUF values ​​corresponding to inversion flags generated for a given number of opcode commands. In this case, the processor 12 may generate a different IP value for each PUF value. In one embodiment, each instruction pointer value may be a different lookup table address for the corresponding PUF. Similarly, the IP value of the lookup table 13 may be associated with the same IP value in one or more lookup tables in the chip 20 that store PUF key values ​​and / or PUFs to recover the inversion flag value for a confused conditional branch command in an opcode stored in memory area 22 of the chip 20.

[0036] The logic value generated by the logic combination executed by logic 14 can be considered the PUF_Key value. The PUF key value can be used by the chip processor to recover the inversion flag for a corresponding number of commands in the obfuscated opcode, as will be discussed in more detail below. Controller 10 transmits the PUF key value generated by logic 14 to be stored in chip 20. In one embodiment, the controller may transmit a corresponding instruction pointer to chip 20 for storage associated with the PUF key value, thereby allowing retrieval of the PUF key value to recover the original command of the obfuscated opcode. In this case, chip 20 may include a lookup table that operates based on the same instruction pointer value as the PUF stored in lookup table 13 of the controller (e.g., having a PUF key stored at the same address).

[0037] Chip 20 includes a processor 21, a storage area 22, and at least one lookup table 23. Processor 21 performs operations to recover unobfuscated opcodes from obfuscated opcodes generated by converter 15 and stored in storage area 22. Recovery of the unobfuscated opcodes is performed based on PUF key values ​​stored in at least one lookup table 23. In one embodiment, lookup table 23 may store the same PUF of the chip as the PUF stored in lookup table 13 of the controller. In one embodiment, chip 20 may include two lookup tables: lookup table 23 for storing PUF key values ​​and lookup table 24 for storing the PUF of the chip. In one embodiment, lookup table 24 may be replaced by a PUF generator, as described in more detail below. Processor 22 may perform the operations described herein based on instructions stored in memory 25. This memory may be a non-transitory computer-readable medium, such as any of various read-only memories or random access memories, as in the case of memory 18.

[0038] Figure 2 An embodiment of processor 21 is shown, comprising inverted flag recovery logic 210, a converter 220, and a region 230 for storing and / or executing unobfuscated opcodes output from converter 220. Inverted flag recovery logic 210 recovers the encoding of the inverted flag into a logical value stored in a lookup table 23 as a PUF key value. These values ​​are recovered by logically combining each PUF key value with a logical value of one of the corresponding PUFs (output from tables 23 or 24) used to generate a PUF key value in the controller for one of the obfuscated commands in an associated opcode stored in memory region 22 of the chip. Logic 210 also performs an XOR operation when logic 14 performs an XOR operation.

[0039] For example, a PUF key value can be generated using logic 14 based on Equation 1, where This represents the logical XOR operator.

[0040]

[0041] The inversion flag recovery logic 210 can recover the logic value of the inversion flag for a given obfuscated opcode command based on Equation 2, where the PUF and PUF key values ​​are retrieved from a lookup table in the chip.

[0042]

[0043] Examples of obtaining the logical value of the inverted flag by applying Equation 2 using logic 210 are shown in Table 1.

[0044] 0 0 XOR 0 BEQ 1 1 XOR 0 BEQ 0 1 XOR 1 BNE 1 0 XOR 1 BNE

[0045] Table 1

[0046] The PUF key and PUF can be retrieved from Table 23 and / or Table 24, for example, using an associated IP value received from controller 10 and associated with a corresponding address in the table. (e.g.) Figure 2 As shown, the IP can be stored in, for example, a lookup table 23, in association with the PUF key value.

[0047] Once the logic value of the inversion flag has been restored, the converter 220 can use it to convert or interpret one of the associated obfuscated commands (e.g., corresponding to the associated IP value) into its original unobfuscated command in opcode 230. Table 2 shows examples of the conversions for the conditional branch commands BEQ and BNE, as previously discussed. Once the conversion has been performed, the unobfuscated opcode can be executed to implement the intended application of the chip.

[0048] 0 BEQ was not converted. 1 Convert BEQ to BNE

[0049] Table 2

[0050] In one embodiment, obfuscated opcodes may include a combination of unobfuscated and obfuscated conditional branch commands. Because the output of converter 15 includes at least one or more obfuscated conditional branch commands, the opcodes output to chip 20 can be referred to as obfuscated opcodes.

[0051] Figure 3 An embodiment of a method for generating obfuscated opcodes and PUF key values ​​for chip 20 is shown. The method can be, for example, […]. Figure 1 It can be executed by one system, or it can be executed by another system.

[0052] refer to Figure 3 The method includes, at 310, determining one or more PUF values ​​for chip 20. As previously indicated, the PUF values ​​determined based on reading from a PUF generator during production testing by the manufacturer, and the PUF values ​​stored in a lookup table 13 of the controller, correspond to addresses of the respective instruction pointer IPs. In one embodiment, after the PUF values ​​are stored in table 13, the controller can be modified to prevent unauthorized readings of the PUF values ​​in table 13, thereby preventing attackers from accessing the PUF values.

[0053] At 320, unobfuscated opcodes are retrieved from storage area 11 and converted into obfuscated opcodes by converter 15. The converter can selectively perform opcode conversions for commands of a predetermined type. As previously indicated, these commands include BEQ and BNE commands, which are considered to be inverse versions of each other. The conversions in operation 320 can be performed for pairs or multiple pairs of complementary conditional branch commands of the same or different types.

[0054] At 330, inversion flags are generated for one or more predetermined types of conditional branch commands affected by obfuscation in the obfuscated opcodes output from converter 15. The logical value of each inversion flag can be predetermined based on whether converter 15 has obfuscated the commands (e.g., inverting BEQ to BNE, or vice versa). For example, converter 15 can generate an inversion flag of logic zero for each BEQ command that has not yet been inverted, and an inversion flag of logic one for each BNE command that has been inverted.

[0055] At 340, processor 12, including converter logic, assigns an instruction pointer (IP) value to an address in lookup table 13, which stores the PUF values ​​of the inverted flags for each branch command of a pair of complementary conditional branch command types affected by obfuscation. (For example, some types of commands or instructions in an unobfuscated opcode may not be specified for obfuscation, while others (e.g., BEQ / BNE pairs) may be specified for obfuscation.) When multiple BEQ commands are included in an opcode, the inverted flags assigned to each BEQ command may have the same logical value but may be assigned different PUFs. In another embodiment, multiple (or all) BEQ commands may be assigned the same PUF and inverted flags with the same logical value. When multiple BNE commands are included in an opcode, the inverted flags assigned to each BNE command may have the same logical value but may be assigned different PUF values. In another embodiment, multiple (or all) BNE commands may be assigned the same PUF value and inverted flags with the same logical value.

[0056] At 350, the inversion flag for each conditional branch command of the obfuscated type can be logically combined with one of the corresponding PUFs output from lookup table 13 to generate a corresponding PUF key value for the command. As previously indicated, the logical combination can be based on XOR logic or different logic.

[0057] At 360, processor 12 controls the transfer of obfuscated opcodes to store them in storage area 22, and controls the transfer of each PUF key generated by control logic 14 to store it in lookup table 23 of chip 20. This may include performing preprocessing on the opcodes and keys to store them in the chip (in this case, another entity or device may actually perform copying or loading the opcodes and keys into the chip) and / or actually transferring the opcodes and keys to the appropriate locations in the chip. As previously indicated, the PUF values ​​of chip 20 may have been pre-stored in lookup table 13 by the manufacturer. In one embodiment, the lookup table and storage area of ​​chip 20 may be one-time programmable (OTP) storage areas.

[0058] Figure 4 Another embodiment is shown for converting obfuscated opcodes stored in chip 400 and then executing the code. (Reference) Figure 4 The integrated circuit chip 400 includes a storage area 410, an inversion flag recovery logic 420, and a processor 430. The storage area 410 stores, for example... Figure 1 The controller 10 receives obfuscated opcodes. The obfuscated opcodes include one or more predetermined conditional branch commands, which have been inverted and assigned corresponding inversion flags as described herein. Inversion is used to obfuscate those commands and thus effectively obfuscate the entire opcode used by the chip.

[0059] The inversion flag recovery logic 420 includes a PUF key memory 421, a PUF generator 422, and logic 423. The PUF key memory 421 stores PUF keys for corresponding instances of obfuscated conditional branch commands in obfuscated opcodes on an IP-by-IP basis. For example, during manufacturer initialization or configuration operations, PUF keys can be received from the controller 10 that generates the obfuscated opcodes, and the PUF keys can be stored in storage area 410.

[0060] PUF generator 422 generates PUFs during the chip's testing phase. As previously described, physically unclonable features can correspond to a unique characteristic of the chip based on variations, values, or other flags that occur during the manufacturing process. For example, a PUF may correspond to an initial value loaded into a register, flip-flop, or memory address of the chip upon power-up and before a reset operation. Due to the chip's unique characteristics, this initial value is constant at each power-up. PUF generator 422 may include a detector that reads the initial power-up value of one or more of the registers, flip-flops, or memory addresses to form a corresponding PUF. In other embodiments, the PUF generator may detect or generate different PUFs, for example, based on variations in chip size, traces, components, or other characteristics.

[0061] Figure 5This demonstrates outputting one or more PUF values ​​described in this article to... Figure 1 An example of a PUF generator 422 in controller 10. Once the PUF value is received, the controller stores the value corresponding to one or more PUFs in PUF lookup table 13. As previously described, the PUF is then used to generate a corresponding inversion flag associated with the opcode command (or instruction) obfuscated by the converter. PUF generator 422 outputs the PUF in inversion flag recovery logic 420 in chip 400 to recover the inversion flag by converting the obfuscated opcode in the chip back to its unobfuscated form and then applying the inversion flag.

[0062] Refer again Figure 4 Different PUFs can be used for different instances of obfuscated conditional branch commands synchronized with the output of one of the associated PUF keys from the PUF key memory 421. The outputs of the PUF key memory 421 and the PUF generator 422 are synchronized, for example, based on the same instruction pointer IP. In one embodiment, the PUF generator 420 may include a lookup table storing PUF values ​​for corresponding IP values. By using the IP values, the inversion flag recovery logic ensures that the PUF key and PUF are associated with each other for a corresponding conditional branch command in the obfuscated opcode being executed by the processor.

[0063] In one embodiment, the PUF generator 422 can be a random access memory (RAM). In this case, the PUF can correspond to the power-on values ​​of different RAM cells, and the PUF generator can be processed (or configured) to output a PUF based on a corresponding RAM cell. In another embodiment, the PUF generator 422 can be an arbiter PUF configured by selecting a pair of "identical" signal paths P1 and P2. If P1 is faster than P2, the PUF value can be logic zero. Conversely, if P1 is slower than P2, the PUF value can be logic one.

[0064] Logic 423 matches the logic in controller 10 used to generate an inversion flag for the obfuscated opcode. In this example, logic 423 executes an XOR function as previously described. The XOR function logically combines the PUF and PUF key for the corresponding conditional branch command in the obfuscated opcode to recover the inversion flag used for said command. The inversion flag can be a single-bit value indicating whether the branch command has been inverted, for example, whether the BNE command in the original opcode has been obfuscated to make the BNE command look like the BEQ command stored in storage area 421.

[0065] Processor 430 may be a central processing unit (CPU) or a dedicated processor of chip 400. In one embodiment, the processor may be one of multiple cores of an IC chip processor. The processor executes opcodes for the chip based on obfuscated opcodes in storage region 410. For commands and instructions in the obfuscated opcodes that are not obfuscated (e.g., not reversed or otherwise modified for protection purposes), processor 430 executes those commands and instructions in a normal manner, e.g., without considering the inversion flag. For obfuscated commands (e.g., conditional branch commands), the processor may perform opcode execution, e.g. Figure 4 As shown.

[0066] exist Figure 4 In this example, processor 430 includes an instruction pointer stack 431, a status flag register 432, logic 433, and branch execution logic 434. The instruction pointer stack 431 stores instruction pointers for corresponding instructions and commands in obfuscated opcodes, or, in one embodiment, for conditional branch commands—such as BEQ and BNE commands—that are affected by obfuscation by the controller. In the latter case, the processor can determine whether a particular opcode command or instruction has been obfuscated based on whether the command or instruction has a corresponding instruction pointer stored in stack 431.

[0067] Status flag register 432 stores bits corresponding to the instruction or command of the opcode being executed. The values ​​of these bits can be used as a basis for determining whether the current opcode command or instruction should be executed upon receipt from storage area 430, or whether it should be inverted before execution. For example, a status flag bit with a logic zero value can indicate that the current opcode command or instruction should be executed by the processor without inversion. Conversely, a status flag bit with a logic one value can indicate that the current opcode command or instruction should be inverted before execution because it has been confused by the controller. The logical values ​​of the register bits can, for example, be based on the type of operation performed by logic 433.

[0068] Logic 433 logically combines a status flag bit with a corresponding inverted flag value to generate a control signal 435 for input to branch execution logic 434. Based on the logical combination performed by logic 433, the inverted flag is allowed to invert the corresponding processor status flag, which is then estimated in the branch command execution controller. In one embodiment, branch execution logic 434 decodes the opcode received from memory region 431 on an instruction-by-instruction basis, converts (e.g., inverts) the obfuscated conditional branch command in the opcode based on the control signal output from logic 433, and then executes the command in either its inverted or uninverted form.

[0069] For example, logic 433 can perform an XOR operation. When the status flag and the invert flag have the same value (i.e., both are true or both are false), logic 433 generates a control signal indicating that the current opcode command or instruction will be executed by the branch command execution controller without inversion. When the status flag and the invert flag have different values ​​(i.e., one is true and the other is false), logic 433 generates a control signal indicating that the current opcode command or instruction will be inverted by the branch command execution controller 435 before execution.

[0070] Therefore, by confusing the Figure 1 The controller executes opcodes that prevent malicious attackers from uniquely obfuscating both the hardware (e.g., conditional branch logic) and the software (opcodes) in a way that is understood by them, even if an attacker can capture the opcodes stored in the IC chip. More specifically, in one embodiment, a combined obfuscation of the chip's hardware and software is performed, which may prove to be more effective than embodiments that obfuscate the chip's hardware and software separately. Furthermore, the embodiments described herein can be applied alone or in conjunction with other obfuscation and / or security measures.

[0071] Figure 6 Examples of possible variations 6101 to 6104 of unobfuscated opcodes that can be obfuscated and transformed according to one or more embodiments described herein are shown. In this example, the transformation for obfuscating the original opcode command includes an inversion operation, such as inverting one or more BNE commands to make them appear as BEQ commands. When BEQ and BNE commands are paired, the following variations of the unobfuscated code are transformed into BEQ / BEQ pairs 620: BEQ / BEQ, BEQ / BNE, BNE / BEQ, and BNE / BNE. In one embodiment, each command in the pair may include its own inversion flag to indicate whether the corresponding command in the command has been inverted (obfuscated).

[0072] Figure 7 It shows Figure 1 This example illustrates how a controller can generate an inversion flag for each of a predetermined number of BEQ commands and a predetermined number of BNE commands in a misinterpretation opcode. In this example, the predetermined number of BEQ commands and the predetermined number of BNE commands can be the same or different. In one embodiment, the commands can be based on... Figure 6 The indicated changes are in pairs.

[0073] refer to Figure 7The inversion flag 710 for the first conditional branch exchange command in a pair of commands is generated by performing an XOR operation between the PUF and the PUF key assigned to the first conditional branch exchange command, where the PUF and PUF key are PUF1 and PUF_Key1, respectively. The inversion flag 720 for the second conditional branch exchange command in a pair of commands is generated by performing an XOR operation between the PUF and the PUF key assigned to the second conditional branch exchange command, where the PUF and PUF key are PUF2 and PUF_Key2, respectively. As shown in Table 2 and based on the previously discussed BEQ / BNE obfuscation example, when the unobfuscated version of one (or both) of the first and second commands is BNE, the corresponding inversion flag has a logical value of one (based on the logical combination of the PUF and PUF key values). Similarly, when the unobfuscated version of one (or both) of the first and second commands is BEQ, the corresponding inversion flag has a logical value of zero (based on the logical combination of the PUF and PUF key values). In Table 2, symbols I1 to I4 indicate the corresponding changes (6101 to 6104) and functions indicate the corresponding pair of conditional branch exchange commands.

[0074]

[0075] According to one or more embodiments, a PUF key store (or table) can be configured such that there is no one-to-one correspondence between the number of memory / table addresses and the number of command keys. For example, consider a case where opcodes include one million (1M) commands. To support a one-to-one correspondence, the instruction pointer (IP) address range must also be 1M to provide storage locations in the PUF key store / table for storing the same number of corresponding PUF keys. Providing memory or a table to accommodate 1M IP addresses is too large, making it inefficient or impossible for many applications. This is especially true when considering that the storage area / memory used to store 1M PUF keys may have specific protection features against reverse engineering.

[0076] According to one embodiment, the size of the memory / table storing the PUF key (IP) can be significantly reduced. For example, for many applications, it may only be necessary to obfuscate 100 conditional branch commands to achieve a sufficient level of protection for the opcodes. By reducing the number of commands to be obfuscated (rather than obfuscating all commands or instructions), the number of PUF keys to be stored and the size of the PUF key memory / table can be reduced proportionally by one or more orders of magnitude. For example, if only 100 conditional branch commands are obfuscated, the size of the PUF key memory / table can be reduced to, for example, only 1,000 addresses to store the IP, the PUF, and inverted flag information about the PUF key stored at those addresses. In one embodiment, the PUF_KEY(IP) bit and the inverted flag calculated based on the PUF_KEY(IP) bit can be provided in the same CPU loop as the branch command with the IP value.

[0077] In one embodiment, and according to the foregoing example, in a PUF key memory with 1,000 (1k) addresses, entries for PUF_KEY(IP) pairs of IP values ​​can be distributed across the entire IP address space. A 1k memory covering a 1M address space would have entries for IP addresses 0, 1k, 2k, ..., 1023k, as... Figure 8 As indicated. If the IP value is not overridden by a conditional branch command, the corresponding inversion flag can be set to 0. This is irrelevant because no conditional branch command exists. The corresponding PUF_KEY(IP) bit is relevant only if a conditional branch command exists at the IP value, and can be logically combined with the corresponding PUF(IP) bit (e.g., by XOR operation) to obtain the inversion flag. Therefore, the converter can only select to obfuscate those branch commands overridden by the PUF_KEY memory. Considering the large number of existing branch commands in common opcodes, selecting a smaller number of branch commands to obfuscate improves efficiency and performance while providing sufficient protection against hacking.

[0078] Figure 9 An example of logic that may be included in a processor within a chip is shown, said logic being used to generate a control signal indicating whether a current opcode command to be executed has an instruction pointer (IP) value stored in a PUF key memory. This control signal can be used by the associated processor within the chip to selectively determine whether the current opcode command is in an obfuscated form that needs to be converted to an unobfuscated form.

[0079] refer to Figure 9Logic 900 includes a gate 910 that receives an instruction pointer value from the IP stack. Gate 910 may be, for example, a NOR gate that receives a predetermined number of least significant bits of the address of the instruction pointer value corresponding to the current opcode command to be executed in the chip. For illustrative purposes, the length of the entire IP value is shown as 20 bits (0, ..., 19), and the length of the number of least significant bits is shown as 10 bits (0, ..., 9). In one embodiment, logic 900 may include routing logic for routing the least significant bits to the NOR gate 910. The output of the NOR gate generates a control signal (IP_in_Lookup_Table) indicating whether the current opcode command has an instruction pointer (and therefore a PUF key value) in the PUF key memory. If the instruction pointer is present, the current opcode command can be executed (without inversion or with inversion) based on the logic value of the corresponding inversion flag of the current opcode command.

[0080] Figure 10 An embodiment of a method for converting obfuscated opcodes for execution in a semiconductor device is illustrated. The method can be performed, for example, according to any of the integrated circuit embodiments described herein.

[0081] refer to Figure 10 At 1010, the method includes obtaining a first value from a first storage area in the chip. The first value may be, for example, a PUF of the chip obtained from a previously described PUF generator. At 1020, the method includes obtaining a second value from a second storage area in the chip. The second value may be a PUF key value corresponding to a stored obfuscated opcode command received from storage area 22 in the chip. The PUF key value and / or PUF value may be obtained, for example, based on a corresponding instruction pointer value. At 1030, a third value is generated based on the first and second values. The third value may be an inversion flag of the obfuscated command obtained by logically combining the PUF key value and the PUF value. At 1040, once the value of the inversion flag has been recovered, the obfuscated opcode command is converted into its corresponding unobfuscated opcode command based on the recovered value of the inversion flag. At 1050, the unobfuscated opcode command may then be executed to perform the intended application of the chip. As previously indicated, the obfuscated opcode command and the unobfuscated opcode command may be, for example, a BEQ command and a BNE command, respectively.

[0082] Figure 11 Another embodiment for converting obfuscated opcodes stored in chip 1100 and then executing the code is shown. This embodiment includes... Figure 4 The logic described herein is used to selectively control the execution of opcode branch commands.

[0083] refer to Figure 11Integrated circuit chip 1100 may include the same features as those in integrated circuit chip 400, except that this embodiment includes IP_in_lookup_table gate 1110 and additional logic 1120. As previously indicated, IP_in_lookup_table gate 1110 continuously receives instruction pointer values ​​from the IP stack and then determines whether the opcode command has a corresponding PUF key stored in the PUF key memory. For example, this operation may be performed based on the least significant bit of each of the IP values ​​as previously described.

[0084] The control signal output from IP_in_lookup_table gate 1110 determines whether the current opcode command is in an obfuscated form, and therefore needs to be converted (e.g., inverted) before execution. This can be achieved by logically combining the output of the XOR gate with gate 1120 (corresponding to...). Figure 4 The AND gate outputs a control signal from the IP_in_lookup_table gate 1110 (in the embodiment of the inversion flag). If the output of gate 1110 is logic 1, the AND gate outputs an inversion flag indicating that the current command has a PUF key and needs to be converted into an unobfuscated form. Otherwise, if the output of gate 1110 is logic 0, the AND gate does not output an inversion flag and executes the current opcode command without performing an inversion operation.

[0085] In one embodiment, both hardware and software watermarking operations can be performed. Because this watermarking can be implemented using a unique PUF, it ensures that, from the manufacturer's perspective, the PUF_KEY memory of each IC chip is programmed through its unique PUF_KEY table. This is also possible in one or more embodiments, as obfuscated opcodes may be IC-specific. This provides the possibility of watermarking, which can offer additional protection against certain threats, such as those from untrusted chip manufacturers, testing centers, and other types of third parties. This could prevent manufacturers from producing excessive quantities of wafers to sell on the grey market or reporting wafer breakage during actual packaging and sale, or prevent testing centers from selling slightly defective ICs.

[0086] In one embodiment, one or more protections can be implemented to prevent hardware and software cloning. Hardware obfuscation techniques hinder the ability to read and understand the netlist of an IC chip, and thus can be implemented to prevent malicious attackers from reconstructing the IC and adding malware, Trojans, software backdoors, etc., to the chip. However, hardware obfuscation does not automatically hinder the ability to directly clone the chip layout, for example, based on GDS2 layout files obtained from an untrusted wafer fabricator.

[0087] However, according to the implementation described herein, a PUF can be used to prevent cloning, making each potential clone "unique" and therefore unusable. Simultaneously, access to the PUF that obfuscates both hardware and software can be restored by using a reversal flag and a PUF key value (also specific to the chip's PUF) as described herein. Therefore, even if the hardware is cloned, the cloned software (opcode) will not run on the chip because each chip's PUF is unique and unknown, and thus impossible to clone.

[0088] Obfuscation performed according to one or more embodiments described herein can be implemented in a manner that does not adversely affect or otherwise interfere with any optimization techniques that can be implemented against a chip processor (CPU). For example, the obfuscation described herein may not cause the execution of obfuscated opcodes to be slower than the execution of unobfuscated opcodes. For example, obfuscation can be implemented without adding extra instructions that might impair code efficiency. Similarly, the obfuscation described herein can be implemented to maintain branch symmetry (safety-critical opcodes can be created such that, for example, two branches expressed as "if" have the same number of instructions, take the same number of computation cycles, etc.). Similarly, in one or more embodiments, cache efficiency can be maintained (e.g., the percentage of memory content retrieved from a fast cache rather than slow memory).

[0089] Additionally, one or more embodiments may not compromise the following characteristics of the chip: branch prediction (e.g., the percentage of successful predictions of future branches), speculative execution (e.g., speculative execution of execution and efforts to reverse results in the event of a prediction error), and code memory efficiency (e.g., using page-based access to quickly obtain pages instead of slowly obtaining scattered data).

[0090] The requirement to prevent these aspects of the chip from being compromised can be met through one or more embodiments described herein, particularly (but not exclusively) when the reversal of the conditional branch command in the obfuscated opcode is the only modification performed. In these embodiments, the structure of the obfuscated opcode may be exactly the same as the structure of the unobfuscated opcode.

[0091] Furthermore, implementing hardware obfuscation according to one or more embodiments can incur minimal overhead in terms of chip power consumption, area requirements, PUF implementation schemes (e.g., area consumption, requirements for special processing options, etc.), and timing (e.g., without adding additional latency on timing-critical paths). For example, these advantages can be achieved because, for at least some embodiments, the major hardware modifications involve only adding a PUF key table to the secure OTP, the PUF generator, and branch commands in the inverted processor (CPU) branch unit. No changes are required to the core library or the process. Moreover, in one or more embodiments, only standard digital logic units (e.g., flip-flops, multiplexers, etc.) with minimal invasiveness and that satisfy all relevant design rules can be used. No dedicated hardware (adding to cost and design complexity) is required. Therefore, hardware obfuscation can be performed efficiently from both a cost and design perspective.

[0092] The hardware and software obfuscation techniques described herein can also have synergistic effects. For example, obfuscating both hardware and software only allows the intended software to be executed on the corresponding hardware. This improves the flexibility of reverse engineering while preventing a significant increase in chip hardware. Furthermore, performing obfuscation based on PUF and PUF key combined with inverted flags improves the stability and efficiency of the embodiments described herein.

[0093] Variations and / or combinations of the foregoing embodiments can be implemented to form additional features and / or embodiments. For example, in one embodiment, obfuscation can be implemented using an IC-specific PUF key table, and the obfuscation opcode can be the same for multiple IC chips from the same manufacturer. For example, with regard to conditional BEQ and BNE commands, the BEQ branch command can be used with an obfuscated opcode that does not have a BNE command (because the BNE command has been obfuscated as a BEQ command). In this way, all ICs have the same obfuscation opcode, but have different PUF_KEY tables based on the unique PUF for each individual IC chip.

[0094] In another embodiment, the PUF key table and obfuscation opcodes can be IC chip-specific. For example, the converter generating the obfuscation opcodes can use not only a single branch command (e.g., BEQ) for multiple (or all) obfuscation branch commands, but also a random mixture (true or false) of BEQ and BNE commands. The PUF_KEY value can be adjusted accordingly. Then, each IC chip can have not only a dedicated PUF_KEY table, but also dedicated obfuscation opcodes that can only be executed on said chip. One advantage of this embodiment is that it provides additional protection against software copying (opcodes).

[0095] In another embodiment, the obfuscation opcode is made IC chip specific, and the PUF key table can be the same for multiple IC chips. Because the PUF_KEY value is the same for multiple IC chips, the obfuscation opcode can contain BEQ branch commands and BNE branch commands based on the chip's unique PUF value PUF(ID). This allows the embodiment to be used without a PUF key memory / table.

[0096] In another embodiment, multiple IC chips can have the same obfuscated opcodes and the same encoding table. Therefore, a chip-specific PUF is not used. Similarly, a chip-specific PUF key table is not used. In some cases, this embodiment may be easier to handle in production and programming while still providing protection for the opcodes against attackers who want to understand them.

[0097] In another embodiment, the converter can obfuscate commands or instructions in opcodes other than conditional branch commands. For example, one of the opcode commands SEQ (set if equal) and SNE (set if not equal) can be obfuscated as the other of these two commands.

[0098] The methods, processes, systems, and / or operations described herein can be executed by code or instructions that are executable by a computer, processor, controller, or other signal processing device. According to one or more embodiments, the code or instructions can be stored in a non-transitory computer-readable medium. The medium can store instructions that, when executed by one or more processors, perform the operations of the embodiments described herein. Because the algorithms underlying the methods (or the operations of a computer, processor, controller, or other signal processing device) are described in detail, the instructions for implementing the operations of the method embodiments can transform a computer, processor, controller, or other signal processing device into a dedicated processor for performing the methods herein.

[0099] Processors, converters, logic, generators, controllers, gates, and other information generation, processing, and computation features of the embodiments disclosed herein may be implemented logically, such as including hardware, software, or both. When implemented at least partially in hardware, processors, converters, logic, generators, controllers, gates, and other information generation, processing, and computation features of the embodiments may be, for example, any of a variety of integrated circuits, including but not limited to application-specific integrated circuits, field-programmable gate arrays, combinations of logic gates, systems-on-a-chip, microprocessors, or other types of processing or control circuitry.

[0100] When implemented at least partially in software, the processor, converter, logic, generator, controller, gates, and other information generation, processing, and computational features of the embodiments may include, for example, memory or other storage devices for storing code or instructions to be executed by, for example, a computer, processor, microprocessor, controller, or other signal processing device. Because the algorithms underlying the method (or the operation of the computer, processor, microprocessor, controller, or other signal processing device) are described in detail, the code or instructions for implementing the operations of the method embodiments can transform the computer, processor, controller, or other signal processing device into a dedicated processor for performing the methods described herein.

[0101] As will be apparent from the foregoing description, various exemplary embodiments of the invention can be implemented in hardware. Furthermore, these exemplary embodiments can be implemented as instructions stored on a non-transitory machine-readable storage medium—such as volatile or non-volatile memory—that can be read and executed by at least one processor to perform the operations described in detail herein. A non-transitory machine-readable storage medium can include any means for storing information in a machine-readable form, such as a personal computer or laptop computer, a server, or other computing device. Therefore, a non-transitory machine-readable storage medium can include read-only memory (ROM), random access memory (RAM), disk storage media, optical storage media, flash memory devices, and similar storage media, but not transient signals.

[0102] While various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects of various exemplary embodiments, it should be understood that the invention permits other exemplary embodiments, and the details of the invention allow for modifications in various obvious aspects. Variations and modifications can be made, as will be readily apparent to those skilled in the art, while remaining within the spirit and scope of the invention. The embodiments may be combined to form additional embodiments. Therefore, the foregoing disclosure and drawings are for illustrative purposes only and do not limit the invention in any way, which is defined only by the claims.

Claims

1. A method for protecting a semiconductor device, characterized in that, include: Receive the first opcode command for the chip; The first opcode command is confused with the second opcode command; Generate a key based on the chip's Physically Unclonable Function (PUF) feature; as well as The transmission of the first opcode command, which is obfuscated into the second opcode command, and the key are controlled so that they are stored in the chip, wherein the first opcode command obfuscated into the second opcode command has the same syntax as the second opcode command but performs a different function than the second opcode command, and wherein the key includes a value indicating the obfuscation type performed when obfuscating the first opcode command into the second opcode command. Generating the key includes: Logically combine the first and second values. Wherein the first value corresponds to the value of the PUF, and The second value is based on the value indicating that the first opcode command is obfuscated into the obfuscation type performed by the second opcode command.

2. The method according to claim 1, characterized in that: The first opcode command is a first conditional branch command, and The second opcode command is the second conditional branch command.

3. The method according to claim 2, characterized in that, The second conditional branch command is the inversion of the first conditional branch command.

4. The method according to claim 3, characterized in that: The first opcode command is a branch (BNE) command if not equal to, and The second opcode command is the BEQ command, which branches if equal to.

5. The method according to claim 3 or 4, characterized in that, The obfuscation type is inversion.

6. The method according to claim 5, characterized in that, Generating the key includes: Generate a reversal flag corresponding to the reversed value; and Logically combine the inversion flag and the value of the PUF.

7. The method according to claim 6, characterized in that, The inversion flag and the value of the PUF are logically combined based on an XOR operation.

Images