D efending against malicious hardware

1. Defending against malicious hardware Sam King

3. People involved with research • DHOSA Team • Matt Hicks, MurphFinnicum, Sam King • Illinois • Cynthia Sturton, David Wagner • Berkeley • Other participants • Milo Martin, Jonathan Smith • Upenn

4. Building secure systems • We make assumptions designing secure systems • Break secure system, break assumptions • E.g., look for crypto keys in memory • People assume hardware is correct • What if we break this assumption?

5. Hardware as complex as software

6. Malicious hardware HW Circuit designed

7. Malicious hardware HW HW Circuit designed Attack inserted

8. Malicious hardware Test cases Test cases HW HW HW Circuit designed Attack inserted Suspicious circuits identified and removed Design Time

9. Malicious hardware Test cases Test cases OS BlueChip BlueChip HW HW HW HW Circuit designed Hardware triggers emulation software Attack inserted Suspicious circuits identified and removed Design Time Run Time

10. Finding suspicious circuits • Similar to testing hardware • Come up with some metrics, test • Code coverage, unused circuits, and so on • Tough problem when circuits are malicious • Proposed algorithm, UCI (Oakland 2010) • Adversarial analysis of UCI (Oakland 2011) • We found that UCI was broken • Output: suspicious circuits

11. Remove unused circuits • If identified circuits are attacks, works • If identified circuits are legit, might not work

12. Remove unused circuits • If identified circuits are attacks, works • If identified circuits are legit, might not work • Soln: use existing CPU mechanisms, redundancy for forward progress

13. BlueChip run time HW and SW make forward progress OS BlueChipemul. software BlueChiprem HW detection HW BlueChip hardware detects inconsistent states BlueChip software emulates around removed hardware

14. BlueChip does NOTemulate the removed hardware

15. BlueChipDOES emulate the behavior of the hardware spec at a higher level of abstraction

16. BlueChipuses redundancy in processor to make forward progress

17. Software emulation of OR inst. Processor PC: 1000 … R3: 0x2 R4: R5: 0x4 … // get registers regs = processor_regs() // fetch instruction inst = *(regs[PC]) // decode operands (op, rd, rs1, rs2) = decode(inst) if( op == OR) { // execute instruction regs[rd] = regs[rs1] | regs[rs2] regs[PC] += 4 } else if( op == AND) { … } … // commit regs to processor 1000: or r3, r5, r4 Processor PC: 1004 … R3: 0x2 R4: 0x6 R5: 0x4 …

18. Problem: recursive BlueChip faults • Emulating an instruction using the same instruction could cause another fault • Solution: use different instructions for emu. • Alternative ALU operations • Implement word size load/store using byte size

19. BlueChip handles false positives

20. Conclusions and future work • BlueChip– runtime system to enable defenders to remove hardware safely • Currently trying to generalize BlueChip • Use emulation testing for our emulator • Using formal methods for building our emulator • Use SVA to isolate emulator within malicious OS

21. UCI – finding suspicious circuits • Intuition – try to find circuits that are part of the design but are never activated during design time testing

23. Invariant: priv == out for test cases

24. Will UCI miss attacks?

25. Example of how UCI is broken i0 f OR i1 OR m0 AND m1 OR i0 f = (i0V i1) V (m0Λm1)

26. Practical Attack if (holdn = ‘1’) thensuper <= in.super; end if if resetn = ‘0’ thensuper <= ‘1’; end if • super <= ~reset V(holdnΛin.super) V (~holdnΛ super)

27. Practical Attack i0 • super <= ~reset V(holdnΛin.super) V (~holdnΛ super) i1 f = (i0V i1) V (m0Λm1) • m0 : previous instruction isor r0, r0, 0x0 • m1 : current instruction is or r0, r0, 0x0

28. Practical Attack (holdnΛin.super) V (~holdnΛ super) super OR ~reset OR prev AND curr OR (holdnΛin.super) V (~holdnΛ super)

29. BlueChip emulation of OR inst. Add Or r3, r5, r4 Sub … BlueChip software … Load regs[3], t1 Load regs[5], t2 Xor t1, 0xffffffff, t1 Xor t2, 0xffffffff, t2 Nand t1, t2, t3 Store t3, regs[4] // update pc and npc // commit regs