はじめに

本記事では、TEEと呼ばれる技術の背景や概要、TEEの種類について解説し、その後TEEのメリット・デメリットについて説明します。

ここでは、筆者が別の機会で作成した資料・ドキュメントである参考文献[1], [3]のコンテンツを適宜自己引用しながら説明を進めます。

TEEのエッセンス

TEEの考え方を説明するためにも、TEEのバックグラウンドや思想から説明した方がスムーズなのですが、いきなりそこから説明し始めるのも混乱を招きますので、軽い概要だけこちらで先に説明します。

TEEとは、Trusted Execution Environmentの略称であり、日本語に直すならば「信頼可能な実行環境」とも呼べる、ここ比較的最近台頭してきている技術です。

一言で言ってしまうのであれば、「秘密にしたいデータを信頼可能な領域に配置し、その信頼可能領域内でそのデータを用いた処理を完結させる」事を実現するための、ハードウェア支援技術と表現する事が出来ます。

これだけでは、それなら具体的にどうやってそれを実現するのかなど不明瞭だと思いますが、詳細に関しましては本記事の後半で説明いたします。

また、TEEはHIEE（Hardware-assisted Isolated Execution Environment；ハードウェア支援を用いた隔離実行環境）技術の1つでもあります。

他のHIEE技術（Intel TPMなど）と比較した場合のTEEの大きな特徴として、ユーザが実行環境内の動作などを定義する事ができる、というものがあります。[2]

TEEの思想

TEEは、いくつか存在する秘密計算に利用可能な展望のある技術の中でも、比較的信頼可能と見なす対象の基準が厳しめな技術です。

例えば、現在普及しているクラウドサーバについては、基本的にTEEではその環境を信頼可能であるとは見なしません。

何故ならば、そのクラウドプロバイダが悪性であればそのクラウド環境で取り扱っている情報を盗聴されてしまう可能性がありますし、また提供されているOSが悪意のあるものである可能性もあります。

ファイアウォールやアクセス管理などで外界との境界にて保護しているからセーフ、といった考え方は論外となります。

同時に、そのクラウドサーバがいくらハイパースケーラなどの大手であろうが、TEEにおいては関係ありません。極論を言ってしまえば、どんなに大手だろうがそのクラウドサーバ内は「ブラックボックス」であり、そうである以上「大手であるから安心」は根拠のない神話であるからです。

この点は、シェア（※1）の配布先とするサーバが全て危殆化していたり、あるいは結託・共謀している場合は秘密情報を復元できてしまう秘密分散技術との大きな思想の違いとなります。

（※1：秘密分散により分割された、秘密情報の無意味化された断片。シェアの全てを合わせる事で元の情報を復元する事ができる）

これだけ書くとTEEがヤバい陰謀論の代物に見えるかも知れないですが、言い換えてしまえば、そういった「人間」に依存したセキュリティ上の懸念材料（それこそ世間一般では当たり前とされているようなものであってもです）を徹底的に排するような、徹底して厳格なセキュリティを実現する所にTEEの目的はあります。

要するに、「人間の善意や人間自体の信頼性」は一切あてにせず、「暗号学的・数理的に絶対的な安全性を保証してやればいい」、というのがTEEの思考で、それをハードウェア支援の力で実現するのがTEEという事になります。

TEEの仕組み

TEEと言っても様々な実装例があるので一概には言えませんが、最もハードウェア寄りの例であるIntel SGXをベースに仕組みの説明を行います。

TEEではまず、「信頼可能な実行環境」を提供するために、コンピュータリソースを「信頼可能な領域（Trusted）」と「信頼できない領域（Untrusted）」に分ける所から始めます。

その上で、秘密にしたい情報を信頼可能な領域内で取り扱う事により、データを保護しながらのプログラムの実行を可能とします。

では、具体的に「信頼可能な領域」と「信頼できない領域」はどう分けるのか、という話になりますが、

• 信頼可能な領域：信頼可能なコンポネント内と、そのコンポネントにより生成されたメモリ上の保護領域
• 信頼できない領域：それ以外のすべて

と書き表す事が出来ます。

その技術が前提とする脅威モデルと設計次第では、OSやVMMですら非信頼領域と見なす事になるのは、前述のTEEの思想の所からも容易に想像がつくと思います。

では「信頼可能なコンポネント」とは何なのか、抽象的すぎないか、という話になると思うのですが、具体的な実例としては、例えばIntel SGXではこの「信頼可能なコンポネント（ハードウェア）」としてCPUがその役割を果たします。

これを踏まえると、SGXの例では

• 信頼可能なハードウェアであるCPU内
• CPUにより生成されるメモリ上の保護領域
• CPUとメモリ上の保護領域との通信路

の3つが、TEEに分類される具体的な領域という事になります。

構造として比較的SGXに類似しているRISC-V KeyStoneやARM TrustZoneは、ハードウェアによる保護領域の暗号化と境界管理をベースとするSGXと異なり、ハードウェアの機能に強く結びついたソフトウェアにより非常に厳格なアクセス制御で保護領域の隔離を実現する（暗号化はデフォルトではしない）ため、上図とは少々構図が異なってきます。

例えば、RISC-V KeyStoneであれば、CPU内やメモリ上の保護領域が信頼可能である（と見なす）事についてはSGXと同じですが、メモリ上の保護領域の管理やアクセス制御は「Security Monitor」という特権クラスのソフトウェアが行うため、中心となるのはCPUではなく寧ろSecurity Monitorという事になります。[7]

ちなみに、TEEの外にあたる「信頼できない領域」の事を、REE（Rich Execution Environment）と呼ぶ事があります。

ただの外界が「リッチな実行環境」と呼ばれる所以としては、一般的にTEE内部で動作させられるプログラムにはキツい制約（使用可能なリソース量やライブラリなど）がかかる事が多いため、TEEから見た相対的な呼称であると推察できます。

さまざまなTEE技術

TEEの実装としていくつかの実例が既に世の中に出回っていますが、大別すると「部分隔離型」と「全体保護型」の2種類に大別する事ができます（この2つの語彙自体は完全に筆者の造語なので覚える必要はございません）。

部分隔離型は、前述の説明でも出てきたようなTEEとしてはスタンダードなタイプで、メモリ上の特定の区画を隔離・保護するモデルです。

実装の具体例としては、Intel SGX、ARM TrustZone、RISC-V KeyStoneが挙げられます。

対する全体保護型は、文字通りメモリ（あるいはVM）を丸ごと保護してしまうという新しいアプローチのTEEです。

こちらの実装の具体例としては、AMD SEVやIntel TDXが挙げられます。

部分隔離型と全体保護型は、どちらも一長一短となっています。

部分隔離型のメリットとしては、

• より厳しい脅威モデルに対応できる
• 安全性がより高い

といったものが挙げられます。

部分隔離型は、CPU内部、一部のメモリ上の領域、KeyStone等では特権ソフトウェア、そしてその通信路のみを信頼可能と見なすため、利用するマシンのオーナーやクラウドベンダは勿論、BIOS、OS、VMMといった要素すらも危殆化しているような、非常に過酷な環境でも安全性を保証しながら処理を遂行させる事が出来ます。

また、Intelの主張[4]によれば、TCB（Trusted Computing Base；TEEと非常に似た用語ですが、「TEE」が比較的概念的な使われ方をするとすれば、実際の物理的な領域の方にニュアンスが近いイメージです）の面積は小さければ小さいほど安全性が増すとの事なので、そういった側面からも安全性が高くなります。

この理由としては、参考文献[5]によれば、実行コードの側面で見た場合、純粋にTCB内のコードを減らす事により、いらぬ（潜在的な）脆弱性を抱えてしまう可能性を下げるという意味合いのようです。

また、データの側面で見た場合、当然データをTCBに入れれば入れるほど攻撃に成功された時の漏洩量は増えますし、場合によっては処理時間が増えることにより、後述のサイドチャネル攻撃などの実行時間・機会を増やしてしまう可能性があります。

結果として、TCBに入れるデータやコードを必然的に制限する部分隔離型TEEでは、その側面でも安全性が更に強化されるという事になります。

部分隔離型のデメリットとしては、

• コードの設計思想を根本的に変える必要がある
• 使用可能なリソース（メモリ量）が制限される
• コードの実装難易度が異常に高い

といったものが挙げられます。

部分隔離型は、メモリ上の特定の領域を保護して信頼可能とし、信頼可能部分での処理と非信頼可能部分での処理を（時には互いにやり取りしながら）進めていくので、基本的に従来の設計思想通りに進められる事はありません。

また、メモリの一部を保護領域として切り出す以上、信頼可能部分では普通のアプリケーションほどには自由にメモリを使えません。

例えばIntel SGXであれば、Windowsで動作させる場合、保護領域である「Enclave」の事実上ユーザが使用可能な上限サイズは原則96MBに抑えられています。

また、これも筆者のSGXの経験に強く寄っている部分もありますが、保護領域内で動作させられる機能が制限されている・専用APIがお粗末・独特な記法の設定ファイルがあるなどにより、開発難易度が異常なまでに高くなりがちという欠点があります。

例として、参考文献[6]では、412LOCの一般的なコードをSGXで動作できるように改修した所、3523LOCまで膨れ上がったと報告しています。

対して、全体保護型のメリットとしては、

• TEEを使う事によるリソースや機能、設計思想の制限が無い

という、部分隔離型の苦痛を全て払拭してくれるものとなります。

要するに、開発者からしたら滅茶苦茶に楽なのです。

しかし、全体保護型の場合、メモリを丸ごと中身ごと保護してしまうので、当然メモリに載っているOSやアプリケーションは無条件に信頼する事になってしまいます。

これは即ち、元々TEEのメリットでもあった「OSやクラウドベンダすら信頼しない」運用が出来ない事になりますので、前提とする脅威モデルが厳し目な場合は状況では使用できない事になります。

TEEのメリットとデメリット

前の項まででTEEの基本的な説明をした上で、TEE技術のメリットとデメリットをここで紹介します。

まずは、メリットの方から列挙していきます。

時間計算量・空間計算量がとても軽い（非常に高速で、メモリも食わない）

TEEは、ハードウェア（やそれに強く結びついたソフトウェア）によるアクセス制御や、AESのように計算コストの小さい暗号化によって保護領域によるデータ保護を実現するため、同じく秘密計算への利用が検討される機会の多い秘密分散や準同型暗号と比べても、実行時間・メモリ消費共に非常に高効率です。

TEEと同等以上に厳しい脅威モデルに対応できる、秘密計算への応用が見込まれている技術に完全準同型暗号がありますが、現代のコンピュータリソースやアルゴリズムではまだまだパフォーマンスが現実的とは言い難い部分があります。

また、秘密分散と異なり、複数のマシンの必要性もなく、秘密分散で発生する通信に伴うオーバヘッドもありません。

よって、この高効率さは現代の技術においては有力候補の中でもTEEの大きなメリットと言えます。

対応可能な脅威モデルが多い（部分隔離型の場合）

部分隔離型の場合、保護領域に入れるデータやコードを開発者（ユーザ）が決める事が出来るため、前述の通りマシンオーナー、クラウドベンダ、BIOS、OS、VMMが危殆化している環境でも動作させる事が可能になります。

このメリットに関しては、秘密計算への応用が見込まれている有力候補の中では、マシンが全て同一攻撃者によって危殆化している場合にシェアを復元されてしまう秘密分散に対する明確なメリットです。

一方で、デメリットとしては以下のようなものが挙げられます。

ハードウェアベンダを信頼する必要がある

さて、散々今までTEEは様々な脅威モデルに対応できる、と説明してきましたが、一つ重大なデメリットが残っています。

それは、ハードウェア支援を用いて保護領域における隔離実行を実現している以上、無条件にそのハードウェアベンダを信頼しなければならないという点です。

クラウドベンダは信頼ならないといいながらも、ハードウェアベンダを信頼しろと言っている事になりますので、見方や思想によってはこれは大きな問題となります。

また、当然ハードウェアベンダが作った技術はそのベンダのマシンでしか動きませんし、ベンダが出したプロダクトに脆弱性があればそこを突かれて攻撃されてしまいます。

未対策ではサイドチャネル攻撃に弱い

一般論として、TEEは未対策の状態ではサイドチャネル攻撃に対して無力です。

サイドチャネル攻撃とは、保護されている情報を直接解読しようとするのではなく、周辺の環境情報（最も簡単な例で言えば実行時間）からその情報を推測し盗み出す類の攻撃です。

SGXについては、ページフォルトを悪用したサイドチャネル攻撃（Controlled-Channel Attacks）や投機的実行を悪用した攻撃（SgxPectre）など、無数のサイドチャネル攻撃の餌食となっています。

勿論、例えばKeyStoneではデフォルトで一定のサイドチャネル攻撃対策が施されていたり、SGXにおいてもSGX-LAPD [8]のようにサイドチャネル攻撃を対策する技術が複数開発されていますが、場合によっては開発者もサイドチャネル攻撃について一定の考慮をしなければならない状況も十分に起こり得ます。

リソースや機能の制限があり、アプリケーションの設計思想も変わる（部分隔離型の場合）

これも前述の通りであり、例えばSGXであれば保護領域のサイズや保護領域内で利用可能な機能（ライブラリやAPIなど）は著しく制限されます。

また、信頼可能領域と非信頼可能領域の2つを常に念頭に置きながら、コードやデータをどちらで動かしたり配置したりするかを考えながらの開発は、他のシチュエーションではなかなか無いものであり、不慣れな人にとってはこれだけでも負担になり得ます。

量子コンピュータ耐性は無い

SGXの保護領域はデフォルトで暗号化されており、KeyStoneやTrustZoneでも保護領域の暗号化を行うプラグインのようなものは存在しておりますが、いずれもAES暗号ベースであるため、量子コンピュータ耐性があるとは言えないのが現実です。

以上のように、メリットによる恩恵が非常に大きい一方で、決して無視できないデメリットも複数存在するため、TEEの採用は環境やユースケースに応じて慎重に検討する必要があります。

まとめ

少し長くなりましたが、本記事では以下について説明してきました。

• TEEは、ハードウェアによる支援を用いながら保護された隔離環境を作り、そこで秘密を扱うことでセキュリティを実現する技術
• 使用する技術によっては、OSやクラウドベンダなどが信頼できない環境でも安全性を保証できる
• 秘密計算への応用が見込まれる技術の中でも非常に高効率
• ハードウェアベンダは無条件に信頼しなければならない
• メリット・デメリット両方を見て利用を見極めるべきである

次回のTEE関係の記事では、TEE技術の中でもIntel SGXについて、秘密計算への応用を考えた場合の困難さについてご説明する予定です。

参考文献

[1] “TEEとIntel SGX入門”, 自己引用, https://speakerdeck.com/hello31337/teetointel-sgxru-men

[2] “TEE (Trusted Execution Environment)は第⼆の仮想化技術になるか?” by Kuniyasu Suzaki, http://www.ipsj.or.jp/sig/os/index.php?plugin=attach&refer=ComSys2020&openfile=ComSys2020-Suzaki.pdf

[3] “Intel SGX入門 – SGX基礎知識編”, 自己引用, https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf

[4] “Size limitation for EPC in SGX”, https://community.intel.com/t5/Intel-Software-Guard-Extensions/Size-limitation-for-EPC-in-SGX/td-p/1130830?profile.language=en

[5] “Trusted Execution Environmentの実装とそれを支える技術” by Kuniyasu Suzaki, https://www.jstage.jst.go.jp/article/essfr/14/2/14_107/_pdf/-char/ja

[6] “SgxElide: Enabling Enclave Code Secrecy via Self-Modification” by Erick Bauman et al., https://web.cse.ohio-state.edu/~lin.3021/file/CGO18.pdf

[7] “Keystone: An Open Framework for Architecting Trusted Execution Environments” by Dayeol Lee et al., https://n.ethz.ch/~sshivaji/publications/keystone_eurosys20.pdf

[8] Fu, Yangchun & Bauman, Erick & Quinonez, Raul & Lin, Zhiqiang. (2017). Sgx-Lapd: Thwarting Controlled Side Channel Attacks via Enclave Verifiable Page Faults. 357-380. 10.1007/978-3-319-66332-6_16.