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

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

3. 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 Shared Memory Middleware Libs (Dynamically Linked Code) Application Code System Libs (Dynamically Linked Code) OS Kernel (mapped to user space)

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

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

6. 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. 7 Memory-centric Protection Concept 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 Security Attributes Secure Memory Capsules...

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

9. 9 TLB Security Attribute Table (SAT) Security Table Security Attribute Table 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. 10 Example of Access Requirement Memory Capsule AMemory Capsule C (Shared data) Memory Capsule B Shared MiddlewareApplication AcallsB’s functionpermitted AreadsB’s code/datadisallowed Areadsshared data Cpermitted BcallsA’s functionpermitted BreadsA’s code/datadisallowed Breadsshared data Cpermitted

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

12. 12 Cross-Principle Function Call Memory Capsule A (Principle A) Memory Capsule C (Shared data) Memory Capsule B (Principle B) A B Shared Middle-wareApplication A B A 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. call return

13. 13 Passing Values for Cross-Principle Call 200000 800000 199984 Caller’s StackCallee’s Stack 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.

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

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

16. 16 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); … Security Pointers 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. 17 Address Pointer ID Fetch instruction’s principle ID Security Pointer Buffer Extend RF with pointer token Cache security pointer declarations in SPB Secure Pointer Buffer Extended RF for ptr High Addr ID Control Bits ID Control Bits ID Control Bits Rd Wr Low Addr High Addr Pointer token... Pointer token Vld

18. 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. 19 Simulation Setup Application System Library Wrapper to identify pointers System Library System Library 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

20. 20 Simulation Parameters ParametersValue L1 I/D CacheDM, 8KB, 1cycle L2 Cache4way, unified, 512KB, 8 cycles Memory Bus200MHz, 8B wide CPU Clock1GHz AES Latency80ns Authentication tree cache size32KB SHA256 Latency80ns Security Attribute Table Latency1cycle Counter cache8KB, 32bit counter, 8 way Counter mode encryption with counter cache MAC (message authentication code) tree for integrity verification with tree cache.

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

22. 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. 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. 24 Questions