Memory-centric Security Architecture

1. Memory-centric Security Architecture Weidong Shi Chenghuai Lu Hsien-Hsin (Sean) Lee Georgia Institute of Technology Atlanta, Georgia 30332, USA

2. Security Processor Applications of Security Processor Anti reverse engineering Tamper-proof distributed computing (trusted end-system) Tamper-proof embedded sensor device Tamper-proof digital right protection

3. Drawback of Single Master Key Based Approach • Encrypt application memory space with a single encryption key • Not suitable for open environment • Dynamically linked modules come from heterogeneous sources • Diversified security and digital right requirements • Not practical neither secure to require different applications to share encryption keys Application Code Shared Memory Middleware Libs (Dynamically Linked Code) System Libs (Dynamically Linked Code) OS Kernel (mapped to user space)

4. Add-on services, complete app Encrypted with Key chosen by vendor Financial Modeling Library Open Software Environment Application Code Middleware Libs (Dynamically Linked Code) System Libs (Dynamically Linked Code) • IP of financial modeling lib need protection • No reverse engineering • No illegal duplication). • Licensed user app allowed to use (call) the libs. OS Kernel (mapped to user space)

5. Application Code Hardware Eavesdrop (prevented by encryption) Library Software Eavesdrop (read library code/data instead of calling, prevented by access control) Protection from Threats Secure Processor Library Library Processor Core App App Library OS Protection boundary App RAM Caches

6. Objectives of MESA Memory-centric Security Architecture • Allow inter-operation of separately protected software modules • Allow protected code modules or middleware to be shared • Allow data to be shared by separately protected processes • Integrated with tamper-resistant, tamper-evident hardware

7. ... ... ... ... ... ... ... ... ... ... Memory-centric Protection Concept Security Attributes Secure Memory Capsules • Secure memory capsules – Individually protected memory subspace • A memory capsule may contain shared code or shared data • Each memory capsule may have its own encryption key, integrity signature • A process’s memory space may contain multiple memory capsules

8. Memory-centric Protection Application Code Middleware Lib (Dynamically Linked Code) Code function call Code Private Heap Private Heap Private Stack Principle A Private Stack Memory Space Principle B function call Principle C function call System Lib (Dynamically Linked Code) Encryption Key Encryption Key Code (system32.dll, kernel32.dll, …) Encryption Key Private Heap Private Stack

9. Security Attribute Table TLB Security Attribute Table (SAT) • Security engine decrypts and authenticates data fetched from memory using SAT • A capsule can be a package of code, private heap and private stack

10. Example of Access Requirement Memory Capsule A Memory Capsule C (Shared data) Memory Capsule B Application Shared Middleware A calls B’s function permitted A reads B’s code/data disallowed A reads shared data C permitted B calls A’s function permitted B reads A’s code/data disallowed B reads shared data C permitted

11. ID of Active Principle (Memory Capsule ID) Shared Data Access Control Load/store address SAT Access Lookup Table A memory capsule always allows its own code to access its own data. Cache

12. Cross-Principle Function Call Memory Capsule A (Principle A) Memory Capsule C (Shared data) Memory Capsule B (Principle B) Application Shared Middle-ware A call • Switch execution from one memory capsule to another capsule. • Each principle has its own stack. • Caller principle pushes data to callee’s private stack. • Exchange data through shared memory capsule. B call A return B return A

13. Passing Values for Cross-Principle Call • Secure transition from caller’s stack to callee’s. • Caller pushes values to callee’s stack (encrypted using callee’s key if needed) • Caller cannot read callee’s stack. Caller’s Stack Callee’s Stack 800000 200000 199984

14. push_stack_ptr push ebp ebp = esp swap_stack foo … push 0x10 r1 = [ebp +4] call foo esp = [ebp] pop ebp swap_stack r1 return r1 Passing Values for Cross-Principle Call Stack Context Table Low addr – high addr Stack Frame Ptr EBP 200000 200000 799988 Caller 199984 ESP 199984 199988 199988 800000 199984 799988 799988 799992 799996 800000 700000 - 800000 Callee 800000 100000 - 200000 Caller’s Stack Callee’s Stack 800000 200000 0x10 Return addr push_stack_ptr push ebp 800000 ebp = esp swap_stack foo … 200000 push 0x10 r1 = [ebp +4] call foo esp = [ebp] pop ebp swap_stack r1 return r1 • Swap_stack checks address range against “low and high addr” in the stack context table

15. Foo(char* p, int s) { int x = *(p+40); … } Passing Address Pointer p = malloc(20); (Principle A) Foo(p,20) (Principle B) • Temporarily allow callee to share data from caller’s space. • Be careful to prevent callee from reading data outside the designated range.

16. Security Pointers unsigned char *p; security void* sp; … callee_id = get_id(“foo”); sp = sec_add_sharing_ptr(p, 0x20, callee_id, RD|WR); foo(sp, 0x20, …); sec_remove_ptr(sp); … • Store declared security pointers in a “secure pointer buffer”. • Security pointer identified by a pointer token. • Check de-referenced pointer value is inside the designated range.

17. Security Pointer Buffer Vld Pointer token ... Vld ... Pointer token ... Vld Pointer token ID Rd Wr Pointer token Low Addr High Addr Control Bits Low Addr High Addr ID Rd Wr Control Bits Pointer token ID Rd Wr Pointer token Low Addr High Addr Control Bits Fetch instruction’s principle ID Extended RF for ptr Pointer ID Secure Pointer Buffer Address • Extend RF with pointer token • Cache security pointer declarations in SPB

18. Simulation Framework • A x86 system emulation (Bochs) + cycle-level architecture simulator (TAXI) • x86 out-of-order simulator (TAXI) • Run Windows NT OS with applications • IE Explorer (fetch websites) • Adobe Acrobat (open pdf file, search key words) • Media Player 2 (avi file play) • Visual Studio (compile C++ project) • Word (type, cut, paste, grammar check) • Povray 3 (render default image) • Winzip (unzip package)

19. Separate protection OS System libraries Applications System libraries from Win NT4.0 gdi32.dll, kernel32.dll, user32.dll, ddraw.dll, etc. Use wrapper to keep track of pointers Wrapper consults Wine Linux header files for pointers Simulation Setup Application System Library System Library System Library Wrapper to identify pointers

20. Simulation Parameters • Counter mode encryption with counter cache • MAC (message authentication code) tree for integrity verification with tree cache.

21. MESA Performance • All the software are encrypted • MESA incurs 1 to 1.8% performance degradation

22. MESA Performance w/ Different Levels of Protection • Bar 2 and 4 only encrypt applications. • 1.5% - 5% increase of performance due to reduced decryption overhead and workload

23. Conclusions • MESA facilitates secure sharing of software and data using memory-centric protection. • Under MESA, middleware developers do not need to share encryption keys or have libraries re-encrypted each time it is mapped into application’s memory space • Security attribute table and crypto engine automatically chooses decryption key and integrity signature based on fetch address • Acceptable performance loss

24. Questions