パブリッククラウドでのコンフィデンシャルコンピューティング: 隔離とリモート認証について

by Canonical on 20 February 2023

このブログシリーズの前半では、実行時のセキュリティ問題について扱いました。コードやデータは、パブリッククラウドのインフラストラクチャに含まれる特権システムソフトウェアやその管理者に対して脆弱なのです。この問題に対処する方法として、TEE（trusted execution environment、信頼できる実行環境）とコンフィデンシャルコンピューティング（CC）の概念についても紹介しました。CCの考え方は現実的です。まず、クラウドのシステムソフトウェアがブートストラップする実行環境を信用できないものと見なし、セキュリティ重視のワークロードは隔離されたTEEで実行することを提案します。TEEのセキュリティ保証の根拠は、プラットフォームの最も基本的なハードウェア層にあります。そしてセキュリティはリモートで検証できます。 

しかし、CCはどのように機能するのでしょう？ TEEとCCを詳しく理解するには、隔離とリモート認証について把握する必要があります。

TEEとCCについて論じる前に、まず2つの基本事項、1) 隔離、2) リモート認証を理解しましょう。  ブログ第2部のテーマはそれです。始めましょう！

隔離

ハードウェアの隔離によってセキュリティの保証されたTEEを作るというアイデアは、決して新しくありません。昔からハードウェアでTEEを実現するさまざまな方法が開発されました。大まかに言えば、物理的隔離と論理的隔離に分けられます。

物理的隔離

コードは物理的に隔離されたプロセッサ内で動作し、信頼できない実行環境とはいかなるコンテキストも共有しません。代表的な例にはコプロセッサ、スマートカード、セキュアエレメントなどがあります。このようなソリューションは完全な隔離のおかげで、ホストプラットフォームのサイドチャネル攻撃に対しては高い侵害保証を提供します。しかし、システムのメモリには直接アクセスできません。処理リソースも非常に限られます。

多重化された論理的隔離

セキュリティ重視のワークロードが、同じホスト市販プロセッサ内で動作し、同じ物理的実行コンテキストを共有します。ただし、メインCPUとは以下のように論理的に隔離されています。

1. メインメモリの暗号化によるメモリの隔離：多くのコンフィデンシャルコンピューティング対応CPUは、新しいAES-128ハードウェア暗号化エンジンをメモリコントローラに組み込んでいるため、メモリの読み出し/書き込みの都度、メモリページを暗号化/解読します。ワークロードのコードとデータを実行時にクリアテキスト（平文）でシステムメモリに入れることはありません。これにより、メモリからデータを収集しようとする悪質なシステム管理者や脆弱なオペレーティングシステムは、暗号化されたサイファーテキスト（暗号文）にしかアクセスできません。暗号化キーは、ハードウェアレベルでさらに保護および管理され、クラウドの特権システムソフトウェアや管理者にアクセスされることはありません。

2. その他のCPUベースのハードウェアアクセス制限メカニズム：暗号化はコンフィデンシャルワークロードのメモリページの機密性を保護しますが、まだ他の方法で攻撃される可能性があります。たとえば悪質なホストオペレーティングシステムが、同じメモリページを2つの異なるプロセスに配置する場合があります。リプレイ攻撃の一環として暗号化されたメモリの値を変更し、コンフィデンシャルワークロードの完全性保証を破る場合もあります。この解決策として、コンフィデンシャルコンピューティング対応CPUは新しい命令と新しいデータ構造を実装し、従来は特権システムソフトウェアが実行していたセキュリティ重視型のタスク（メモリの管理やプラットフォームのデバイスへのアクセスなど）を監査します。たとえばコンフィデンシャルワークロードに位置づけられたメモリページを読む新しい命令は、データの破壊とリプレイ攻撃を防ぐため、直前にページに書き込まれた値も返す必要があります。

リモート認証

さて、これでワークロードは隔離されたTEE内でセキュアに実行されます。ですよね？ コンフィデンシャルでない通常の環境にクラウドプロバイダーがワークロードを展開していないことを、どうすれば確認できるのでしょう？ どうすれば本物のハードウェアTEEにワークロードをプロビジョニングしたことがわかるのでしょう？ そうだとしても、あなたの意図どおり、そのシステムソフトウェアがTEEにアプリケーションをロードしたことを確認できますか？ クラウドプロバイダーの言葉どおりに受け取りますか？ その必要はありません。TEEに大切なアプリをプロビジョニングし、結果を信用して受け取る前に、そのハードウェアTEEのリモート認証機能を利用することをおすすめします。 

少なくともリモート認証は、以下を含む暗号上の証明を提供します。

1. TEEにロードしたソフトウェアの完全性を証明する測定値/ハッシュ
2. 使用されているクラウドのTEEハードウェアが本物であり、無効でないことを証明する暗号署名（ハッシュを使用）

リモート認証の実装の詳細は、基本的なハードウェアTEEとパブリッククラウドプロバイダーによって決まります。これは、このシリーズの次のブログでご紹介しましょう。

パブリッククラウドのコンフィデンシャルコンピューティング

コンフィデンシャルコンピューティングとは、複数の関係者の協力を必要とする業界全体の取り組みです。ハードウェア側では、すでにシリコンプロバイダーがかなりのリソースをTEEの開発に投入しています。Intel SGX、Intel TDX、AMD SEV（X86アーキテクチャ）、ArmエコシステムではTrustZoneと次のARM CCA、Keystone（RISC-Vアーキテクチャ）など、例には事欠きません。

ハードウェアのTEEを積極的に採用しているのがパブリッククラウドプロバイダー（PCP）です。PCPは、コンフィデンシャルワークロードをユーザーが簡単に実行できるよう、VM全体をそのままTEE内で実行する「シフト＆リフト」への対応に力を注いでいます。 

これなら、開発者がコンフィデンシャルアプリのリファクタリングや書き直しをする必要はありません。ただし、ゲストオペレーティングシステムを最適化することで、ユーザーのアプリがプラットフォームのハードウェアTEE機能を利用し、起動中や休止中のVMもしっかり保護するようにする必要があります。

Google CloudのグループプロダクトマネージャーであるNelly Porterは次のように述べています。「Google Cloudのコンソールには、Google Cloudのコンフィデンシャルコンピューティング機能を利用して使用中のデータのセキュリティを確保するよう最適化されたUbuntu LTSイメージが使用されています。Canonicalの協力もあり、UbuntuベースのコンフィデンシャルVM環境はシンプルで使いやすさも抜群です。」

現在、Canonicalのクラウドコンフィデンシャルコンピューティング製品群には、Google CloudのコンフィデンシャルVMがあります。でも、まだまだこれから！ 

Canonicalは、コンフィデンシャルコンピューティングを強く推進しており、これはUbuntuのコンフィデンシャルコンピューティング機能をさまざまなパブリッククラウドやコンピューティングクラスに展開する第一歩にすぎません。ポートフォリオの拡大について情報を共有するとともに、コンフィデンシャルコンピューティングを活用する新しい事例について皆様から教えていただければ幸いです。 

その他のリソース

• コンフィデンシャルコンピューティングに関するウェビナー
• CanonicalがAzure対応CVMを実現した経緯を解説
• AzureでUbuntu CVMの作成と利用を始める
• Linuxはセキュア？
• Google Cloudのコンフィデンシャルコンピューティングについて