機密コンピューティングのリモートアテステーション

リモート・アテステーションを使用して、OCI上の機密VMシェイプが信頼できるセキュアな環境で実行されていることを個別に検証します。

機密コンピューティングとアテステーションについて

機密コンピューティングは、処理中に信頼できる実行環境で機密データとコードを分離するテクノロジを使用して、不正アクセスや環境外からの変更を防止することで、使用中のデータを保護します。リモート・アテステーションは、Trusted Execution Environment (TEE)の機密性と整合性を検証するメカニズムを提供します。

機密コンピューティングは、共有リソースを使用するシステムで仮想化されたワークロードが実行される可能性がある環境で重要です。一部のハードウェア・コンポーネントは、稼働中にワークロードを分離して保護するのに役立つテクノロジを提供します。これらのテクノロジは、ハードウェアベースの分離レイヤーを追加し、専用ゲスト・メモリー・リージョン内のデータをハイパーバイザまたは他のゲストによるアクセスから保護します。機密コンピューティング用に Oracle Linuxシステムを構成する方法の詳細は、Confidential Computing For Oracle Linuxを参照してください。

リモート・アテステーションは、ゲストVMが信頼できるセキュアな環境で実行されていることをリモート・パーティに証明するメカニズムを提供します。これは、プラットフォームとゲストVMのメモリー・リージョンの整合性を検証する一連の暗号化の課題とレスポンスによって実現されます。リモート・アテステーションを構成することで、ワークロードが実行されているシステムが、処理中にデータを保護するように正しく構成されていることを個別に検証します。

サポートおよび制限事項

リモート・アテステーションは、次のOracle Linuxバージョンを実行しているインスタンスでサポートされています。

  • Oracle Linux 9
  • Oracle Linux 10
ノート

リモート・アテステーションには、Unbreakable Enterprise Kernel 8 (UEK 8)以上が必要です。

インスタンスは、AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP)をサポートしている必要があります。このテクノロジをサポートするコンピュート・シェイプのリストは、機密コンピューティングを参照してください。

構成証明ソフトウェア

このソリューションに使用されるアテステーション・ソフトウェアは、検証サーバー、エビデンス・コレクタおよびエンドースメント・プロビジョニング・ツールで構成されます。

コンポーネントは次のとおりです。

  • veraison-services: リモート・アテステーション検証サーバーおよび関連サービス。

  • veraison-ratsd: リモートアテステーションエビデンスコレクタ。

  • cocli: エンドースメント・プロビジョニング・ツール。

リモート・アテステーションのロールに従って、インスタンスにアテステーション・ソフトウェアをインストールおよび構成します。

アテステーション・ロール

アテステーション・ロールは、リモート・アテステーションに関係する様々なアクターまたはエンティティとその関連を定義します。

このリモート・アテステーション・フレームワークで使用されるコア概念は、RFC 9334: Remote Attestation Procedures (RATS) Architectureで定義されています。次の主要なロールが定義されています。

  • Attester: 請求の形で検証者に伝達される証拠を作成するエンティティです。要求は、インスタンスについて収集できる情報の事前定義済のエンコーディングです。

    この場合、検証するOCIインスタンスはアテスタであり、veraison-ratsdエビデンス・コレクション・サービスを実行します。

  • 検証者: アテスタに関する証拠の妥当性を評価し、アテステーション結果を生成するエンティティです。請求は、検証者にプロビジョニングされた承認を使用して証拠を評価し、信頼を確立するのに役立つ評価ポリシーに従って評価されます。ポリシーは、ベリファイア所有者によって定義されます。

    この場合、ベリファイアはveraison-servicesを実行しているインスタンスです。

  • リライイング・パーティ: アプリケーション固有のアクションを確実に適用する目的で、アテスターに関する情報の妥当性に依存するエンティティ。リライイング・パーティは、アテスタのアテステーション結果をセキュアに提供するためにベリファイアを信頼するサーバーまたはインスタンスである場合があります。

    この場合、リライイング・パーティは、HTTPS経由でベリファイアへのTLSセキュア接続をオープンするように適切に構成されたインスタンスであり、veraison-servicesによって提供される結果に基づいて評価ポリシーで構成されます。

  • リライイング・パーティ所有者: アテステーションの評価ポリシーを構成する権限があるエンティティが、リライイング・パーティになります。リライイング・パーティ所有者の設定は、このドキュメントの範囲外です。

  • 検証者所有者: 検証者のエビデンスに対する評価ポリシーの構成を許可されたエンティティ。検証者所有者は、検証者に承認をプロビジョニングすることもできます。

    この場合、ベリファイア所有者は、cocliプロビジョニング・ツールを使用して、エンドースメントでveraison-servicesをプロビジョニングできます。

  • 推薦者: 検証者が証拠の真正性を評価し、査定者のさらなる機能を推論するのに役立つエンティティ。信頼性に関する証拠は複雑であるため、ベリファイアはメーカー、ディストリビューター、またはデバイス所有者が提供する信頼できる承認を使用して、アテスターが提供する証拠を評価できます。

    この場合、エンドーサはソフトウェア・アーティファクトのサプライヤになる可能性があります。

  • 参照値プロバイダ: 検証者が証明を評価し、受理可能な既知の要求が参加者によって記録されたかどうかを判断するのに役立つ参照値を持つエンティティ。推薦と同様に、信頼できる参照値は製造業者、流通業者またはデバイス所有者によって提供され、ベリファイアで使用して、アテスターによって提供される証拠を評価できます。

    この場合、エンドーサは AMDなどのハードウェアベンダーになることがあります。

これらのロールは、常に相互に排他的であるとは限らず、エンティティは同時に複数のロールを引き受けることができます。

この図は、IETF Remote Attestation Procedures (RATS)作業グループによって提案されたアテステーションアーキテクチャーを示しています。上部の行には、「推薦者」、「参照値プロバイダ」、「検証者所有者」および「リライイング・パーティ所有者」が表示され、それぞれが中央の「検証者」ボックスに入力(推薦、参照値および評価ポリシー)を提供します。下の行には、検証者にエビデンスを送信するアテスタと、検証者からアテステーションを受信するリライイング・パーティが表示されます。キー・フローは、検証と意思決定をサポートするために、情報とポリシーがロール間でどのように移動するかを示します。

リモート・アテステーション・コンポーネントの設定

リモート・アテステーション・コンポーネントでは、インフラストラクチャ内の複数のインスタンスに対する設定および構成が必要です。

リモート・アテステーションでは、コンポーネントを設定し、次の各インスタンスに対して構成ステップを実行する必要があります。
  • すべてのアテスター・システムまたはOCIインスタンスは、信頼できる実行環境で実行されているという証拠を提供する必要があります。

  • アテスタ・インスタンスによって提供されるエビデンスを評価し、ベンダーまたはサード・パーティ・エンドースメント用に構成できるベリファイア・インスタンス。

  • アテスタ・インスタンスをベリファイアに対して検証する必要があるリライイング・パーティ・インスタンス。

ノート

リモート・アテステーション環境のすべてのコンポーネントには、このサービスに使用されるTCPポートへのネットワーク・アクセスが必要です。VCNセキュリティ・ルールまたはセキュリティ・リストを構成している場合は、これらが正しく構成されていることを確認する必要があります。

詳細は、アクセスとセキュリティを参照してください。

次の図は、アテステーション・コンポーネント間の一般的な関係とワークフローを示しています。

この図は、アテステーション・コンポーネントのワークフローを示しています。この図は、リライイング・パーティ、ベリファイア・サーバーおよび機密VMシェイプを示しています。Verifierサーバーには、Verification (ポート8443)、Management (ポート10443)、Provisioning (ポート9443)の3つのエンドポイントがあります。Confidential VM Shapeには、veraison-ratsdサービスが含まれています。双方向の矢印は、リライイング・パーティを検証エンドポイントに1というテキストで接続します。セッションを作成し、nonceを取得します。双方向の矢印は、リライイング・パーティをConfidential VM Shapeのveraison-ratsdサービスに接続し、テキストは2です。ノンスを送り、証拠を得る。双方向の矢印は、リライイング・パーティを検証エンドポイントに3というテキストで接続します。検証のために証拠を送る。cocliエンティティは、信頼アンカー、参照値というテキストを使用して、プロビジョニング・エンドポイントへの単方向矢印で接続します。
リモート・アテステーション・コンポーネントに必要なTCPポート
ポート コンポーネント 目的
8895 veraison-ratsd (アテスター) エビデンス・コレクションおよびアテスタ相互作用に使用されるREST API。
8443 ベレゾンサービス(Verifier) メイン検証エンドポイントとして使用されるREST APIおよびチャレンジ・レスポンス・エンドポイント。
9443 ベレゾンサービス(Verifier) ベリファイアのcocliツールで使用される承認プロビジョニングAPI。
10443 ベレゾンサービス(Verifier) 将来の拡張およびサポート・サービスに使用されるベリファイア・サービスAPI。
ノート

TCPポート50080は、veraison-vcek-cacherとのプロセス間通信にveraison-servicesによってベリファイアで使用されます。イングレス・ファイアウォール・ルールが制限されていない場合、このポートへの外部アクセスを明示的に防止します。

veraison-vcek-cacherサービスは、AMD発行のVCEK (バージョニングされたチップ・エンドースメント・キー)証明書をキャッシュして、同じ証明書に対するAMDのKDS (Key Distribution Service)への繰返しリクエストを最小限に抑えます。

VCEKは、AMDプロセッサごとにプロビジョニングされた一意キーであり、AMD SEV-SNPのアテステーション・レポートの署名に使用されます。特定のハードウェアおよびファームウェアバージョンに VMのIDをバインドすることで、機密計算アテステーションが可能になります。キャッシュされたVCEK証明書には、SEV-SNPアテステーションレポートの署名を検証するために使用されるVCEK公開鍵が含まれています。

  1. veraison-ratsdサービスをインストールして、アテスター・インスタンスを設定します。「アテスタの設定」を参照してください。
  2. veraison-servicesをインストールおよび構成して、ベリファイア・インスタンスを設定します。ベリファイアの設定を参照してください。
  3. ベリファイアとの通信時に接続が暗号化および検証されるように、任意のリライイング・パーティでTLSを構成します。リライイング・パーティ用のTLSの構成を参照してください。
  4. すべての参加者が提出した請求および証拠の評価に役立つように、検証担当者にサードパーティによる承認をプロビジョニングします。ベリファイアでの承認のプロビジョニングを参照してください。

出席者の設定

アテスタは、機密コンピューティング・インスタンスです。各インスタンスにveraison-ratsdソフトウェアをインストールおよび設定します。

インスタンスをアテスタとして設定するには、次のステップを実行します。

  1. インスタンスがConfidential Computingを使用して作成されていることを確認します。詳細は、Confidential Computing For Oracle Linuxを参照してください。
  2. インスタンスがAMD SEV-SNPをサポートし、モジュールが有効になっていることを確認します。
    cat /sys/module/kvm_amd/parameters/sev_snp

    コマンドは、レスポンスとして'Y'を返す必要があります。SEV-SNPは機密コンピューティングに必要です。SEV-SNPがないと、インスタンスはリモート・アテステーションに適していません。

    インスタンスにSEV-SNPが含まれていない場合は、サポートされているUEKバージョンおよびコンピュート・シェイプでインスタンスが実行されていることを確認します。詳細は、Support and Limitationsを参照してください。

  3. oci_included yumリポジトリがシステムで有効になっていることを確認します。このリポジトリは、Oracle Linuxプラットフォーム・イメージではデフォルトで有効になっています。
    • Oracle Linux 10の場合、次のコマンドを実行します。

      sudo dnf config-manager --enable ol10_oci_included
    • Oracle Linux 9で、次を実行します:

      sudo dnf config-manager --enable ol9_oci_included
  4. veraison-ratsdパッケージをインストールします。
    sudo dnf install -y veraison-ratsd
  5. veraison-ratsdサービスが有効化され、システムで実行されていることを確認します。
    sudo systemctl enable --now veraison-ratsd
    sudo systemctl status veraison-ratsd
  6. システムがveraison-ratsdサービスに接続できるようにファイアウォール・ルールを構成します。
    sudo firewall-cmd --permanent --add-port=8895/tcp
    sudo firewall-cmd --reload

    デフォルトでは、veraison-ratsdサービスはTCPポート8895で実行されます。

検証機能の設定

検証者は、アテスターから提供された証拠を確認します。機密コンピューティング・インスタンスにベリファイアをインストールする必要はありませんが、推奨されます。veraison-servicesソフトウェアをインスタンスにインストールして設定します。

ベリファイアとしてインスタンスを設定するには、次のステップを実行します。

  1. oci_included yumリポジトリがシステムで有効になっていることを確認します。このリポジトリは、Oracle Linuxプラットフォーム・イメージではデフォルトで有効になっています。
    • Oracle Linux 10の場合、次のコマンドを実行します。

      sudo dnf config-manager --enable ol10_oci_included
    • Oracle Linux 9の場合、次のコマンドを実行します。

      sudo dnf config-manager --enable ol9_oci_included
  2. veraison-servicesパッケージをインストールします。
    sudo dnf install -y veraison-services
  3. veraison-services TLS証明書を構成します。

    サービスのインストール時に生成された自己署名証明書を使用するか、認証局(CA)によって署名された証明書をインストールできます。自己署名証明書を使用する場合は、任意のリライイング・パーティに対して追加の構成ステップを実行する必要がある場合があります。

    • 自己署名証明書を使用します。

      1. 自己署名証明書ルートCA証明書をシステムのCAトラスト・アンカーにコピーします。

        sudo cp /etc/veraison-services/certs/rootCA.crt /etc/pki/ca-trust/source/anchors/
      2. システムのCAトラスト・ストアを更新します。

        sudo update-ca-trust
      3. 自己署名証明書を使用してリライイング・パーティを更新します。「リライイング・パーティ用のTLSの構成」を参照してください。

    • CA署名証明書の使用:

      1. CAからvtsprovisioningおよびverificationの各サービスに対する個々の証明書とその公開キーを取得します。

      2. 3つの署名付き証明書およびキーを/etc/veraison-services/certsにコピーします。
      3. サーバーを再起動します。
        sudo veraison -s stop
        sudo veraison -s start
  4. veraison-servicesが有効になっており、システムで実行中であり、システムがAMD Key Distribution Server (KDS)に到達できることを確認します。
    sudo systemctl enable --now veraison-services
    sudo veraison -s status
    curl -v https://kdsintf.amd.com
  5. システムがveraison-servicesに接続できるようにファイアウォール・ルールを構成します。
    sudo firewall-cmd --permanent --add-port=8443/tcp
    sudo firewall-cmd --permanent --add-port=9443/tcp
    sudo firewall-cmd --permanent --add-port=10443/tcp
    sudo firewall-cmd --reload

リライイング・パーティ用のTLSの構成

リライイング・パーティは、HTTPSを介してベリファイアと通信します。リライイング・パーティを構成して、ベリファイアで使用されるTLS証明書を検証します。

ベリファイアが自己署名証明書を使用している場合、署名証明書がシステムCAトラスト・ストアで使用できない場合、リライイング・パーティのツールでSSL/TLS検証に失敗する可能性があります。CA署名証明書を使用するようにベリファイアを構成した場合は、このステップをスキップできます。

  1. ベリファイア・インスタンスからルートCA証明書を取得します。

    veraison-servicesを実行しているインスタンスでは、ルートCA証明書は/etc/veraison-services/certs/rootCA.crtにあります。次のコマンドの出力をコピーして、ルートCA証明書の内容を取得できます。

    sudo cat /etc/veraison-services/certs/rootCA.crt
  2. ルートCA証明書の内容をリライイング・パーティのCAトラスト・アンカーに追加します。
    リライイング・パーティ・ホストで、ルートCA証明書の内容を格納するファイル/etc/pki/ca-trust/source/anchors/veraison-services.crtを作成します。システム・テキスト・エディタを使用して、前のステップでコピーしたコンテンツを貼り付けます。
  3. リライイング・パーティ・ホストのCAトラスト・ストアを再構築します。
    sudo update-ca-trust

検証者での承認のプロビジョニング

cocliツールを使用して、検証システムに承認をロードできます。

エンドースメントと参照値は、Concise Binary Object Representation (CBOR)形式で出荷されたConcise Reference Integrity Manifest (CoRIM)データモデルで表されます。cocliツールは、CoRIMエンドースメント・ファイルを操作するために使用され、検証者へのエンドースメントの発行など、様々なアクションを実行できます。

cocliツールは、veraison-servicesを実行しているベリファイアに接続できる任意のシステムで実行できます。わかりやすくするために、このツールをveraison-servicesと同じホストで実行します。

  1. oci_included yumリポジトリがシステムで有効になっていることを確認します。このリポジトリは、Oracle Linuxプラットフォーム・イメージではデフォルトで有効になっています。
    • Oracle Linux 10の場合、次のコマンドを実行します。

      sudo dnf config-manager --enable ol10_oci_included
    • Oracle Linux 9で、次を実行します:

      sudo dnf config-manager --enable ol9_oci_included
  2. veraison-cocliパッケージをインストールします。
    sudo dnf install -y veraison-cocli
  3. アテステーションに必要な承認を取得します。

    エンドースメントは、インストールしたveraison-cocliパッケージにCBOR形式のファイルとして含まれています。

    エンドースメント・ファイルは、次のパスに格納されます。

    • TrustAnchors: /usr/share/veraison-cocli/TA
    • 参照値: /usr/share/veraison-cocli/RV
    エンドースメント・ファイルには、適用されるシェイプに従って名前が付けられます。
    ノート

    veraison-cocliパッケージを更新して、最新のエンドースメント値を取得します。
  4. cocli corim submitコマンドを実行して、検証サーバーでの承認をプロビジョニングします。

    各承認について、TrustAnchor CBORファイルへのパスおよび参照値CBORファイルへのパスを指定します。エンドースメントをプロビジョニングするスクリプトについては、次の例を参照してください。

自動推薦プロビジョニング

次のbashスクリプトは、ドキュメント化された手順に基づいて最新のエンドースメントを使用してエンドースメントのプロビジョニングを自動化するサンプル・アプローチを提供します。このスクリプトは、cronジョブまたはsystemdタイマーとして実行します。

#!/bin/bash
sudo dnf update -y veraison-cocli

if [ $# -eq 0 ]; then
    echo "Error: Server address is required." >&2
    echo "Usage: $0 <server-IP-or-hostname>" >&2
    exit 1
fi

VERAISON_SERVER="$1"

for file in /usr/share/veraison-cocli/TA/*.cbor; do
        cocli corim submit --corim-file=$file --api-server="https://$VERAISON_SERVER:9443/endorsement-provisioning/v1/submit"\
        --media-type="application/corim-unsigned+cbor; profile=\"https://amd.com/ark\""
done

for file in /usr/share/veraison-cocli/RV/*.cbor; do
        cocli corim submit --corim-file=$file --api-server="https://$VERAISON_SERVER:9443/endorsement-provisioning/v1/submit"\
        --media-type="application/corim-unsigned+cbor; profile=\"tag:amd.com,2024:snp-corim-profile\""
done                         

スクリプトを起動するには、次の構文を使用します。

sh ./provision.sh <veraison-server-ip>

前述の<veraison-server-IP>はサーバーのIPアドレスです。例:

sh provision.sh localhost

リライイング・パーティからのアテステーションの実行

リモート・アテステーションは、リライイング・パーティから実行され、アテスタ・ホストによって行われた証拠または請求が有効かどうかを判断します。検証は検証者によって実行されます。すべての相互作用は、アテスタ・ホストおよびベリファイア・サーバーで実行されているサービスに対してREST APIエンドポイントを使用して実行されます。

アテステーションは、そのホストでワークロードを実行する前にアテスタ・ホストを検証する必要があるリライイング・パーティによって実行されます。リライイング・パーティは、一連のREST APIコールを使用してエビデンスを収集し、エビデンスを評価し、レポートを返すことで、リモート・アテステーションを実行します。このプロセスは、次の3つのAPIコールで構成されます。

  1. 検証サーバー上でチャレンジ・レスポンス・セッションを設定し、検証トークン(nonce)を取得して、特定のアテステーション・レポートにエビデンスを結び付けるために使用できます。
  2. システムが実行環境のために作成している請求について、アテスタ・ホストから証拠を取得します。
  3. 検証用のエビデンスをベリファイア・サーバーに提供し、エビデンスが有効で、アテスタ・ホストが信頼できるかどうかを示すレポートを取得します。

APIコールと一般的なアプローチおよび例について説明します。リライイング・パーティは、必要に応じて検証を実行するためにこれらのAPIコールをコード化するため、リクエストおよびレスポンス評価の例は、説明のみを目的としています。

用語

説明されているAPIインタラクションでは、さらに説明が必要な用語がいくつか使用されています。

アテスタ・ホスト・ベースURI
ベースURIには、スキームと完全なURIの権限部分が含まれ、権限にはサービスがリスニングしているホスト名とポート番号が含まれます。アテスタ・ホストでveraison-ratsdサービスを実行する場合、サービスはTCPポート8895をリスニングするため、アテスタ・ホスト・ベースURIは次のようになります。
https://instance.example.com:8895
チャレンジ・レスポンス・セッション

アテステーションは単一のチャレンジ・レスポンス・セッションとして実行され、セッション内の参加者はトークンとしてnonceを使用して、各参加者によって返される情報が同じセッションに属し、信頼できることを確認します。セッションには、アテステーション・プロセスの様々なステージの追跡に使用されるセッションIDも割り当てられます。チャレンジ・レスポンス・セッションが作成されると、セッションIDがロケーション・ヘッダーとして返されます。

EATアテステーション結果

EAT (Entity Attestation Token)アテステーション結果(EAR)は、JSON Web Token (JWT)で、シリアライズされたbase64エンコード形式でアテステーションの結果を記述する値が含まれています。形式については、https://datatracker.ietf.org/doc/draft-ietf-rats-ear/で詳しく説明します。EATアテステーション結果は、リライイング・パーティがアテスタ・ホストを信頼できるかどうかを判断するために使用されます。

ノンス

nonce("number used once")は、暗号通信で1回のみ使用されるランダムまたは擬似乱数の値です。nonceは通常、リプレイ攻撃を防ぐために使用され、攻撃者は以前に有効なメッセージまたは認証トークンを再利用しようとします。

nonceは、アテスターから提供された証拠が新鮮で改ざんされていないことを確認するために使用されます。ベリファイアはnonceを生成し、それをアテスターに送信し、エビデンスにnonceを含めます。その後、検証者は、nonceが生成したnonceと一致することを確認することで、エビデンスが本物であることを検証できます。

検証サーバー・ベースURI
ベースURIには、スキームと完全なURIの権限部分が含まれ、権限にはサービスがリスニングしているホスト名とポート番号が含まれます。ベリファイア・サーバーの場合、veraison-servicesを実行すると、サービスはTCPポート8443でリスニングするため、ベリファイア・サーバーのベースURIは次のようになります。
https://veraison-services.example.com:8443

チャレンジ・レスポンス・セッションの作成

リモート・アテステーションのチャレンジ・レスポンス・セッションを作成するためのAPIコール。

要求

チャレンジ・レスポンス・セッションを作成するには、ベリファイア・サーバーのベースURIの次のエンドポイントにPOSTリクエストを送信します。

POST /challenge-response/v1/newSession

POSTリクエストには、次の相互に排他的なGET変数を含めることができます。

  • nonce: 事前生成されたURLセーフなnonce。次のコマンドを実行してnonceを生成できます。
    nonce=$(openssl rand 64 | openssl base64 | tr '+/' '-_' | tr -d '=' | head -c 64)
  • nonceSize: 64バイトのnonceの場合は64に設定することをお薦めします。サービスでnonceを生成する必要がある場合は、このオプションを使用します。nonceはレスポンス本文で返されますが、返されたnonceはURLセーフではなく、チャレンジ・レスポンス・セッション中に他のリクエストで使用するためにクリーンアップする必要があることに注意してください。

応答

レスポンスには、ベリファイア・サーバーとの他の相互作用を実行するときにセッションを追跡するために使用されるロケーション・ヘッダー・エントリが含まれます。

location: session/657f1750-7916-11f0-a190-333334633039

レスポンス本文には、nonce、expiry timeおよび受け入れられる形式のリストが含まれます。例:

{
 "status": "waiting",
 "nonce":  "oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg==",
 "expiry": "2025-08-13T19:13:24.96426094Z",
 "accept": [
     "application/vnd.parallaxsecond.key-attestation.tpm",
     "application/psa-attestation-token",
     "application/eat+cwt; eat_profile=\"tag:psacertified.org,2023:psa#tfm\"",
     "application/vnd.veraison.tsm-report+cbor",
     "application/vnd.enacttrust.tpm-evidence",
     "application/eat-cwt; profile=\"http://arm.com/psa/2.0.0\"",
     "application/eat+cwt; eat_profile=\"tag:psacertified.org,2019:psa#legacy\"",
     "application/pem-certificate-chain",
     "application/vnd.veraison.configfs-tsm+json",
     "application/vnd.parallaxsecond.key-attestation.cca",
     "application/eat+cwt; eat_profile=\"tag:github.com,2025:veraison/ratsd/cmw\"",
     "application/eat-collection; profile=\"http://arm.com/CCA-SSD/1.0.0\""
 ]
}                    

エビデンスがベリファイア・サーバーに発行されるときに使用するレスポンス・ヘッダーのlocation値を格納します。

この問合せのnonceを事前に生成しなかった場合は、nonceをHTTPレスポンス本文に格納します。nonceは、アテスタからエビデンスを収集するときに使用され、アテスタによって返されたアテステーション・レポートに表示されます。

重要

レスポンスで返されたnonceはURLセーフではありません。JSONレスポンスに含まれるようにnonceを使用する場合は、他のリクエスト・ペイロードで使用する前にそれをクリーンアップしてください。たとえば、次のコマンドを実行します。

echo "oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg==" | tr '+/' '-_' | tr -d '='

リクエストの例

次のコマンド例は、新しいセッションのnonceを生成する方法を示しています。

curl -X POST https://veraison-services.example.com:8443/challenge-response/v1/newSession?nonceSize=64

出力は次のようになります:

HTTP/2 201 
content-type: application/vnd.veraison.challenge-response-session+json
location: session/657f1750-7916-11f0-a190-333334633039
content-length: 837
date: Thu, 14 Aug 2025 13:55:54 GMT
                            
{"status":"waiting",
 "nonce":"oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg==",
 "expiry":"2025-08-14T13:58:24.75546442Z","accept":["application/vnd.parallaxsecond.key-attestation.cca",
 "application/eat+cwt; eat_profile=\"tag:github.com,2025:veraison/ratsd/cmw\"",
 "application/eat-collection; profile=\"http://arm.com/CCA-SSD/1.0.0\"","application/vnd.parallaxsecond.key-attestation.tpm",
 "application/psa-attestation-token","application/eat+cwt; eat_profile=\"tag:psacertified.org,2023:psa#tfm\"",
 "application/vnd.veraison.tsm-report+cbor","application/vnd.enacttrust.tpm-evidence",
 "application/eat-cwt; profile=\"http://arm.com/psa/2.0.0\"","application/eat+cwt; eat_profile=\"tag:psacertified.org,2019:psa#legacy\"",
 "application/pem-certificate-chain","application/vnd.veraison.configfs-tsm+json"]}

アテスタからの証拠の取得

アテスタ・ホスト上のveraison-ratsdサービスからエビデンスを取得するためのAPIコール。

要求

veraison-ratsdサービスからエビデンスを取得するには、アテスタ・ホスト・ベースURIの次のエンドポイントにPOSTリクエストを送信します。

POST /ratsd/chares

リクエスト本文には、チャレンジ・レスポンス・セッションで使用されるURLセーフ・ノンスが含まれている必要があります。

{
  "nonce": "oWTtIjdJf8CR-ASRW70UOzeFHj5SdlFLBqan10pardkBK_7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg"
}

応答

レスポンスには、前のステップで指定した形式のエビデンスが含まれます。

{"cmw":"eyJfX2Ntd2NfdCI6InRhZzpnaX29uIiwiZXlKaGRYaGliRzl..9pSm1ZV3RsWEc0aWZRIl19",
 "eat_nonce":"TUlEQk5IMjhpaW9pc2pQeXh4eHh4eHh4eHh4eHh4eHhNSURCTkgyOGlpb2lzalB5eHh4eHh4eHh4eHh4eHh4eA",
 "eat_profile":"tag:github.com,2024:veraison/ratsd"}                        

cmwキーの値は、JSON Webトークン(JWT)としてのエビデンス・クレームのシリアライズです。この問合せに対するレスポンスの完全な出力を格納し、ベリファイア・サーバーによる検証のためにそのまま送信できます。

リクエストの例

次のコマンド例は、セッションnonceを指定することによって、アテスタホストからエビデンスを取得する方法を示しています。

curl -X POST http://instance.example.com:8895/ratsd/chares \
 -H "Content-type: application/vnd.veraison.chares+json" \
 -d '{"nonce": "oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg=="}' \ 
 -o evidence

このコマンドからの出力は、evidenceという名前のファイルに格納されます。このファイルは、ベリファイアからアテステーション結果のリクエストを送信するときに使用できます。

エンド・ツー・エンドの例は、veraison-ratsdバージョン1.0.9以降で使用可能な/usr/share/doc/veraison-ratsd/examples/attestation-sample.pyを参照してください。

ベリファイアからのアテステーション結果の取得

ベリファイアのveraison-servicesからアテステーション結果を取得するためのAPIコール。

要求

veraison-servicesからアテステーション結果を取得するには、ベリファイア・ホストURI権限の次のエンドポイントにPOSTリクエストを送信します。

POST /challenge-response/v1/<session_location>

リクエスト・エンドポイントには、nonceがベリファイア・サーバーによって生成されたときに元のチャレンジ・レスポンスのヘッダーに返されるsession_locationが含まれます。「アテスタからのエビデンスの取得」「チャレンジ・レスポンス・セッションの作成」を参照してください。

リクエスト・ヘッダーには、アテスタ・ホスト・ベースURIと一致するHost値、エビデンスが収集された形式に設定されたContent-Type、および目的のレスポンス形式を表すAccept値が含まれます。例:

Host: instance.example.com:8443
Content-Type: application/eat+cwt; eat_profile="tag:github.com,2025:veraison/ratsd/cmw"            
Accept: application/vnd.veraison.challenge-response-session+json

リクエスト本文ペイロードには、veraison-ratsdサービスを実行しているアテスタから取得したエビデンスが含まれている必要があります。Get Evidence From an Attesterを参照してください。

応答

応答にはエビデンスとEATアテステーションの結果が含まれます。

{
 "status": "complete",
 "nonce": "oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg==",
 "expiry": "2025-08-14T16:44:22.733250762Z",
 "accept": [
  "application/eat-cwt; profile=\"http://arm.com/psa/2.0.0\"",
  "application/eat+cwt; eat_profile=\"tag:psacertified.org,2019:psa#legacy\"",
  "application/pem-certificate-chain",
  "application/vnd.veraison.configfs-tsm+json",
  "application/vnd.parallaxsecond.key-attestation.cca",
  "application/eat+cwt; eat_profile=\"tag:github.com,2025:veraison/ratsd/cmw\"",
  "application/eat-collection; profile=\"http://arm.com/CCA-SSD/1.0.0\"",
  "application/vnd.parallaxsecond.key-attestation.tpm",
  "application/psa-attestation-token",
  "application/eat+cwt; eat_profile=\"tag:psacertified.org,2023:psa#tfm\"",
  "application/vnd.veraison.tsm-report+cbor",
  "application/vnd.enacttrust.tpm-evidence"
 ],
 "evidence": {
  "type": "application/eat+cwt; eat_profile=\"tag:github.com,2025:veraison/ratsd/cmw\"",
  "value": "eyJjbXciOiJleUpmWDJOdGQyTmZkQ0k2SW5SaFp6cG5hWF...DI0OnZlcmFpc29uL3JhdHNkIn0="
 },
 "result": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ...t4sZ_dmpPK-BX8tnCmdmCyqoMUg"
}

リクエストの例

次のリクエスト例では、Get Evidence From an Attesterのサンプル・リクエストから取得されたevidenceという名前のファイルからデータ・ペイロードがロードされます。curlコマンドを使用する場合、ファイルからデータをロードするには、ファイル名の前に@文字を使用する必要があります。

curl -X POST https://veraison-services.example.com:8443/challenge-response/v1/session/94e9ea97-792d-11f0-a190-333334633039 \
 -H "Host: instance.example.com:8443" \
 -H "content-type: application/eat+cwt; eat_profile=\"tag:github.com,2025:veraison/ratsd/cmw\"" \
 -H "accept: application/vnd.veraison.challenge-response-session+json" \
 --data "@evidence"

レスポンス評価の例

指定された問合せからのレスポンスの場合は、任意のJSON Webトークン・ビューアまたはライブラリを使用して結果をデコードし、標準のJSON形式にデコードできます。デコードされた出力は次のようになります。

{
 "ear.verifier-id": {
   "build": "N/A",
   "developer": "Veraison Project"
 },
 "eat_nonce": "oWTtIjdJf8CR+ASRW70UOzeFHj5SdlFLBqan10pardkBK/7lOoSLMsdvhMF0DcqTpgg4nN08Ql2MWAmLFy97cg==",
 "eat_profile": "tag:github.com,2023:veraison/ear",
 "iat": 1755189767,
 "submods": {
   "SEVSNP": {
    "ear.appraisal-policy-id": "policy:SEVSNP",
    "ear.status": "affirming",
    "ear.trustworthiness-vector": {
        "configuration": 0,
        "executables": 0,
        "file-system": 0,
        "hardware": 2,
        "instance-identity": 0,
        "runtime-opaque": 2,
        "sourced-data": 0,
        "storage-opaque": 0
     },
    "ear.veraison.annotated-evidence": {
      "environment": {
        "class": {
          "id": {
            "type": "oid",
            "value": "1.3.6.1.4.1.3704.3.2"
          }
        }
       },
      "measurements": [
        {
         ...
        }
      ]
     }
    }
  }
}

SEV-SNP信頼性のインスタンスの評価は、SEVSNPサブモジュールの結果に重点を置いています。ear.statusを評価して、アテスタ・ホストが信頼できる実行環境で実行されているかどうかを決定できます。「確認」とマークされている場合、ホストは請求の評価に基づいて信頼されます。

ear.trustworthiness-vectorは、ベリファイアによって検証された様々な要求の結果を示します。

ear.trustworthiness-vector
ear.trustworthiness-vector 意味
0 要求に対してアサーションが行われず、検証者が評価スコアを指定していません。
1 証拠には未知の要素が含まれており、ベリファイアの評価を阻害した。
2 審査員は請求を確定する。
>2 2より大きい値は、ポリシーを満たすための様々なレベルの障害を示し、99の値は完全な障害です。
この出力例では、SEV-SNPはハードウェア要求と実行時不透明度についてのみテストされています。これらの各ケースで2の結果は次のようになります。
  • hardware: アテスタは、ハードウェアおよびファームウェアの検証に合格し、これらは本物であることを示すために必要です。
  • runtime-opaque: アテスタの実行中のターゲット環境およびアテスト環境は暗号化され、信頼できる実行環境内でOS、仮想マシン・マネージャおよびピア・アプリケーションに対して不透明です。