The Piracy Threat • Problem 1 : Unauthorized over ‐ production of IC • $$ Lost revenue opportunities Synthesis, Verification & Test for Secure ICs • Undesired exposure of proprietary technology Protecting Integrated Circuits • Problem 2 : Substandard production from Piracy with Test ‐ aware Logic Locking • Insertion of harmful Trojans • Sabotage and espionage opportunities Stephen Plaza Igor Markov Driving factor Worldwide distribution of IC production (i.e., outsourcing) An “EPIC” Solution? The Piracy Threat EPIC • Basic idea: hide functionality from manufacturer Rights Rights Design Risks holder Design PUF holder promised production Unauthorized Manufacturing done by 3 rd party • production Optimization • Manufacturing often done Optimization Rights PUF Manufacturer in remote areas → fewer legal op � ons Holder unique insert random unlocking XOR logic A Risky Relationship key non ‐ functional/incomplete EPIC Problem: Manufacturer needs a Manufacturing Manufacturing IC design promised production of pirated ICs Manufacturing functionally correct circuit for testing • Split manufacturing, test, etc between di ff erent companies → infeasible Testing/ Testing/ Testing/ Packaging Packaging Packaging • EPIC active metering approach [Roy ’08, ‘10 revision] Rights Advertising/ Manufacturer Black market Holder • Springboard for many Advertising/ Marketing distribution subsequent research efforts Marketing • Unique chip ID (e.g., PUF) Sales • Locking mechanism to prevent Sales correct circuit operation IC design Unauthorized Unauthorized Replica IC Variants
Our Solution Outline EPIC Rights • Background Mux ‐ based locking that preserves Design holder PUF test response → manufacturer does • XOR locking (and variants) not activate the circuit • Types of attacks Optimization PUF Insertion of • XOR locking vulnerability to attacks test ‐ preserving Advantages MUX locks Manufacturing 1. Manufacturer never has • MUX ‐ based locking a functional circuit • Background on simulation ‐ based synthesis Testing/ • Mux locking strategy 2. Supplied test response cannot Packaging • Practical considerations reveal locking scheme 3. End ‐ user can validate authenticity Advertising/ Marketing • Results Sales Circuit Locking Adding XOR ‐ based Locks Properties • Add logic to the circuit to alter circuit output • XORs placed randomly throughout circuit • Key bits that can disable locks • Key bits not obvious even with known output response add lock circuit (XOR/XNOR) F F F’ CK 1 CK i XOR hide key bit CK 2 (equivalent circuit) CK 3 CK i CK i XOR XNOR key bit not obvious upon inspection
Types of Attacks Outline • Background • Mask modification to disable PUF • XOR locking (and variants) • Types of attacks • Mask modification to disable locks • Hard to find on inspection • XOR locking vulnerability to attacks • Hard to modify in current technologies Supplied test patterns and response indicate expected behavior → • MUX ‐ based locking • “Guess” key bit values potential attack vulnerability • Background on simulation ‐ based synthesis • Random key patterns intractable • Mux locking strategy • Simulation based on stolen netlist [Rajendran ’12] • Practical considerations (better placement of XORs make this attack difficult) • Results XOR Lock Attack XOR Lock Attack High ‐ level Strategy circuit Assume access to key bits Response 1 Response 2 Response 1 Response 2 Pattern 1 Pattern 2 • Inputs: test pattern input, test pattern output, locked circuit 0 0 1 1 0 • Output: key bit assignment that unlocks circuit CK 1 1 0 1 1 1 0 0 … … 0 CK 2 Algorithm 1 1 1. Choose a key bit at random 1 1 1 0 2. Apply all test patterns, observe test response 0 0 0 CK 3 3. Flip key bit value 0 0 0 0 4. Apply all test patterns, observe test response 5. Choose the key bit value that minimizes test response differences 4 differences for 1 differences for 6. Repeat till convergence CK 1 = 1 CK 1 = 0
XOR Lock Attack Considerations Outline • Background • Output response often betrays gradient toward unlocked • XOR locking (and variants) configuration • Types of attacks • Random restarts needed since algorithm gets caught in local • XOR locking vulnerability to attacks minimum • MUX ‐ based locking • Adding XOR locks with downstream correlation can make a • Background on simulation ‐ based synthesis naïve attack trickier • Mux locking strategy • Practical considerations • Results Efficient Resynthesis through Signatures and Bit Simulation Simulation ‐ based Approximations • Signature : partial truth table associated • Simulation can be used to approximate circuit behavior with each node in a circuit • Estimate average case behavior • Stimulate inputs with simulation vectors • Linear ‐ time computation generate signatures • Apply values, e.g., random, Sig(x 1 ) = { 011} random bit ‐ parallel simulation to primary inputs simulation I 1 011 x x x 011 010 • Associate signatures x 1 111 x 001 x x I 2 with each node 011 101 011 x x x I 3 x 4 • Use signatures to enable 001 001 x 2 complex optimizations I 4 010 x 3 15
Signature ‐ based Synthesis Signature ‐ driven Locking Strategy Optimization Apply Apply Test Finding Locks Random Node Merging • Use signatures to guide synthesis optimization Patterns with Signatures with Signatures Simulation sig(f 1 ) = sig(f 2 ) • e.g. , find signatures that are equal → merge? and merge nodes Extract Extract • Need to prove equivalence (e.g., by using SAT) Signatures Signatures f 1 010 010 f 2 ,f 1 Find Equal Find Equal I 1 100 Signature 111 Signature x 1 111 I 2 011 Disprove 011 with I 3 repeat repeat x 4 Verify 001 Random 101 Formally x 2 I 4 Simulation circuit simplified not equivalent 001 x 3 equivalent x 3 MUX Add Lock Optimize Finding Candidate Signatures MUX ‐ based Locking Algorithm • Problem: few signals with equal 100 I 1 111 signatures that are not logically x 1 111 I 2 2. Create Candidate Cover for equivalent 1. Apply Test Patterns 011 011 Randomly Chosen Node (most have covers) I 3 x 4 • Solution: create equal signatures 001 001 x 2 100 using logic covers I 4 111 x 1 111 101 x 4 011 011 010 x 3 011 = x 3 Logic Cover x 4 010 001 x 2 x 3 Synthesize x* 2 x 5 • ��� � � ��� � ↔ ��� � � ��� � &��� � 010 • ��� � � ��� � ↔ ��� � � ��� � |��� � x 3 Sig x2 � Sig X3 ↔ x 2 Sig x2 = Sig x3 & Sig x2 x* 2 x 3
Practical Considerations MUX ‐ based Locking Algorithm of MUX Locking to the Design Flow 3. Apply Random Simulation Area considerations 5. Add MUX lock • Each optimization requires minimal additional logic 010 011 2 gates 011 x 1 011 x 1 111 001 x 4 101 x 2 • Only a few locks (e.g. 64, 128) are needed for the key to be uncrackable x 4 x 5 x 2 x 5 110 x 3 Timing and wiring • We avoid operations that increase logic levels x 3 4. Disprove Candidate Cover • More generally: use local signals when synthesizing locks to uphold � ming/wiring constraints → need many candidate locking sites Circuit Test… key x 4 011 010 ≠ x 3 110 x 3 Handling Untestable Logic Handling Untestable Logic with Probabilistic Testing with Probabilistic Testing Solution: run test patterns multiple times with different key bit values Problem 1: incorrect lock key will make some logic untestable choose circuit a Response 1 Response 2 Response 1 Response 2 random a not observable when b=0 Pattern 1Pattern 2 combination 0 1 1 0 c 0 1 CK 1 b 1 0 1 1 1 0 0 … … … 0 CK 2 1 1 1 1 0 1 key = 1 (locked) Problem 2: unpredictable output response could complicate diagnosing 0 0 1 0 CK 3 0 0 0 0 a={0,0} a={1,1} (stuck ‐ at ‐ 1 fault) CK ={1,0,0}: Resp1, Resp2 CK ={1,0,1}: Resp1, Resp2 Properties c={0,0} 0 expected faulty c = {1,1} • If there are no interactions between locked sites, exponential …. b={1,0} 1 c={1,0} fewer untested sites for each combination • Improved testability possible because covers can increase observability of internal signals key = 1 (locked)
Recommend
More recommend
