1 epic: ending piracy of integrated circuits jarrod roy, farinaz koushanfar and igor markov jarrod...

1

EPIC: Ending Piracy EPIC: Ending Piracy of Integrated Circuits of Integrated Circuits

Jarrod RoyJarrod Roy†,,Farinaz KoushanfarFarinaz Koushanfar‡

and Igor Markovand Igor Markov††University of Michigan and ‡Rice University

2

Problem: Piracy of ICs Semiconductor manufacturing is outsourced

to foreign countries, especially E. & S.E. Asia LSI recently sold its last fab & quit the business TI and Freescale outsourced sub-65nm manufacturing Qualcomm one top 10 IC producers, Summer 2007

Rampant piracy in E. & S.E. Asia Clothing, software, consumer electronics, chips “Fake NEC” corporation discovered in China US is initiating anti-piracy proceedings

against China in WTO CeBIT raids on March 6, 2008

Masks can be stolen, used for free Produced chips will be identical

3

Similar to Software Piracy ?

Software is easy to copy Activation keys, e.g., MS Office

Every CD requires its own key But this key can be copied too

SW is easy to modify – cracked versions abound E.g., computer games on Bit-Torrent, etc

HW is drastically different No known techniques for physically copying ICs Reproducing IC requires masks & access to a fab Modifying a chip requires FIB – very slow &

expensive (impractical in large quantities)

4

IC Design, Fabrication & Test Three entities

Chip designer Holder of IP rights for the chip Manufacturer (fab) & circuit tester

Challenges Do not allow fabs to sell excess chips Make the theft of masks (by or from fab)

insufficient to produce working chips Our solution: EPIC

A chip-locking system where each chiprequires a different code to operate

Without the right code, chips fail test

Usually same

5

EPIC: Ending Piracy of ICs

Additional hardware A novel lightweight locking system Public-key crypto with random key generation

(available on Niagara2) Additional pins for encrypted keys

Keys Common key (CK) – built into gate-level circuit Master keys (MK) – owned by holder of IP rights:

private key never transmitted, cannot be deduced Random chip keys (RCK) – public/private keys Input key (IK) – key entered to unlock the chip

6

Holder of master key

and IP rights

EPIC: Design Flowmodule foo(a, b, c, o1, o2, o3);input a, b, c;output o1, o2, o3;reg o2, o3;assign o1= a & b;always @(a, b, c) o2= a | c;… RTL

Logic Synthesis

and Tech. Mapping

Placement

+

DFY & DFM

Common key

Combinational

locking

Routing

Master key (public)

Adding

locks & crypto

7

Holder of master key

and IP rights

EPIC: Activation and Testing

Cutting andpackaging

X

Testing

Activation

First power-up,

random bits Chip Key (Public)

Input Key

Sales

Chip-Key generation

8

Details: Combinational Locking Modifies combinational circuits

E.g., control logic & datapaths

Adds k new XOR gates k new inputs for bits of common key

Uses these identities x 0=x, x 1=x’ x y= x’ y’= (x y’)’

Accommodates any key

Select

wires

Insert

XORs

One bit of common key

1 0 1 14-bit common key

9

Spurious Common Keys ? Consider circuit C(x) and a locked variant C(x,y)

such that for a designated key y0 x C(x, y0)=C(x)

To find a working common key,must solve this Boolean equation y0 x C(x, y0)=C(x) Our locking construction guarantees solution Note that this problem is beyond NP

Can there be multiple solutions ? - Yes Consider initial circuit c=XOR(x1,x2) Locked variant c=XOR(XOR(x1,y1),XOR(x2,y2)) Common keys: (0,0) and (1,1)

10

Unique Common Keys

Ideally we have y0 x C(x, y0)=C(x)

This can be checked for a given circuit Build BDDs of C(x) and C(x, y) Build BDD of the miter C(x,y)=C(x) Quantify out () the variable x Count paths in the resulting BDD (linear time) Expected result: a single path

To ensure unique common keys Each wire should affect an output

not affected by other wires ( no cancellations)

11

Length of Common Key (1) In digital circuits, inversion of a single wire

will usually affect the output Sufficient to disable the circuit Insufficient to hide the key (can try 0 and 1)

Brute-force enumeration Requires the ability to try many different keys

(not necessarily a specific key !) For many different keys, run circuit test,

wait until it passes Common key must be long enough

to defeat brute-force enumeration, e.g., 64 bits

12

Length of Common Key (2)

Suppose that 32 bits lock an adderand another 32 bits lock a multiplier Can apply brute force to the adder first Then to multiplier 232+ 232 << 264

This is only slightly better than locking the adder and multiplier with the same 32-bit key

If a key locks n independently-testable blocks, its effective length (EL) is log2 ((2k1 + 2k2 + … +2kn) / #working keys) “=“ when bits are not reused for multiple blocks

13

EPIC: Vulnerability Assessment Main scenarios:

Fab selling excess chips Forgers stealing masks & using fabs

Additional cases, when forgers can Reverse-engineer and modify masks Modify chips in large quantities (FIB required) Observe individual transient signals on chip

Also must consider Stolen RTL, gate-level netlist Stolen layouts (placed & routed) Stolen test vectors & correct responses

14

Operational assumptions Public-key crypto cannot be broken or reversed RCK is random (available in Sun’s Niagara 2) RCK is generated once per chip (burned into fuses) Common Key is unique (or has very few variants)

By construction + empirically checked

Multiple levels of protection Some keys are never transmitted (e.g., MK-Private) Some keys are not in RTL (CK), or layout (RCK) To break EPIC, must have both Master Keys (MK),

Common Key (CK) and RCK-Public for each chip

Technology Context

15

Knowing a good CKis not sufficient to pirate ICs

Chip can only be unlocked with good IK Good IK = good CK encrypted

with MK-Private & RCK-Public Good IKs are as random as RCKs Same number of good CKs & good IKs A good IK can only be decrypted by the chip

MK-Private and RCK-Private never transmitted Good IK for one chip does not unlock another

EPIC: Guarantees

16

Guarantees due to Public-Key Crypto

Public Chip Key & Master Key do not revealinformation about their private counterparts(which are never transmitted)

Input Key for one chip gives no infofor other chips

Knowing Common Key, all Public Keys and all Random Chip Keys does not allow creating a good Input Key

17

Discussion of Attacks (1)

Guessing, stealing or reverse-engineeringthe Common Key is insufficient Common Key is produced by decrypting Input Key

Intercepting communications from/to the chipis insufficient Guarantees provided by public-key crypto In particular, Input Keys cannot be reused

Inspecting a working chip and havinga full understanding of masks is insufficient Only provides Common Key,

Chip Keys and Public Master Key

18

Discussion of Attacks (2)

Suppose that the forger Found Common Key (by mask inspection) Found Public Master Key (by mask inspection) Powered-up a chip Discovered Random Chip Keys (power analysis?)

The forger must now generate a good Input Key But this requires Private Master Key Private Master Key is never transmitted

and cannot be deduced from Public Master Key Brute-forcing Input Key or Random Chip Keys

Infeasible + Chip Keys are burned into fuses

19

Source-level Protection

Source files are not transmitted to the fab much harder to steal

But what if RTL and gate-level netlist are stolen ? Common Key is added after placement Random Chip Keys are created on power-up The attacker cannot activate normal chips

What if placed & routed layout is stolen? – this might help finding Common Key, but … Need “locked” & “original” netlists (or test responses)

Finding Common Key is worse than NP-complete Having Common Key does not enable piracy

20

Additional Protection Mechanisms

Multipliers are harder to unlock even at gate level Transmit serial numbers and current date+time

with public key during activation Restrict activation to one chip

in 10 seconds during certain hours Encrypted communication between the chip

and the holder of IP rights authenticated by fab Stronger encryption can be added, changed Curb man-in-the-middle & denial-of-service attacks Better accountability, easier to trace forgers Motivate fab to guard information

21

Spies infiltrate the main office and steal Common Key & both Master Keys

During chip activation Random Chip Key -public

appears on output pins, encrypted by MK-public The forger can decrypt it using MK-private Then encrypt CK with MK-private and RCK-public Enter it as Input Key (IK)

EPIC can deal with this ! Add another layer with Fab Keys (public & private) Only the intended fab can perform chip activation

Dealing With the Human Factor

22

Technologically Advanced Forger ? W/o spies, must change the masks Having that ability seems to defeat many possible

protection schemes, at least in principle Full understanding of the masks & complete info

about a working chip reveals Common Key Masks can be changed to hardwire Common Key

& disconnect it from Public-Key Crypto module In practice, this seems infeasible

Below 90nm, mask analysis is very hard due to OPC Watching a working chip is even harder Producing a modified chip requires a fab or FIB

23

Pirated ICs must be cheaper than original ICs A pirate cannot advertise

lower volumes Pirate’s risk is higher

higher margins required Pirate’s investment

(sales of pirated ICs) - margins A pirate cannot invest much !

Modifying each chip using FIB is very slow Running P&R, DFM & DFY incurs NRE costs Using a different fab requires yield ramp-up

Financial Limitations of Piracy

24

Delay, Power, Verification & Test

Only non-critical wires are selected (after placement) Inserted XORs do not touch critical paths

Common key fixed – no new switching activity A slight penalty for inserted XOR gates

Old test vectors & responses remain valid The activated circuit is just like the original

Turn off RNG & Crypto after activation

25

Area Overhead of EPIC

2-3 new package pins for Input Key Use scan chains to “scan-in” the IK

True random number generator – small(Su`97, Blaauw`06, etc);available on Niagara2

Public-key crypto – bulk of EPIC overhead Available on Niagara2, small area Does not have to be fast Can be sequential; can use CPU, but not SW

26

Empirical Evaluation

Select large combinational circuits for locking (we used ISCAS’85)

Randomly select wires andperform combinational locking

Check y0 x C(x, y0)=C(x) using BDDs

Confirm unique common key or count keys Results:

Very few duplicate keys with random wire selection 64-bits sufficient to thwart brute force

> 100 years using 10000 machines

27

EPIC: Conclusions

Hardware piracy a growing threat Current efforts barely go beyond serial numbers

We propose a robust mechanismto protect against piracy of ICs Lock embedding Combinational locking with common key Random chip-key generation upon 1st power-up Public-key cryptography with holder of IP rights Input key activates a chip (different for each chip)

Overhead and attacks analyzed

28

Questions ?

29

Selecting Wires for Common Key

1. For each wire, count the number of signal paths traversing it (pseudo-linear time)

2. Select one of the wires with most paths

3. Find all outputs in its fanout cone1. Find an output with least wires in its fanin cone

2. Mark those wires as prohibited

4. If any unmarked wires remain, goto 2

Theorem: for the wires selected by the above procedure, there will be a unique common key

30

Limits on Key Length

A small circuit cannot accommodate long keys Our wire-selection algorithm cannot pick

more wires than primary outputs in the circuit #POs is not an upper bound, but

helps proving uniqueness Multiple working keys may be OK

Used by tell who activated the circuit But would decrease effective key length

31

Why not Insert XORs on FF inputs ?

Our algorithm can insert XORs on FF inputs if that is deemed useful

Each XOR will affect only a single output Easier to reverse-engineer Limits key size (but not more than our algorithm) This is very likely to affect critical paths

32

EPIC: KeysD

esig

ner

Fo

un

dry

IP

Master Key (MK) &

Private Key

Public Key

Chip Key Pair (RCK)

Input Key (IK)

Public KeyCrypto

Common Key (CK)

Unlocking theControl Logic

Control LogicLocked

RCK-Public

33

EPIC: Ending Piracy of ICs Every chip generates a Random Chip Key (RCK)

upon first power-up Using a true random number generator Collisions rare & harmless

Control logic is locked by Common Key (CK),but CK cannot be entered directly CK is comp’d by public crypto from Input Key (IK)

IK is sent by the holder of IP rightsin response to RCK-Public Can only be generated from master key (MK) Can only be decrypted with RCK-Private

34

Encrypting Common Key The Common Key can be discovered, stolen,

reverse-engineered, etc The leakage of Common Key does not break EPIC Successful activation requires Input Key

Common Key produced by decrypting the Input Keywith Private Random Chip-Key & Public Master Key

Public Master Key is hardwired on the chip To produce IK, need RCK-Public and MC-Private Random Chip Keys do not repeat among chips

Public Random Chip Key is transmittedto the holder of Master Key

35

Locking Scan Chains ?

+ Does not affect the main circuitwith respect to delay, power

- Requires a large number of scan chains(one bit per chain)

- Scan chains are independent the effective length of such key will be very small

+ When locking a module, also locking its scan chain(s) will complicate test-based attacks

36

Other Considerations & Ideas

Locking clock wires – seems like a bad idea Adds clock skew; significant power overhead Easier to reverse-engineer

Locking multipliers – good as an extra Not an essential functionality, but common Attempts to reverse-engineer using SAT,

BDD or other techniques would be hopeless

37

Which Circuit Modules To Lock ? Possible strategies:

Lock the most vital modulesto make the chip useless in all cases

Lock corner-case behavior, make failures subtle Lock performance, unlocked chips will run slower

Comprehensive locking in a microprocessor:lock control logic No need to lock all pipeline stages –

if one is disabled, others cannot work Lock stages with more logic & wider circuit

Subtle locking: forwarding logic Performance locking: branch predictors, caches