rus
In the third part of a series of articles devoted to Hardware Trojans the most effective methods to prevent and to detect them are considered.
Теги: hardware backdoor hardware trojan integrated circuit аппаратная закладка аппаратный троян интегральная схема кибербезопасность
Hardware Trojans pose a significant security risk, so the most effective measure to combat them is to prevent introducing them in the IC design. Prevention is the first level of protection against hardware Trojans and an important link in the multi-layered security strategy. According to the traditional rules, procedures and practical experience, in order to maintain control over the IC development, trusted teams of developers, design tools and trusted productions should be involved. However, special research on new methods of prevention of the introduction of hardware Trojans is undertaken at various stages of IC design and manufacture.
PREVENTION OF HARDWARE TROJANS AT DESIGN STAGE
At the design stage the hardAt the design stage, a hardware backdoor can be introduced in a project by a development team member, untested software for the IC development, or through inclusion in the project of some unverified third-party intellectual property modules (IP modules). The creation of the checked schemes (without hardware Trojans) using untested IC CAD tools is discussed in [1]. The proposed solution is based on the use of CAD tools for the complex synthesis and very simple proven programme created by the developer to control the results and identify possible modifications introduced in the project. The key idea is to create such project specifications which would exclude adding any malicious scheme by unverified CAD tools. Full specification should assume that the hardware resources of the project should be fully involved in all strokes. The method is based on the fact that it is easy enough to check whether a project uses all the resources (NP-complete problem), similar to that it is difficult to find a solution for a NP-complete problem but it is relatively easy to verify whether the solution will be suitable.
The main problem with this approach is that it is quite possible [2] to build a hardware Trojan using only logic already involved in the project. It is relatively easy to develop a programme to check that a project is using all available hardware resources, but it is quite difficult to determine whether there are no malicious changes.
A similar approach, although using obfuscation methods, is discussed in detail in [3]. The correct functionality (normal mode) is hidden behind a secret initiating sequence, any deviation from which switches IC to the irrecoverable "obfuscation mode" in the status column. The difference between this approach and the one described above is that the obfuscation technique uses dead states but not the desire to use all available logic gates. This simplifies its implementation and also allows you to make a simple change in the project out of sequence. This approach does not protect against possible changes to the source code, and they cannot be detected by a special analysis of the design through reverse engineering after producing IC.
PREVENTION AT STAGE
OF MANUFACTURE
Some issues concerning the IC manufacture at untested production are considered in [4]. The authors have proposed a system that provides the developer consuming IP modules with the specification on hardware used in it as well as a list of so-called "properties relating to confidentiality". Both the supplier and consumer of IP modules agree to translate these properties into a formal mathematical code in the "automatic proof" language. Since the developer of an IP module writes an HDL code, it carries out a formal proof that the specified hardware performs all the required properties. They can be checked through the automatic proof programme when an IP module will be delivered to the consumer. This idea is similar to the programme verification based on the PCC code (proof-carrying code) [5]. Linking the formal project model with the project specification can lead to some more correct implementation of IC. However, as the authors note, it is the supplier of an IP module who is to create a formal model, and you should be fully confident in its reliability and that it does not add any hardware backdoor in the project or in a proof code. Otherwise, it will be quite difficult to detect such a hardware backdoor.
PREVENTIVE MEASURES
AFTER IC MANUFACTURE
In [2] considered is a concept of implementing IC using reconfigurable logic (it is specified after IC manufacture) which is located between the outputs of a pattern and the inputs of another one. By doing so, a project can be protected against an intruder that has access to the description at the register transfer level. This approach can be considered as a countermeasure and as a method of prevention during the IP operation with a hardware Trojan. In terms of preventive qualities, this method leaves an intruder in the uncertainty without the knowledge of the reconfigurable logic circuit thus narrowing the scope of possible attacks.
Even making great efforts, it is difficult to completely prevent the implementation of a hardware Trojan in IC. However, the best results in the complex countermeasures to hardware Trojans can be achieved by excluding it in IC.
DETECTING HARDWARE TROJANS
Along with preventive measures against the Trojans in any project or in IC, there are methods for detecting them. In identifying a hardware Trojan can be removed from the project (if found in the description at the register transfer level) or ICs with Trojan may not be used or may be used also with the hardware Trojan. Depending on the detection mechanism, a hardware Trojan can be identified, or the likelihood of changes in the project may be statistically estimated.
Traditional testing and verification of IC are aimed at checking compliance with technical requirements and specifications. Some additional functional features of IC are usually not checked. Talking into account all the space of states, in which the extra functions may be hidden, such testing is feasible only for smaller logic projects.
Currently, there is no common approach to guarantee detection of all hardware Trojans. Most studies have focused on finding the hardware Trojans after manufacturing IC since this stage is seen as the weakest link in the full cycle of IC development and production. A small part of research is dedicated to the detection of hardware Trojans in the original RTL (Register Transfer Language) code to design the project synthesis (translation of a project written at the register transfer level into the binary no-sheet code for templates), or directly in the manufacture of IC. It is expected that there is complete trust to the personnel in charge of the search for Trojans, and the search for hardware Trojans is a trusted expert procedure which should include a project assessment at the register transfer level as well as the project simulation behaviour study.
During the individual design of hardware Trojans, attempt to circumvent any existing and emerging R&D methods for detecting Trojans will be made. It is a kind of arms race, like the one we are witnessing in the antivirus software industry. Fig. shows the classification of modern hardware Trojans detection methods [3].
DESTRUCTIVE DETECTION METHODS
The destructive methods involve the detection of hardware Trojans that lead to the complete destruction of IC. Complete destruction greatly limits their application. To be sure that the IC does not contain any hardware Trojan, it is examined by reverse engineering. However, reverse engineering of our today’s complex ICs is quite a time-consuming and expensive process. Usually, it is carried out by the chemical and mechanical polishing methods with the subsequent reconstruction and analysis of the IC topology using a scanning electron microscope. In most cases, the chip "correctness" is set by visual comparison with the reference or a benchmark IC. However, if a hardware Trojan was introduced just before the manufacture (hence, it will be found in all the manufactured ICs), visual comparison will not be helpful.
Only some IC may be subjected to the hardware modifications. In this case, a reverse engineering method can only give limited grounds to assert that IC does not contain a hardware Trojan. In this regard, in [6] it is proposed to use destructive reverse engineering to determine "good" IC. Before performing any reverse engineering, indirect IC sampling characteristics are randomly examined, e.g. the profiles of power consumption, temperature, electromagnetic radiation and leakage currents. As a result, for each IC, a set of characteristics, fingerprint can be obtained. If there is some distribution of the selected characteristics, then all samples from the sample are subjected to reverse engineering to check for hardware Trojans. In the future, belonging of the IC fingerprint to a typical distribution (for both "good" and "infested" IC) can be used for non-destructive IC sorting in a lot.
The described approach does not solve a number of problems. For example, hardware Trojans can be implemented by adding, removing or modifying only two logic gates [7], while modern IC consists of one billion gates. Search for a "needle in a haystack" requires complete reverse engineering of IC at the gate level, and it can be much more expensive than the IC development and production. On the other hand, there is no guarantee that the IC fingerprint with the hardware Trojan will be different from any non-infested IC against the background of increasing dispersion of IC performances, which is due to a decrease in the typical linear dimension.
NON-DESTRUCTIVE
DETECTION METHODS
Non-destructive methods for the detection of hardware Trojans do not lead to a violation of the IC integrity, and are classified as invasive and non-invasive. The non-invasive methods do not change the IC project while the invasive ones can be characterised by making changes to the project in order to add functions that contribute to the Trojan detection.
Invasive methods are divided into two classes, preventive and auxiliary. Auxiliary methods are used in order to make it easier to detect the Trojan in the tests after IC manufacturing. In [3] a scheme is proposed that allows you to detect a hardware Trojan in a multi-modal project. This is achieved by using additional inputs and outputs which are added to each module. Additional inputs provide a "key" which translates a module into the "transparent mode". In this mode, the module performs self-testing of a circuit designed in such a way as to check the rare and unlikely event status. After the end of self-testing, at the module output there is a signature that includes the input key and self-testing results. This signature is then successively supplied to the input of the next module as input "key". Thus, a simple special input key entered at the main entrance will test the entire system, and the test result shows a single value at the main output. The authors argue that this method is effective against an attacker who has the information about the functional and logical structure of IC.
In practice, the logic allowing you to check the expanded space of states, which can manifest a hardware Trojan, provides very little protection from the targeted instrument bug. As discussed in this section, the likelihood of finding a professionally designed hardware Trojan is quite low. In addition, this method assumes that the hardware Trojan will be brought at a specific design stage. However, an attacker can insert Trojans after the development of a functional design of the module but before the development of the logic of the fingerprint definition.
In [8] a method based on the addition to the design of the dead trigger circuit, which results in an increased hardware Trojan activity during activation, is proposed. This makes its detection through the side channels easier. In [9], for the detection of a hardware backdoor through the side channels an additional circuit, which characterises the IC delay time changing in the event of a Trojan, is proposed.
Non-invasive methods for the detection of hardware Trojans are based on a comparison of IC operating performances with the characteristics of the knowingly operational benchmark IC. Detection with the non-invasive method can be carried out during the IC operation or during IC testing. The detection mechanisms of during the IC operation largely overlap with the methods of counteracting hardware Trojans. If a hardware Trojan is found, you can try to continue the IC operation with it. Detection during the test is based on the improvement of traditional testing or an analysis of the side characteristics of the IC (side channel).
In [10] it details the approach to detect hardware Trojans using hardware and software. The strategy can detect only two types of attacks. DoS (Denial of Service) attacks are detected using a small customised protection circuit on the memory bus, which is programmed to respond to the episodic "survivability" pings. Failure to respond within the specified time is seen as a successful attempt to detect DoS attacks. Combined attacks using hardware and software when a hardware Trojan disables memory protection, and the software Trojan can extend its privileges can be found by testing whether or not non-privileged programmes can get access to the memory sections close for them. This approach also requires changes to the operating system to work with a protection circuit.
ANALYSIS OF INDIRECT CHARACTERISTICS
An analysis of the indirect IC characteristics (an analysis of side channels) in contrast to the immediate activation of the hardware Trojan, for the purpose of detecting it, exploits the fact that the injected activation trigger mechanism changes some characteristic of IC irrespective of whether or not the Trojan is activated. The amount of power consumed by different parts of the IC, the amount of heat generated in certain areas, or the time required by certain modules to perform operations (delay) are typical examples of the secondary characteristics of IC that can be used for the analysis. This kind of analysis appears to provide the best probability of hardware Trojan detection since it does not require any activation.
In [11] it shows a typical example of the considered Trojan detection mechanism. Initially IC samples are researched without hardware Trojans, the benchmark IC, and one or more characteristic of the secondary characteristics, the so-called "fingerprints" are taken. Then, other chips are tested, and their fingerprint are compared with the benchmark ones. In order to select statistically significant (but well hidden) differences, various statistical methods can be used. The authors, in particular, used the IC power consumption used as the main indirect characteristic. The obvious drawback of the method is that you should be completely sure that the benchmark IC is not infected.
Another indirect IC feature, the transient power consumption feature was analysed in [12]. The objective is to determine the smallest hardware Trojan which can be detected by the proposed method. The tests that emulate the work of a particular experimental IC have shown that this method can be used to detect the minimum hardware Trojan consisting of three gates.
In [13] a method to enhance the difference between the indirect characteristics of IC, which has no hardware Trojans, and the same IC but infected with a Trojan, was proposed. Power consumption was examined as an indirect feature. The so-called method of a sustainable vector periodically applied to individual IC inputs was used. After some time of supplying, IC reaches the stable state. This procedure is called by the authors "switching minimisation". By changing the input vector, you can use different IC sections. Changing the difference of the consumed power with the benchmark sample indicates foreign hardware devices in the tested section of the IC, that is identified are chains which are active but they should not be active.
The analysis and use as an indirect characteristic of IC and its fingerprint of the signal delay were studied in [14]. The authors looked at two categories of hardware Trojans with explicit and implicit loads. Trojans with obvious useful load directly influence the circuit to which they are attached (e.g. change the value of the control or data signals). Hardware Trojans with implicit useful load do not make immediate changes to the circuit but may, for example, read information through side channels or perform DoS-attack when initialising. The authors argue that they can detect 100% explicit and 36% of implicit hardware Trojans but the experiments were conducted on simulators (simulation programmes), and the Trojans were simple modifications specially designed and affecting power consumption and path delay. In a similar paper [15] leakage current and path delay were considered as indirect characteristics and a side channel.
Another approach is described in [3]. The authors measured the integration current, time dependence of the electric charge in the IP nodes and used the data obtained from different parts of the circuit to make an analysis and search for the Trojan chain. The analysis also took into account the data taken from the benchmark IC not containing any Trojans. The authors have stated that they can detect the added hardware Trojans with the size of "a few gates" occupying 0.1% of the area of the entire IC.
The main problem of the method for analysing the indirect characteristics for the detection of the hardware Trojans is that it is totally dependent on the presence of a true benchmark IC which can be used for comparison and evaluation. If a hardware Trojan was added anywhere before the manufacturing stage and is therefore contained in each IC, the method in question is not applicable. Furthermore, the search space using this method can be very large. Despite the challenging developments and the use of modern statistical methods for determining differences in the characteristics of the modified and true IC, the likelihood of detecting this difference is very low, especially if the hardware Trojan is well designed and has a purpose.
CONCLUSION
Thus, studies aimed at the detection of hardware Trojans, are mainly devoted to destructive methods and approaches that use side channels and auxiliary methods in the testing phase of IC. Detection mechanisms are often focused on a particular class of hardware Trojans, there is no common method or combination of methods, which could ensure a wide coverage in identifying unauthorized bookmarks.
The most effective way to prevent any hardware Trojans in the IC is careful control of the whole cycle of development and manufacture. Small trusted team of developers using in-house software tools and libraries can create the IC project that is guaranteed free from hardware bookmarks. The implementation of this project on the proven crystal production (managed by a small group of trusted persons) will provide right and reliable products. Final assembly and packaging of microchips and their subsequent use only by persons who are completely trusted by the customer, will provide complete confidence that the original project was implemented without the malicious changes.
For a country like Russia, which is not a leader in the semiconductor industry, it is possible to close the cycle from design to manufacturing only for small projects of specialized IC, so the share of ICs made in cooperation with foreign partners, will increase. In this regard, the probability of insertion of hardware Trojans will increase. To ensure safe operation of electronic equipment it is extremely important to develop methods of control that will be able to securely guarantee the authenticity of the used ICs.
Also other approach based on use of the certified commercial electronic components (COTS – Commercial Off The Shelf) is possible. The commercial sector uses the vast libraries of IP cores for quick development of new and more functional devices (e.g., smartphones). If defensive sector will develop and use only their own IP cores, then the military developments related to electronics would be far behind commercial civil products. So it makes sense to develop only some ICs, such as the crypto chips with a small number of logical gates, where the completely proven cycle of development/manufacturing is possible. However, in this case theft, reverse engineering, modification during manufacturing and substitution of original IC through an unreliable chain of suppliers and intermediaries are also possible. ■
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/БЧ.
PREVENTION OF HARDWARE TROJANS AT DESIGN STAGE
At the design stage the hardAt the design stage, a hardware backdoor can be introduced in a project by a development team member, untested software for the IC development, or through inclusion in the project of some unverified third-party intellectual property modules (IP modules). The creation of the checked schemes (without hardware Trojans) using untested IC CAD tools is discussed in [1]. The proposed solution is based on the use of CAD tools for the complex synthesis and very simple proven programme created by the developer to control the results and identify possible modifications introduced in the project. The key idea is to create such project specifications which would exclude adding any malicious scheme by unverified CAD tools. Full specification should assume that the hardware resources of the project should be fully involved in all strokes. The method is based on the fact that it is easy enough to check whether a project uses all the resources (NP-complete problem), similar to that it is difficult to find a solution for a NP-complete problem but it is relatively easy to verify whether the solution will be suitable.
The main problem with this approach is that it is quite possible [2] to build a hardware Trojan using only logic already involved in the project. It is relatively easy to develop a programme to check that a project is using all available hardware resources, but it is quite difficult to determine whether there are no malicious changes.
A similar approach, although using obfuscation methods, is discussed in detail in [3]. The correct functionality (normal mode) is hidden behind a secret initiating sequence, any deviation from which switches IC to the irrecoverable "obfuscation mode" in the status column. The difference between this approach and the one described above is that the obfuscation technique uses dead states but not the desire to use all available logic gates. This simplifies its implementation and also allows you to make a simple change in the project out of sequence. This approach does not protect against possible changes to the source code, and they cannot be detected by a special analysis of the design through reverse engineering after producing IC.
PREVENTION AT STAGE
OF MANUFACTURE
Some issues concerning the IC manufacture at untested production are considered in [4]. The authors have proposed a system that provides the developer consuming IP modules with the specification on hardware used in it as well as a list of so-called "properties relating to confidentiality". Both the supplier and consumer of IP modules agree to translate these properties into a formal mathematical code in the "automatic proof" language. Since the developer of an IP module writes an HDL code, it carries out a formal proof that the specified hardware performs all the required properties. They can be checked through the automatic proof programme when an IP module will be delivered to the consumer. This idea is similar to the programme verification based on the PCC code (proof-carrying code) [5]. Linking the formal project model with the project specification can lead to some more correct implementation of IC. However, as the authors note, it is the supplier of an IP module who is to create a formal model, and you should be fully confident in its reliability and that it does not add any hardware backdoor in the project or in a proof code. Otherwise, it will be quite difficult to detect such a hardware backdoor.
PREVENTIVE MEASURES
AFTER IC MANUFACTURE
In [2] considered is a concept of implementing IC using reconfigurable logic (it is specified after IC manufacture) which is located between the outputs of a pattern and the inputs of another one. By doing so, a project can be protected against an intruder that has access to the description at the register transfer level. This approach can be considered as a countermeasure and as a method of prevention during the IP operation with a hardware Trojan. In terms of preventive qualities, this method leaves an intruder in the uncertainty without the knowledge of the reconfigurable logic circuit thus narrowing the scope of possible attacks.
Even making great efforts, it is difficult to completely prevent the implementation of a hardware Trojan in IC. However, the best results in the complex countermeasures to hardware Trojans can be achieved by excluding it in IC.
DETECTING HARDWARE TROJANS
Along with preventive measures against the Trojans in any project or in IC, there are methods for detecting them. In identifying a hardware Trojan can be removed from the project (if found in the description at the register transfer level) or ICs with Trojan may not be used or may be used also with the hardware Trojan. Depending on the detection mechanism, a hardware Trojan can be identified, or the likelihood of changes in the project may be statistically estimated.
Traditional testing and verification of IC are aimed at checking compliance with technical requirements and specifications. Some additional functional features of IC are usually not checked. Talking into account all the space of states, in which the extra functions may be hidden, such testing is feasible only for smaller logic projects.
Currently, there is no common approach to guarantee detection of all hardware Trojans. Most studies have focused on finding the hardware Trojans after manufacturing IC since this stage is seen as the weakest link in the full cycle of IC development and production. A small part of research is dedicated to the detection of hardware Trojans in the original RTL (Register Transfer Language) code to design the project synthesis (translation of a project written at the register transfer level into the binary no-sheet code for templates), or directly in the manufacture of IC. It is expected that there is complete trust to the personnel in charge of the search for Trojans, and the search for hardware Trojans is a trusted expert procedure which should include a project assessment at the register transfer level as well as the project simulation behaviour study.
During the individual design of hardware Trojans, attempt to circumvent any existing and emerging R&D methods for detecting Trojans will be made. It is a kind of arms race, like the one we are witnessing in the antivirus software industry. Fig. shows the classification of modern hardware Trojans detection methods [3].
DESTRUCTIVE DETECTION METHODS
The destructive methods involve the detection of hardware Trojans that lead to the complete destruction of IC. Complete destruction greatly limits their application. To be sure that the IC does not contain any hardware Trojan, it is examined by reverse engineering. However, reverse engineering of our today’s complex ICs is quite a time-consuming and expensive process. Usually, it is carried out by the chemical and mechanical polishing methods with the subsequent reconstruction and analysis of the IC topology using a scanning electron microscope. In most cases, the chip "correctness" is set by visual comparison with the reference or a benchmark IC. However, if a hardware Trojan was introduced just before the manufacture (hence, it will be found in all the manufactured ICs), visual comparison will not be helpful.
Only some IC may be subjected to the hardware modifications. In this case, a reverse engineering method can only give limited grounds to assert that IC does not contain a hardware Trojan. In this regard, in [6] it is proposed to use destructive reverse engineering to determine "good" IC. Before performing any reverse engineering, indirect IC sampling characteristics are randomly examined, e.g. the profiles of power consumption, temperature, electromagnetic radiation and leakage currents. As a result, for each IC, a set of characteristics, fingerprint can be obtained. If there is some distribution of the selected characteristics, then all samples from the sample are subjected to reverse engineering to check for hardware Trojans. In the future, belonging of the IC fingerprint to a typical distribution (for both "good" and "infested" IC) can be used for non-destructive IC sorting in a lot.
The described approach does not solve a number of problems. For example, hardware Trojans can be implemented by adding, removing or modifying only two logic gates [7], while modern IC consists of one billion gates. Search for a "needle in a haystack" requires complete reverse engineering of IC at the gate level, and it can be much more expensive than the IC development and production. On the other hand, there is no guarantee that the IC fingerprint with the hardware Trojan will be different from any non-infested IC against the background of increasing dispersion of IC performances, which is due to a decrease in the typical linear dimension.
NON-DESTRUCTIVE
DETECTION METHODS
Non-destructive methods for the detection of hardware Trojans do not lead to a violation of the IC integrity, and are classified as invasive and non-invasive. The non-invasive methods do not change the IC project while the invasive ones can be characterised by making changes to the project in order to add functions that contribute to the Trojan detection.
Invasive methods are divided into two classes, preventive and auxiliary. Auxiliary methods are used in order to make it easier to detect the Trojan in the tests after IC manufacturing. In [3] a scheme is proposed that allows you to detect a hardware Trojan in a multi-modal project. This is achieved by using additional inputs and outputs which are added to each module. Additional inputs provide a "key" which translates a module into the "transparent mode". In this mode, the module performs self-testing of a circuit designed in such a way as to check the rare and unlikely event status. After the end of self-testing, at the module output there is a signature that includes the input key and self-testing results. This signature is then successively supplied to the input of the next module as input "key". Thus, a simple special input key entered at the main entrance will test the entire system, and the test result shows a single value at the main output. The authors argue that this method is effective against an attacker who has the information about the functional and logical structure of IC.
In practice, the logic allowing you to check the expanded space of states, which can manifest a hardware Trojan, provides very little protection from the targeted instrument bug. As discussed in this section, the likelihood of finding a professionally designed hardware Trojan is quite low. In addition, this method assumes that the hardware Trojan will be brought at a specific design stage. However, an attacker can insert Trojans after the development of a functional design of the module but before the development of the logic of the fingerprint definition.
In [8] a method based on the addition to the design of the dead trigger circuit, which results in an increased hardware Trojan activity during activation, is proposed. This makes its detection through the side channels easier. In [9], for the detection of a hardware backdoor through the side channels an additional circuit, which characterises the IC delay time changing in the event of a Trojan, is proposed.
Non-invasive methods for the detection of hardware Trojans are based on a comparison of IC operating performances with the characteristics of the knowingly operational benchmark IC. Detection with the non-invasive method can be carried out during the IC operation or during IC testing. The detection mechanisms of during the IC operation largely overlap with the methods of counteracting hardware Trojans. If a hardware Trojan is found, you can try to continue the IC operation with it. Detection during the test is based on the improvement of traditional testing or an analysis of the side characteristics of the IC (side channel).
In [10] it details the approach to detect hardware Trojans using hardware and software. The strategy can detect only two types of attacks. DoS (Denial of Service) attacks are detected using a small customised protection circuit on the memory bus, which is programmed to respond to the episodic "survivability" pings. Failure to respond within the specified time is seen as a successful attempt to detect DoS attacks. Combined attacks using hardware and software when a hardware Trojan disables memory protection, and the software Trojan can extend its privileges can be found by testing whether or not non-privileged programmes can get access to the memory sections close for them. This approach also requires changes to the operating system to work with a protection circuit.
ANALYSIS OF INDIRECT CHARACTERISTICS
An analysis of the indirect IC characteristics (an analysis of side channels) in contrast to the immediate activation of the hardware Trojan, for the purpose of detecting it, exploits the fact that the injected activation trigger mechanism changes some characteristic of IC irrespective of whether or not the Trojan is activated. The amount of power consumed by different parts of the IC, the amount of heat generated in certain areas, or the time required by certain modules to perform operations (delay) are typical examples of the secondary characteristics of IC that can be used for the analysis. This kind of analysis appears to provide the best probability of hardware Trojan detection since it does not require any activation.
In [11] it shows a typical example of the considered Trojan detection mechanism. Initially IC samples are researched without hardware Trojans, the benchmark IC, and one or more characteristic of the secondary characteristics, the so-called "fingerprints" are taken. Then, other chips are tested, and their fingerprint are compared with the benchmark ones. In order to select statistically significant (but well hidden) differences, various statistical methods can be used. The authors, in particular, used the IC power consumption used as the main indirect characteristic. The obvious drawback of the method is that you should be completely sure that the benchmark IC is not infected.
Another indirect IC feature, the transient power consumption feature was analysed in [12]. The objective is to determine the smallest hardware Trojan which can be detected by the proposed method. The tests that emulate the work of a particular experimental IC have shown that this method can be used to detect the minimum hardware Trojan consisting of three gates.
In [13] a method to enhance the difference between the indirect characteristics of IC, which has no hardware Trojans, and the same IC but infected with a Trojan, was proposed. Power consumption was examined as an indirect feature. The so-called method of a sustainable vector periodically applied to individual IC inputs was used. After some time of supplying, IC reaches the stable state. This procedure is called by the authors "switching minimisation". By changing the input vector, you can use different IC sections. Changing the difference of the consumed power with the benchmark sample indicates foreign hardware devices in the tested section of the IC, that is identified are chains which are active but they should not be active.
The analysis and use as an indirect characteristic of IC and its fingerprint of the signal delay were studied in [14]. The authors looked at two categories of hardware Trojans with explicit and implicit loads. Trojans with obvious useful load directly influence the circuit to which they are attached (e.g. change the value of the control or data signals). Hardware Trojans with implicit useful load do not make immediate changes to the circuit but may, for example, read information through side channels or perform DoS-attack when initialising. The authors argue that they can detect 100% explicit and 36% of implicit hardware Trojans but the experiments were conducted on simulators (simulation programmes), and the Trojans were simple modifications specially designed and affecting power consumption and path delay. In a similar paper [15] leakage current and path delay were considered as indirect characteristics and a side channel.
Another approach is described in [3]. The authors measured the integration current, time dependence of the electric charge in the IP nodes and used the data obtained from different parts of the circuit to make an analysis and search for the Trojan chain. The analysis also took into account the data taken from the benchmark IC not containing any Trojans. The authors have stated that they can detect the added hardware Trojans with the size of "a few gates" occupying 0.1% of the area of the entire IC.
The main problem of the method for analysing the indirect characteristics for the detection of the hardware Trojans is that it is totally dependent on the presence of a true benchmark IC which can be used for comparison and evaluation. If a hardware Trojan was added anywhere before the manufacturing stage and is therefore contained in each IC, the method in question is not applicable. Furthermore, the search space using this method can be very large. Despite the challenging developments and the use of modern statistical methods for determining differences in the characteristics of the modified and true IC, the likelihood of detecting this difference is very low, especially if the hardware Trojan is well designed and has a purpose.
CONCLUSION
Thus, studies aimed at the detection of hardware Trojans, are mainly devoted to destructive methods and approaches that use side channels and auxiliary methods in the testing phase of IC. Detection mechanisms are often focused on a particular class of hardware Trojans, there is no common method or combination of methods, which could ensure a wide coverage in identifying unauthorized bookmarks.
The most effective way to prevent any hardware Trojans in the IC is careful control of the whole cycle of development and manufacture. Small trusted team of developers using in-house software tools and libraries can create the IC project that is guaranteed free from hardware bookmarks. The implementation of this project on the proven crystal production (managed by a small group of trusted persons) will provide right and reliable products. Final assembly and packaging of microchips and their subsequent use only by persons who are completely trusted by the customer, will provide complete confidence that the original project was implemented without the malicious changes.
For a country like Russia, which is not a leader in the semiconductor industry, it is possible to close the cycle from design to manufacturing only for small projects of specialized IC, so the share of ICs made in cooperation with foreign partners, will increase. In this regard, the probability of insertion of hardware Trojans will increase. To ensure safe operation of electronic equipment it is extremely important to develop methods of control that will be able to securely guarantee the authenticity of the used ICs.
Also other approach based on use of the certified commercial electronic components (COTS – Commercial Off The Shelf) is possible. The commercial sector uses the vast libraries of IP cores for quick development of new and more functional devices (e.g., smartphones). If defensive sector will develop and use only their own IP cores, then the military developments related to electronics would be far behind commercial civil products. So it makes sense to develop only some ICs, such as the crypto chips with a small number of logical gates, where the completely proven cycle of development/manufacturing is possible. However, in this case theft, reverse engineering, modification during manufacturing and substitution of original IC through an unreliable chain of suppliers and intermediaries are also possible. ■
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
