Towards the Issues in Architectural Support for Protection of Software Execution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.