【USENIX Security '21】Enclaveに強力な分離と高カスタマイズ性をもたらすCUREアーキテクチャ
TL;DR
Enclaveを分離された3つのtypeで再定義
3つのEnclaveを組み合わせてセキュアかつ高カスタマイズ性を実現するアーキテクチャCUREを提案
RISC-Vベースの実装とベンチマーク評価を実施
オーバーヘッド大きめ
本文
既存のTEEアーキテクチャの多くは単一のenclave typeのみをサポートし、機械学習用途のASICなど周辺機器とデータの受け渡しを行う安全なチャネルを柔軟かつ効率的にサポートすることができない。またcache side-channel攻撃に対する保護がアドホックな対策となっている。
これらを解決するために強力に分離されたenclaveを提供するTEEアーキテクチャを提案する論文だ。分離されたenclaveは以下3つのtypeが存在し、単一のenclaveを周辺機器、CPUコア、cacheリソースへと割当が可能となっている。
User-space enclave
いわゆるuser-spaceで動かすアプリケーション
メモリ管理、例外/割込、System CallはすべてOSに依存
Kernel-space enclaves
メモリ管理やruntimeをenclave内に実装
VMをカプセル化するenclaveを構築可能
Sub-space enclaves
enclaveの信頼境界を自由に定義
https://gyazo.com/cbb21e52e6c051064daa1c8e381a6775
(論文より引用)
https://gyazo.com/191a7d4c6427d013e679f648a538007b
https://gyazo.com/67a444f579c8a015a232cf9e98445d57
CUREの脅威モデルとしては、一般的なTEEと同様に、enclaveから機密データを取得しようと企む攻撃者を想定
OSを含むsystem softwareを操作可能
悪意あるプロセスやenclaveの生成は可能
特定のTrusted Code Base (TCB) の生成は不可
周辺機器からのDirect Memory Access (DMA) 攻撃が可能
ハードウェアレベルでの攻撃は不可
物理アクセス攻撃不可
faultインジェクション攻撃不可
物理サイドチャネル攻撃不可
悪意ある周辺機器の物理接続不可
DoS攻撃はスコープ外
冒頭で説明した3つのenclave typeそのアーキテクチャは以下のようになっている。
https://gyazo.com/bd2ffdc3ce39c70a73a76d093603ab4c
(論文より引用)
$ Encl_1: User-space Enclave
TEEアプリケーションが動く
$ Encl_2、$ Encl_3: Kernel-space enclaves
runtime (RT) をenclave内に実装可能
周辺機器とのsecure channel確立
Untrusted OSとのリソース共有が減らせる
$ Encl_4: Sub-space enclaves
同じ特権レベルPL0であるが、Security Monitorをファームウェアコードから分離するために利用
著者らはRISC-VベースでCUREのプロトタイプを実装(ハードウェアレベルのアーキテクチャはAppendixに記載)し、ベンチマークを実施している。以下はマイクロベンチマークの結果である。
https://gyazo.com/8beaf65bb2e255d1ee5aa304bd4ef167
通常のプロセスに比べてオーバーヘッドが大きくなっている。その多くはバイナリの検証である(User-spaceで91.3%、Kernel-spaceで52.1%)。その他の要因としては以下が挙げられていた。
enclaveバイナリのロード
enclaveの設定
TLBとL1 cacheのフラッシュ
enclaveへのジャンプ
Appendix
https://gyazo.com/4e392640134ab7511d8467b367415097
(論文より引用)
SP1
Enclave Execution Contexts
Enclave IDやその伝播方法を定義
SP2
Access Control on the Bus
enclaveの分離とperipheralsのアサインのため、アクセスコントロールが必要
Arbiterをmain memory chipの前段に配置
SP3
On-Demand Cache Partitioning