rus
In the final part of the cycle of review articles devoted to Hardware Trojans problems of maintaining system secure operation in the presence of Hardware Trojans are considered. To date no general countermeasures have yet been developed or proposed that would allow an IC to operate in a trustworthy manner in the presence of an arbitrary Hardware Trojan. Some aspects of such protection, details of its implementation and analyzing the general applicability of the countermeasures are discussed.
Теги: cyber security hardware backdoor hardware trojan integrated circuit malicious modification аппаратная закладка аппаратный троян интегральная схема кибербезопасность несанкционированная модификация
As it has been previously noted [1–3], the preventive approaches and modern methods for the detection of hardware Trojans do not give a complete assurance that manufactured IC does not contain hardware backdoors. A wide variety of security threats associated with them, as well as a huge state space for embedding hardware backdoors raised the question, how to ensure the safe operation of the system with the "infected" IC and, in particular, the goal to prevent the activation of Trojans. This approach would allow the use of the equipment, not paying attention to embedded hardware Trojans, and even use of COTS (Commercial off-the-shelf) components to build reliable computing systems that are resistant to hardware backdoors.
The most publications associated with this kind of counteraction to hardware Trojans, consider the protection against only one class or subclass of the threats. It is assumed that greater security will provided by a multilevel defense in which each level irrespective of others focused on specific actions and mechanisms of activation of Trojans, followed by combining all these measures into an overall strategy of protection.
Proposed and experimentally tested mechanisms of countermeasures can be divided into the following groups:
• data protection;
• new architecture at the RTL-level (register-transfer level);
• reconfigurable architecture;
• strategies of replication, fragmentation and voting.
DATA PROTECTION
Protection of data (including processor commands) involves the prevention of the activation of a hardware Trojan or/and blocking direct access of Trojan equipment to any vulnerable data. The protective device can control data stored or transmitted within or between ICs and logical modules, and block mechanism by which the Trojan interacts with the data.
In [4] several methods of protection of data by preventing activation of a Trojan are proposed. Some of these methods were implemented on the Zesto x86 simulator. To prevent the receiving an activation code by Trojan a scrambling (encryption) of information channel (bus) is used. It is used for data processing units that are not involved in the calculations. The authors propose to use simple trusted encryption schemes to hide data (for example, XOR with pseudo-random numbers – Xorshif encryption), secretive them only for a short time.
The effectiveness of this scrambling was investigated by introducing parameterized delay in the cache and the memory controller. The scrambling of the bus prevented the activation of simple Trojans, however, this possibility still remained. For example, when using a simple 32-bit trigger, activation will occur for 232 cycles. A more controlled approach could be implemented through the override of all inputs into a fully functionally reliable state space using the trusted and stable encryption schemes.
Since such data obfuscation will lead to wrong calculations in computing units, in this case, it is proposed to use homomorphic encryption [5], which allows computing units to work with encrypted data. Encryption is determined as homomorphic by the computing function and computing unit obtain the correct results only with encrypted values. The final result can be decrypted.
The implementation of such homomorphic functions is not a trivial task, and their computation is costly, and it is quite difficult to build a scheme of homomorphic encryption for general use. In the same way as in the case of scrambling of data bus, the encryption and decryption blocks must be implemented in a fully tested hardware. The authors of [4] did not consider homomorphic encryption, but instead have proposed and analyzed the use of a cryptographic algorithm with a public key (RSA-encryption). The use of schemas that implement the Yao's Garbled Circuit algorithm [6], can be considered as an alternative approach for obfuscation of data of the computing blocks.
It is also proposed in [4] to use a "time protection" to prevent activation of a hardware Trojan within a confirmed state space. The IC is checked for complete functional reliability for a specified number of cycles. In the future, when IC reaches this number of cycles, the circuit is deactivated and activated, thereby avoiding temporary activation of a Trojan. The hardware solution allows to save context during the period of the outage, providing continuity of the computational process. The authors make the assumption that any hardware Trojan, which was in rest mode at the complete testing of the state space (the state space of time and inputs), will be in rest mode also during the same period of operation.
This approach is not suitable for triggers, built on the bases of non-volatile memory, storage mechanism (for example, the accumulation of charge on the capacitance [7]), side channels, degradation, and triggers with external control (for example, via radio). The authors propose to circumvent the first of these variants by visual inspection for the presence of cells of non-volatile memory, or a special burning of such cells during assembly. Another solution is to use a manufacturing process, eliminating the realization of non-volatile memory. Any hardware used to restart the IC, as well as means of saving context during the period of on/off switching must be trusted.
Also "security guards" are proposed, which randomly changes the order of events and introduce a fictitious event into the input sequences of the various modules, for example, in the memory controller, so that saved or loaded sequences are violated. These "guards" protect from the activation of trigger of sequenced type.
In conclusion, the authors of [4] propose to use multiple versions of untested hardware blocks of IC developed by different designers. Outputs from the module are verified through comparison between themselves and the true value is determined by a voting. The disadvantages of this approach is high cost due to the increase in chip area and high power consumption of IC. The authors tried to cover all aspects of the activation of hardware Trojans, however, completely bypassed the issues related to the activation through side channels and external trigger activation.
In [8] a secure architecture of system bus is proposed for SoC chips. Its peculiarity lies in the fact that the bus changes its state (master/slave) for the detection of a hardware Trojan, which is trying to block it using the standard control commands. Such activity is easily detected using updated counters and simple heuristic algorithms, which then forms a black list of suspicious master/slave devices on the bus with the submission of the report. The proposed approach was tested on a Advanсed Micro-controller Bus Architecture (AMBA) of ARM company. Such countermeasures are focused on a specific architectural feature and a special class of hardware Trojans, prevent the intervention of the backdoors into the correct operation of the SoC bus and therefore affect the performance of the entire system.
A number of researchers have considered the placement of the "guards" of the memory bus in the processor architecture, solving the task of preventing activation of the Trojan and data leakage.
In [9] it is proposed to insert so-called "shadow entries", a related entries for all memory instructions. The addresses of these shadow entries are encrypted versions of the original records. The core of the gatekeeper (hardware implementation) located on the memory bus, verifies that all memory entries have occurred for the respective encrypted addresses. Thus, the gatekeeper ensures execution of only legitimate entries, thereby preventing leakage of confidential information via a hardware Trojan. The circuit of the gatekeeper must be fully tested. The authors have developed a fully functional prototype that executes x86 instructions and included gatekeeper circuit, which has detected all of the shadow entries. However, this approach is based on the fact that the data output supposes their writing to memory (to send over the network, for example), but in practice it may also occur with the use of side channels, for example, by analyzing changes in consumption or changes in time characteristics.
Double protection between the CPU and the data bus is proposed in [10]. Two security devices have independent keys and check each other for correctness. Executable programs are encrypted at the same time on two "guards" with different keys, the data is decrypted on the way to the CPU and encrypted on the way back to memory. The system assumes the absence of correlation between the guards. The hardware compiler is a critical part of the system, forming a binary code, BIOS commands, and images of operating system immediately before execution. Double protection eliminates the need to trust both guards, more important is the absence of "collusion" between them. To study this approach a simulator of computer architecture with open source SimpleScalar was used.
In 2003, in [11] was presented AEGIS processor architecture in which it is possible to use an untested plug-in peripheral devices as well as run an untested operating system. Using primitive encryption, it acts as a guard between itself and all unreliable peripheral devices. The main difficulty of such an implementation is that IC of such a CPU should be completely free from hardware backdoors.
As you can see, the idea of the use of a minimum proven computing base (TCB, Trusted Computing Base) or tested hardware to counter hardware backdoors, is the basic condition for each of these countermeasures. The discussed mechanisms of memory protection against hardware Trojans can be extended to other channels of data transmission and hardware modules inside the IC. The authors of [12] have developed this idea by introducing the concept of the Silicon Security Harness (by analogy with the seat belts in the car). The proposed concept includes several levels of protection and monitoring which are provided by the hardware and system components, or are implemented as part of the architecture. It is designed to provide protective measures and increase resistance to hardware backdoors.
NEW ARCHITECTURES AT RTL-LEVEL
In several works, to protect against hardware Trojans, it is proposed making special modifications to the processor architecture or IC. The basis of this approach is the addition or change of logical gates to identify the presence or the to prevent activation of hardware backdoors.
In [13] a comprehensive software and hardware, the BlueChip, is proposed to counter hardware Trojans. This defensive strategy includes safety components both during development and during system operation to counteract hardware Trojans with arbitrary localization, at RTL-level. The developed algorithm of UCI (Untrusted Circuit Identification) and the toolkit automatically detects and removes potentially malicious circuits in the project at RTL-level for processor ICs. All suspicious schemes, which are included in the project, but do not affect any outputs during testing are detected and removed during verification of the project. Removed hardware devices are replaced with logic that causes an exception (unexpected error) if the removed area is activated. This can occur due to the potential activation of a Trojan or permit access to the system, initialized by the removed fragment. Low-level software by emulation try to reconstruct and to predict the consequences of the action of suspicious areas, using a small set of proven instructions.
The BlueChip conception was tested on a Leon3 processor (Aeroflex Gaisler AB) developed on the base of Xilinx Virtex5 FPGA. Safety in this concept is mainly provided by trusted software components, and only partially by trusted hardware, which are used to emulate the remote fragments. The strategy is best suitable for CPU projects, where the software emulation for the study of exceptions is possible. For dissemination of the approach to the general case of the IC design a trusted coprocessor can be used, which will identify exceptions and emulate removed hardware devices. The BlueChip concept also needs to be improved, because the malicious hardware are known [14], which cannot be detected by the UCI algorithm and successfully passes the verification.
With this regard, in [15] it states that there are no mechanisms of protection against Trojans, guaranteeing their discovery before start of use IC. The authors propose to detect attacks related to the presence of Trojans in ICs in the process of their use by adding additional integrated logic blocks, which perform a self-test of IC and search of hardware backdoors. Such additional logic, called DEFENSE (DEsign-For-Enabling-Security) is integrated into the SoC to perform real-time configurable security checks through the multiplexing of the various parts of the system with the verification block. For example, the legality of access and the legitimacy of the state, situations associated with DoS error messages, and the system integrity can be checked. In the case of detection of an attack, the real-time countermeasures are taken, for example, suspicious logical blocks are disabled. The authors also propose to use a failover states, backup logical units, copying of the current state when an attack is detected. The comprehensive coverage of all kinds of hardware attacks in real time is a difficult enough task, so the prototype of DEFENSE platform was not created. No less difficult is the implementation of such countermeasures in real time without interrupting the operation of the IC.
In [16] it is proposed to use the unique checksum of hardware for a limited period of time using trusted hardware. This hardware checksum is calculated for the involved low-level microelements of the processor. The hardware is queried, and the checksum is determined for a limited time. The authors believe that the original checksum may not be emulated or simulated in a limited time, and only the authentic hardware can correctly respond. The mechanism guarantees that Trojans haven't been added after manufacturing of the IC. To ensure such control, called MSF (Micro-Architecture Signature Function), and to generate a unique response to the request, the new instructions for the processor were developed. However, this approach does not allow to detect Trojans inserted in the project at stages of specification, development, verification or manufacturing.
In [10], during considering threats associated with "denial of service" attack (DoS attack), a special function of "heartbeat" is developed to check the continuity of operation of IC. Non-cacheable memory accesses are added to the software, after which these signals appear on the memory bus as a regular, but random intervals, which are used to detect fact of a DoS attack.
RECONFIGURABLE ARCHITECTURE
The use of reconfigurable logic to counter hardware Trojans has significant benefits, but poses new challenges at the stage of design. There is a spectrum of reconfigurable logic devices, including:
• FPGA of high logic density, where most part of the device is reprogrammable;
• target FPGAs containing fixed semiconductor elements, e.g., memory controllers, and even entire processor cores;
• custom ASIC that may contain small reconfigurable parts to perform certain functions, such as implementing a binding logic circuits or a custom element for joint processing.
The main advantage of reconfigurable logic is the possibility of separation between design of IC and its hardware implementation. If the design of a standard IC is passed directly to the chip production, then, in the case of reconfigurable logic, programmable logic unit or a macro block is inserted into the IC before start of manufacturing, and after production it is programmed by configurable bitstream completing the hardware implementation of the project. This separation means that the project can be developed almost entirely in the trusted environment, except for some peripheral functions that are added to the main logical elements.
The approach provides full control of the project at the RTL-level, but the development and inclusion of reconfigurable logic are subject to the same threats from hardware Trojans, which are characteristic of standard ASIC. However, the attacker can execute only a general attacks against the architecture of the reconfigurable logic, which hinders the smooth intervention or modification of logic operations of configured project. But it is possible to undertake the full range of attacks: to change functionality, to change the specification, to steal confidential information and to perform DoS attacks. So, for example, the changes in the logic elements can lead to additional logical operations that are potentially dangerous and leading to the emergence of hidden errors in the project, or to the leakage of information through peripheral devices.
Thus, there is a new problem: how best to implement reliable project, knowing that the underlying reconfigurable logic can be infected by arbitrary hardware Trojan, and how to protect the integrity of the project after it is created, that is, to protect the bitstream from distortion or infection with a Trojan. General three-step approach to ensuring the integrity of the bitstream of the FPGA is proposed in [17]. First, the integrity of the configuration is checked by the reverse reading, secondly, in case of detection of incorrect configuration, the FPGA is partially modificeres (from original parts of the bitstream), and thirdly, if the system was compromised, the FPGA uses the request-response protocol for notifying a third party.
In [18] a review of the solutions on the protection of the bitstream of the FPGA and configuration memory from the event failures is proposed. The authors make the following conclusions:
• if the manufacturing of the FPGA and design of IC on an FPGA are completely separated, or third party’s IP blocks are used, the attacker can easy make changes to any project;
• reverse engineering of configuration bitstreams is quite difficult both for the attacker, making impossible for him to understand the purpose of IC, and for search of backdoors;
• the bitstreams can be encrypted, which provides good protection, and then the internal hardware decoding of the bitstream is possible in many of the FPGA's. However, this encryption does not allow partial reconfiguration, therefore, is not applicable for applications such as adaptive computing, which are an important niche for FPGA. Encryption of the bitstream does not protect against the penetration of hardware Trojans through IP blocks of third-party developers.
To identify the authenticity of the developed project it is proposed to use the additional configuration logic blocks (CLB) in the FPGA based on error correction code (ECC), which form an group for parity checking. Checking the parity of each element of the CLB allows to reveal all changes in the project. Two-stage randomization that is used to generate the parity signal, ensures the unpredictability of the result of the CLB.
In [19] the protection against hardware Trojans at the manufacturing stage is proposed. If to place a reconfigurable logic blocks between critical elements in the project, then some reconfigurable architecture in some areas of the chip is visible at the production stage. These blocks that are called "the barriers" by the authors are programmed after manufacture with use of a secret key that leads to the unlock of the project and its logical completion. If the location and functionality of these barriers are chosen optimally, then it will be difficult to activate any inserted hardware Trojans, and we can block their impact on IC. The authors pay special attention to the type of reprogrammable logic, key management, and various heuristic methods of placing barriers. Combining permanent and programmed logic, we can develop unique solutions against potential hardware Trojans. At the same time, reconfigurable logic can be used for the implementation of local protective mechanisms.
The use of reconfigurable logic as a protection against hardware backdoors poses new challenges for design and verification, and moves the focus from the semiconductor manufacturing to the RTL project. To implement an effective hardware backdoor on the level of IC in this case, an attacker would have to provide the relationship (agreement) between the manufacturer and software supplier. Implementation of a complex reconfigurable logical project, usually is based on the integration of multiple IP blocks. In [20] the idea of "moats and drawbridges" as isolation primitives is proposed, which are used in case of multiple IP blocks. They help block illegal arms and interconnects inside the reconfigurable blocks.
Let's list some other approaches with the use of reconfigurable logic that can be used for combating hardware Trojans:
• partial and dynamic reprogramming of the logic blocks[21];
• encrypting the configuration bitstreams [18];
• replication and lock-stepping of logic [22];
• use of functionally identical, but having different architecture logic blocks [23];
• generation of unambiguous hardware modules with the use of random numbers [24].
REPLICATION OF PARTS, FRAGMENTATION AND VOTING
Development of effective hardware Trojans requires understanding of the operation of the IC project from the level of gates, RTL level, IC level, and ending with the macro level of the entire system. At all these levels to combating hardware Trojans the following general approaches can be applied:
• replication or doubling of logic and/or data;
• separation or fragmentation of logic and/or data;
• dispersion or distribution of logic and/or data;
• accumulation and merging of logical functions and/or data, for example, using the voting.
These general countermeasures are effective in three cases:
• for protection against hardware Trojans, leading to the leaking of confidential information by separating the data and its processing by independent logical elements;
• for protection against functional or specificational modifications of elements using multiple copies or duplicates of the logical blocks;
• for protection against DoS attacks by setting a redundancy operating logical elements in the project.
These countermeasures may be placed at different levels: gate, RTL, logic design, functional modules, IP cores, up to the level of IC and devices on the macro level. Protection mechanisms assume that there is no "collusion" between replicated or duplicated elements in the project.
Method of dynamic evaluation of verification of the equipment during its operation is proposed in [23]. Its essence lies in the detection of hardware Trojan in the system, after which it continues to operate with the removal or small use of suspicious items. The authors propose to use a multi-core data processing system with redundancy, rejecting the cores that are not credible. Functionally equivalent versions of the processes are performed on multiple processors with comparison of their results. Different variants of the same CPU processings can be performed based on different compilations or implementations. Different data processing algorithms can also be used. If the results of the two elements differ, the calculations are carried out at the third element with comparison of the three results. This process continues until you reach the conformity at least between two elements of data processing. Processor elements that give inconsistent (incorrect) results are dynamically "penalized", i.e., "trust" to them is less and they are used less.
This method can be extended with the use of random sampling of variants of functionally equivalent hardware. It can also be applied at different levels of abstraction, for example, of instructions, gate, software, or IC. If the method is used on the command level, the activity on it can be transparent to higher levels, including for small trusted computing base (TSB), which can verify command level schedules, selection of the replication blocks, options specification, and voting.
In [22] it is proposed a FPGA-based configuration of dual-processor architecture with direct connections, which at the macrolevel is an implementation of replication and voting. Both processors receive and process the same instructions at the same time. Hardware-implemented logic checks and compares all of the control signals of each transaction on the bus. If an error is detected, the system is forcibly introduced into the sequence to fix the error. For adequate counteraction to hardware Trojans a complete verification of TSB-blocks of detecting and fixing errors must be carried out. The method can be extended for a larger number of processors, which can be single ICs or parts of the same FPGA.
In 1991, in [25] the issues of high reliability and efficiency, as well as the preservation of data privacy in large distributed systems was studied. The threats associated with hardware Trojans, have not been considered, however, the proposed methods of fault tolerance are relevant to counter unauthorized backdoors. The general approach involves dividing the data into small fragments, so that each of them contains rather little information. It can be used both for data storage and processing (accordingly, they are grouped as fragments for the storage and processing). Replication (redundancy) of fragments is used to ensure the reliability of the system. Threshold schemes like a "secret sharing" (e.g. [26]) are proposed for rearranging the stored and processed data. In this case, determination of fragmentation functions of general purpose is quite difficult and expensive computational process. Such a mechanism can be implemented in the form of computational elements on discrete hardware. In this case, the TSB includes the inputs and outputs for processing and storage of operations.
CONCLUSION
Currently, there is no single solution that can provide complete protection against the entire spectrum of threats and mechanisms of activation of the hardware backdoors during operation of the system. It is unlikely that such a solution will ever be found, and a combination of countermeasures is necessary to counter specific classes of hardware Trojans in specific application areas. These countermeasures should be developed taking into account systems in which they are applied, and also given the provided level of protection. As it is shown in [14], the development of new countermeasures in a natural way creates ways to work around them. This "arms race" in the field of hardware Trojans necessitates the use of integrated "deeply layered" approaches to security of electronic systems. ■
This paper was created with the financial support of the Ministry of Education and Science of the Russian Federation within the framework of the state order 16.9021.2017/БЧ.
The most publications associated with this kind of counteraction to hardware Trojans, consider the protection against only one class or subclass of the threats. It is assumed that greater security will provided by a multilevel defense in which each level irrespective of others focused on specific actions and mechanisms of activation of Trojans, followed by combining all these measures into an overall strategy of protection.
Proposed and experimentally tested mechanisms of countermeasures can be divided into the following groups:
• data protection;
• new architecture at the RTL-level (register-transfer level);
• reconfigurable architecture;
• strategies of replication, fragmentation and voting.
DATA PROTECTION
Protection of data (including processor commands) involves the prevention of the activation of a hardware Trojan or/and blocking direct access of Trojan equipment to any vulnerable data. The protective device can control data stored or transmitted within or between ICs and logical modules, and block mechanism by which the Trojan interacts with the data.
In [4] several methods of protection of data by preventing activation of a Trojan are proposed. Some of these methods were implemented on the Zesto x86 simulator. To prevent the receiving an activation code by Trojan a scrambling (encryption) of information channel (bus) is used. It is used for data processing units that are not involved in the calculations. The authors propose to use simple trusted encryption schemes to hide data (for example, XOR with pseudo-random numbers – Xorshif encryption), secretive them only for a short time.
The effectiveness of this scrambling was investigated by introducing parameterized delay in the cache and the memory controller. The scrambling of the bus prevented the activation of simple Trojans, however, this possibility still remained. For example, when using a simple 32-bit trigger, activation will occur for 232 cycles. A more controlled approach could be implemented through the override of all inputs into a fully functionally reliable state space using the trusted and stable encryption schemes.
Since such data obfuscation will lead to wrong calculations in computing units, in this case, it is proposed to use homomorphic encryption [5], which allows computing units to work with encrypted data. Encryption is determined as homomorphic by the computing function and computing unit obtain the correct results only with encrypted values. The final result can be decrypted.
The implementation of such homomorphic functions is not a trivial task, and their computation is costly, and it is quite difficult to build a scheme of homomorphic encryption for general use. In the same way as in the case of scrambling of data bus, the encryption and decryption blocks must be implemented in a fully tested hardware. The authors of [4] did not consider homomorphic encryption, but instead have proposed and analyzed the use of a cryptographic algorithm with a public key (RSA-encryption). The use of schemas that implement the Yao's Garbled Circuit algorithm [6], can be considered as an alternative approach for obfuscation of data of the computing blocks.
It is also proposed in [4] to use a "time protection" to prevent activation of a hardware Trojan within a confirmed state space. The IC is checked for complete functional reliability for a specified number of cycles. In the future, when IC reaches this number of cycles, the circuit is deactivated and activated, thereby avoiding temporary activation of a Trojan. The hardware solution allows to save context during the period of the outage, providing continuity of the computational process. The authors make the assumption that any hardware Trojan, which was in rest mode at the complete testing of the state space (the state space of time and inputs), will be in rest mode also during the same period of operation.
This approach is not suitable for triggers, built on the bases of non-volatile memory, storage mechanism (for example, the accumulation of charge on the capacitance [7]), side channels, degradation, and triggers with external control (for example, via radio). The authors propose to circumvent the first of these variants by visual inspection for the presence of cells of non-volatile memory, or a special burning of such cells during assembly. Another solution is to use a manufacturing process, eliminating the realization of non-volatile memory. Any hardware used to restart the IC, as well as means of saving context during the period of on/off switching must be trusted.
Also "security guards" are proposed, which randomly changes the order of events and introduce a fictitious event into the input sequences of the various modules, for example, in the memory controller, so that saved or loaded sequences are violated. These "guards" protect from the activation of trigger of sequenced type.
In conclusion, the authors of [4] propose to use multiple versions of untested hardware blocks of IC developed by different designers. Outputs from the module are verified through comparison between themselves and the true value is determined by a voting. The disadvantages of this approach is high cost due to the increase in chip area and high power consumption of IC. The authors tried to cover all aspects of the activation of hardware Trojans, however, completely bypassed the issues related to the activation through side channels and external trigger activation.
In [8] a secure architecture of system bus is proposed for SoC chips. Its peculiarity lies in the fact that the bus changes its state (master/slave) for the detection of a hardware Trojan, which is trying to block it using the standard control commands. Such activity is easily detected using updated counters and simple heuristic algorithms, which then forms a black list of suspicious master/slave devices on the bus with the submission of the report. The proposed approach was tested on a Advanсed Micro-controller Bus Architecture (AMBA) of ARM company. Such countermeasures are focused on a specific architectural feature and a special class of hardware Trojans, prevent the intervention of the backdoors into the correct operation of the SoC bus and therefore affect the performance of the entire system.
A number of researchers have considered the placement of the "guards" of the memory bus in the processor architecture, solving the task of preventing activation of the Trojan and data leakage.
In [9] it is proposed to insert so-called "shadow entries", a related entries for all memory instructions. The addresses of these shadow entries are encrypted versions of the original records. The core of the gatekeeper (hardware implementation) located on the memory bus, verifies that all memory entries have occurred for the respective encrypted addresses. Thus, the gatekeeper ensures execution of only legitimate entries, thereby preventing leakage of confidential information via a hardware Trojan. The circuit of the gatekeeper must be fully tested. The authors have developed a fully functional prototype that executes x86 instructions and included gatekeeper circuit, which has detected all of the shadow entries. However, this approach is based on the fact that the data output supposes their writing to memory (to send over the network, for example), but in practice it may also occur with the use of side channels, for example, by analyzing changes in consumption or changes in time characteristics.
Double protection between the CPU and the data bus is proposed in [10]. Two security devices have independent keys and check each other for correctness. Executable programs are encrypted at the same time on two "guards" with different keys, the data is decrypted on the way to the CPU and encrypted on the way back to memory. The system assumes the absence of correlation between the guards. The hardware compiler is a critical part of the system, forming a binary code, BIOS commands, and images of operating system immediately before execution. Double protection eliminates the need to trust both guards, more important is the absence of "collusion" between them. To study this approach a simulator of computer architecture with open source SimpleScalar was used.
In 2003, in [11] was presented AEGIS processor architecture in which it is possible to use an untested plug-in peripheral devices as well as run an untested operating system. Using primitive encryption, it acts as a guard between itself and all unreliable peripheral devices. The main difficulty of such an implementation is that IC of such a CPU should be completely free from hardware backdoors.
As you can see, the idea of the use of a minimum proven computing base (TCB, Trusted Computing Base) or tested hardware to counter hardware backdoors, is the basic condition for each of these countermeasures. The discussed mechanisms of memory protection against hardware Trojans can be extended to other channels of data transmission and hardware modules inside the IC. The authors of [12] have developed this idea by introducing the concept of the Silicon Security Harness (by analogy with the seat belts in the car). The proposed concept includes several levels of protection and monitoring which are provided by the hardware and system components, or are implemented as part of the architecture. It is designed to provide protective measures and increase resistance to hardware backdoors.
NEW ARCHITECTURES AT RTL-LEVEL
In several works, to protect against hardware Trojans, it is proposed making special modifications to the processor architecture or IC. The basis of this approach is the addition or change of logical gates to identify the presence or the to prevent activation of hardware backdoors.
In [13] a comprehensive software and hardware, the BlueChip, is proposed to counter hardware Trojans. This defensive strategy includes safety components both during development and during system operation to counteract hardware Trojans with arbitrary localization, at RTL-level. The developed algorithm of UCI (Untrusted Circuit Identification) and the toolkit automatically detects and removes potentially malicious circuits in the project at RTL-level for processor ICs. All suspicious schemes, which are included in the project, but do not affect any outputs during testing are detected and removed during verification of the project. Removed hardware devices are replaced with logic that causes an exception (unexpected error) if the removed area is activated. This can occur due to the potential activation of a Trojan or permit access to the system, initialized by the removed fragment. Low-level software by emulation try to reconstruct and to predict the consequences of the action of suspicious areas, using a small set of proven instructions.
The BlueChip conception was tested on a Leon3 processor (Aeroflex Gaisler AB) developed on the base of Xilinx Virtex5 FPGA. Safety in this concept is mainly provided by trusted software components, and only partially by trusted hardware, which are used to emulate the remote fragments. The strategy is best suitable for CPU projects, where the software emulation for the study of exceptions is possible. For dissemination of the approach to the general case of the IC design a trusted coprocessor can be used, which will identify exceptions and emulate removed hardware devices. The BlueChip concept also needs to be improved, because the malicious hardware are known [14], which cannot be detected by the UCI algorithm and successfully passes the verification.
With this regard, in [15] it states that there are no mechanisms of protection against Trojans, guaranteeing their discovery before start of use IC. The authors propose to detect attacks related to the presence of Trojans in ICs in the process of their use by adding additional integrated logic blocks, which perform a self-test of IC and search of hardware backdoors. Such additional logic, called DEFENSE (DEsign-For-Enabling-Security) is integrated into the SoC to perform real-time configurable security checks through the multiplexing of the various parts of the system with the verification block. For example, the legality of access and the legitimacy of the state, situations associated with DoS error messages, and the system integrity can be checked. In the case of detection of an attack, the real-time countermeasures are taken, for example, suspicious logical blocks are disabled. The authors also propose to use a failover states, backup logical units, copying of the current state when an attack is detected. The comprehensive coverage of all kinds of hardware attacks in real time is a difficult enough task, so the prototype of DEFENSE platform was not created. No less difficult is the implementation of such countermeasures in real time without interrupting the operation of the IC.
In [16] it is proposed to use the unique checksum of hardware for a limited period of time using trusted hardware. This hardware checksum is calculated for the involved low-level microelements of the processor. The hardware is queried, and the checksum is determined for a limited time. The authors believe that the original checksum may not be emulated or simulated in a limited time, and only the authentic hardware can correctly respond. The mechanism guarantees that Trojans haven't been added after manufacturing of the IC. To ensure such control, called MSF (Micro-Architecture Signature Function), and to generate a unique response to the request, the new instructions for the processor were developed. However, this approach does not allow to detect Trojans inserted in the project at stages of specification, development, verification or manufacturing.
In [10], during considering threats associated with "denial of service" attack (DoS attack), a special function of "heartbeat" is developed to check the continuity of operation of IC. Non-cacheable memory accesses are added to the software, after which these signals appear on the memory bus as a regular, but random intervals, which are used to detect fact of a DoS attack.
RECONFIGURABLE ARCHITECTURE
The use of reconfigurable logic to counter hardware Trojans has significant benefits, but poses new challenges at the stage of design. There is a spectrum of reconfigurable logic devices, including:
• FPGA of high logic density, where most part of the device is reprogrammable;
• target FPGAs containing fixed semiconductor elements, e.g., memory controllers, and even entire processor cores;
• custom ASIC that may contain small reconfigurable parts to perform certain functions, such as implementing a binding logic circuits or a custom element for joint processing.
The main advantage of reconfigurable logic is the possibility of separation between design of IC and its hardware implementation. If the design of a standard IC is passed directly to the chip production, then, in the case of reconfigurable logic, programmable logic unit or a macro block is inserted into the IC before start of manufacturing, and after production it is programmed by configurable bitstream completing the hardware implementation of the project. This separation means that the project can be developed almost entirely in the trusted environment, except for some peripheral functions that are added to the main logical elements.
The approach provides full control of the project at the RTL-level, but the development and inclusion of reconfigurable logic are subject to the same threats from hardware Trojans, which are characteristic of standard ASIC. However, the attacker can execute only a general attacks against the architecture of the reconfigurable logic, which hinders the smooth intervention or modification of logic operations of configured project. But it is possible to undertake the full range of attacks: to change functionality, to change the specification, to steal confidential information and to perform DoS attacks. So, for example, the changes in the logic elements can lead to additional logical operations that are potentially dangerous and leading to the emergence of hidden errors in the project, or to the leakage of information through peripheral devices.
Thus, there is a new problem: how best to implement reliable project, knowing that the underlying reconfigurable logic can be infected by arbitrary hardware Trojan, and how to protect the integrity of the project after it is created, that is, to protect the bitstream from distortion or infection with a Trojan. General three-step approach to ensuring the integrity of the bitstream of the FPGA is proposed in [17]. First, the integrity of the configuration is checked by the reverse reading, secondly, in case of detection of incorrect configuration, the FPGA is partially modificeres (from original parts of the bitstream), and thirdly, if the system was compromised, the FPGA uses the request-response protocol for notifying a third party.
In [18] a review of the solutions on the protection of the bitstream of the FPGA and configuration memory from the event failures is proposed. The authors make the following conclusions:
• if the manufacturing of the FPGA and design of IC on an FPGA are completely separated, or third party’s IP blocks are used, the attacker can easy make changes to any project;
• reverse engineering of configuration bitstreams is quite difficult both for the attacker, making impossible for him to understand the purpose of IC, and for search of backdoors;
• the bitstreams can be encrypted, which provides good protection, and then the internal hardware decoding of the bitstream is possible in many of the FPGA's. However, this encryption does not allow partial reconfiguration, therefore, is not applicable for applications such as adaptive computing, which are an important niche for FPGA. Encryption of the bitstream does not protect against the penetration of hardware Trojans through IP blocks of third-party developers.
To identify the authenticity of the developed project it is proposed to use the additional configuration logic blocks (CLB) in the FPGA based on error correction code (ECC), which form an group for parity checking. Checking the parity of each element of the CLB allows to reveal all changes in the project. Two-stage randomization that is used to generate the parity signal, ensures the unpredictability of the result of the CLB.
In [19] the protection against hardware Trojans at the manufacturing stage is proposed. If to place a reconfigurable logic blocks between critical elements in the project, then some reconfigurable architecture in some areas of the chip is visible at the production stage. These blocks that are called "the barriers" by the authors are programmed after manufacture with use of a secret key that leads to the unlock of the project and its logical completion. If the location and functionality of these barriers are chosen optimally, then it will be difficult to activate any inserted hardware Trojans, and we can block their impact on IC. The authors pay special attention to the type of reprogrammable logic, key management, and various heuristic methods of placing barriers. Combining permanent and programmed logic, we can develop unique solutions against potential hardware Trojans. At the same time, reconfigurable logic can be used for the implementation of local protective mechanisms.
The use of reconfigurable logic as a protection against hardware backdoors poses new challenges for design and verification, and moves the focus from the semiconductor manufacturing to the RTL project. To implement an effective hardware backdoor on the level of IC in this case, an attacker would have to provide the relationship (agreement) between the manufacturer and software supplier. Implementation of a complex reconfigurable logical project, usually is based on the integration of multiple IP blocks. In [20] the idea of "moats and drawbridges" as isolation primitives is proposed, which are used in case of multiple IP blocks. They help block illegal arms and interconnects inside the reconfigurable blocks.
Let's list some other approaches with the use of reconfigurable logic that can be used for combating hardware Trojans:
• partial and dynamic reprogramming of the logic blocks[21];
• encrypting the configuration bitstreams [18];
• replication and lock-stepping of logic [22];
• use of functionally identical, but having different architecture logic blocks [23];
• generation of unambiguous hardware modules with the use of random numbers [24].
REPLICATION OF PARTS, FRAGMENTATION AND VOTING
Development of effective hardware Trojans requires understanding of the operation of the IC project from the level of gates, RTL level, IC level, and ending with the macro level of the entire system. At all these levels to combating hardware Trojans the following general approaches can be applied:
• replication or doubling of logic and/or data;
• separation or fragmentation of logic and/or data;
• dispersion or distribution of logic and/or data;
• accumulation and merging of logical functions and/or data, for example, using the voting.
These general countermeasures are effective in three cases:
• for protection against hardware Trojans, leading to the leaking of confidential information by separating the data and its processing by independent logical elements;
• for protection against functional or specificational modifications of elements using multiple copies or duplicates of the logical blocks;
• for protection against DoS attacks by setting a redundancy operating logical elements in the project.
These countermeasures may be placed at different levels: gate, RTL, logic design, functional modules, IP cores, up to the level of IC and devices on the macro level. Protection mechanisms assume that there is no "collusion" between replicated or duplicated elements in the project.
Method of dynamic evaluation of verification of the equipment during its operation is proposed in [23]. Its essence lies in the detection of hardware Trojan in the system, after which it continues to operate with the removal or small use of suspicious items. The authors propose to use a multi-core data processing system with redundancy, rejecting the cores that are not credible. Functionally equivalent versions of the processes are performed on multiple processors with comparison of their results. Different variants of the same CPU processings can be performed based on different compilations or implementations. Different data processing algorithms can also be used. If the results of the two elements differ, the calculations are carried out at the third element with comparison of the three results. This process continues until you reach the conformity at least between two elements of data processing. Processor elements that give inconsistent (incorrect) results are dynamically "penalized", i.e., "trust" to them is less and they are used less.
This method can be extended with the use of random sampling of variants of functionally equivalent hardware. It can also be applied at different levels of abstraction, for example, of instructions, gate, software, or IC. If the method is used on the command level, the activity on it can be transparent to higher levels, including for small trusted computing base (TSB), which can verify command level schedules, selection of the replication blocks, options specification, and voting.
In [22] it is proposed a FPGA-based configuration of dual-processor architecture with direct connections, which at the macrolevel is an implementation of replication and voting. Both processors receive and process the same instructions at the same time. Hardware-implemented logic checks and compares all of the control signals of each transaction on the bus. If an error is detected, the system is forcibly introduced into the sequence to fix the error. For adequate counteraction to hardware Trojans a complete verification of TSB-blocks of detecting and fixing errors must be carried out. The method can be extended for a larger number of processors, which can be single ICs or parts of the same FPGA.
In 1991, in [25] the issues of high reliability and efficiency, as well as the preservation of data privacy in large distributed systems was studied. The threats associated with hardware Trojans, have not been considered, however, the proposed methods of fault tolerance are relevant to counter unauthorized backdoors. The general approach involves dividing the data into small fragments, so that each of them contains rather little information. It can be used both for data storage and processing (accordingly, they are grouped as fragments for the storage and processing). Replication (redundancy) of fragments is used to ensure the reliability of the system. Threshold schemes like a "secret sharing" (e.g. [26]) are proposed for rearranging the stored and processed data. In this case, determination of fragmentation functions of general purpose is quite difficult and expensive computational process. Such a mechanism can be implemented in the form of computational elements on discrete hardware. In this case, the TSB includes the inputs and outputs for processing and storage of operations.
CONCLUSION
Currently, there is no single solution that can provide complete protection against the entire spectrum of threats and mechanisms of activation of the hardware backdoors during operation of the system. It is unlikely that such a solution will ever be found, and a combination of countermeasures is necessary to counter specific classes of hardware Trojans in specific application areas. These countermeasures should be developed taking into account systems in which they are applied, and also given the provided level of protection. As it is shown in [14], the development of new countermeasures in a natural way creates ways to work around them. This "arms race" in the field of hardware Trojans necessitates the use of integrated "deeply layered" approaches to security of electronic systems. ■
This paper was created with the financial support of the Ministry of Education and Science of the Russian Federation within the framework of the state order 16.9021.2017/БЧ.
Readers feedback
