Memory-centric Security Architecture

Weidong Shi Chenghuai Lu Hsien-Hsin (Sean) Lee

1

Applications of Security Processor

Anti reverse engineering

Tamper-proof distributed computing (trusted end-system)

Security Processor
Processor/DSP Core Cache/ SRAM

Tamper-proof embedded sensor device

Crypto Engine

Tamper-proof digital right protection

2

Drawback of Single Key Based Approach

Application Code

Encrypt application memory space

with a single encryption key

Shared Memory

Not suitable for open software

environment where dynamically linked software modules come from heterogeneous sources and with diversified security and digital right requirements

Middle-ware Libs (Dynamically Linked Code)

System Libs (Dynamically Linked Code) OS Kernel (mapped to user space)

Not practical neither secure to

require different applications to share encryption keys for supporting shared memory
3

Example
Application Code

Add-on services, complete app Encrypted with Key chosen by Financial Modeling Library
System Libs (Dynamically Linked Code) OS Kernel (mapped to user space)

Middle-ware Libs (Dynamically Linked Code)

vendor

Vendor of financial modeling lib wants

its IP to be protected (no reverse engineering, no illegal duplication). Library is licensed. Licensed user app allowed to use (call) the libs.

Threats
Secure Processor
Processor Core
Library OS App

Library
App

Library
App

RAM
Caches

Application Code

Hardware Eavesdrop (prevented by encryption)

Library

Software Eavesdrop (read library code/data instead of

calling, prevented by access control)

Objective of Memory Centric Security Architecture

Allow inter-operation of separately protected software
modules Allow protected code modules or middle-ware to be shared Allow data to be shared by separately protected processes Integrate over hardware memory crypto engine

Memory Centric Protection

Security Attributes

Secure Memory Capsules

Secure memory capsules Individually protected memory sub space A memory capsule may contain shared code or shared data Each memory capsule may have its own encryption key, root integrity
signature A processs memory space may contain multiple secure memory capsules 7

Memory Centric Protection

Application Code Middle-ware Lib (Dynamically Linked Code) Code

Code
Private Heap Private Stack Principle B function call

function call

Private Heap
Private Stack Principle A Memory Space

Principle C

function call

Encryption Key Encryption Key Encryption Key

System Lib (Dynamically Linked Code)

Code (system32.dll, kernel32.dll, )

Private Heap Private Stack
8

Security Attribute Table

TLB

Security Attribute Table

Security engine automatically decrypts

and authenticates data fetched from a memory capsule using the capsules key and signature A capsule can be a package of code, private heap and private stack
9

Access Requirement
Memory Capsule A (Principle A) Memory Capsule C (Shared data) Memory Capsule B (Principle B)

Shared Data Space

Application

Shared Middle-ware

A A A B B B

calls reads reads calls reads reads

Bs function Bs code/data shared data C As function As code/data shared data C

permitted disallowed permitted permitted disallowed permitted

10

Access Control
Load/store address
ID of Active Principle (Memory Capsule ID)

... ... ...

SAT Index SAT Index SAT Index

Encryption Key Encryption Key Encryption Key

Authentication Signature Authentication Signature Authentication Signature

ID ID ID

Control Bits Control Bits Control Bits

Access Lookup Table

Cache

A memory capsule always allows its own code to access its own data.
11

Process Execution
Memory Capsule A (Principle A) Memory Capsule C (Shared data) Memory Capsule B (Principle B)

Shared Data Space

Application

Shared Middle-ware call

A B
call

Switch execution from one memory capsule to

another capsule. Each principle has its own stack. Caller principle pushes data to callees private stack. Exchange data through shared memory capsule.
12

A
return

B A
return

Stack Security
Callers Stack Callees Stack

200000

800000

Caller pushes values to callees stack (encrypted

using callees key) Secure transition from callers stack to callees stack. Caller cannot read callees stack. Maintain all stacks status.

13

Transition of Execution Stack

Stack Context Table Caller

Callee

Low addr high addr Stack Frame Ptr 199984 800000

Callers Stack

EBP ESP

200000 199988 199984 799988 799992 799996 800000 200000 199996

Callees Stack

200000 push_stack_ptr push_stack_ptr ebp = esp 199984 r1 = [ebp +4] esp = [ebp] swap_stack r1 return r1 0x10 Return addr 800000

800000

push ebp swap_stack foo push 0x10 call foo pop ebp

200000

Note: Caller allowed to push values to callees stack. Caller cannot read Callees stack after stack switch.

14

Pointer Passing
(Principle A)
P = malloc(20); Foo(p,20)

(Principle B)

Foo(char* p, int s) { int x = *(p+40); }

Temporarily allow callee to share data from callers

space. Be careful to prevent callee from trying to read data outside the exposed range.
15

Security Pointer
unsigned char *p; security void* sp;

callee_id = get_id(foo); sp = add_sharing_ptr(p, 0x20, callee_id, RD|WR); foo(sp, 0x20, ); remove_ptr(sp);

Store declared security pointers in a table. Security pointer identified by a pointer id. Check de-referenced pointer value is inside the declared range.
16

Security Pointer Buffer

Fetch instructions principle ID
Address Calculation

Pointer ID Pointer Buffer

Address
Range and ID Check ID==Fetch Insts Principle ID && addr>=low addr && addr<=high addr

Instrument register file with pointer ID Cache security pointer declarations in security pointer buffer
17

Testbed
A x86 system emulation (Bochs) + cycle-based architecture simulator (TAXI)

x86 out-of-order simulator

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

Protection Assumption
Separate protection of OS, system libraries, and applications

System libraries include

Application

gdi32.dll, kernel32.dll, user32.dll, ddraw.dll,

Dummy Library

Dummy Library

Dummy Library

System Library

System Library

System Library

To keep track switch between protected software module, use API hijack, redirect system libraries function calls to dummy system libraries
Dummy libraries conduct switch between protected modules Dummy libraries created based on Wine Linux header files, +1000 19 functions

Experiment Setup
Parameters L1 I/D Cache L2 Cache Memory Bus CPU Clock AES Latency Authentication tree cache size SHA256 Latency Value DM, 8KB, 1cycle 4way, unified, 512KB, 8 cycles 200MHz, 8B wide 1GHz 80ns 32KB 80ns

Security Attribute Table Latency

Counter cache

1cycle
8KB, 32bit counter, 8 way

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

Performance
1.2 1 0.8 0.6 0.4 0.2 0 acrobat reader media player msdev winzip MSword IExplorer pov-ray Average
XOM-like(AES) MC-XOM-like(AES)

Normalized IPC (512K L2)

Counter+MAC tree

MC-Counter+MAC tree

5% performance loss AES block cipher 13% performance loss Memory centric, additional 1.8% performance loss
21

Performance
1.2 1 0.8 0.6 0.4 0.2 0 acrobat reader media player msdev winzip MSword IExplorer pov-ray Average
XOM-like(AES) XOM-like-app

Normalized IPC (512K L2)

Counter+MAC tree

MC-Counter+MAC tree+app

Only application itself is encrypted. 1.5% - 5% increase of performance due to reduced decryption
overhead and workload
22

Conclusions
Memory centric protection facilitates secure sharing of software
and data.

Under memory centric protection, middle-ware developers do not

have to share encryption keys or have libraries re-encrypted each time it is mapped into applications memory space

Security attribute table and crypto engine automatically chooses

decryption key and integrity signature based on fetch address

Acceptable performance loss using counter mode + caches

23

Questions

24