Docstoc

Trust and Protection in the Illinois Browser Operating System - dhosa

Document Sample
Trust and Protection in the Illinois Browser Operating System - dhosa Powered By Docstoc
					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
                                        Test        Test
                                       cases       cases



HW                  HW                HW


Circuit designed    Attack inserted   Suspicious circuits
                                        identified and
                                           removed
                      Design Time
                   Malicious hardware
                                        Test       Test   OS
                                       cases      cases
                                                                   BlueChip


                                                                   BlueChip
HW                  HW                HW                  HW


Circuit designed    Attack inserted   Suspicious circuits Hardware triggers
                                        identified and emulation software
                                           removed
                      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

               OS
                      BlueChip emul. software


                     BlueChip rem HW detection
               HW




  BlueChip hardware detects inconsistent states

BlueChip software emulates around removed hardware
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
Software emulation of OR inst.
     Processor
                       // get registers
   PC: 1000
                       regs = processor_regs()
   …
   R3: 0x2
                       // fetch instruction
   R4:
                       inst = *(regs[PC])
   R5: 0x4
                       // decode operands
   …
                       (op, rd, rs1, rs2) = decode(inst)
 1000: or r3, r5, r4   if( op == OR) {
                          // execute instruction
                          regs[rd] = regs[rs1] | regs[rs2]
     Processor
                          regs[PC] += 4
   PC: 1004            } else if( op == AND) {
   …                      …
   R3: 0x2             }
   R4: 0x6             …
   R5: 0x4
   …                   // commit regs to processor
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
                                  i0
                                        OR   f
                     i1
                           OR
          m0
m1             AND
i0   OR

                 f = (i0 V i1) V (m0 Λ m1)
          Practical Attack
if (holdn = ‘1’) then
  super <= in.super;
end if
if resetn = ‘0’ then
  super <= ‘1’;
end if




super <= ~reset V
  (holdn Λ in.super) V (~holdn Λ super)
                Practical Attack
                   i0

   super <= ~reset V
     (holdn Λ in.super) V (~holdn Λ super)


                            i1
f = (i0 V i1) V (m0 Λ m1)

        m0 : previous instruction is or r0, r0, 0x0
        m1 : current instruction is or r0, r0, 0x0
               Practical Attack
(holdn Λ in.super) V (~holdn Λ super)
                                             super
                                        OR
                     ~reset
                              OR
            prev

curr               AND
       OR


(holdn Λ in.super) V (~holdn Λ super)
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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:5/8/2013
language:
pages:29