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