# 暗号・CVMビルド＆スクラップゼミ応募課題




# 回答にあたっての注意事項
本ゼミはルートを2つ用意していますが、学ぶ対象の違いから評価基準に差が生じる部分があります。共通する条件は以下のとおりです。


* 本応募課題では、各問難易度を高めに設定しており、（コード実装含め）完答を前提としてはおりません。  
  同時に、ゼミの主題であるTEEや暗号への（スタンス的な）適性や、解答までのプロセス、熱意を測る意味合いを多分に含めています。  
  完答が難しい場合、途中までの調査結果や思考内容、自らの意見等を記述していただければ、そちらも大きく加点対象といたします。  


* 文字数が多い事により採点に有利になることはありません。  


* フォームの文字数制限を超過する場合は、外部サービス（Gist、Zenn、Qiita、個人ブログ等）を利用し、限定共有の形で共有いただいて構いません。  


* この応募課題のテキストは、Markdown形式で記述しているため、Markdownとして表示する事ができます。  


## 暗号ルート
* 各設問には発展問題を追加で設定してありますが、これらはあくまで発展問題です。したがって、解いていなくても一切減点はされません。「適当に全部を埋めた応募用紙より、丁寧に書かれた発展なしの応募用紙のほうが高評価」と思ってもらって構いません。


* ただ調べたことを書くだけではなく、「どんなRFC、NIST規格、論文、本、Webサイト等を参照したか」のリストも書いてください。「どの部分はどれのどこを参考にした」まで書かれている場合、これは加点対象になりますが、無くても減点はされません。
  - これに限らず、評価は原則として加点方式です。
  - 正しく道筋を辿れている証跡があれば、完全な正答でなくとも部分点の加算可能性はあります。解ききれなかったからといって諦めないでください。


* ChatGPTやGemini等のLLMを利用しても構いませんが、その場合「なぜその出力が正しいと判断できたのか・誤りだと判定したか」をプロンプト・出力と共に追加記述してください。
  - このルートでは、実装も理論もボイスチャットやリアルタイムなテキストチャットによるゼミを実施します。
  - つまり、応募課題をLLMのみに頼ったとしても、実際のゼミではLLMなしでもやっていけるだけの筋力を付けていただくことになります。いわば「楽」はできません。
  - LLMを否定するものではありません。今後の社会ではそれを使いこなすことは必須技能となるでしょう。しかしながら、暗号技術という「LLM出力の正誤判定自体に専門技能・特殊技能を要する技術」におけるエキスパートとなるためにも、このルートではあえてLLMを利用せずとも判断できる能力の鍛錬を主軸に考えています。


* 実装問題の実装言語は問いません。ただし、後から第三者が読んで理解できる程度のコメントを残してください。


* 知らない単語ばかりに見えてしまうかもしれませんが、「知らない」ということは「伸び幅がそこにある」ということでもあります。是非これをきっかけとしてチャレンジしてみてください。
  - 逆に、簡単だと思える内容が実は奥深いものかもしれません。この応募課題はいくらでも深堀りできるように書いていますので、好きなだけ掘って頂ければと思います。


## CVMルート
* 解答を作成する上で、各種参考文献やサービス（LLM等）を参照するのは全く減点要素にはならず、寧ろ大歓迎です。  
  ただし、文献やサービスを参照した際には必ず参考文献を記載してください。  
  LLMで解答を導出し、論拠となるサイトや文献の特定に失敗した場合、使用したLLM名（サービス、モデル）も必ず明記してください。  
  （DeepResearch等による助力含め、LLMの回答の論拠を特定できた場合は不要です）


TEEについての基本的な前提知識については、例として以下の文献を参考にしてください（勿論以下の文献に限りません）。
* https://www.ieice.org/~dpf/wp-content/uploads/2021/08/DFS研究会産総研須崎.pdf
* http://www.ipsj.or.jp/sig/os/index.php?plugin=attach&refer=ComSys2020&openfile=ComSys2020-Suzaki.pdf
* https://acompany.tech/privacytechlab/author/ao-sakurai
* https://qiita.com/Cliffford/items/2f155f40a1c3eec288cf
* https://qliphoth.io/seccamp/
* https://zenn.dev/acompany/articles/55423b96eadc71
* https://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20250519-1.pdf


# 簡易的な前提知識
TEEとは、ハードウェア（主にCPU）により厳重に隔離された領域にデータを保持し、その状態で隔離保護領域用に定義された  
コードを実行する事で、終始データを保護しながらそのデータを利用した処理を可能とする技術です。  
最近ではVMを丸ごと保護するタイプのTEEが台頭しており、そのように保護されているVMを一般に「Confidential VM（CVM）」と呼びます。
ほとんどのCVMは、CPUの極めて特権的な制御により隔離されている上、その全域がAESベースで暗号学的に保護（暗号化）されているという特長を有しています。


# 問題
## Q1（共通）. https://tee.fail/ という攻撃手法があります。この手法について、以下解答してください。
1. この攻撃手法は、何を対象とし、何を実現するためのものでしょうか。その前提条件と効果を、TEE.fail論文のどこからどこまでという出典付きで説明してください。
2. TEE.failは「Attestation鍵が漏洩する」という大きな成果を出しています。この成果はどのような影響を及ぼしますか。特にRemote attestationという仕組みに対してどのような影響を与えますか。


## Q1（共通発展）. 本問題は順不同です。どれか一つを選択して解いてもらって構いません。もちろん全部を解いてもらっても構いません。
* 完全準同型暗号（FHE）の技術はTEEと似たような要件を実現可能です。ただ、完全に同一な結果を実現するわけではありません。他方、TEE.failを「攻撃手法ではあるけれどもサポート範囲外」とするベンダが存在します。攻撃手法なのになぜ範囲外になるのか、その理由について想像し、利用者の視点ではどう対応するか、そしてFHEでこの問題は解決可能かどうかについて考え、自分なりの結論を書いて下さい。
* （Q1-2.）について、利用者・メーカ・クラウドベンダそれぞれの立場からどのように受け取り方が変化するかを考え、なぜ違いが生まれるのかについて考えて下さい。
* TEEにはIntel SGXやAMD SEV等の他、TEE.failの範囲外にあるTEEも存在します。そのようなTEEを挙げ、同様の攻撃手法が成立するかどうか、またその利用シチュエーションと信頼モデルの違いについて述べて下さい。


## Q2（共通）. 
暗号ルートとCVM（TEE）ルートのどちらに応募したいかを書いてください。両方も可能としますが、その場合は双方のルートの問題に答える必要があり、ご負担は増えます。


以降は、暗号ルートとCVM（TEE）ルートで分岐します。


## 暗号ルート
### Q3 （暗号）. 量子計算機による攻撃手法が現実化した後の世界について問います。


1. 公開鍵暗号方式と秘密鍵暗号方式の間には、量子計算機実用化に対する温度感に差があります。なぜ差が生まれるのでしょうか。
2. 耐量子計算機暗号（Post-Quantum Cryptography, PQC）として様々な暗号技術が提案されています。その中から一つ好きなものを選択し、それを説明してください。
3. （Q3-2.）で選択した暗号は、他の耐量子暗号方式と比較してどのようなメリット・デメリットが存在するのかについて書いて下さい。


### Q3 （暗号発展）. （Q3-2.）で選択した暗号方式を実装してください。また、その暗号方式の実装を「正しい実装」だと思える証拠を提示して下さい。


### Q4 （暗号）. どのような暗号方式であっても、そこには必ずなんらかの安全性仮定が存在し、安全である範囲を定めています。また、その安全性の範囲は解読手法の発展・計算能力の発展に伴い常に変化しています。


1. （Q3-2.）で選択した暗号は、どのような安全性仮定のもとで安全なのでしょうか。
2. （Q3-2.）で選択した暗号が安全だと思える範囲はどの範囲になるでしょうか。


### Q4 （暗号発展）. 安全性仮定が存在するということは、その仮定を置けない場合には安全とは言い切れなくなるはずです。つまり、どのような暗号方式にも（それが非現実的な設定であったとしても）必ず解読されるシチュエーションを考えることは可能です。


1. （Q3-2.）で選択した暗号方式に関する解読手法を探し、その手法の提案論文を探してください。
2. （1.）で見つけた解読手法はどのような場合に有効なのでしょうか。
3. （Q3-2.）で選択した暗号は、その解読手法があっても安全に運用できるものでしょうか。


### Q5 （暗号）. 自己アピールできることがあれば、ここに書いてください。これまでの実績や、本課題を進める過程で実装した他のスクリプト等が存在するgithubリポジトリ、はたまた学んだ結果を書いたブログ記事など、なんでもいいので書いてみてください。何もなければ美味しいカレーの作り方でも研究室の話などでもOKです。 


## CVM（TEE）ルート
### Q3（CVM）.
あなたがTEEを使用して実現してみたいプロダクト（アプリケーションやシステムなど）を、理由と共に紹介してください。  
セキュリティに対する興味を交えて紹介いただけるとベターです。  
その上で、本ゼミで取り上げるTEE（メインはIntel TDX）は、この上で動作するアプリケーション等の実装には少なくとも
Pythonレベルの実装経験は必須である他、この分野のレイヤの低さから鑑みて、C、C++、Rustといった比較的ストイックな言語の
経験についても歓迎されます。  
そこで、ご自身でこれまでに開発したものの内、相対的に低レイヤに属すると思うものを紹介してください。
例えばサーバ・クライアント通信の実装、インフラ系、OSカーネル関係等、バックエンド以下全般くらいのものを想定していますが、
紹介していただけるのであればこの限りではありません。
GitHub等に自作のコードがあれば、そのリンクも共有してください。  
もし開発経験がない場合は、ゼミ本番までの習得に関する計画を述べてください。経験の有無自体が採点に影響する事はありません。  


### Q4（CVM）. 
TEEにおいては、それがいかに重要な機能であっても、比較的唐突かつ十分な猶予無しに破壊的変更や最悪の場合廃止を宣告される事があります。  
例えば、Intel SGXにおいて種々の信頼可能な機能を提供していた、Intel製の特別なEnclaveであるPSE（Platform Service Enclave）がこれに該当します。  
また、AMD SEV-SNPでは、Remote AttestationというTEE検証処理の検証結果の構造体の構造が、互換性の無い形で破壊的に変更され、
既存アセットに対する大幅な修正を各人が強いられる状況も生まれています。  
また、TDX/SGX向けの同じくRemote Attestationの準備に必要な既存ツールが勝手に変えられて既存の手順書通りに進まなくなったり、
そもそもRemote Attestation用の付属情報を置いておくためのキャッシュサーバ構築アセットごと一時期無くなる等、
TEE開発者は一切の油断を許されない状況を強いられています。


あなたは、これらの機能をヘビーに使用している状態で、もしこのような唐突な廃止や破壊的変更を宣告された場合どのように思いますか。  
また、このようなTEEベンダ（例：Intel、AMD）による運用は褒められたものでは無いと考えられますが、それでもTEEベンダがそうせざるを得なかった理由と、  
本来取るべきであった理想的な運用についても考察（あるいは調査）して回答してください。  


### Q5（CVM）.
Linuxカーネルは、Integrity Measurement Architecture（IMA）という機能を提供しています。
IMAは、Measured Bootという仕組みを実現するための一員として機能するものです。
Measured Bootは、対象をロードする主体（例：ブートローダ）が、ロード対象（例：OS）の測定値（ハッシュ値）を算出し、
それをTPM（Trusted Platform Module）のPCR（Platform Configuration Register）という測定レジスタにExtend（ハッシュ拡張）
する事で、真に意図している通りのコンテンツがロードされたかを、改竄不能な形で記録させそれを検証できるようにする仕組みです。


IMAは、いわばOSカーネルがOS起動後のコンテンツ（例：共有ライブラリ、ユーザプログラム）を測定するためのLinux機能で、
IMAポリシと呼ばれる設定ファイルの内容も参照しながら、測定対象を決定し測定を行います。
しかし、現状のIMAの実装では、それを単に用いるだけでは測定の対象を厳密に固定できず、結果としてOS→ユーザワークロードの
Measured Bootチェーンが途切れてしまう状況が発生し得ます。


これに関して、何故このような事が起きてしまうのかについて調査または考察して説明してください。また、その対策となり得る解決策の案
についても考察し記述してください。


### Q6（CVM）.
TEEのRemote Attestation（RA）では、そのTEEの身元証明書（Attestation Report）に対して、一般にAttestation Key（AK）と呼ばれる鍵を用いて
そのTEEにとって信頼の前提とする安全な場所で署名します。
そして、AKはTEEベンダが管理するCA（認証局）でTEEベンダの鍵により署名され、その証明書が頒布されます。
このPKIの仕組みがあるため、TEEを使いたいリモートユーザは、「この身元証明書はTEEベンダのお墨付きである」と確信の上で、
身元証明書が偽造・改竄されていない事を前提に、その中身を見て要求に即しているかを確かめます。


Intel TDX/SGXではPCKという鍵が（その下に「AK」が存在しますがここでは無視します）、AMD SEV-SNPでは主にVCEKという鍵がAKとして機能します。
SEV-SNPの場合、AMDの持つASKという鍵がVCEK証明書を作成し、さらにASKの証明書はAMDのルートCA鍵（ARK）で作成されます。
つまり、VCEK←ASK←ARKのような証明書チェーンを形成します。


同時に、万が一脆弱性等でAKが漏洩した場合に備え、TEEでは証明書失効リスト（CRL）とTCB Recoveryの2つの対策を用意している事が多いです。
CRLは、漏洩した鍵に対する証明書を列挙（ブラックリスト化）する事で、その鍵の認証を要求された場合に即座に失格として棄却します。
一方、TCB RecoveryはAKの導出時にそのTEEのセキュリティバージョン番号（SVN）を織り交ぜる事で、SVNが変われば別の鍵になるようにし、
古いSVNに紐づく鍵の流用を阻止する仕組みです。


上記を踏まえ、AMD SEV-SNPに関して、以下について調査・考察し解答してください。
* AMD SEV-SNPにおけるCRLは、何に対する失効（例：VCEK、ASK、ARK）を行うためのものであるかを調査・考察してください。
* AMD SEV-SNPにおけるこのCRLで失効処理を行った場合、失効による影響を受けるマシン台数はどの程度の規模感になりますか。
* このCRL処理にTCB Recovery処理を併用する事で解決できるシナリオ例を考察し説明してください。また、それでも依然として懸念点があるようであれば、
  そちらについても説明してください。