FUJITSU-MONAKAによる機密コンピューティングの実現に向けて #1 ～Arm CCAに触れてみた～

こんにちは、富士通研究所先端技術開発本部の堀です。私の所属する本部では、次世代の省電力ArmプロセッサFUJITSU-MONAKAを開発しています。その中で私たちのチームでは、FUJITSU-MONAKAを最大限に活用できるユースケース創出に取り組んでいます。

FUJITSU-MONAKAが持つ特徴の1つにArm Confidential Compute Architecture(Arm CCA)があります。これはハードウェアをベースとした機能でセキュリティを高めるConfidential Computingと呼ぶ技術です。

Arm CCAは開発途上ということもあり、解説記事は多くはなく、日本語記事になるとさらに少ないです。このブログではConfidential Computing技術の概要やFUJITSU-MONAKAでのユースケースなどを数回に分けて紹介します。皆さんにFUJITSU-MONAKAに関心を持っていただけると幸いです。

1回目となる今回はArm CCAについて、Armアーキテクチャでの動作検証例を中心に紹介します。なお、Arm CCAは現在開発中のため、今後仕様が変更される可能性があります。ご了承ください。

Confidential Computingとは

みなさんが普段使っているネットショッピングではクレジットカード番号や住所などの個人情報を入力しますが、他人に覗かれないだろうかと不安になることはありませんか。個人情報のような機密データを脅威から保護する技術が重要になってきます。

データの状態

一般的にデータには3つの状態があります。

at Rest : データがストレージに保存されている状態
in Transit : データがネットワーク上で転送されている状態
in Use : コンピュータのメモリ上やCPU上にある、処理中の状態

このうち、at Restとin Transitのデータについては、データを保護するための暗号化技術がすでに普及しています。例えば、ストレージ上のデータについては暗号化して保存することで、システムに侵入されたり、物理的に装置が盗まれたりすることでストレージ上のデータにアクセスされ、読み取られても、第三者には容易には解読できません。インターネットを経由してデータを転送するときも暗号化することで安全に相手に送れます。

処理中のデータを保護するConfidential Computing

残るin Useのデータに対する保護技術がConfidential Computingです。

例えば、クラウドで提供されるサービスは、クラウド事業者が用意するリソース(CPU、ストレージ、ネットワークなど)上で動作しています。クラウドのインフラが攻撃を受けても利用者はそれに気づきにくく、大切なデータの改ざんや漏洩につながってしまいます。これはオンプレの計算機であっても同じことが言えます。対策としてはデータが読み取られてもどういう内容かわからないようにデータを暗号化することです。ストレージやネットワーク上のデータを暗号化する技術はすでに普及しています。

コンピュータのメモリ上にあるデータはどうでしょうか？ソフトウェアの脆弱性を利用してメモリに不正アクセスされたり、極端な例ではメモリを物理的に取り外して内容を読み取られたりするリスクがあります。そこでメモリ上のデータも暗号化して保護する必要があります。

Confidential Computingではメモリ上のデータを、ハードウェアを基盤とした技術であるTrusted Execution Environment(TEE)で保護します。CPUはメモリ上にあるデータ(ここではプログラムコードもデータとします)を読み、処理します。しかし、データが暗号化されているとそのままでは実行できませんので復号する必要があります。 TEEはハードウェアレベルで保護された安全な実行環境です。メモリ上の暗号化されたデータは、TEEの中で復号、実行されます。実行結果はメモリに書き込まれるときに暗号化されます。

ハードウェア(プロセッサ)が信頼の基点となるConfidential Computing分野において、FUJITSU-MONAKAは国産であることの信頼性を活かして安心・安全な実行環境を提供できます。

Confidential Computingを取り巻く状況

ここでConfidential Computingを取り巻く環境について紹介します。

国際動向としては米国・中国を中心に、プラットフォーマーによるConfidential Computingサービスが展開され、基礎研究から応用研究の段階へシフトしています(出典:国立研究開発法人科学技術振興機構研究開発戦略センターの資料「CRDS-FY2022-FR-04；2.4.5 システムのデジタルトラスト」) 。例えば、商用クラウドAmazon Web Services(AWS)、Microsoft Azure、Google Cloud Platform(GCP)などのハイパースケーラーはConfidential Computingサービスの提供をしています。

また、主要なプロセッサアーキテクチャにはConfidential Computing技術がすでに実装されています。Confidential Computingの先駆けとしてはIntel SGXが登場しました。これはアプリケーションプロセスの一部を暗号化されたエンクレーブ(保護領域)として隔離するプロセスベースの技術であり、アプリケーションの修正が必要です。その後、システムメモリ全体を暗号化し、アプリケーションの修正が不要な仮想マシン(VM)ベースの技術、例えばAMD SEVやIntel TDXが登場しました。現在はVMベースの技術がConfidential Computingの主流になりつつあります。Armアーキテクチャにおいても、従来からセキュア実行環境と非セキュア実行環境を分離する技術TrustZoneがあります。そして2021年にはTrustZoneを拡張したVMベースの技術であるArm CCAが発表され、現在、ハードウェアとソフトウェアの開発が進められています。

オープンソースコミュニティにおいては、Linux FoundationのプロジェクトコミュニティとしてConfidential Computingの普及を推進するConfidential Computing Consortiumが発足されました。主要なハードウェアベンダー、クラウドプロバイダー、およびソフトウェア開発企業が参加しています。富士通も2023年からメンバーとして参加しています。他には、Cloud Native Computing FoundationのConfidential ContainersプロジェクトではVMベースのコンテナ基盤の開発が進められています。

国内ではまだ基礎研究段階でコア技術・応用に関する動きは少ないです。しかし、Confidential Computingの重要性は認識されていて、サイバーセキュリティに関する指針・規制に関して、IPA(独立行政法人情報処理推進機構)は「重要情報を扱うシステムの要求策定ガイド」を2023年に公開しています。このガイドは重要情報を扱うシステムにおけるサービスの安定供給にあたって、そのシステムのオーナーである管理者が必要な対策を策定する指針を定めています。この中では「計算途上のデータの暗号化の確保」として、メモリからデータを読み取ろうとする攻撃に対して例えばハードウェア技術によって計算結果を暗号化・隔離する機能が必要であると述べています。

Arm CCA

Arm CCAの大きな特徴の1つとして、Realm(レルム)と呼ぶ実行環境があります。Realmはハードウェア機能であるRealm Management Extension(RME)よって、コードの実行やデータを通常の実行環境から隔離された環境です。そして、RealmはRealm Management Monitor(RMM)と呼ぶソフトウェア機能によって管理されます。

前述のセキュリティ技術であるTrustZoneもハードウェア機能を利用してメモリを隔離する機能を持っています。しかし、システム起動時に初期化され、メモリがセキュアか非セキュアかは固定的でした。これに対してRealmは動的に作成したり、削除したりでき、メモリを柔軟に使い分けられます。ハイパーバイザーはRMMを通してRealmを管理できますが、Realm内のメモリはハードウェアによって暗号化されるためハイパーバイザーであってもそれらの内容を覗くことができません。

つまり、Realmはハイパーバイザーで管理できる使い勝手を持ちつつ、リソースの隔離もできるというメリットを持つと言えます。

Realm環境を起動してみる

技術の説明だけではなかなか理解が難しいので、実際に動かしてみます。とはいっても、執筆時点ではArm CCAを搭載したCPUは残念ながらまだ世の中に出回っていません。このため、オープンソースのエミュレータQEMUを使ってRealmに触れてみたいと思います。

ビルド方法はLinaro(※)が公開しているサイトの"Building an RME stack for QEMU"を参考にし、その中で紹介されている一番簡単な自動ビルド(“With the OP-TEE build environment”)を利用することにします。詳細な手順の説明は別の機会があれば紹介することにして、今回は省略します。

※Linaroは、Armアーキテクチャベースのシステム向けのオープンソースソフトウェアの開発と普及を推進する非営利団体です。

ビルドに使った環境は以下のとおりです。つまり、Intel機でArmアーキテクチャをエミュレートします。

計算機: PRIMERGY RX2530M6
CPU: Intel Xeon Silver 4309Y CPU @ 2.80GHz*32コア
メモリ: 64GB
OS: Ubuntu 22.04.4 LTS
X Window System + GNOMEデスクトップ環境が必要

ビルドが成功したら、QEMUによるシステムのエミュレーションを起動します。エミュレーションが始まると、4つの端末ウィンドウが開かれます。それぞれのウィンドウには、Firmware、host、Realm、そしてSecureという名前がついています。

Firmware : エミュレートしているArm仮想マシン(ホスト)のファームウェアの出力画面
host : エミュレートしているArm仮想マシン(ホスト)のコンソール画面
Realm : エミュレートしているArm仮想マシン(ホスト)上で実行されるRealm VMのコンソール画面
Secure : 今回の検証では出力されることがなかったので説明は省略(実は、よくわかっていません)

最初に起動されるのは、Arm仮想マシン(ホスト)です。今回の検証機では数秒でホストOSのログインプロンプトがhost端末上に表示されました。ホストOSにはrootユーザ(パスワードなし)でログインします。

ホストOSにログイン後、さらにQEMUを実行してRealmを起動します(“Launching a Realm guest”の” Launching a Realm guest using QEMU”参照)。ここで起動するQEMUがRealmを管理するハイパーバイザーの位置づけになります。QEMU上でさらにQEMUを実行する形になるため、Realmの起動には時間がかかります。Firmware端末上にファームウェアのログが流れ、そのうち、Realm端末上にゲストOSの起動ログが出始めます。

今回の検証ではホストOSやゲストOSとして最小限の機能に絞ったLinuxを起動しましたが、Ubuntuを起動してその上でアプリケーションを実行することもできます。

ゲストOSが起動したときのソフトスタックを図にすると以下の図のようになります。

参考: "Building an RME stack for QEMU"

Realm上ではメモリが暗号化されるので、仮に外部からメモリを覗いても意味がある情報として認識することはできません。例えば、ゲストOS上で適当な環境変数を設定し、ゲストOSのメモリ全体をダンプして中身を覗いても環境変数やその値は見つからないはずです。ただ、現在の環境ではメモリの暗号化処理は実装されていないようでした。Arm CCAはまだ開発途上であることと、ソフトウェアによるエミュレーションでのメモリ暗号化処理は性能面で実用的でない可能性があることからしょうがないかなと思います。将来、実ハードウェア上などで動作が確認できたときに機会があれば紹介したいと思います。

アテステーション

Realmは外部から隔離されている環境ですが、これが第三者の提供している実行環境だとしたら、セキュリティ的にはまだ心配な点があります。使おうとする実行環境は改ざんされている可能性がないかということです。Realmによって外部と隔離されていて安全と言っても、その中身が改ざんされていたり、出どころがわからなかったりするシステムは使いたくありませんね。そこで、システムのベンダーが提供した正当な環境かどうか(OS、ファームウェア、ハードウェアなど)を確認したくなります。

あるシステムが正当な環境であることを証明することをアテステーション(Attestation)と呼びます。簡単に言えば、正当性を証明したいシステムのOS(カーネルや初期RAMディスクなど)、ファームウェア、ハードウェアなどから求められる何らかのハッシュ値と正解値を比較し、同じなら正当なシステムであると判断するようなことです。この正解値とは、システムを構成するハードウェアやソフトウェアの提供元からの情報です。

アテステーションには、検証する側と検証される側が同じシステムであるローカルアテステーションと、検証を信頼できる第三者に依頼するリモートアテステーションがあります。リモートアテステーションについては、IETF(Internet Engineering Task Force)のRATS(Remote ATtestation ProcedureS)ワーキンググループでフレームワーク標準化が進められています。アテステーションサービスの実装例としては、クラウドサービスやCPUベンダーによる独自実装(Microsoft Azure Attestation、Intel Trust Authorityなど)があります。Arm CCAについては、アテステーションサービスに必要なソフトウェアコンポーネントを提供する、RATS準拠のVeraisonの開発が進められています。他にはConfidential ContainersのTrusteeなどもあり、リモートアテステーションはコミュニティでも活発に議論・開発されています。

以下ではVeraisonを使ったRealm VMのリモートアテステーションを紹介します。 Veraisonを使ったアテステーションサービスの構築方法はhttps://github.com/veraison/servicesを参照してください。

アテステーションの構成要素

Veraisonを使ったリモートアテステーションは以下の図のような構成になります。

出典: "veraison-tmpdev2023.pdf"

リモートアテステーションにおける主な登場人物(役割)は以下のとおりです。

Attester : 自分が正当であることの証拠となる情報を提示します。今回の検証ではRealm に相当します。
Relying Party : Attesterを信頼して使いたい側です。今回の検証ではRealm内のゲストOSを利用する側に相当します。
Endorser : Attesterが正当であることを保証します。つまり、システムを出荷する提供者になります。今回は検証者自身です。
Verifier : Attesterを信頼できるかどうか検証します。今回の検証ではVeraisonに相当します。

アテステーションのモデル

アテステーションのやり方にはパスポートモデルとバックグラウンドチェックモデルがあります。今回はパスポートモデルによるアテステーションをしました。

パスポートモデル : Attesterが証明結果を提示するタイプで、入国審査におけるパスポートに例えることができます。
バックグラウンドチェックモデル : Attesterの知らないところ(バックグラウンド)で検証が行われるタイプで、入社の審査に例えることができます。

アテステーションのフロー

Realm VMが正当な環境であることをVeraisonに検証を依頼するデモ用のコマンドcca-workload-attestationがあります。Realm環境を自動ビルドした場合は、ゲストOSのイメージ内にコマンドはインストールされています。

コマンドcca-workload-attestationによるアテステーションの流れは以下の図のようになります。

参考: CCA workload attestation PoC

コマンドでVeraisonへ検証を依頼します。
VeraisonからChallenge(nonce(乱数))が返されます。
受け取ったChallengeを使って、RMMにCCA attestation token(正当性を示す証拠データ)を要求します。要求はゲストOSからRMMへRSIというAPIを使って送られます。
RMMからCCA attestation tokenが返されます。CCA attestation tokenはEntity Attestation Token (EAT)という仕様のデータです。
VeraisonへCCA attestation tokenを送信します。
CCA attestation tokenを検証した結果がEAT Attestation Result(EAR)として返されます。
検証結果(EAR)を表示します。

CCA attestation tokenの構造

アテステーションの過程でRMMからCCA attestation tokenが得られます(前述のフローの項番4)。このCCA attestation tokenはConcise Binary Object Representation(CBOR)というフォーマットのデータで、以下の構造になっています。

出典: "Realm Management Monitor specification"

CCA attestation tokenには、Realm tokenとCCA platform tokenの情報が含まれています。

Realm token : Realmの初期状態、カーネルや初期RAMディスクなどの情報が含まれます。
CCA platform token : Arm CCAプラットフォームに関する情報です。Realm tokenと紐づけられています。

Veraisonによる検証結果

正当性を検証するVeraisonには予め正解値が登録されています。Veraisonは、その正解値と検証を依頼されたデータを比較し、結果をEARという情報で返します。

このEARを見て検証結果を判断します。今回使ったcca-workload-attestationコマンドはEARを目に見える形で以下のように表示します。なお、表示されている具体的な値はエミュレーション環境向けのサンプルデータです。

検証が成功した場合、以下のような出力になります。項目"ear.status"が"affirming"(確認した/裏付けした、の意味)になっています(★1)。

  # cca-workload-attestation passport
  {
   "ear.verifier-id": {
    "build": "N/A",
    "developer": "Veraison Project"
   },
   "eat_nonce": "T-2f6sxIC4j7T79kAP16wInCxIssa-FR94XJNgHieI1KvnpYRuiHzcLHmnw9Ythz4nMIg9No8hVSlarFP7UQRQ==",
   "eat_profile": "tag:github.com,2023:veraison/ear",
   "iat": 1716253055,
   "submods": {
    "CCA_SSD_PLATFORM": {
     "ear.appraisal-policy-id": "policy:CCA_SSD_PLATFORM",
     "ear.status": "affirming", ★1
     "ear.trustworthiness-vector": {
      "configuration": 2,
      "executables": 2,
      "file-system": 0,
      "hardware": 2,
      "instance-identity": 2,
      "runtime-opaque": 2,
      "sourced-data": 0,
      "storage-opaque": 2
     },
    ・・・

検証が失敗した場合、以下のような出力になります。今回は意図的にVeraisonに登録されている正解値を削除して検証を失敗させました。その結果、項目"ear.status"が"contraindicated"(信頼できない、の意味)になっています(★2)。また、項目"problem"に"no trust anchor for evidence"と表示されています(★3)。

  # cca-workload-attestation passport
  {
   "ear.verifier-id": {
    "build": "commit-4e66fdd",
    "developer": "Veraison Project"
   },
   "eat_nonce": "6uJg7wz0R76nZcC5WBUw4rGMxvW1PHUblm7Us3rlJTwog0_4XQzidSEfFhzzqSZxg2pADr-9p8-CUntKNGukQA==",
   "eat_profile": "tag:github.com,2023:veraison/ear",
   "iat": 1716252157,
   "submods": {
    "CCA_SSD_PLATFORM": {
     "ear.appraisal-policy-id": "policy:CCA_SSD_PLATFORM",
     "ear.status": "contraindicated", ★2
     ・・・
   "ear.veraison.policy-claims": {
      "problem": "no trust anchor for evidence" ★3

富士通の取り組み

ここでArm CCAにおける富士通の取り組みについてもご紹介します。

2027年度にリリース予定のArmプロセッサFUJITSU-MONAKAは富士通独自技術による省電力かつ高性能を兼ね備えているだけではなく、Arm CCA技術も搭載することでクラウドシステムやAI/ML分野では機密性の高いデータを保護しながら高いパフォーマンスを提供することを目指しています。

しかし、Arm CCAを含むConfidential Computing技術は発展途上の技術であり、まだまだ課題があります。オープンソース(OSS)コミュニティでも活発に技術検討や機能開発が行われています。富士通は2023年にLinux Foundation配下のConfidential Computing Consortiumのメンバーになり、Arm CCAを含むConfidential Computing技術の開発や普及に向けて、OSSコミュニティや開発パートナー(Arm社やLinaro)と連携して、ハードウェア・ソフトウェアの両面でArm CCAの機能強化を進めています。

また、共創パートナー様ともFUJITSU-MONAKAの特長を活かしたユースケースの創出やConfidential Computingの普及に向けた検討も開始しています。そして、これら新しいユースケース検討から出てきた課題を製品仕様やOSSコミュニティへフィードバックしていきます。

おわりに

今回はConfidential Computingについて、Arm CCAにおけるRealmやそのアテステーションを中心に紹介しました。技術的な話が中心でしたので、これがどう役に立つのかについてはイメージにしにくかったかもしれません。次回以降では、FUJITSU-MONAKAのArm CCA技術を活用したユースケースやArm CCA機能のOSSコミュニティの開発状況や検証事例などをご紹介できればと思います。

謝辞

この成果は、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)の助成事業の結果得られたものです。

fltech - 富士通研究所の技術ブログ

富士通研究所の研究員がさまざまなテーマで語る技術ブログ