Circuit CAD Tools as a Security Threat University of Michigan † and Rice University ‡ June 9, 2008 Jarrod A. Roy †, Farinaz Koushanfar ‡ and Igor L. Markov † June 9, 2008 Jarrod A. Roy †, Farinaz Koushanfar ‡ and Igor L. Markov †

Trusted Computing Breaches of hardware security increasing Cell-phone tapping of Greek officials Kinko’s key logger Compromised weapons systems Electronic voting irregularities Push for open-source EDA Easy to spoof binaries and libraries Emerging technology must be tamper-resistant Smart cards, RFIDs, e-cash, … Demand for trusted computing increasing Key logger sold by ThinkGeek

Software vs. Hardware Exploitation Both target unauthorized control of a system, but … Software exploits are well-studied Anti-virus and anti-malware programs effective, quickly updated for new threats Removal usually possible Complete system reinstall as a last resort Compromised hardware more challenging Can be designed to resist modern detection techniques Removal may not be possible Post-silicon fixes slow, expensive May need to completely replace

Anatomy of a Hardware Trojan Trigger: activates the exploit Special input sequence Time Payload: performs the intended action Replace logic Dump sensitive data Inject faults Memory: storage for the exploit Trigger patterns Compromised data Side channel buffer Detection avoidance

Avoiding Detection Trojans can be considered design errors Can standard verification techniques catch them? Bounded Model Checking (BMC) Simulate circuit for several cycles, check output against golden model Defeated by: add binary counter and trigger exploit after several days or weeks Design for Test (DFT) Test circuit after manufacture Use scan chains and automatic test pattern generation (ATPG) Defeated by: insert before ATPG –Trojan is now fault-tested!

Injecting Trojan Horses Designs can be altered at nearly any flow stage By compromised tools Logic synthesis tools can add payload logic Routers can introduce shorts, opens Or the scripts that run them Preprocess Verilog Postprocess gate-level netlist First step of injection is target detection Pattern-matching in text files, e.g., Verilog Pattern-matching distinctive circuits Combinational equivalence checking

Case Study: Compromising Crypto Circuits Cryptographic circuits have many unique elements: Large quantities of XOR gates, bit shifts and bit permutations Distinctive “magic” constants Changing one constant can disable randomness, for example Application“Magic” constants or formulas Linear congruential PRNG Mersenne twister MT19937 algorithm 397, 624, , , , MD5 hash 0x , 0x , 0x98BADCFE, 0xEFCDAB89 SHA-256 hash 0x1F83D9AB, 0x3C6EF372, 0x510E527F, 0x5BE0CD19, 0x6A09E667, 0x9B05688C, 0xA54FF53A, 0xBB67AE85 x n+1 = × x n mod x n+1 = × x n mod

Compromising Crypto Circuits Identifying bit permutations DES uses at least six distinctive 32-bit permutations Carefully crafted attack on DES could remove permutations, exposing plaintext Substitution functions Easily identified by magic constants or equivalence checking AES uses several S-boxes Compromised with standard fault injection techniques

Countermeasures Attackers can defeat static testing techniques Leverage short avg. test time, difficulty of 100% verification Solution: dynamic verification The DIVA approach [Weaver & Austin 2001] Add simple circuit to verify in real-time Small enough to be known correct On error, begin analysis and recovery Or shut down completely for data security Verifier Error? Inputs and Outputs

Conclusions High demand for trusted computing Military, medicine, voting, … Attackers can modify CAD tool flows to inject Trojans Automatically recognize certain circuit types Magic numbers, permutations, substitution functions, … Inject targeted changes/faults Trivially resistant to modern test techniques Dynamic verification helps Verify all outputs of untrusted circuits Will slow but not necessarily stop attacks Total solution an open challenge

Questions?