Towards the Issues in Architectural Support for Protection of Software Execution

Weidong Shi Ph.D Hsien Hsin Lee Mrinmoy Ghosh Chenghui Lu School of Electrical and Computer Engineering Georgia Institute of Technology
1

Content

Motivation Necessity for Hardware Cryptography Based

Protection Attack to Counter Mode Encryption Fight Against On-line Attack Using Delay Logic Conclusions

Motivation
Put issues debated off-line on-fine Highlight several issues Reach consensus

Necessity for Hardware Cryptography Based Protection

S: Hardware memory encryption is not necessary

and does not provide any additional security

R: The answer is yes and no depending on the

security requirement, business model, software operating environment and etc.

Necessity for Hardware Cryptography Based Protection cont Secure future applications, applications cannot be secured today and new business models
Software secrecy Anti-reverse engineer Data secrecy/integrity Anti-machine emulator Anti-authoritative client

Military embedded systems, mobile software agents

Program, software, library as IP Distributed computing, mobile software agents Software rights On-line video games

The threats of hardware attack should not be underestimated. Hackers are able to build spoof devices, bus tracing devices, signal replaying devices .
5

Attack On Counter-mode Encryption

S: Counter mode alone or counter mode plus lazy
integrity check is enough to provide SW secrecy.

R: The answer is no. Rigorous, timely, and

appropriate check on integrity is a MUST. Active flow based attack can compromise SW secrecy protected by counter mode when integrity check is weak.

Counter-mode Background
Sender side
Counter + 0 Key Block Cipher Key Block Cipher Counter +1 Key Block Cipher Counter + n

Pseudo-random pad

Pseudo-random pad

Pseudo-random pad

Plaintext

Plaintext

Plaintext

Ciphertext

Ciphertext

Ciphertext

First presented by W. Diffie and M. Hellman in 1977. Sender and receiver shares a secret key, and an initial counter. A pseudo-random pad is generated deterministically based on the counter and key Counter does not have to be a secret.
7

Counter-mode Background
Receiver side
Counter + 0 Key Key Block Cipher Block Cipher Counter +1 Key Block Cipher Counter + n

Pseudo-random pad

Pseudo-random pad

Pseudo-random pad

Ciphertext

Ciphertext

Ciphertext

Plaintext

Plaintext

Plaintext

Receiver generates the same pad sequence using the same key and counter.

Counter-mode Summary
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 melleable. Flip bits in the ciphertext can induce flipped corresponding bits in the plaintext. Miss use of counter mode can jeopardize security. Timely, appropriate check on integrity is a MUST.
9

Counter-mode Summary cont

Chosen ciphertext melleable
ciphertext
1 0 1 1 0 1 0 1 1

plaintext
0 1 0 1 0 0 1 1 0

How about other NIST block cipher based modes

such as CBC (cipher block chaining).
ciphertext, memory block n-1
1 0 1 1 0 1 0 1

ciphertext, memory block n

1 0 1 1 0 1 0 1

Block Cipher

1 0 1 1 0 1 0 1

10

Attack On Counter-mode
Dangerous practice on integrity check
Aggregated SW(instruction/data) integrity check. Allow processor/memory state change by unverified instructions/data. Allow processor/memory state change by data derived from unverified data. Data/instruction fetch issued to memory based on unverified instructions, or based on control flow determined by unverified data Data/instruction fetch issued to memory using address obtained from unverified data.

11

Attack On Counter-mode
Ability to obtain SW execution traces and bus traces
Logical analyzer Interposer card Low cost FPGA based trace device

12

Attack On Counter-mode

Exploit regularity of RISC instruction set for

increment guesses.

Convert secret information into data/instruction fetch

address observable on SW execution/bus trace.

13

Attack On Counter-mode - Example

Addr = 0x12001139c 0x12001139c

ciphertext
0x9426814a

plaintext
0x40c05411

Instruction
addq t5, 0x2, a1

Opcode 0x10

RA

Disp

Branch Format Memory Format Operate Format

Opcode Opcode Opcode

RA RA RA RB RB

Disp Disp Function RC

6-bit opcode, 64 possible opcodes. Flip bits of opcode ciphertext and trace program control.

14

Attack On Counter-mode
plaintext
Opcode 0x10 RA Disp

ciphertext
opcode guess

Opcode 0x25
Opcode 0x4

RA

Disp

RA

Disp

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

guessed opcode
0 0 0 1 0 0

Ciphertext after bit flip

0 1 0 0 0 1 Opcode 0x11

target opcode
1 1 0 0 0 0

ciphertext after flip decrypted opcode

RA

Disp

Opcode 0x24(stf)

RA

Disp

15

Attack On Counter-mode
plaintext
Opcode 0x10 RA Disp

ciphertext
opcode guess

Opcode 0x25
Opcode 0x10

RA

Disp

RA

Disp

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

guessed opcode
0 1 0 0 0 0

Ciphertext after bit flip

0 0 0 1 0 1

target opcode
1 1 0 0 0 0

ciphertext after flip

Opcode 0x5

RA

Disp

decrypted opcode

Opcode 0x30

RA

Disp
16

Attack On Counter-mode
plaintext
Opcode 0x10 RA Disp 0x5411

ciphertext
decrypted opcode

Opcode 0x5

RA

Disp

Opcode 0x30

RA

Disp 0x5411

Addr = 0x12001139c

0x12001139c

Addr = 0x1200263e0

Decrypted instruction triggers fetch from a new address, which discloses 16 bits of plaintext.
17

Attack On Counter-mode
Data Next Data Next

Secret

Data NULL

Convert secret into data fetch address so it can be Observed in program trace
18

Fight Against Attack on Counter-mode

Use non-melleable encryption mode
Counter-mode, CBC are all melleable.

Hide program trace and fetch address. Hardware

obfuscation, CASES 2004. OVERHEAD!!!

Authenticate appropriately, PACT 2004

Change on processor/memory state prohibited by unverified code/data or results obtained from un-verifed code/data. Stall pipeline when it happens and wait result of integrity check. Code/data fetch from memory stalls and wait for integrity cehck 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
19

Fight Against On-line Attack

S: Memory integrity can only be protected using long
bit Hash such as Merkle Tree and 160 bit hash.

R: Hash tree is vulnerable to off-line attack, and MAC

(message authentication code) tree is preferred because of its efficiency and robustness against offline attack. Use Integrity verification triggered delay logic.

20

Fight Against On-line Attack

Off-line vs. On-line attack
Off-line attack can be launched on multiple-machines. Used for key search, find hash collisions, etc. On-line attack has to be launched on the victim/targeted machine. Brute force attack on MAC.

Hash tree vs. MAC tree

Hash tree is more vulnerable to off-line attacks. Brute force attack on MAC tree has to be conducted on the victim machine.

21

Original Code
push param1 push param2 push param3 push param4 push param5

Fight Against On-line Attack

call security_check /*a jump to a subroutine */ tst ax, 0 /* assume return value in ax*/ bne security_failed

Alter Code Only

mov ax, random\_num xor ax, ax

Alter MAC and Code

nop nop nop

mov bx, random\_num

Attacker can

xor bx, bx mov cx, random\_num xor cx, cx nop nop

nop
nop nop nop

come up huge number of attack codes and hope one of them has a MAC collision.
22

nop

modify the code and brute force attack the MAC

Fight Against On-line Attack

Tamper Prevention Time (TPT)
integrity check failure Delay Logic Driven by Authentication/ stall CPU clock Integrity Verification Engine OK, continue

State of TPT is persistent, survive power cycling. TPT counts number of integrity verification failures. TPT has delay logic that stalls processor pipeline when tracked number of integrity failure crosses a threshold. TPT state not accessible by SW. EXAMPLE: 1min delay for every 10 failed integrity check, require 204 years for on-line brute force attack to succeed breaking 32-bit MAC. Processor speed is irrelevant. SIMPLE and EFFECTIVE
23

Conclusions
Hardware cryptography based software protection
provides a new security model for applications.

Appropriate extra security measures have to be used

together with counter mode to prevent active flow based attacks.

MAC tree is better than Hash tree. TPT is a simple and effective way to fight against
on-line attacks on software integrity.

24