TRUSTED MEMORY Software-Based O-Chip Memory Protection for RISC-V - PowerPoint PPT Presentation

TRUSTED MEMORY Software-Based O�-Chip Memory Protection for RISC-V Trusted Execution Environments Gui Andrade Krste Asanović Dayeol Lee David Kohlbrenner Dawn Song University of California, Berkeley

TRUSTED MEMORY? Securing data/code against snooping/reverse-engineering Cryptographic keys Personally identifiable information Proprietary algorithms Code obscurity Biometric data (defense-in-depth)

TRUSTED MEMORY? Two security domains of system memory: on-chip and ofg-chip . On-chip presumed secure , ofg-chip not quite

TRUSTED MEMORY? Two security domains of system memory: on-chip and ofg-chip . On-chip presumed secure , O�-chip memory On-chip memory ofg-chip not quite a determined extremely di�cult hobbyist (!) could (expensive) to compromise compromise

TRUSTED MEMORY? Two security domains of system memory: on-chip and ofg-chip . On-chip presumed secure , O�-chip memory ofg-chip not quite On-chip memory some gigabytes of some megabytes of storage storage

TRUSTED MEMORY? (to scale) On-chip RAM Two security domains of system memory: on-chip and ofg-chip . Ofg-chip RAM On-chip presumed secure , ofg-chip not quite Hifive Unleashed

also, who’s this Determined Hobbyist?

also, who’s this Determined Hobbyist? the person trying to dump their game console RAM (“neimod” soldered FPGA I/O to this Nintendo 3DS’s memory bus)

Problems Confidentiality Integrity “can an attacker “can an attacker secretly read my data?” change my data?” chonge

Today Keystone Framework intro 1 Prior art in Intel SGX 2 Protected paging 3 Evaluation 4 Conclusion 5

Our Toolset?

an extensible, customizable Trusted Execution Environment framework for RISC-V

Trusted Execution Other Apps Environments Ring 3 RAM OS / Hypervisor Ring 0 - 2 Trustworthy Hardware

Trusted Execution Other Apps Environments Ring 3 RAM OS / Hypervisor Ring 0 - 2 Trustworthy Trusted Hardware Untrusted

Trusted Sensitive Execution Other App Apps Enclave Environments Ring 3 RAM OS / Hypervisor Ring 0 - 2 Enclave Memory Trustworthy Trusted Hardware Untrusted

Trusted Sensitive Execution Other App Apps Enclave Environments Ring 3 RAM OS / Hypervisor Ring 0 - 2 Integrity Enclave Memory Confidentiality Trustworthy Trusted Hardware Remote Attestation Untrusted

Trusted ML Execution Training/ Competitor Inference Environments Ring 3 RAM Cloud provider Ring 0 - 2 Integrity Enclave Memory Confidentiality Trustworthy Trusted Hardware Remote Attestation Untrusted

Perfect! but... Sensitive Other App Apps Enclave Ring 3 RAM On-chip memory OS / Hypervisor some megabytes of Ring 0 - 2 storage Enclave Memory Trusted Untrusted

Perfect! but... Sensitive Other App Apps Enclave Ring 3 RAM On-chip memory OS / Hypervisor exhausted very Ring 0 - 2 quickly Enclave Memory Trusted Untrusted

Perfect! but... Sensitive Other App Apps demand paging Enclave Ring 3 RAM On-chip memory OS / Hypervisor exhausted very Ring 0 - 2 quickly Enclave Memory Trusted Untrusted

Problems Confidentiality Integrity “can an attacker “can an attacker secretly read my pages?” change my pages?” chonge

Solutions Encryption Hashing any outbound pages any inbound pages have are encrypted their hashes checked

Precedent Confidentiality Integrity Intel’s Secure Guard Extensions solve in hardware

Precedent Confidentiality Integrity Modified Carter-Wegman AES-CTR, 128-bit MAC, 56-bit 512b block granularity Version counters Merkle tree for replay hash storage protection

A Software Approach for commodity RISC-V hardware Confidentiality Integrity AES-CTR, 256-bit SHA256 page size granularity Version counters Merkle tree (multiple for replay hash storage of 4096b) protection

The Scheme s_hash := sha(s)

The Scheme s_hash := sha(s) s_enc := aes(s)

The Scheme s_hash := sha(s) s_enc := aes(s) d_dec := aes(d)

The Scheme s_hash := sha(s) s_enc := aes(s) d_dec := aes(d) d_hash := aes(d_dec)

The Scheme s_hash := sha(s) s_enc := aes(s) d_dec := aes(d) d_hash := aes(d_dec) check_hash(d_hash)

The Scheme s_hash := sha(s) s_enc := aes(s) d_dec := aes(d) d_hash := aes(d_dec) check_hash(d_hash) store_hash(s_hash)

The Why a tree? Scheme Array of page hashes too big (wasteful) for s_hash := sha(s) s_enc := aes(s) on-chip memory d_dec := aes(d) d_hash := aes(d_dec) Move it o�-chip check_hash(d_hash) store_hash(s_hash)

The Why a tree? Scheme O �-chip hashes s_hash := sha(s) s_enc := aes(s) Untrusted hashes? d_dec := aes(d) d_hash := aes(d_dec) check_hash(d_hash) store_hash(s_hash)

Problems Confidentiality Integrity “can an attacker “can an attacker secretly read my hashes?” change my hashes?” chonge

Solutions Don’t care! More hashing! cryptographic hash the hash hashes leak no store, keep the information root hash safe

Hashing Resident pages Enclave memory the store Hash store sha(p1) sha(p1) sha(p2) sha(p3) sha(p4) sha(p5) sha(p6) sha(p7) Trusted world Original plan: Keep nonresident page hashes in Non-resident secure memory User OS pages Problem: On-chip memory too valuable! Untrusted world

Hashing Resident pages Enclave memory the store Root hash sha(hash store) Trusted world Solution: Move store ofg-chip, check its Non-resident integrity during User OS pages page swaps Problem: Hash store Hashing the entire sha(p1) sha(p1) sha(p2) sha(p3) sha(p4) sha(p5) sha(p6) sha(p7) store wastes CPU Untrusted world cycles

Hashing Resident pages Enclave memory the store Root hash sha(left block || right block) Trusted world Solution: - Split hash store - Hash left or right Non-resident side as needed User OS pages - Propagate to root Hash store Problem: Hashing half of sha(p1) sha(p1) sha(p2) sha(p3) sha(p4) sha(p5) sha(p6) sha(p7) store still too much Untrusted world for one page swap

Hashing Resident pages Enclave memory the store Root hash sha(left node || right node) Trusted world Solution: - Recursive splits - Hash only the Non-resident relevant leaf User OS pages - Propagate to root Hash store sha(left block || right block) sha(left block || right block) This tree structure is called a Merkle Tree . sha(p1) sha(p1) sha(p2) sha(p3) sha(p4) sha(p5) sha(p6) sha(p7) Untrusted world

Hashing Resident pages Enclave memory the store Root hash sha(left node || right node) Trusted world Merkle tree tradeofgs: - Very little secure memory usage Non-resident - Deeper tree needs Hash store User OS sha(left node || right node) sha(left node || right node) pages more insecure mem - Deeper tree hashes sha(left || right) sha(left || right) sha(left || right) sha(left || right) fewer bytes total - Deeper tree needs sha(p1) sha(p1) sha(p2) sha(p3) sha(p4) sha(p5) sha(p6) sha(p7) more hash passes Untrusted world

Evaluation Software memory protection feasible, with appreciable overhead. Optimizations pending; current implementation conservative with security guarantees

Evaluation With effjcient paging infrastructure, even unoptimized protection routines could be viable.

Evaluation Unfortunately, paging currently accounts for huge runtime overheads

Conclusion Protected paging appropriate for security-critical , speed-flexible operations Specifically, ones under secure memory pressure

Conclusion Protected paging lays groundwork for other space optimizations - Free up L2 cache when enclave is idle - Balance on-chip memory among several enclaves

A Flexible Approach

Conclusion Software protections need no special IP blocks! Frees up die area for cost constrained hardware

Conclusion Software protections are complemented by special IP blocks! One scheme parametrizable over many hardware configurations