8/6/2019 conf-drm-2004

1/25

1

Attack and Risk Analysis for HardwareSupported Software Copy Protection Systems

Weidong Shi

Hsien-Hsin (Sean) Lee

Chenghuai Lu

Tao Zhang

School of Electrical and Computer Engineering

Georgia Institute of Technology

8/6/2019 conf-drm-2004

2/25

2

Content

Why Software Copy Protection So Hard

Security In Silicon, the Future of Software RightProtection?

Issues of Enforcing Software Right In Hardware

Memory Encryption, Security Should not Be Takenfor Granted

- Counter Mode Memory Encryption

- Security of Selective Protection Conclusions

8/6/2019 conf-drm-2004

3/25

3

Causes of Reduce In Software Piracy

Economic: When software is more affordable

Legal: When copy right law is enforced rigorously.

Business model: When there is a new business

morel. Noticeably on-line games.

Technology: The contribution seems opposite.P2P network, low cost IC chip (mod chip)

8/6/2019 conf-drm-2004

4/25

4

Know Your Enemy

Hackers are sophisticated and knowledgeable

Widely available after breach, P2P network as adistribution channel, MOD chip as a business

Not so successful to hide secret from hackers,reverse engineer using software/hardwaremeans

Not so successful preventing hackers frombypassing hardware copy protection measures.

What is often heard, our approach is good

enough to provide DRM.

8/6/2019 conf-drm-2004

5/25

5

XBOX, Is It Good Enough

P IIINbridge + GPU

South Bridge

Secret Key BIOS Flash

(some BIOS codes

are encrypted)

MOD Chip

(PCB with micro-controller

and Flash memory)

FPGA based

Bus Tracer

Find out the key

BIOS hijack

socket over HT

Bus soldered by

hackers

Low cost FPGA

based bus

snooping device

HT (hyper-

transport)

Consoles are much better

protected than PCs designed with

copy right protection in mind.

8/6/2019 conf-drm-2004

6/25

6

Security In Silicon

Encrypted software is hard to break and topirate.

Future CPU has the space to support softwaredecryption on the fly.

8/6/2019 conf-drm-2004

7/257

How Does It Look Like

Unprotected RAM

Crypto

Engine

ProcessorCore

Secure Processor

Unprotected Storage

Private Key

Software Encrypted by a Symmetric Key, K. Key K

encrypted by public key of processor. ASPLOS 02,

ICS 03, Micro 03, SOSP 03

Software

Key Table

EncryptK(Software)

EncryptK(Software)

Decryted

Software,Cache

8/6/2019 conf-drm-2004

8/258

All Sound So Good, But Wait a Minute

Security. Is this really secure?

Performance, Performance, Performance.

- CBC encrypted software can be ten times slower.

- 5 year CPU design cycle. Profound impact on design and

performance.

Programming Model.

Test and Verification.

Debug.

Software Distribution.

User Privacy

8/6/2019 conf-drm-2004

9/259

Trade-off Between Security and Performance

Counter mode is faster than CBC. Much faster.Micro 03

Aggregated integrity check on instructions is fasterthan timely check on per instruction basis. Micro 03

Selective protection is faster than whole protection.ASPLOS, 02, SOSP, 03

But what are the risks of using counter mode +

aggregated integrity check + selective protection?

8/6/2019 conf-drm-2004

10/2510

Counter Mode

Pros

Widely used, allow pad pre-computation.

Proved to be secure by Bellare, etc (1997). If you break

counter-mode, you break the underlying cipher.

Cons

Chosen ciphertext malleable. Flip bits in the ciphertext caninduce flipped corresponding bits in the plaintext.

Miss use of counter mode can jeopardize security. Timely,

appropriate check on integrity is a MUST.

8/6/2019 conf-drm-2004

11/2511

Counter Mode

1 0 1 1 0 1 0 1 0 1 0 1 0 0 1 1

ciphertext plaintext

Chosen ciphertext malleable

How about other NIST block cipher based modessuch as CBC.

1 0 1 1 0 1 0 1

0 1 1 0 0 1 1 1

0 0 0 1 1 0 1 1

Block Cipher

ciphertext,

memory block n-1

ciphertext,

memory block n

1 0

0

1plaintext

8/6/2019 conf-drm-2004

12/25

12

Dangerous Practice on Integrity CheckWhen Using Counter Mode

Aggregated SW(instruction/data) integrity check.

Allow processor/memory state change by unverifiedinstructions/data.

Allow processor/memory state change by data derived from

unverified data.

Data/instruction fetch issued to memory based on un-verified instructions, or based on control flow determined

by unverified data

Data/instruction fetch issued to memory using addressobtained from unverified data.

8/6/2019 conf-drm-2004

13/25

13

Attack On Counter Mode

Exploit regularity of RISC (reduced instruction set)instruction set for incremental guesses.

Convert secret information into data/instruction fetchaddress observable on SW execution/bus trace

(reduce brute force search space)

Patching software with small piece of attack code,e.g., binary search code

8/6/2019 conf-drm-2004

14/25

14

Attack On Counter Mode - Incremental Guess

0x9426814a

0x9426814a

ciphertext plaintext

0x40c05411

Instruction

addq t5, 0x2, a1

Opcode RA Disp

Opcode RA DispRB

Opcode RA FunctionRB RC

Branch FormatMemory Format

Operate Format

Opcode

0x10RA Disp

Addr = 0x2001139c

6-bit opcode, 64 possible

opcodes. Flip bits of opcode

ciphertext and trace program

control.

8/6/2019 conf-drm-2004

15/25

8/6/2019 conf-drm-2004

16/25

16

Opcode

0x25RA Dispciphertext

Opcode

0x10RA Dispplaintext

Opcode

0x10RA Dispopcode guess

Opcode

0x5RA Dispciphertext after flip

Opcode

0x30 RA Dispdecrypted opcode

Flip bits of opcode ciphertext based on guessedopcode. The target is opcode 0x30 (opcode of jmp)

1 0 0 1 0 1 0 1 0 0 0 0

1 1 0 0 0 00 0 0 1 0 1

guessed opcode

target opcode

ciphertext

ciphertext after bit flip

Attack On Counter-mode - Incremental Guess

8/6/2019 conf-drm-2004

17/25

17

Opcode

0x30RA

Disp

0x5411decrypted opcode

Opcode

0x5RA Dispciphertext

Opcode

0x10

RADisp

0x5411plaintext

Addr = 0x2001139c

Addr = 0x200263e0

0x12001139c

Decrypted instruction triggers fetch from a new

address, which discloses 21 bits of plaintext.

0x9426814a

Attack On Counter-mode - Incremental Guess

8/6/2019 conf-drm-2004

18/25

18

Attack On Counter Mode Binary Search

Stick in a small piece of attacking codes. Moreradical attack

Large percentage of information in memory ispredictable. predictable data/code, array of 0s,

Example, flip bits of known values to stick a piece of

binary search code (constant starts from 2^16, ifR2>2^16, try 2^24 next, At most 32 trials tocompromise the secret)

R1 = a constant value;

R2 = load some secret

if (R1

8/6/2019 conf-drm-2004

19/25

19

Fight Against Attack on Counter Mode

Use chosen-ciphertext non-malleable encryption mode

Counter-mode, CBC, all stream cipher based modes are allmalleable.

Hide program trace and fetch address. Hardwareobfuscation, CASES 2004. OVERHEAD, OVERHEAD!!!

Authenticate appropriately, PACT 2004

Change on processor/memory state prohibited by un-verifiedcode/data or results obtained from un-verified code/data. Stall

pipeline when it happens and wait result of integrity check. Code/data fetch from memory stalls and wait for integrity check

if address computed from un-verified data

Code/data fetch from memory stalls and wait for integrity check

if control flow determined by un-verified data/code

8/6/2019 conf-drm-2004

20/25

20

Security of Selective Protection

Encrypt only necessary and important codes.Valuable core software functions (concerns onreverse engineer).

BIOS, firmware (concerns on disclose of designsecret, machine emulator).

Valuable data, private data

8/6/2019 conf-drm-2004

21/25

21

Enter security

Start security mode after thisinstruction.A key is used to

decrypt all the succeeding

instructions

Instruction Format Definition

Exit security Exit security mode. No decryptionfor succeeding instructions

Secure store st $rt,offset($base)Stores $rt into memory

[$base+offset]

Secure load ld $rt,offset($base)Load $rt with memory

[$base+offset]

Support for Selective Protection

Taken from ASPLOS 2002, SOSP 2003. XOM

Boundary between protected an un-protected domains set

by individual load/store instructions.

8/6/2019 conf-drm-2004

22/25

22

Encrypt Malicious Data into Code

Manipulate input or address

used by secure load/store.

Can generate arbitrary encrypted

code or software patchwith arbitrary code input.

// not protected data and code

unsigned int array_dat[] = { ... };

...

//protected code,encrypted/authenticated

enter_security

...

// load array_dat and secure_save

unsigned int x;

for (i=0; i

8/6/2019 conf-drm-2004

23/25

23

// disclose results of computing to public

struct node_t {

unsigned int dat;

...

node_t* pnext;}

//protected code,encrypted/authenticated

enter_security

... //process link-list//release results

node_t* pnode = head of link_list;

while (pnode)

{

secure_load pnode->dat to temp;

save temp to un-encrypted memory;

pnode = pnode->pnext; // regular load

}

exit_security

Data

Next

Data

Next

Data

NULL

Secret

Disclose Secret by Altering Data Pointer

8/6/2019 conf-drm-2004

24/25

24

Conclusions

Hardware cryptography based copy protectionmaybe a direction for future software rightprotection.

Trade-off between security and performance not well

understood

Counter mode + aggregate integrity check is risky.

Selective protection is also risky without additionalprotection.

8/6/2019 conf-drm-2004

25/25

25

memory block counter

cache linecache linecache line

cache linecache line

Crypto

Engine

Processor

Core

Secure Processor

Counter Mode

memory block counter

memory block counter

memory block counter

memory block countermemory block counter

Counter mode has to used properly to support

Randomly Accessed Memory