Remote Attestation
Agenda
IASの仕組み概要
debug/release/pre-release mode
IASのproduction
DCAPの仕組み概要
Azure Attestation概要
前提
Provisioning/Attestation形式にはEPIDベースとDCAPベースが存在
EPID (Enhanced Privacy Identifier)の利用
Root Provisioning KeyがRoT
IAS(Intel Attestation Service)がquote検証
DCAP (Data Center Attestation Primitives) (2018)
ECDSA署名
IPS/IASの検証ステップ
TPM1.2で実装されたDAA(Direct Anonymous Attestation)の拡張
大きく、provisionig -> quote検証のステップ
TCBと provisoning keyからProvisioning EnclaveとIPSやりとりし、EPIDメンバ秘密鍵を生成
IASがEPIDグループ公開鍵やrevocation listを持っているのでQuote時に検証
Provisioning
EPIメンバ秘密鍵のprovisoning
Provisoning keyとSealing keyの関係
Root Provisioning KeyはCPU製造時にIntel側で保存
https://gyazo.com/b64f041070781736d3ab06cdbc52d6e0
architectual enclavesとIPS/IASの関係
https://gyazo.com/03532a6d604023e54ff0af65c6b7416c
EPID署名とSigRLの関係
秘密鍵：公開鍵がN：１で対応するグループ署名鍵
https://gyazo.com/bc023a264e25177c2feaa34e2d5f13ac
Quote検証
https://gyazo.com/4db2cce056c624fdbe17d4dcb6669f3a
いわゆるRemote Attestaiton時
(linkable signaturesの場合）SPIDがユーザーリクエストのSPIDと一致するか
GIDが最新のグループであるか
ストレージから秘密鍵のRevocation List、署名Revocation List、GIDのEPID公開鍵を取得
Quoteの署名がグループメンバにより署名されているか検証
署名がrevokedされた秘密鍵による署名ではないか
署名が最新のsigRLを使っているか、それぞれのsigRLのメンバが正しいエントリか検証
IAS所有のReport Signing KeyでREPORTを署名しレスポンス
https://gyazo.com/100071cd51a1c18e15f88d857a32c1f7
(ref: EPID Provisioning and Attestation Services 4.5.3)
Production based on IAS
IASが一連の検証を実施
debug mode
デバッガやパフォーマンスメトリクス取得のためEnclaveメモリにアクセス可能
つまり、隔離保護されていない
IASによるQuote検証もされない
release mode
隔離保護適用
コンパイル最適化
SIGSTRUCTを登録していないとrelease modeビルドでRemoteAttestationできない
IASのproductionに対応するまでに必要なステップ
mrsignerの鍵を登録（ホワイトリスト）
https://gyazo.com/00a22b35bafee4bdd49e37f7ac16000a
sgx_signでenclaveを署名
SIGSTRUCTファイルの提出
Enclave.soに対しSIGSTRUCT構造体を追加するとEnclave.singed.so
https://gyazo.com/9cd093ef91a886d908094e842c98b507
RSAモジュラス、RSA暗号化指数、RSA署名、Q1、Q2
sgx_sign dump -enclave enclave.signed.so -dumpfile enclave.sigstruct.hex
QUOTE検証時にIASがMRSIGNERを登録されたSIGSTRUCTを使って検証
DCAP
https://gyazo.com/d9313cd5ebf3d8702af9dd66f035659f
CRLsのキャッシュ更新頻度などは謎
PPIDとTCBを組み合わせてintelにPCK問合せ
Provisioning Certification Serviceに以下を問合せ
PCKのintel発行証明書
PCK証明書のrevocation list
最新のCPUとPCEに対するSVNs
attestation keyとQuotesを生成するQuoting Enclaveのidentity
DCAPでもIntelがQuote署名のCAとして機能するための仕組み（IASの場合はSGXがQUOTEをIASに送信し署名してもらうだけだったが、DCAPだとIntel所有鍵を持たないクラウドプロバイダ等に送るのでそのままだとIntel署名ができない）
Quoting Enclaveが乱数ベースで生成したAttestation Keyの公開鍵をProvisioning Certificate Enclaveに送信
Provisioning Certificate Enclaveがlocal attestationなどで認証し、Attestation Keyに対する証明書(Attestation Key Cert)を生成
Provisioning Certification KeyはデバイスとTCB特有の鍵
Provisioning Certificate EnclaveがQuoting EnclaveのためのローカルCAとして機能
QUOTEはQuoting EnclaveによりAttestation Keyで署名され、クラウドプロバイダは諸々検証し、レスポンス
https://gyazo.com/0b3ebbf9bf8a2b60c026fc838a96801a
検証者は署名付きQUOTE(REPORT)・証明書チェーン・Intelが公開するAttestation Key CertのRevocation Lists(CRLs)で検証することが可能
https://gyazo.com/3b0b5ce414c8b70b29b3e9b2a8804d1d
Intel SGX provisioning certificate service
Caching Sercice for Intel SGX provisioning certificate service
PCK certificate, PCK CRL(certificate revocation lists), TCB information, QE identity structuresがintelにより全て署名され、CSPが保存
PCK(provisioning certificate key)
PCE(provisioning certificate enclave)が利用可能な署名鍵
プロセッサとTCB(HW&PCE)にユニーク
公開鍵はPCK Certificateに。
PCK signing Chain: root CAはIntel所有
PCK cert chainの検証
CSPは可用性提供、
Azure Attestation
手順
Azure Attestationリソース生成、ポリシー設定
SGX VM側
以下のようなjsonファイルをSGX VMで生成
メリ
可用性
ECDSA
デメ
リクエストとレスポンスのフォーマット互換性ない
オンチェーンで証明書チェーン検証必要そう
reference
SIGSTRUCT