design and implementation of the ascend secure...
TRANSCRIPT
![Page 1: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/1.jpg)
Design and Implementation of the Ascend Secure ProcessorLing Ren, Christopher W. Fletcher, Albert Kwon, Marten van Dijk, Srinivas Devadas
![Page 2: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/2.jpg)
Agenda
▪ Motivation
▪ Ascend – Overview
▪ ORAM for obfuscation
▪ Ascend: Frontend
▪ Ascend: Backend
▪ ASIC Implementation
▪ Conclusion
![Page 3: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/3.jpg)
Motivation
![Page 4: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/4.jpg)
Motivation
▪ Computation outsourcing is
becoming more ubiquitous.
▪ Involves sharing private data to
untrusted servers/applications.
▪ With physical access to the
compute node, adversary can
observe access patterns.
![Page 5: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/5.jpg)
Motivation
▪ The state-of-the-art secure systems
can not stop an adversary targeting
Memory access pattern.
▪ Encrypting data does not help.
▪ Solution: Necessary to provide
hardware support for obfuscating the
access patterns.
![Page 6: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/6.jpg)
The dilemma of secure hardware architects
![Page 7: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/7.jpg)
The dilemma of secure hardware architects
▪ For a given program P and input x, it needs T(P,x) time.
▪ Two Choices:
1. Optimize the program based on input data = Security Vulnerability
2. T(p) is oblivious to input = Worst case Performance
▪ Ascend leans towards choice 2.
▪ What is the mid-point?
– Application specific security features
![Page 8: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/8.jpg)
Ascend: Problem Statement
Given an arbitrary batch program P , a public length of
time T and two arbitrary inputs to P namely x and y:
running P(x) for T time is indistinguishable from
running P(y) for T time from the perspective of the
Ascend chip’s power and IO pins.
![Page 9: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/9.jpg)
The protocol overview
![Page 10: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/10.jpg)
Threat Model
▪ The session key K is stored in a register, not accessible to P.
▪ The Ascend chip is assumed to be tamper-resistant : TCB.
▪ The server can monitor the traffic and timing on I/O pins.
▪ Server can tamper the Program or external memory.
▪ Analog channels are not protected.
![Page 11: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/11.jpg)
ORAM for
Obfuscation
![Page 12: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/12.jpg)
Oblivious RAM (ORAM) [Goldreich-Ostrovsky’96]
ORAM
Controller Shuffled
Cache miss
Chip pins
Provably removes all access pattern, leakage
On-chip
![Page 13: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/13.jpg)
Basic ORAM Primitive
▪ Given two memory sequences A and A` with same length
– The sequences can be read/write.
– ORAM guarantees that both are computationally indistinguishable.
– An adversary watching the accesses can not tell:
• Whether the source is reading or writing?
• Where the the access going to?
• What data is accessed?
![Page 14: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/14.jpg)
Path ORAM [CCS’13]
ORAM
Controller
(on-chip)
“The ORAM”Chip pins
Read/writes
![Page 15: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/15.jpg)
Path ORAM Algorithm
1. Look up PosMap for input address a to
obtain the leaf label l. Generate and
replace l with a new random label – l`.
2. Traverse the path to l and decrypt and
store all the data in stash.
3. Update block a in the stash to l`.
4. If not write, return the data else write the
data to contents of
5. Evict and encrypt as many blocks as
possible from the stash to P(l) in the
ORAM tree
![Page 16: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/16.jpg)
Bucket
▪ Made up of Z (L + O(L) + B) bits.
▪ If L=4, there is 50% of actual data on DRAM.
▪ AES-128 in counter mode is used to encrypt the plaintext bucket
▪ A monotonically increasing counter is used to encrypt:
– Each 128 bit chunk is encrypted with
– The value of IV (counter) is added along the bucket.
– Use a different key K every run to avoid a replay attack.
![Page 17: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/17.jpg)
Recursive ORAM
▪ Size of the PosMap grows linearly with the size.
▪ Such huge memory on-chip is a bad idea.
▪ This is similar to classic VAPA conversion!
▪ Solution:
– Store PosMaps in a separate ORAM.
– There are effectively two types of ORAMs:
• Data ORAM
• PosMap ORAM
![Page 18: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/18.jpg)
Recursive ORAM
![Page 19: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/19.jpg)
ORAM in Hardware: Challenges
▪ Size of PosMap.
– Even with a recursive ORAM, a
large chunk of data accesses is
for PosMap ORAM.
▪ Complex Stash Eviction Logic
▪ Modifying DRAM as ORAM
– Inefficiencies due to row misses
(accessing different rows)Percentage of Bytes read from PosMap ORAMs
for X=8 and Z=4.
![Page 20: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/20.jpg)
Frontend
![Page 21: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/21.jpg)
PLB and Unified ORAM
▪ PosMap Lookaside Buffer(PLB):
– Store the leaf information to avoid accesses to PosMap ORAM.
– Security Risk!
▪ Proposed Solution:
– Combine the PosMap and data ORAMs to form a Unified ORAM
– This Unified ORAM contains both Path and data info in its leaves.
– PosMap access is as costly as data access!
– But secure.
![Page 22: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/22.jpg)
Security problem
ORAM-level access pattern
Time
Without PLB
With PLB
Data
ORAM
Map ORAM
![Page 23: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/23.jpg)
Unified ORAM
23
Data ORAMMap
ORAM
Unified ORAM
A
A+1
Path’’’’Path’’’Path’’Path’
![Page 24: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/24.jpg)
ORAM-level access pattern
Time
Data ORAMMap
ORAM
Unified ORAM
Unified ORAM
![Page 25: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/25.jpg)
PMMAC - Memory Integrity Check
▪ The data read from the external memory is passed through
PMMAC to verify the authenticity.
▪ But MAC is susceptible to replay attacks.
▪ Paper proposes to use PosMap entries as non-repeating counters.
▪ MAC is attached to the data block and is relatively small
compared to the data.
▪ Authors prove that “Breaking the PMMAC scheme is as hard as
breaking the underlying MAC scheme.”
![Page 26: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/26.jpg)
PMMAC - Memory Integrity Check
▪ Consider block a with data d and access counter c.
▪ Data Write:
– Replace PosMap entry of a with c
– Generate the leaf l as mod 2L
– Backend receives the data as (h,d) where
▪ Data Read:
– PMMAC receives data from backend as (h*, d*)
– You can verify the integrity by
![Page 27: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/27.jpg)
Backend
![Page 28: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/28.jpg)
Stash Eviction Logic
▪ One of the most crucial part of Path ORAM and generally the
bottleneck for throughput is eviction from stash.
▪ Strategy should also not let the stash overflow.
– Push each evicted block to the deepest possible leaf in the Path (P(l))
▪ During the read/eviction, there are basically 2 tasks:
– Generate the path of access [PushBack()]
– Push the data down the path. [PushToLeaf()]
▪ Authors propose a single cycle algorithm for PushBack()
![Page 29: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/29.jpg)
Stash Eviction Logic
▪ Consider a block a that needs to be evicted from the stash which
resided at leaf l and now moved to l`.
▪ You need to figure out what’s the best place to push the block a in
the tree, for this scenario.
▪ Info necessary: Current Occupancy, Paths to l and l` and stash.
▪ Algorithm:– a_loc = PushBack(l, l`, occupancy); //Called many times
– PushToLeaf(stash, l); //Clears the stash for the path l
![Page 30: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/30.jpg)
Mapping ORAM to DRAM
▪ In a naïve representation of
ORAM in DRAM, every
access to a leaf is different
DRAM row.
▪ Solution
– Build subtrees and map to same
row of the DRAM.
– Improved the bandwidth to 90-
95% of the peak bandwidth.
Example of a k=2 subtree
![Page 31: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/31.jpg)
ASIC Implementation
![Page 32: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/32.jpg)
Chip Specification
▪ 25 SPARC T1 Cores (Princeton)
▪ The LLC misses are handled by the ORAM controller
▪ ORAM Controller with L=23 and B=512
▪ AES and SHA units (for ORAM and server communication)
▪ PMMAC support with 64bit counters and SHA3-224
▪ PosMap of size 8kb on chip (6 levels of recursion)
![Page 33: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/33.jpg)
ASIC Implementation
![Page 34: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/34.jpg)
Power, Performance and Area
▪ Consumes 299mW at 857MHz with Vdd=1.1V (32nm node)
▪ Completes an ORAM access of 512 bits in 1275 cycles
▪ Average slowdown of around 4x on SPEC-Int-2006
▪ Total area of 0.326 mm2 for ORAM Controller.
Module Frontend Backend Encryption
Dimensions( um) 636.7 x 218.7 346.6 x 364.5 669.0 x 364.5
Area (mm2) 0.139 0.126 0.244
![Page 35: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/35.jpg)
Challenges
▪ Significant storage space is spent for metadata.
▪ Can not have a large DRAM
▪ Total number of memory accesses are not hidden
▪ Single user is resident on the chip
▪ Can not bypass the ORAM controller
▪ Increased power consumption my multiple redundant accesses
![Page 36: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/36.jpg)
Conclusion
▪ This work presents the first silicon implementation of ORAM,
integrated in a system.
▪ Presents the entire execution model for running an untrusted
program on sensitive user data.
▪ The implemented logic is only half the size of a single SPARC
core.
▪ Adds an estimated performance overhead of 4x – a reasonable
ask if security is the first class citizen.
![Page 37: Design and Implementation of the Ascend Secure Processorcwfletcher.net/Content/598/lec27_ascend_kartikh.pdf · PLB and Unified ORAM PosMap Lookaside Buffer(PLB): –Store the leaf](https://reader036.vdocument.in/reader036/viewer/2022062603/5f0ac68a7e708231d42d4846/html5/thumbnails/37.jpg)
Questions?