CCS'16 ~ Private Circuits III: Hardware Trojan-Resilience Via Testing
Total Page：16
File Type：pdf, Size：1020Kb
Private Circuits III: Hardware Trojan-Resilience via Testing Amplification Stefan Dziembowski Sebastian Faust François-Xavier Standaert University of Warsaw University of Bochum Université catholique de Louvain Institute of Informatics Fakultät für Mathematik ICTEAM – Crypto Group [email protected] [email protected] [email protected] ABSTRACT has recently gained attention, since the increasing complex- Security against hardware trojans is currently becoming an ity of electronic systems, and the ongoing trend of outsourc- essential ingredient to ensure trust in information systems. ing chip fabrication to a few specialized foundries, has made A variety of solutions have been introduced to reach this it more and more realistic, with possibly catastrophic conse- goal, ranging from reactive (i.e., detection-based) to pre- quences for security and safety [2, 8]. As documented in [7, ventive (i.e., trying to make the insertion of a trojan more 28] the attacks by a malicious manufacturer are also hard to difficult for the adversary). In this paper, we show how test- prevent, since they can lead to very diverse attack vectors, ing (which is a typical detection tool) can be used to state with various activation mechanisms and payloads. concrete security guarantees for preventive approaches to In this context, and looking back at the already broad lit- trojan-resilience. For this purpose, we build on and formal- erature on countermeasures against side-channel and fault ize two important previous works which introduced \input attacks, an important lesson learned is that the most ef- scrambling" and \split manufacturing" as countermeasures fective protections usually rely on a good separation of du- to hardware trojans. Using these ingredients, we present ties between well-chosen (generally physical) assumptions a generic compiler that can transform any circuit into a and sound mathematical principles to amplify them. Taking trojan-resilient one, for which we can state quantitative se- one emblematic example, masking improves security against curity guarantees on the number of correct executions of the side-channel attacks by relying on the assumption that phys- circuit thanks to a new tool denoted as \testing amplifica- ical leakages are noisy, and by amplifiying this noise thanks tion". Compared to previous works, our threat model covers to secret sharing [13]. Based on the similar (physical) na- an extended range of hardware trojans while we stick with ture of hardware trojans, it is therefore reasonable to expect the goal of minimizing the number of honest elements in that solutions to prevent them may follow a similar path. our transformed circuits. Since transformed circuits essen- In this respect, and starting at the hardware level, detection tially correspond to redundant multiparty computations of thanks to side-channels possibly amplified by some finger- the target functionality, they also allow reasonably efficient printing has been studied, e.g., in [1, 3, 26]. Very summa- implementations, which can be further optimized if special- rized, such approaches are powerful in the sense that they ized to certain cryptographic primitives and security goals. are in principle able to detect any type of trojan, including purely physical ones (e.g., triggered by a temperature change 1. INTRODUCTION and sending secret messages through an undocumented an- While modern cryptography generally assumes adversaries tenna), which makes them an important part of the puzzle. with black box access to their target primitives, the last two But they are also inherently limited by their heuristic na- decades have witnessed the emergence of increasingly pow- ture and sometimes strong assumptions. For example, they erful physical attacks that circumvent this abstract model. work best in presence of a golden (trusted) chip that may Side-channel analysis [23, 24] and fault attacks [10, 9] are not be easily available, and the effectiveness of the detection typical examples of such concerns, where the adversary can decreases when reducing the size of the trojan circuitry. respectively observe physical leakages produced by an imple- In this paper, we therefore tackle the question whether mentation, or force it to perform erroneous computations. more formal solutions can help to rule out well-defined classes In this respect, hardware trojan attacks can be viewed as of hardware trojan attacks, and achieve stronger resistance the ultimate physical attack, where the adversary can even in practice. For this purpose, we build on two important modify the implementations at design time, in order to hide previous works. In the first one, Waksman and Sethumad- a backdoor that may be used after deployment. This threat havan consider digitally triggered trojan attacks [30]. A dig- itally triggered trojan is a malicious piece of hardware that Permission to make digital or hard copies of all or part of this work for personal or delivers its payload when a digital input is given to the de- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation vice. This can be done, for instance, through so-called\cheat on the first page. Copyrights for components of this work owned by others than the codes" or \time bombs". The first type of attack triggers author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or the malicious behavior of the trojan when a certain input republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. is provided to the device, while \time bombs" activate the CCS’16, October 24 - 28, 2016, Vienna, Austria trojan, e.g., after the device is executed for a certain num- c 2016 Copyright held by the owner/author(s). Publication rights licensed to ACM. ber of times. The work of Waksman and Sethumadhavan ISBN 978-1-4503-4139-4/16/10. $15.00 provides ad-hoc countermeasures against these two types of DOI: http://dx.doi.org/10.1145/2976749.2978419 142 attacks. In particular, they propose to scramble the inputs the number of executions for which the output produced by to defeat the cheat codes and use power resets to protect the device has to be identical to the honest specification Γ. against (volatile) time bombs. In the second one, Imeson et Typically, for our constructions we require t > n. al. introduce the concept of \split manufacturing" for obfus- cation, as a way to make it hard for an adversary to identify A trojan protection scheme for any functionality Γ. the gates of an implementation that he would need to mod- Our main contribution is the design of a trojan protection ify to mount his attack [20]. The main contribution of our scheme that achieves robustness for any functionality Γ. We work is to provide generic countermeasures for significantly next give a high-level description of our trojan protection broader classes of trojan attacks, and to provide a formal scheme omitting several technical details. As a first step, the transformation compiles the specifica- framework in which these countermeasures can be analyzed 0 1 2 and concrete security bounds can be derived. We describe tion Γ into three so-called mini-circuits (Γ ; Γ ; Γ ). These our technical contribution in more detail below. mini-circuits emulate Γ using a passively secure 3-party pro- tocol, where the inputs to (Γ0; Γ1; Γ2) are secret-shared by Types of hardware trojans. Similar to Waksman and the trusted master circuit M. Sethumadhavan, we consider a setting where the produc- The first observation in order to achieve robustness is that tion of a device is outsourced to a potentially malicious if the mini-circuits Γi follow exactly the secure 3-party proto- hardware manufacturer. The manufacturer produces a set col, then they do not learn anything about the user provided of devices D1;:::; D` that supposedly implement function- input. Hence, a malicious user is hindered in activating the i alities Γ1;:::; Γ`, but may contain trojans and react ma- trojan by choosing a special input. Of course, once Γ gets liciously. As in [30] we restrict the type of malicious be- implemented by A nothing stops A to produce devices Di havior to hardware trojans that are digitally triggered, such that do not follow the protocol, e.g., by transmitting their as cheat codes or time bombs. Besides formally modeling shares to the other devices. Such a behavior will, however, such digitally triggered trojans, we also extend the model be detected with good probability during the testing phase. of Waksman and Sethumadhavan by not only considering The above only prevents activation of the trojan by a ma- volatile time bombs (i.e., where the clock needs to be pow- licious input, but does not deal yet with an activation via ered) but also non-volatile ones (which may become hard to time-bombs. For instance, assume that the trojan is acti- detect in highly integrated electronic systems). vated only after the (t + 1)-th execution. If we test devices The trojan protection schemes. To protect against dig- only for t times, the malicious behavior will not be detected and achieving robustness is infeasible. To circumvent this, itally triggered hardware trojans we introduce so-called tro- 0 0 jan protection schemes. A trojan protection scheme consists we randomize the number of tests t , where t is drawn uni- of two components: a circuit transformation TR and a tester formly from f1; : : : ; tg. Since (i) the total number of exe- T. The transformation describes a method to compile an cutions after testing is bounded by n and (ii) test and real arbitrary functionality described as an arithmetic circuit Γ executions look the same from the device's point of view (due into a protected specification consisting of a trusted master to the 3-party computation), we can bound the probability that malicious behavior is triggered by time bombs.