Confidential AI 推論とremote attestationの信頼境界

Confidential AI inferenceでは、CPU TEEだけでなくGPU device、driver/firmware、起動状態、workload policyのattestation evidenceを検証し、許可状態と一致した場合だけmodel decryption key、dataset key、API credential等をreleaseする。remote attestationは診断ログではなくsecret release前のpolicy gateとして扱う。

Google Cloud Confidential VMのattestationはbootloader、hardware、firmware等のmeasurementを含む。GPU側ではdriver attestationとNVIDIA GPU device attestationが分かれ、NVIDIA Attestation SDKはConfidential Computing対応GPUのlocal/remote attestationを提供する。AI inferenceではmodel executionがGPUへ移るため、VM attestation成功とGPU attestation成功を別evidenceとして保持し、双方を必要とするpolicyならAND条件で判定する。

CPU attestationだけでGPU workloadへsecretを渡す、startup時一度のattestationで長寿命credentialを配る、reference value更新を自動許可する、過去tokenをreplay可能にする、といった構成では信頼境界が弱い。hardware measurementが正しくても、hostからguestへの操作面やapplication authorizationが過大なら安全性は成立しない。

release対象を分類し、attestationなしでは取得不能にする。平文secretをimage、startup script、環境変数へ先置きしてからattestationしてはならない。attestation policyはversioned artifactとして管理し、CPU TEE type、expected measurements、GPU model/mode、driver/firmware reference、Secure Boot、workload identity、agent policy等の必須条件を明示する。reference value更新にはchange control、旧新値、適用開始時刻、rollback条件を残す。

nonce/challenge、issuer、audience、expiry等でfreshnessを検証し、過去に成功したtokenのreplayを拒否する。attestation service outage、measurement mismatch、GPU evidence取得失敗はfail-closeを基本とする。break-glassが必要なら通常policyと分離し、承認・期限・監査証跡を持たせる。

NVIDIA Confidential Containersではremote attestation後にKey Broker Service/Attestation Serviceを介してsecretまたはsensitive resourceをreleaseする構造が示されている。attestation resultを記録するだけでなく、resource release pathへ接続することがcontrolの要点である。

Remote attestationは実行環境が期待状態かを検証する仕組みであり、modelの安全性・正確性、prompt injection耐性、application authorizationを証明しない。TEE内部で脆弱なapplicationを正しく起動してもattestationは成功し得る。provider/hardwareごとにclaimsとreference value semanticsも異なるため、Google Cloud Attestation、NVIDIA Remote Attestation Service、AMD SEV-SNP、Intel TDX等を一つのbooleanへ潰さず、raw evidence locator、verifier、policy version、decisionを保存する。

Confidential Computingは攻撃面を消滅させない。firmware、driver、attestation verifier、reference-value supply chain、TEE implementation自体がtrust baseになる。measurement mismatch等のplatform defectもあり得るため、attestation failureを即侵害と断定せず切り分ける必要がある。ただし切り分け中のsecret release許可とは別問題である。provider-operated verifierは独立性要件を満たさない場合があり、第三者/local verifierではreference value配布・revocation・availabilityの運用負担が増える。

• CPU TEE、GPU、driver、workload policyの必要十分なclaim組合せ。
• firmware/driver更新時のreference-value rolloutとfail-close可用性の両立。
• long-running inferenceの再attestation間隔と既発行secretのrevocation。
• multi-GPU/NVSwitch構成で全device evidenceを束ねるatomicity。
• provider verifierと第三者verifierの独立監査境界。

「remote attestationに成功すればConfidential AI inferenceは安全」とは断定しない。「CPU/GPU/driver/firmware/workload policy等のattestation evidenceをversioned policyで検証し、許可状態に一致した場合だけsecretや暗号化資産をreleaseすることで、機密AI workloadの実行環境に対する信頼境界を強化する」とする。

• Google Cloud, Confidential VM attestation: https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/attestation
• Google Cloud, Confidential VM overview: https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/confidential-vm-overview
• NVIDIA Attestation SDK: https://docs.nvidia.com/attestation/attestation-client-tools-sdk/latest/gpu_and_switch_attestation.html
• NVIDIA Confidential Containers Attestation: https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/attestation.html
• NVIDIA Hopper Remote Attestation Example: https://docs.nvidia.com/attestation/quick-start-guide/latest/attestation-examples/hopper_single_gpu.html