using address independent seed encryption and bonsai ... · using address independent seed...
TRANSCRIPT
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
3Brian Rogers AISE + BMT for Secure Processors MICRO 40
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??
4Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
5Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
6Brian Rogers AISE + BMT for Secure Processors MICRO 40
OutlineMotivation & BackgroundMemory Encryption
Overview of counter-mode encryptionAddress Independent Seed Encryption
Memory Integrity VerificationEvaluationConclusion
7Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
8Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
9Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
10Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
11Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
12Brian Rogers AISE + BMT for Secure Processors MICRO 40
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%)
13Brian Rogers AISE + BMT for Secure Processors MICRO 40
OutlineBackgroundMemory EncryptionMemory Integrity Verification
Merkle Tree overviewBonsai Merkle Trees
EvaluationConclusion
14Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
15Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
16Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
17Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
18Brian Rogers AISE + BMT for Secure Processors MICRO 40
BMT Structure
Secure Root
Data Ctrs MT nodes
Secure Root
Data Ctrs MT nodes
Secure Chip Boundary
Secure Chip Boundary
MerkleTree
MerkleTreeData MACs
Reduced memory storage overhead & L2 cache contention
Standard Merkle Tree Bonsai Merkle Tree
19Brian Rogers AISE + BMT for Secure Processors MICRO 40
OutlineBackgroundMemory EncryptionMemory Integrity VerificationEvaluationConclusion
20Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
21Brian Rogers AISE + BMT for Secure Processors MICRO 40
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%
22Brian Rogers AISE + BMT for Secure Processors MICRO 40
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%)
23Brian Rogers AISE + BMT for Secure Processors MICRO 40
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
24Brian Rogers AISE + BMT for Secure Processors MICRO 40
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%)
25Brian Rogers AISE + BMT for Secure Processors MICRO 40
Questions
Email: [email protected]
NC STATE UNIVERSITY
GeorgiaTech