1

Memory-centric Security ArchitectureMemory-centric Security Architecture

Weidong Shi

Chenghuai Lu

Hsien-Hsin (Sean) Lee

Georgia Institute of Technology

Atlanta, Georgia 30332, USA

2

Crypto Engine

Processor/DSPCore

Cache/SRAM

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

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

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

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)

Prot

ecti

on b

ound

ary

6

Objectives of MESAMemory-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

Principle 0

Principle 1

Principle N

• 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

SecurityAttributes

SecureMemory Capsules

......

...

...

...

...

...

...

......

......

......

......

ProcA

ProcB

ProcX

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

Encryption Key

Encryption Key

Memory-centric Protection Memory-centric Protection

Principle A

Principle BPrinciple C

Memory Space

function call

function call

function call

9

SAT Index...

...

...

SAT Index

SAT Index

AuthenticationSignature

ID Control Bits

ID Control Bits

ID Control Bits

AuthenticationSignature

AuthenticationSignature

Encryption Key

Encryption Key

Encryption Key

Code Space

Private Heap

Private Stack

TLB

Security Attribute Table (SAT)

Security Security Attribute Table 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

Example of Access Requirement

Code Space

Private Heap

Private Stack

Code Space

Private Heap

Private Stack

Shared DataSpace

Memory Capsule A Memory Capsule C (Shared data)

Memory Capsule B

Shared MiddlewareApplication

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

SAT Index...

...

...

SAT Index

SAT Index

AuthenticationSignature

ID Control Bits

ID Control Bits

ID Control Bits

AuthenticationSignature

AuthenticationSignature

Encryption Key

Encryption Key

Encryption Key

IDRd/Wr

ID

Cache

Access Lookup Table

Shared Data Access ControlLoad/store address

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

ID of Active Principle(Memory Capsule ID)

SAT

12

Cross-Principle Function CallCross-Principle Function Call

Code Space

Private Heap

Private Stack

Code Space

Private Heap

Private Stack

Shared DataSpace

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

call

return

return

13

Passing Values for Cross-Principle Call

200000 800000

199984

Caller’s Stack Callee’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

200000799988

push ebpswap_stack foopush 0x10call foopop 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 r1return r1

esp = [ebp]

199988

push ebpswap_stack foopush 0x10call foopop ebp

push_stack_ptr

ebp = esp…r1 = [ebp +4]

swap_stack r1return r1

esp = [ebp]

199984800000799996799992799988799988800000199984 199984199988

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

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.

Code Space

Private Heap

Private Stack Code Space

Private Heap

Private Stack

p = malloc(20);

(Principle B)

(Principle A)

Foo(char* p, int s){

int x = *(p+40); …}

Foo(p,20)

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

Range and ID CheckID==Fetch Inst’s Principle ID && addr>=low addr

&& addr<=high addr

Address Calculation

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

Rd

Rd

Wr

Wr

Wr

Low Addr

Low Addr

Low Addr

High Addr

High Addr

Pointer token

Pointer token

Pointer token

Pointer token...

...

...

Pointer token

Pointer token

Vld

Vld

Vld

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

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

Simulation ParametersSimulation Parameters

Parameters Value

L1 I/D Cache DM, 8KB, 1cycle

L2 Cache 4way, unified, 512KB, 8 cycles

Memory Bus 200MHz, 8B wide

CPU Clock 1GHz

AES Latency 80ns

Authentication tree cache size 32KB

SHA256 Latency 80ns

Security Attribute Table Latency 1cycle

Counter cache 8KB, 32bit counter, 8 way

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

tree cache.

21

Normalized IPC (512K L2)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

acrobatreader

mediaplayer

msdev winzip MSword IExplorer pov-ray Average

Counter+MAC tree MESA-Counter+MAC tree XOM-like(AES) MESA-XOM-like(AES)

MESA Performance MESA Performance

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

22

Normalized IPC (512K L2)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

acrobatreader

mediaplayer

msdev winzip MSword IExplorer pov-ray Average

CM+All Encrypted CM+App Encrypted AES+All Encrypted AES+App Encrypted

MESA Performance w/ Different Levels of ProtectionMESA 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

ConclusionsConclusions

• 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

QuestionsQuestions