StealthDB: a Scalable Encrypted Database with Full SQL Query Support
https://gyazo.com/7cb993b72f223566ce7aa545956b138b
特徴
Full SQLクエリサポート
基盤となるDBMSの修正少なめ
TCB最小限
インデックスに対してアクセスパターンの秘匿化をサポートしない
どこまでEnclaveに含めるべきか
https://gyazo.com/f3f9bca0e9fb12d4b1834d3c8347f43f
1st:DBMS全体をEnclaveへ
syscallをサポートしていないなどコードベースの移管に大きなハードル
libos系の活用は一つの手
EPCサイズ制限を考えるとパフォーマンス観点から適切ではない
2nd: Query ExecutorのみEnclaveで実行
https://gyazo.com/976f4528226ec89272e7a08340c0f962
SELECT、JOIN時にそれぞれのtableがenclaveにinputするのでEPCサイズのスケーラビリティ問題
datasizeが増えると指数的に増加
cipepser.icon むしろ128 MBを超えたあと急激に悪くなるようにみえる?(8→32→128までは概ねtimeも4倍ずつで線形っぽい。128→512はtimeが9倍)
Query processingをside-channel attack防ぐの大変
Query Executor自体コードベース大きくEnclaveに入れるよう修正するの大変
3rd: operator (+, >=.,, etc..) のみをenclaveで実行
enclaveコードを最小限にできる一方、クエリ実行時暗号化したデータのリンカビリティは漏洩
https://gyazo.com/88e4e22f22a39cca362d234235332b85
パフォーマンス(レイテンシー)
https://gyazo.com/5ea9a66cdbcd9b842e6bf37ee30140bc
c1: 通常のpostgresql
c2: 2ndパターン( Query ExecutorのみEnclaveで実行)
datasetが増えるとレイテンシーが急激に増大
c3: exitlessを用いたoperatorのみenclaveで実行パターン
アプリケーションレベルでページングロジックを実装(trusted<->untrustedでshared queue)
cipepser.icon 先週紹介したCacheOutにもEleosのauthorが入ってました
Intel SGX SDK公式のswitchless callsとのパフォーマンス比較気になる
5~10x overhaed
c4: 通常のecallを用いたoperatorのみenclaveで実行パターン
100x overhaed
アーキテクチャ
https://gyazo.com/c4984d8d3733eb42c0fef5d6330332aa
複数のenclaveから成り、それぞれのenclaveは互いにlocal attestationを検証しセキュアなチャネルを確立。鍵はそれぞれのenclaveでsealingし保存。
Auth enclave
暗号化・復号をするマスターキーを生成し、それぞれのenclaveに共有
client<->DBはセッションキー、enclave query engine<->storageはマスターキー
クライアントの認証をする(password/ssh key想定)
PreProcessor enclave
クライアントはクエリ全体をセッションキーで暗号化して送信するので、
Ops enclave
実際のoperationを実行
appendix
アクセスパターンに関する脅威モデル
snapshot adversary
memory/diskのsnapshotに対してそれぞれの暗号化data itemになんの情報も得られない
persistent adversary
query実行されたときにmemory/diskで比較されない暗号化data itemになんの情報も得られない
query実行時でのleakageはcomplete SQLをサポートしているprevious workと同じかそれ以上。
インデックスの暗号化
treeのそれぞれのvalueが暗号化されていても不均一であることがrevealしてしまう
snapshot adversaryもindex生成が終わった後可能
sol1. index tree構造に暗号化されたvaluesを置くとき、再暗号化することでtableとindexのlinkできないようにする
order-revealing encryption(ORE) でindex生成から利用までのpersistent adversaryへのセキュリティ強化可能
sol2. index fileをdiskに書き込む前に暗号化し、読み取るときに復号する
index_OP enclaveでindex data pagesの暗号化・復号をする
ログの暗号化
Some of the log files reveal sensitive information about the queries even for a snapshot adversary on disk 30. We can protect against an adversary accessing disk by encrypting the log files on disk in a way similar to our encryption of index files on disk.