Towards the issues in architectural support for protection of software execution
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Towards the Issues in Architectural Support for Protection of Software Execution PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on
  • Presentation posted in: General

Towards the Issues in Architectural Support for Protection of Software Execution. Weidong Shi Hsien-Hsin (Sean) Lee Mrinmoy Ghosh Chenghuai Lu School of Electrical and Computer Engineering Georgia Institute of Technology. Content. Motivation

Download Presentation

Towards the Issues in Architectural Support for Protection of Software Execution

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Towards the issues in architectural support for protection of software execution

Towards the Issues in Architectural Support for Protection of Software Execution

Weidong Shi

Hsien-Hsin (Sean) Lee

Mrinmoy Ghosh

Chenghuai Lu

School of Electrical and Computer Engineering

Georgia Institute of Technology


Content

Content

  • Motivation

  • Necessity for Hardware Cryptography Based Protection

  • Attack to Counter Mode Encryption

  • Fight Against On-line Attack Using Delay Logic

  • Conclusions


Towards the issues in architectural support for protection of software execution

Motivation

  • Put issues debated off-line on-fine

  • Highlight several issues

  • Reach consensus


Towards the issues in architectural support for protection of software execution

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.


Towards the issues in architectural support for protection of software execution

Necessity for Hardware Cryptography

Based Protection – cont’

  • Secure future applications, applications cannot be secured today and new business models

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

Software secrecy

Military embedded systems,

mobile software agents

Anti-reverse engineer

Program, software, library as IP

Data secrecy/integrity

Distributed computing, mobile software agents

Anti-machine emulator

Software rights

Anti-authoritative client

On-line video games


Towards the issues in architectural support for protection of software execution

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 privacy protected by counter mode when integrity check is “weak”.


Towards the issues in architectural support for protection of software execution

Counter-mode Background

Counter +1

Counter + n

Key

Key

Block Cipher

Block Cipher

Block Cipher

Pseudo-random pad

Pseudo-random pad

Pseudo-random pad

Ciphertext1

Ciphertext2

Ciphertextn

Sender side

Counter + 0

Key

Plaintext1

Plaintext2

Plaintextn

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


Towards the issues in architectural support for protection of software execution

Counter-mode Background

Block Cipher

Block Cipher

Block Cipher

Pseudo-random pad

Pseudo-random pad

Pseudo-random pad

Plaintext1

Plaintext2

Plaintextn

Receiver side

Counter + 0

Counter +1

Counter + n

Key

Key

Key

Ciphertext1

Ciphertext2

Ciphertextn

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


Towards the issues in architectural support for protection of software execution

Attack On Counter-mode – Memory Encryption

memory block

memory block

memory block

memory block

memory block

counter

counter

counter

counter

counter

cache line

cache line

cache line

Crypto

Engine

cache line

cache line

Processor

Core

Unprotected RAM

Secure Processor


Towards the issues in architectural support for protection of software execution

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


Towards the issues in architectural support for protection of software execution

Counter-mode Summary – cont’

  • Chosen ciphertext malleable

ciphertext

plaintext

1

0

1

1

0

1

0

1

1

0

1

0

1

0

0

0

1

1

  • How about other NIST block cipher based modes such as CBC (cipher block chaining).

ciphertext,

memory block n-1

ciphertext,

memory block n

0

1

0

1

1

0

1

0

1

0

0

0

1

1

0

1

1

Block Cipher

plaintext

0

1

1

1

0

0

1

1

1


Towards the issues in architectural support for protection of software execution

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 un-verified instructions, or based on control flow determined by unverified data

    • Data/instruction fetch issued to memory using address obtained from unverified data.


Towards the issues in architectural support for protection of software execution

Attack On Counter-mode

  • Ability to obtain SW execution traces and bus traces

    • Logical analyzer

    • Interposer card

    • Low cost FPGA based trace device


Towards the issues in architectural support for protection of software execution

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 (reduce brute force search space)

  • Patching software with small piece of attack code


Towards the issues in architectural support for protection of software execution

  • 6-bit opcode, 64 possible

    opcodes. Flip bits of opcode

    ciphertext and trace program

    control.

Attack On Counter-mode - Incremental Guess

Addr = 0x2001139c

0x9426814a

ciphertext

plaintext

Instruction

0x9426814a

0x40c05411

addq t5, 0x2, a1

Opcode

0x10

RA

Disp

Branch Format

Opcode

RA

Disp

Memory Format

Opcode

RA

RB

Disp

Opcode

RA

RB

Function

RC

Operate Format


Towards the issues in architectural support for protection of software execution

Flip bits of opcode ciphertext based on guessed opcode. The

target is opcode 0x30 (opcode of jmp)

Attack On Counter-mode - Incremental Guess

plaintext

Opcode

0x10

RA

Disp

ciphertext

Opcode

0x25

RA

Disp

opcode guess

Opcode

0x4

RA

Disp

ciphertext

guessed opcode

1

0

0

1

0

1

0

0

0

1

0

0

Ciphertext after bit flip

target opcode

0

1

0

0

0

1

1

1

0

0

0

0

ciphertext after flip

Opcode

0x11

RA

Disp

decrypted opcode

Opcode

0x24(stf)

RA

Disp


Towards the issues in architectural support for protection of software execution

Flip bits of opcode ciphertext based on guessed opcode. The

target is opcode 0x30 (opcode of jmp)

Attack On Counter-mode - Incremental Guess

plaintext

Opcode

0x10

RA

Disp

ciphertext

Opcode

0x25

RA

Disp

opcode guess

Opcode

0x10

RA

Disp

ciphertext

guessed opcode

1

0

0

1

0

1

0

1

0

0

0

0

Ciphertext after bit flip

target opcode

0

0

0

1

0

1

1

1

0

0

0

0

ciphertext after flip

Opcode

0x5

RA

Disp

decrypted opcode

Opcode

0x30

RA

Disp


Towards the issues in architectural support for protection of software execution

Decrypted instruction triggers fetch from a new

address, which discloses 21 bits of plaintext.

Attack On Counter-mode - Incremental Guess

plaintext

Opcode

0x10

RA

Disp

0x5411

ciphertext

Opcode

0x5

RA

Disp

decrypted opcode

Opcode

0x30

RA

Disp

0x5411

Addr = 0x2001139c

0x9426814a

0x12001139c

Addr = 0x200263e0


Towards the issues in architectural support for protection of software execution

Convert secret into data fetch address so it can be

observed in program trace. At least this attack

reduces the search space (only high bits are left) .

Attack On Counter-mode – Convert Secret to Addr

Data

Next

Secret

Data

Next

Data

NULL


Towards the issues in architectural support for protection of software execution

Small enough to fit into one cache line. A cache

line of uniform values widely exits.

Attack On Counter-mode – Binary Search

  • Stick in a small piece of attacking codes. More radical attack

  • Large percentage of information in memory is predictable. 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, if R2>2^16, try 2^24 next, … At most 32 trials to compromise the secret)

R1 = a constant value;

R2 = load some secret

if (R1<R2)

goto addr1

else

goto addr2


Towards the issues in architectural support for protection of software execution

Fight Against Attack on Counter-mode

  • Use chosen-ciphertext non-malleable encryption mode

    • Counter-mode, CBC are all malleable.

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

  • Authenticate appropriately, PACT 2004

    • Change on processor/memory state prohibited by un-verified code/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


Towards the issues in architectural support for protection of software execution

Static Flow Based Attack

unsigned int x; // a secret is stored in x

if (x<40000)

{

} else {

}

  • Software & Program “bug”s.

  • Better solved within software domain. Compiler analysis, programming model

  • Not an attack based on chosen-ciphertext malleability.


Towards the issues in architectural support for protection of software execution

Fight Against On-line Attack

  • S: Memory integrity can only be protected using long bit Hash or Merkle Tree.

  • R: Hash is vulnerable to off-line attack, and MAC (message authentication code) is preferred because of its efficiency and ability to prevent some off-line attack. Use delay logic triggered by integrity verification failures.


Towards the issues in architectural support for protection of software execution

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.


Towards the issues in architectural support for protection of software execution

Fight Against On-line Attack

Original Code

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

Alter Code Only

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

Attacker can

nop

nop

nop

nop

nop

nop

nop

nop

come up huge number of attack codes and

hope one of them has a MAC collision.

modify the code and brute force attack the MAC


Towards the issues in architectural support for protection of software execution

Fight Against On-line Attack

  • State of TPT is persistent.

  • 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 Timer (TPT)

Delay Logic Driven

by Authentication/

Integrity Verification Engine

integrity check failure

stall CPU

clock

OK, continue

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


Towards the issues in architectural support for protection of software execution

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

  • MAC tree is better than Hash tree.

  • TPT is a simple and effective way to fight against

    on-line attacks on software integrity.


  • Login