1. Defending against malicious hardware
Sam King

3. People involved with research
DHOSA Team
Matt Hicks, Murph Finnicum, 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
Latest SPARC over million LOC
Intel core 2 duo average 3 bugs / month for last few years

6. Malicious hardware HW
Circuit designed

7. Malicious hardware HW HW
Circuit designed
Attack inserted

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

9. Malicious hardware Circuit designed Attack inserted
Test cases
Test cases OS
BlueChip
BlueChip HW HW HW HW
Circuit designed
Attack inserted
Suspicious circuits identified and removed
Hardware triggers emulation software
UCI – algorihtm for detecting suspicious circuits
Defeating UCI – security analysis of the UCI algorithm, show that it is broken
BlueChip – hardware / software system for removing suspicious circuits from hardware components
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
Our solution is to remove these circuits from the hardware design

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 progressOS
BlueChip emul. software
BlueChip rem HW detection HW
Hardware component that can effectively remove circuits from the hardware source code of a design, but it does it in a way that can detect if the circuit is activated and can stop the execution of the processor before it enters an inconsistent state.
When BlueChip hardware detects that the removed hardware has an effect it will pass control to BlueChip software, which will emulate around the removed hardware
In the interest of time I am going to skip the discussion about the BlueChip hardware and instead talk briefly about the BlueChip software
BlueChip hardware detects inconsistent states
BlueChip software emulates around removed hardware

14. BlueChip does NOT emulate the removed hardware

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

16. BlueChip uses 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
Classic VMM technique called trap and emulate.
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
Interesting result – there are some circuits that we can remove that would have affected the running of the circuit. Turns out these are from the transitions between user mode and supervisor mode
Interesting result – Blue chip actually works! Removed seemingly random circuits from a design and we can still make forward progress despite this!!!!!

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

22. Key insight here is that the attacker is unlikely to trigger the attack during testing, or else the verification test would show that the priv bit is 1 when it should not be

23. Invariant: priv == out for test cases

24. Will UCI miss attacks?

25. Example of how UCI is brokenOR i1 OR m0 m1
AND i0 OR
Key idea: if you have a circuit that is (i_0 V i_1), then you can replace it with the circuit shown in this slide. The net effect is that the m_0 and m_1 inputs act as a trigger for the attack where the circuit does what it is supposed to unless m_0 and m_1 are both 1, then it will output 1
f = (i0 V i1) V (m0 Λ m1)

26. Practical Attack
if (holdn = ‘1’) then super <= in.super; end if if resetn = ‘0’ then super <= ‘1’;
This slide shows part of the logic for setting the supervisor mode bit in the Leon3 SPARC processor. This VHDL code can be expressed as a boolean formula also.
super <= ~reset V (holdn Λ in.super) V (~holdn Λ super)

27. Practical Attack i0 i1 f = (i0 V i1) V (m0 Λ m1)
super <= ~reset V (holdn Λ in.super) V (~holdn Λ super) i1
f = (i0 V i1)
We can map this to the circuit we showed originally
V (m0 Λ m1)
m0 : previous instruction is or r0, r0, 0x0
m1 : current instruction is or r0, r0, 0x0

28. Practical Attack OR OR AND OR (holdn Λ in.super) V (~holdn Λ super)
~reset OR
prev
AND
curr
Result is that when we assert curr and prev we can transition the Leon3 processor into supervisor mode. This circuit evades UCI and passes the SPARC certification test cases. 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