D efending against malicious hardware
description
Transcript of D efending against malicious hardware
Defending against malicious hardware
Sam King
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
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?
Hardware as complex as software
Malicious hardware
HW
Circuit designed
Malicious hardware
HW HW
Circuit designed
Attack inserted
Malicious hardware
HW HW HW
Test cases
Test cases
Circuit designed
Attack inserted
Suspicious circuits
identified and removedDesign Time
Malicious hardware
HW HW HW HW
Test cases
Test cases
BlueChip
BlueChip
Circuit designed
Attack inserted
Suspicious circuits
identified and removed
Hardware triggers
emulation software
OS
Design Time Run Time
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
Remove unused circuits
• If identified circuits are attacks, works• If identified circuits are legit, might not work
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
BlueChip run time HW and SW make forward progress
HWBlueChip rem HW detection
BlueChip emul. softwareOS
BlueChip software emulates around removed hardware
BlueChip hardware detects inconsistent states
BlueChip does NOT emulate the removed hardware
BlueChip DOES emulate the behavior of the hardware spec at a higher level of
abstraction
BlueChip uses redundancy in processor to make forward progress
PC: 1000…R3: 0x2R4:R5: 0x4…
Processor
// get registersregs = processor_regs()
// fetch instructioninst = *(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
PC: 1004…R3: 0x2R4: 0x6R5: 0x4…
Processor
1000: or r3, r5, r4
Software emulation of OR inst.
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
BlueChip handles false positives
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
UCI – finding suspicious circuits
• Intuition – try to find circuits that are part of the design but are never activated during design time testing
Invariant: priv == out for test cases
Will UCI miss attacks?
Example of how UCI is broken
m0
m1
i0
i1
i0 f
f = (i0 V i1) V (m0 Λ m1)
AND
OR
OR
OR
Practical Attackif (holdn = ‘1’) thensuper <= in.super;
end ifif resetn = ‘0’ thensuper <= ‘1’;
end if
super <= ~reset V (holdn Λ in.super) V (~holdn Λ super)
f = (i0 V i1)
Practical Attack
super <= ~reset V (holdn Λ in.super) V (~holdn Λ super)
i0
i1
m0 : previous instruction is or r0, r0, 0x0m1 : current instruction is or r0, r0, 0x0
V (m0 Λ m1)
Practical Attack
~reset
(holdn Λ in.super) V (~holdn Λ super)super
prev
curr
(holdn Λ in.super) V (~holdn Λ super)
AND
OR
OR
OR
BlueChip emulation of OR inst.
AddOr r3, r5, r4Sub…
…Load regs[3], t1Load regs[5], t2Xor t1, 0xffffffff, t1Xor t2, 0xffffffff, t2Nand t1, t2, t3Store t3, regs[4]// update pc and npc// commit regs
BlueChip software