Using Address Independent Seed Encryption and Bonsai ... · Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and Performance-Friendly

Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and

Performance-Friendly

Brian Rogers, Siddhartha Chhabra,

Yan Solihin

NC STATE UNIVERSITY

GeorgiaTech

§

Milos Prvulovic§

2Brian Rogers AISE + BMT for Secure Processors MICRO 40

Motivation

Why is there a need for secure processors?Digital Rights Management, Copy Protection, Trusted Distributed Computing, Software Piracy, Reverse Engineering, Data Theft

Why are architectural mechanisms necessary?Hardware attacks emerging (e.g. Mod-chips, bus analyzers)

SW-only protection vulnerable to HW attacks

XBOX mod-chip PS mod-chip GC mod-chip

$59.99 $53.49 $49.69

http://www.xbox-modchips.com/dms4-pro-ps2.htm

http://www.xbox-modchips.com/qoob-pro.htm


Secure Processor Architecture

Private and Tamper Resistant execution environment

Crypto Engine

Processor Core

Cache

Trusted DomainTrusted Domain

UnTrustedUnTrusted DomainDomain

Main Memory

(Encrypted Code/Data & Authentication Codes)

Sec

ure

Pro

cess

or??


Prior WorkMemory Encryption

Counter Mode Encryption [Suh ’03], [Yang ’03]Overlap decryption and memory latencies

System-level issues (difficult to support common features)Virtual Memory

Shared memory-based Inter-Process Communication (IPC)

Memory Integrity VerificationMerkle Tree Integrity Verification [Gassend ’03]

Prevents data replay attacks

Performance & storage overheads


ContributionsAddress Independent Seed Encryption (AISE)

Retains same cryptographic latency-hiding ability Compatible with support for virtual memory and IPC

Bonsai Merkle Trees (BMT)New, reduced size Merkle Tree organizationSame protection, but lower storage & performance overheads

Extended Merkle Tree ProtectionNovel mechanism to protect both physical memory and the disk from tampering attacks


OutlineMotivation & BackgroundMemory Encryption

Overview of counter-mode encryptionAddress Independent Seed Encryption

Memory Integrity VerificationEvaluationConclusion


Counter Mode Encryption

AES

Main Memory

Lowest-level Cache

Secure Chip Boundary

Secret Key

SeedPad

Padding Block Address Block Counter128 bits

Seed

Spatial Uniqueness Temporal Uniqueness

Security: Seed must be used only oncePerformance: Seed must be known at cache miss time


Problems with Address-Based SeedsWhat if seed includes Physical Address?

Security: Possible pad reuse between disk & memoryComplexity: Extra cryptographic work on page swaps

What if seed includes Virtual Address?Complexity: Storage of VA’s in lowest-level on-chip cacheSecurity: Possible pad reuse between different processesPrevented by including process ID in seed, but…

Shared-memory based IPC is difficult to supportOS will reuse process ID’s

Fundamental Problem:Address used for memory management purposes, not as a component for security


Possible Solution – Global Counter Eliminates system-level problems of address-based seedsMaintain a large (64b) global counter on-chipSeed == global counter valueLarger performance and storage overheads

Large per-block counters do not cache wellRequire more storage in memory


Address Independent Seed EncryptionUse logical identifiers in seeds instead of addressManage logical ID per physical page, not per blockNew seed composition:

LPIDUnique value assigned to a page when allocatedObtained from a 64b on-chip Global Page Counter

Stored in a non-volatile registerOverflow not an issue

Remains associated with page throughout its lifetime

Padding Block Page Offset Block CounterLogical Page IDentifier (LPID)

Spatial Uniqueness Temporal Uniqueness


LPID StorageBorrow an idea from split counter organization [Yan ’06]

Co-store LPID’s with block counters

Example – 4KB page size, 64B block size, 64-bit LPID, 7-bit counter per block

On block counter overflow:Assign new LPID to block’s page & re-encrypt that page

On-chip counter cache to enable latency-hiding

LPIDCounter Block

64b 64 x 7-bit block counters

64B


AISE AdvantagesRetains latency-hiding ability

Counter caching or counter predictionSeeds are globally unique

Eliminates pad reuseNo special mechanisms for page swaps

Swap page of data, LPID, & block counters to/from diskShared-memory IPC naturally supportedLow memory storage overhead (1.6%)


OutlineBackgroundMemory EncryptionMemory Integrity Verification

Merkle Tree overviewBonsai Merkle Trees

EvaluationConclusion


Merkle Tree Integrity Verification

Main Memory

MA

C

MA

CM

AC

MA

C

MA

C

MA

C

. . . . .

. . . . .

Root MAC

. . . . .

. . . . .

Inte

rmed

iate

MA

Cs

• 64B Block Size

• 128b Auth. Codes


Performance OptimizationProblem: Large performance overhead

Verify MACs to root for every data fetchOptimization: Cache MACs

Cached MAC blocks are verified & trustedOnly verify up the Merkle Tree to first cached MACLower performance overhead, but…

Large portion of L2 cache may be occupied by MACsIncrease in cache capacity misses


Bonsai Merkle Trees (BMT)Leverage counter-mode memory encryptionTwo Observations:

Merkle Tree only needed to prevent replay attacksCounter-mode encryption schemes maintain a counter per memory block

Essentially a version number

ClaimData blocks don’t need MT to guard replay attacks if:(1) Each block is protected with a MAC(2) Block’s MAC computed on ciphertext & counter value(3) Integrity & freshness of counter values guaranteed


BMTs (Cont.)Why claim holds true:

MACold = Hk(Ctextold, Counterold)Attacker replays MACold & Ctextold instead of MACfresh & Ctextfresh

MACold ≠ Hk(Ctextold, Counterfresh)Processor knows Counterfresh

How to guarantee processor knows Counterfresh?We protect counters with Merkle Tree!

Significantly smaller and shallower Bonsai Merkle Tree


BMT Structure

Secure Root

Data Ctrs MT nodes

Secure Root

Data Ctrs MT nodes



MerkleTree

MerkleTreeData MACs

Reduced memory storage overhead & L2 cache contention

Standard Merkle Tree Bonsai Merkle Tree


OutlineBackgroundMemory EncryptionMemory Integrity VerificationEvaluationConclusion


Simulation SetupSESC – A detailed, execution-driven simulator

Three issue, out of order processor

L1 Cache Split I&D, 32KB each, 2-way set-associative, 64B line, 2-cycle/access

L2 Cache Unified 1MB, 8-way set-associative, 64B line, 10-cycle/access

Memory/Bus 200-cycle uncontended access time, 600MHz Bus

AES/SHA-1 Engines 80 cycle latency, 16-stage pipeline

Counter Cache 32KB, 16-way set associative, 64B lineOne 64b LPID, 64-7b minor (4KB page)

Merkle-Tree Covers 1GB memory space, 128b MACs


Address Independent Seed Encryption

AISE performs significantly better for memory-intensive applicationsAISE performance equivalent to prior counter-mode studies [Yan ’06]

0%

5%

10%

15%

20%ap

plu

apsi art

equa

ke gap

mcf

mes

a

mgr

id

swim

wup

wise

AV

G21

Exe

cutio

n T

ime

Ove

rhea

d

AISEglobal32global64

23% 33% 39%


Bonsai Merkle Tree

0%

5%

10%

15%

20%

25%

30%ap

plu

apsi art

equa

ke gap

mcf

mes

a

mgr

id

swim

wup

wise

AV

G21

Exe

cutio

n T

ime

Ove

rhea

d

AISE AISE + MT AISE + BMT

74% 35% 63%

BMTs eliminate significant portion of the overhead of Merkle Tree-based integrity protection (12% to 2%)


L2 Cache Miss Rate

0%

10%

20%

30%

40%

50%

60%

appl

u

apsi art

equa

ke gap

mcf

mes

a

mgr

id

swim

wup

wis

e

AVG

21

Nor

mal

ized

L2

Cac

he M

iss

Rat

e AISE+MT AISE+BMT

BMTs significantly reduce cache contention & L2 miss ratesCounter Cache hits filter Merkle Tree integrity checks


ConclusionsAISE

Retains cryptographic latency-hiding abilityCompatible w/ virtual memory & shared memory IPCSimplifies process of page swapping encrypted pages

BMTsRetain security of standard Merkle Tree over memorySignificant reduction in performance overheads (12% to 2%) and memory storage overheads (33% to 21%)


Questions

Email: [email protected]

NC STATE UNIVERSITY

GeorgiaTech

mailto:[email protected]

Documents

Using Address Independent Seed Encryption and Bonsai ... · Using Address Independent Seed Encryption and Bonsai Merkle Trees to Make Secure Processors OS- and Performance-Friendly