conf wassa 2004

8/6/2019 Conf Wassa 2004

http://slidepdf.com/reader/full/conf-wassa-2004 1/24

1

Towards the Issues in Architectural Support forProtection of Software Execution

Weidong Shi

Ph.D Hsien Hsin Lee

Mrinmoy Ghosh

Chenghui Lu

School of Electrical and Computer Engineering

Georgia Institute of Technology

8/6/2019 Conf Wassa 2004


2

Content

• Motivation

• Necessity for Hardware Cryptography BasedProtection

•Attack to Counter Mode Encryption

• Fight Against On-line Attack Using Delay Logic

• Conclusions

8/6/2019 Conf Wassa 2004


3

Motivation

• Put issues debated off-line on-fine

• Highlight several issues

• Reach consensus

8/6/2019 Conf Wassa 2004


4

Necessity for Hardware CryptographyBased Protection

• S: Hardware memory encryption is not necessaryand does not provide any additional security …

• R: The answer is yes and no depending on thesecurity requirement, business model, softwareoperating environment and etc.

8/6/2019 Conf Wassa 2004


5

• Secure future applications, applications cannot besecured today and new business models

Necessity for Hardware CryptographyBased Protection – cont’

Software secrecyMilitary embedded systems,

mobile software agents

Anti-reverse engineer Program, software, library as IP

Data secrecy/integrity Distributed computing, mobile software agents

Anti-machine emulator

Anti-authoritative client

Software rights

On-line video games

• The threats of hardware attack should not be under-estimated. Hackers are able to build spoof devices, bustracing devices, signal replaying devices ….

8/6/2019 Conf Wassa 2004


6

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, andappropriate check on integrity is a MUST. Active flow

based attack can compromise SW secrecy protectedby counter mode when integrity check is “weak”.

8/6/2019 Conf Wassa 2004


Counter-mode Background

Counter + 0

Plaintext

Ciphertext

Block Cipher

Pseudo-random pad

Plaintext Plaintext

• 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.

Key

Counter +1

Key

Block Cipher

Pseudo-random pad

Counter + n

Key

Block Cipher

Pseudo-random pad

Ciphertext Ciphertext

Sender side

8/6/2019 Conf Wassa 2004


Counter + 0

Ciphertext

Plaintext

Counter +1

Ciphertext

Counter + n

Ciphertext

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

Key

Block Cipher

Pseudo-random pad

Key

Block Cipher

Pseudo-random pad

Key

Block Cipher

Pseudo-random pad

Plaintext Plaintext

Counter-mode BackgroundReceiver side

8/6/2019 Conf Wassa 2004


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 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 Wassa 2004


Counter-mode Summary – cont’

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

ciphertext plaintext

•Chosen ciphertext melleable

•

How about other NIST block cipher based modessuch as CBC (cipher block chaining).

1 0 1 1 0 1 0 1

1 0 1 1 0 1 0 1

1 0 1 1 0 1 0 1

Block Cipher

ciphertext,

memory block n-1

ciphertext,

memory block n

1 0

8/6/2019 Conf Wassa 2004


Attack On Counter-mode

• Dangerous practice on integrity check

• Aggregated SW(instruction/data) integrity check.

• Allow processor/memory state change by unverifiedinstructions/data.

• Allow processor/memory state change by data derived fromunverified 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 address

obtained from unverified data.

8/6/2019 Conf Wassa 2004


8/6/2019 Conf Wassa 2004


13


• Exploit regularity of RISC instruction set forincrement guesses.

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

8/6/2019 Conf Wassa 2004


14

Attack On Counter-mode - Example

0x12001139c

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 = 0x12001139c

• 6-bit opcode, 64 possible

opcodes. Flip bits of opcode

ciphertext and trace program

control.

8/6/2019 Conf Wassa 2004


15


Opcode

0x25RA Dispciphertext

Opcode

0x10 RA Dispplaintext

Opcode

0x4RA Dispopcode guess

Opcode

0x11RA Dispciphertext after flip

Opcode0x24(stf)

RA Dispdecrypted opcode

Flip bits of opcode ciphertext based on guessed opcode. The

target is opcode 0x30 (opcode of jmp)

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

1 1 0 0 0 00 1 0 0 0 1

guessed opcode

target opcode

ciphertext

Ciphertext after bit flip

8/6/2019 Conf Wassa 2004


16

Opcode


Opcode

0x10 RA Dispplaintext

Opcode

0x10RA Dispopcode guess

Opcode

0x5RA Dispciphertext after flip

Opcode

0x30 RA Dispdecrypted opcode

Flip bits of opcode ciphertext based on guessed opcode. 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

8/6/2019 Conf Wassa 2004


17

Opcode

0x30RA

Disp

0x5411decrypted opcode


Opcode


Opcode

0x10

RADisp

0x5411plaintext

Addr = 0x12001139c

Addr = 0x1200263e0

0x12001139c…

Decrypted instruction triggers fetch from a new

address, which discloses 16 bits of plaintext.

8/6/2019 Conf Wassa 2004


18


DataNext

Data

Next

Data

NULL

Secret

Convert secret into data fetch address so it can be

Observed in program trace

8/6/2019 Conf Wassa 2004


19

Fight Against Attack on Counter-mode

• Use non-melleable encryption mode

•

Counter-mode, CBC are all melleable.

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

• Authenticate appropriately, PACT 2004

• Change on processor/memory state prohibited by un-

verified code/data or results obtained from un-verifedcode/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

8/6/2019 Conf Wassa 2004


20

• S: Memory integrity can only be protected using longbit 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 off-line attack. Use Integrity verification triggered delaylogic.

Fight Against On-line Attack

8/6/2019 Conf Wassa 2004


21


• 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/targetedmachine. 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 thevictim machine.

8/6/2019 Conf Wassa 2004


22


push param1

push param2

push param3

push param4

push param5

call security_check /*a jump to a subroutine */

tst ax, 0 /* assume return value in ax*/

bne security_failed

nop

nop

nopnop

nop

nop

nop

nop

mov ax, random\_num

xor ax, ax

mov bx, random\_num

xor bx, bx

mov cx, random\_num

xor cx, cx

nop

nop

Alter MAC and Code

Alter Code Only

modify the code and brute force attack the MAC

come up huge number of attack codes and

hope one of them has a MAC collision.

Attacker can

Original Code

8/6/2019 Conf Wassa 2004


23

Delay Logic Driven

by Authentication/

Integrity Verification Enginestall CPU

OK, continue

integrity check failure

• 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.

Tamper Prevention Time (TPT)


clock

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

8/6/2019 Conf Wassa 2004


24

Conclusions

•

Hardware cryptography based software protectionprovides a new security model for applications.

• Appropriate extra security measures have to be usedtogether 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.

conf wassa 2004

Documents