1 towards the issues in architectural support for protection of software execution weidong shi...
TRANSCRIPT
1
Towards the Issues in Architectural Support for Towards the Issues in Architectural Support for Protection of Software ExecutionProtection of Software Execution
Weidong Shi
Hsien-Hsin (Sean) Lee
Mrinmoy Ghosh
Chenghuai Lu
School of Electrical and Computer EngineeringSchool of Electrical and Computer Engineering
Georgia Institute of TechnologyGeorgia Institute of Technology
2
ContentContent
• Motivation
• Necessity for Hardware Cryptography Based Protection
• Attack to Counter Mode Encryption
• Fight Against On-line Attack Using Delay Logic
• Conclusions
3
Motivation
• Put issues debated off-line on-fine
• Highlight several issues
• Reach consensus
4
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.
5
• Secure future applications, applications cannot be secured today and new business models
Necessity for Hardware Cryptography Based 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, bus tracing devices, signal replaying devices ….
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, 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”.
7
Counter-mode Background
Counter + 0
Plaintext1
Ciphertext1
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.
Key
Block Cipher
Pseudo-random pad
Counter +1
Key
Block Cipher
Pseudo-random pad
Counter + n
Key
Block Cipher
Pseudo-random pad
Ciphertext2 Ciphertextn
Sender side
8
Counter + 0
Ciphertext1
Plaintext1
Counter +1
Ciphertext2
Counter + n
Ciphertextn
• 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
Plaintext2 Plaintextn
Counter-mode BackgroundReceiver side
9
memory block countermemory block countermemory block counter
… …memory block countermemory block counter
Unprotected RAM
cache linecache linecache line
…cache linecache line
Crypto Engine
ProcessorCore
Secure Processor
Attack On Counter-mode – Memory Encryption
10
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.
11
Counter-mode Summary – cont’
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 modes such as CBC (cipher block chaining).
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
12
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.
13
Attack On Counter-mode
• Ability to obtain SW execution traces and bus traces
• Logical analyzer• Interposer card• Low cost FPGA based trace device
14
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
15
Attack On Counter-mode - Incremental Guess
0x9426814a
0x9426814a
ciphertext
plaintext0x40c05411
Instructionaddq t5, 0x2, a1
Opcode RA Disp
Opcode RA DispRB
Opcode RA FunctionRB RC
Branch Format
Memory Format
Operate Format
Opcode0x10
RA Disp
Addr = 0x2001139c
• 6-bit opcode, 64 possible
opcodes. Flip bits of opcode
ciphertext and trace program
control.
16
Opcode0x25
RA Dispciphertext
Opcode0x10
RA Dispplaintext
Opcode0x4
RA Dispopcode guess
Opcode0x11
RA 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
Attack On Counter-mode - Incremental Guess
17
Opcode0x25
RA Dispciphertext
Opcode0x10
RA Dispplaintext
Opcode0x10
RA Dispopcode guess
Opcode0x5
RA Dispciphertext after flip
Opcode0x30
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
Attack On Counter-mode - Incremental Guess
18
Opcode0x30
RADisp
0x5411decrypted opcode
Opcode0x5
RA Dispciphertext
Opcode0x10
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
19
Attack On Counter-mode – Convert Secret to Addr
Data
Next
Data
Next
Data
NULL
Secret
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) .
20
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
Small enough to fit into one cache line. A cache
line of uniform values widely exits.
21
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
22
Static Flow Based Attack
• Software & Program “bug”s.
• Better solved within software domain. Compiler analysis, programming model
• Not an attack based on chosen-ciphertext malleability.
unsigned int x; // a secret is stored in x
…
if (x<40000)
{
…
} else {
…
}
23
• 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.
Fight Against On-line Attack
24
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.
25
Fight Against On-line Attack
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
nop
nop
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
26
Delay Logic Driven by Authentication/
Integrity Verification Enginestall CPU
OK, continue
integrity check failure
• 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)
Fight Against On-line Attack
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
27
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.