Remote Attestationの全体像
TL;DR
Remote Attestationの前提、脅威モデル、攻撃、パラダイム、拡張を整理
論文のコンテキストはIoTデバイス向けだが、考え方はTEEにも応用可能
本文
コペンハーゲンIT大学のAlexander Sprogø Banks氏らによる「Remote Attestation: A Literature Review」がarXiv.orgに投稿された。IoT機器の文脈で、integrityを担保するためのセキュリティ施策Remote Attestation(以下、RA)を体系的に整理し、その代表的なRA実装について比較検討を行った論文だ。今回はその体系的な整理の内容をいくつか紹介する。 本論文ではRAに関わる主体をProverとVerifierとし、Proverがメモリやストレージの内部状態をattestationし、Verifierがこれを検証できるモデルを論じている。RAの対象はマルウェアに侵害されている可能性があるデバイスで、侵害されているか否かをリモートから検証が可能になる。またRAを拡張し、デバイス内のソフトウェアの一部を更新、リセット、削除を行う機能についても議論がある(今回の紹介では省略)。
まずRAの前提としては以下を挙げている。
物理攻撃はスコープ外
VerifierとProverが使用する共有鍵は事前にインストール済み
VerifierとProverの通信はセキュアであること
なお、攻撃者のゴールは「デバイス上にマルウェア等を仕込みつつも、attestationで検出されないこと」であり、攻撃者を5つに分類している。
cipepser.icon とはいえ、上述の通り物理攻撃はスコープ外のため、実際には上2つのRemote AdversaryとLocal Adversaryを中心に議論している
Remote Adversary
最も一般的な攻撃者で、リモートからマルウェア感染させることを目的とする
例: Mirai botnet
Local Adversary
Proverの通信を盗聴、妨害できるローカルの攻撃者
Physical Non-intrusive Adversary
サイドチャネル攻撃が可能な攻撃者
Stealthy Phisical Intrusive Adversary
物理的にシークレットを盗もうとする攻撃者
Physical Intrusive Adversary
Proverを物理的に操作可能な攻撃者。具体的にはメモリ状態やハードウェア変更が可能。
具体的な攻撃としては、DoS攻撃とTime-Of-Check-To-Time-Of-Use(TOCTTOU)攻撃を紹介している。DoS攻撃はデバイスのattestationリクエストを大量に送信し、計算リソースを消費し尽くす攻撃だ。対策としてはリクエストにnonceを含め、不正なリクエストはattestation処理を行わずに破棄するなどが挙げられる。TOCTTOU攻撃はattestationのチェックと実行時の時間差を利用した攻撃だ。侵害されたノードがattestationリクエストを受信した際、攻撃者は以前に記録した正しいコードイメージを返す(time-of-check)が、実行するコード(time-of-use)はattestationしたものと別というものだ。こちらの対策にもnonceが使われ、Verifierがattestation時にnonceを生成し、Proverへ送る。結果、測定値がnonceを反映したものになり、変更を検知できる。
RAのパラダイムとして、ソフトウェアベースRA、ハードウェアベースRA、ハイブリッドRAの3つに整理している。
ソフトウェアRAはハードウェアを使わない代わりに、脅威モデルに強い仮定を置くモデルだ。具体的にはProverが他デバイスと通信をしない、通信をする場合は1ホップまでといった仮定が置かれる。ソフトウェアRAは周辺機器のファームウェアのintegrity保証で使われ、SBAPやApple Aluminium Keyboardにその実例を見ることができる。仕組みとしては、attestationコードのチェックサムの計算に依存している。そのためLocal Adversaryが強い計算力を持ち、他デバイスと共謀できる前提では、ネットワークレイテンシもなく、attestationを破ることが可能になってしまう。また、本論文の調査範囲では、チャレンジ・レスポンスを用いた実装が主流とのことだ。なお、attestation実行中に割り込みが発生しないようOSの割込を無効化し、atomic executionを達成する必要がある。
ハードウェアRAは物理チップ/モジュールに依存するが、強力な保証を提供するモデルだ。TPM、Intel SGX、ARM TrustZoneなどで実装されている。TPMでは、Platform Configuration Registersに暗号化ハッシュを記録する実装がなされている。格納されているハッシュがチェーン上に上書きされていくため、bootなどではチェーン上のどこかが攻撃されると検知が可能。atomic executionについてはハードウェア的に分離されており、割り込みが発生しないため、特に言及されない。
osuke.icon 上記攻撃のどこまで防げる話なのだろう
cipepser.icon 上記のRemote/Local Adversaryが範囲ですね。side-channel attackは議論の対象外でした:cry:
ハイブリッドRAはソフトウェアRAとハードウェアRAを組み合わせ、ハードウェアのfootprintを最小限のトラストアンカーとするモデルだ。シークレットとattestationコードはROMへ記録し、不変性を保証する。秘密鍵へのアクセスはmemory protection unit(MPU)による制御で、attestationコードのみから可能となっている。また、attestation実行中に割り込みが発生しないようOSの割込を無効化し、atomic executionを達成する必要がある点はソフトウェアRAと同様である。
osuke.icon 具体的な製品あるのかな
cipepser.icon 論文上ではVRASEDが最強だぜという主張でした さらにRAの拡張機能として、デバイスが多数存在する場合に効率的にattestationを行うswarm attestationと、executionやruntimeに関するattestationであるControl Flow Attestation(CFA)についても議論されている。特にCFAはここまでの議論で登場したRAが、バイナリのintegrityのみを保証していたのに対して、executionとrun-timeを保証範囲に含めている点で非常に興味深い。run-timeにRAを組み込む実装は、計算のオーバーヘッドとプロトコルが複雑化を招くため、アセンブリ命令のブロックを表すcontrol flow graph(CFG)が使用される。CFG上のパスが特権パスや非特権パスを表し、attestation対象の複雑さ軽減に繋がる。
osuke.icon 動的にアップロードしたwasmバイナリとかのチェックも可能なのかな
cipepser.icon CFA/CFGが具体的にどう表現されるのか勉強が必要です。。。
本記事では、RAの概要、脅威モデルと攻撃、RA類型、拡張としてのCFAについて紹介した。本論文ではほかにも多数のデバイスが存在するswarmに対する効率的なRAや、RAのアーキテクチャやプロトコルに求められるプロパティなどについても議論されており、RAの全体像を掴む上で参考になる論文だ。(文責・恩田) Appendix
Security Architecturesの保証
key-protection
atomic execution
Properties of remote attestation protocols
Fresh information
Comprehensive information
Trustworthy mechanism
Exclusive access
No leaks
Immutability
Atomic execution
Controlled invocation
Properties of a Security Architecture
Key Protection
Immutability
Atomic Execution
External Software
Build-in RA
Shuffled measuments
マルウェアのroving, relocatingを防ぐattestationの拡張
ランダムな順序でメモリをattesting
検出を回避するためにrelocatingするマルウェアを検出
3つの脅威モデル
いずれも物理攻撃はなし
Knowledge of Future Volume
Knowledge of Future Coverage
Knowledge of Future Order
RA残りの課題
swarmの故障デバイスの識別
動的swap トポロジのさらなる発展
証明可能なsecure RA protorolの形式証明