認証 (attestation)

VPC の IBM Cloud Hyper Protect Virtual Servers は非推奨。 2026年2月28日現在、新しいインスタンスを作成することはできない。 既存のインスタンスは、2027年2月20日までサポートされます。 その日付にまだ存在するインスタンスはすべて削除されます。 IBM Confidential Computing Container Runtime(旧称: Hyper Protect Virtual Servers )または IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions(旧称:Hyper Protect Container Runtime for Red Hat Virtualization Solutions )を使用して、ワークロードを再デプロイできます。 データ移行については、 移行ガイドを 参照してください。 詳しくは、 サービス廃止のお知らせを ご覧ください。

認証は、仮想インスタンスの作成時にデフォルトで開始されるプロセスであり、仮想サーバーインスタンスイメージが実際にによって構築されたものであり、かつ改変 IBM されていないことを保証します。 このプロセスは、情報も提供し、デプロイメント時にインスタンスに提供されるすべてのデータの検証を可能にします。

IBM Hyper Protect Container Runtime イメージを使用して仮想サーバー・インスタンスを作成する場合、イメージは、暗号化によって保護され、 IBM Secure Execution によって署名された初期ファイル・システムを使用します。 詳しくは、 Confidential computing with LinuxONE を参照してください。 認証プロセスについて詳しくは、この ビデオ を参照してください。

ブート・プロセスでは、ルート・ディスクを確実に保護するために、固有のルート・ディスク暗号鍵が作成されます。 認証を実行するために、仮想サーバー・インスタンス・イメージには、ビルド時の認証署名鍵とルート区画のハッシュが含まれています。 ブート・プロセスは、ルート区画を検証します。 ルート区画のハッシュが一致しない場合、ブート前にイメージが変更されたと想定されるため、ブート・プロセスは続行されません。 認証署名鍵は、 Hyper Protect Crypto Servicesで保持されている IBM ルート鍵によって署名されたランダム RSA 4 K 鍵です。 IBM ルート鍵は Digicert によって署名されます。

クラウドでの仮想サーバー・インスタンスのデプロイメント中に、認証レコードが作成されます。 以下の項目のハッシュが含まれています。

  • 元の基本イメージ
  • 最初のブートの時点でのルート・パーティション
  • ビルド時のルート・パーティション
  • クラウド初期化オプション

認証レコードは、認証キーによって署名されます。 追加の保護層として、デプロイメント時に公開鍵を提供できます。この公開鍵に対して、認証レコードが暗号化されます。 この公開鍵のハッシュが認証記録に追加され、その記録はコンプライアンス・オーソリティのみが閲覧できるようになる。 そのハッシュによって、期待される権威を簡単に特定することができる。

インスタンスにワークロードをアップロードする前に、認証レコードを検証する必要があります。 インスタンスが作成された後、作成されたインスタンス内の認証レコードを検証できます。 インスタンスには、 /var/hyperprotect ディレクトリーへのアクセス権限が必要です。 その場合は、以下の手順に従ってください。

  • 認証レコードは、認証署名鍵によって署名されます。
  • 認証署名鍵は、 IBM 中間証明書によって確認できます。 のIBM中間証明書は、DigiCert,これはルート証明書によって証明されますDigiCert,こうして信頼の連鎖が完成します。

暗号化証明書と認証証明書は、 IBM 中間証明書によって署名され、 IBM Digicert 中間証明書によって署名される。 IBM Digicert 中間証明書は、 DigiCert 信頼されるルート G4 によって署名される。 証明書の詳細については、 DigiCert Trusted Root Authority Certificatesを 参照のこと。

認証レコードとハッシュを検証するには、以下の手順を使用します。

  • VPC インスタンスの Hyper Protect Virtual Servers から、認証レコード se-checksums.txt および署名ファイル se-signature.bin を取得します。 これを行うために、認証レコードと署名ファイルを提供するコンテナーを実装できます。 認証レコードと署名ファイルが、 /var/hyperprotect ディレクトリー内のコンテナーで使用できるようになります。
  • IBM 認証証明書を取得します。 以下の表に、イメージのバージョンに基づく認証証明書の有効期限日付をリストします。

2025年3月25日以降、証明書リンクが変更される。

証明書の有効期限
イメージのバージョン 証明書リンク 有効期限日付
ibm-hyper-protect-container-runtime-1-0-s390x-29 証明書 2027年7月6日
ibm-hyper-protect-container-runtime-1-0-s390x-28 証明書 2027年6月15日
ibm-hyper-protect-container-runtime-1-0-s390x-26 証明書 2027年2月24日
ibm-hyper-protect-container-runtime-1-0-s390x-25 証明書 2026年11月26日
  • ここ の手順に従って、認証証明書を検証します。

  • 以下のコマンドを使用して、認証証明書から認証公開鍵を抽出する:

    openssl x509 -pubkey -noout -in ibm-hyper-protect-container-runtime-1-0-s390x-29-attestation.crt > contract-public-key.pub
    
  • 認証レコードの署名を検証します。

    openssl sha256 -verify contract-public-key.pub -signature se-signature.bin se-checksums.txt
    

    署名検証は、 暗号化解除された認証ファイル で行う必要があります。

  • これで、認証レコードからのハッシュを検証に使用できます。

認証レコードを暗号化するための公開鍵を指定した場合は、以下のスクリプトがレコードの暗号化解除に役立つことがあります。

  #!/bin/bash
  #
  # Example script to decrypt attestation document.
  #
  # Usage:
  #   ./decrypt-attestation.sh <rsa-priv-key.pem> [file]
  #
  # Token Format:
  #   hyper-protect-basic.<ENC_AES_KEY_BASE64>.<ENC_MESSAGE_BASE64>
  RSA_PRIV_KEY="$1"
  if [ -z "$RSA_PRIV_KEY" ]; then
      echo "Usage: $0 <rsa-priv-key.pem>"
      exit 1
  fi
  INPUT_FILE="${2:-se-checksums.txt.enc}"
  TMP_DIR="$(mktemp -d)"
  #trap 'rm -r $TMP_DIR' EXIT
  PASSWORD_ENC="${TMP_DIR}/password_enc"
  MESSAGE_ENC="${TMP_DIR}/message_enc"
  # extract encrypted AES key and encrypted message
  cut -d. -f 2 "$INPUT_FILE"| base64 -d > "$PASSWORD_ENC"
  cut -d. -f 3 "$INPUT_FILE"| base64 -d > "$MESSAGE_ENC"
  # decrypt password
  PASSWORD=$(openssl pkeyutl -decrypt -inkey "$RSA_PRIV_KEY" -in "$PASSWORD_ENC")
  # decrypt message
  echo -n "$PASSWORD" | openssl aes-256-cbc -d -pbkdf2 -in "$MESSAGE_ENC" -pass stdin --out se-checksums.txt

docker コンテナーの場合は、docker コンテナーに /var/hyperprotect をマウントすることで decrypt-attestation.sh ファイルにアクセスできます。 以下に例を示します。

 volumes:
      - "/var/hyperprotect/:/var/hyperprotect/:ro"

Podman コンテナーの場合、 decrypt-attestation.sh ファイルにアクセスするには、 Podman コンテナーに /var/hyperprotect をマウントします。 以下に例を示します。

 volumeMounts:
     - name: attestation
       readOnly: true
       mountPath: /var/hyperprotect:Z,U

認証文書です。

認証文書は、VPC インスタンスの Hyper Protect Virtual Servers 内の /var/hyperprotect/se-checksums.txt で入手できます。 その他の関連ファイルも同じディレクトリーにあります。

以下の情報は /var/hyperprotect/ :

​/var/hyperprotect
/var/hyperprotect/
|-- certificate_expiry_date.json 
|-- cidata
|   |-- meta-data
|   |-- vendor-data
|-- se-checksums.txt
|-- se-signature.bin
|-- se-version
|-- user-data.decrypted

チェックサムはメッセージ・ダイジェストの SHA256、次の Linux コマンドライン・ユーティリティを使って計算できる:

sha256sum <file>

認証文書の例を以下のスニペットに示します。

26.7.1
Machine Type/Plant/Serial: 8562/02/4C598
Image age: 10 days since creation.
Encryption Certificate valid until: Jul 06 06:44:41 2027 UTC
Attestation Certificate valid until: Jul 06 12:28:59 2027 UTC
5df88e43e3b0819f05c4a2d90253f26fe72308c7102f1cafe60cf2902f26cc06 certificate_expiry_date.json
44d9ccbb009ba581a391ec569f4cce97b365c5ca63c47574c3a3168ddb4115b3 root.tar.gz
87cba102a31c9131a5e04c4d555ef93ff4294aa28faedecb7b94bb726e6a9f4a baseimage
fe40ba8362e570e5caa533b7cbed3cb5f8fa67ed2e7022a678c1c06760821c8f sbom
65b99110547298d3f6fec2888664dcf74fdf53b52e27fa2f9e4e97c274055ac2 /dev/disk/by-label/cidata
f95185cc25937c43d0b912cfcae1934996785f5ecbeed07c1cca3cb8cefd4e0e cidata/meta-data
98a916c28414671a04623ee1a6902dda41777fbb0cd56ebb5ab3c5cb399bc163 cidata/user-data
3bee754bb0c58bb691242b0d1787bc5b1f71d22885d9444b581e4b51adecac0d cidata/vendor-data
6c338061a8a39a9d0d6ca6e8c0ee5b758741b01484abd7403e1481ae75ed1ca1 contract:workload
7f326b4f780652d77e7d2d22631b9da7ec000b97f5363030ed1d7fab4378bb6c contract:env
d879515efa1fb1b94bf00f3e03855539d169c54f4beb4dad3fff91b39467c461 contract:attestationPublicKey

Machine Type/Plant/Serial

Machine Type/Plant/Serial は、安全な実行のためにホスト鍵文書を取得するために必要な情報である VM。 これは、安全な実行 VM が現在どのマシンで実行されているかを反映する。

baseimage

baseimage は、 IBM 内部 QEMU コピー・オン・ライト・バージョン 2 (QCOW2) ファイルです。これは、Hyper Protect Container Runtime イメージのほとんどのオペレーティング・システム・ファイルのソースとして使用されます。 これは、イネーブラー・プロセスによってイメージ・ビルド時にのみ使用されます。 イネーブラは、このソースを他の Debian パッケージとともに使用して、 root.tar.gz と暗号化されたセキュアな実行カーネルまたは「initrd」イメージを作成する。

以下は、 ibm-hyper-protect-container-runtime-1-0-s390x-29 ( baseimage )のシャスムです:

87cba102a31c9131a5e04c4d555ef93ff4294aa28faedecb7b94bb726e6a9f4a baseimage

以下は、 ibm-hyper-protect-container-runtime-1-0-s390x-28 ( baseimage )のシャスムです:

334549f6dfcf8e0e2132c0eb9a5281e9e0b335e319fe2f66158be5b524acdc48 baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-26 baseimage のシャスムである:

f8614f9f6a39302b97b0a590e14b2e64affddb0f98ef459bf0f8c7f185c98bd5 baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-25 baseimage のシャスムである:

f73df7d02327896fbda67f6e7368c3e27fe5e15b580cdfdb60e7310afeed5b75 baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-24 baseimage のシャスムである:

14d2a725746bf9a6cbf9847e09422f5a97609d03f15b373519a16015619f227d baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-23 baseimage のシャスムである:

3e13f7658ef790dbc040e90ff4f8d537c9c10da879b0b16df9e98265c7b5170a baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-22 baseimage のシャスムである:

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

以下は ibm-hyper-protect-container-runtime-1-0-s390x-21 baseimage のシャスムである:

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

root.tar.gz

root.tar.gz は、 IBM Hyper Protect Container Runtime イメージによって有効化される最終的なセキュア実行の一部であり、すべてのオペレーティング・システム・ファイルを含んでいます。 イメージの最初のパーティション(ブートパーティション)に /boot/root.tar.gz として保存されます。

以下は、 ibm-hyper-protect-container-runtime-1-0-s390x-29 ( root.tar.gz )のシャスムです。

44d9ccbb009ba581a391ec569f4cce97b365c5ca63c47574c3a3168ddb4115b3 root.tar.gz

以下は、 ibm-hyper-protect-container-runtime-1-0-s390x-28 ( root.tar.gz )のシャスムです。

692f9724bb6c6fb855d6724c903e080998997b3a8aa2350fd5cb95b1c967ea92 root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-26 root.tar.gz のシャスムである。

f700d860d931d953bffa6a7f2593ec53074a757c0184bcfbea0648de7f2b501b root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-25 root.tar.gz のシャスムである。

3c5866a25d0e64c47e56ba29238b96435c6a81933d4e19bf3bc0704c0504d16b root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-24 root.tar.gz のシャスムである。

a93839d82b98323665740a12ca2b30107bd8488e02eb411a6db6c17703b9b5cf root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-23 root.tar.gz のシャスムである。

84ae048bc5d88e99f6ec13b4c4ba3e2ffe5f10285f7dd71a65ea99eaa1838ce0 root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-22 root.tar.gz のシャスムである。

ff09f53f19d0f82ca24d4f2d5277c851516734c3d55ae7f8db47cde378a51ec9 root.tar.gz

以下は ibm-hyper-protect-container-runtime-1-0-s390x-21 root.tar.gz のシャスムである。

024ff109be23e1e4e7b9f07dc553afc60a5a93645939eedf2a936930cc8a44ae root.tar.gz

/dev/disk/by-label/cidata

/dev/disk/by-label/cidata は、 IBM Cloud® Virtual Private Cloud (VPC) によって提供される cloud-init ファイルを含む実行中のインスタンスに接続されるブロック・デバイスです。 Cloud-Init について詳しくは、 ユーザー・データ、または cloud-init の資料 を参照してください。

cidata

f95185cc25937c43d0b912cfcae1934996785f5ecbeed07c1cca3cb8cefd4e0e cidata/meta-data
98a916c28414671a04623ee1a6902dda41777fbb0cd56ebb5ab3c5cb399bc163 cidata/user-data
3bee754bb0c58bb691242b0d1787bc5b1f71d22885d9444b581e4b51adecac0d cidata/vendor-data

attestationPublicKey

attestationPublicKey は、認証文書の暗号化に使用される公開鍵である。 attestationPublicKey はユーザーデータファイルの一部である。 認証文書の暗号化は任意である。

d879515efa1fb1b94bf00f3e03855539d169c54f4beb4dad3fff91b39467c461 contract:attestationPublicKey

のシャーの計算 ​​​​​​certificate_expiry_date.json​​​​​​​​

​​​​​​certificate_expiry_date.json​​​ の sha256sum 値を計算する: ​​​​​​

  1. ディレクトリから ​certificate_expiry_date.json​​​​ ファイルを取り出す: ​​​​​​/var/hyperprotect
  2. 以下のコマンドを実行する:
    ​sha256sum certificate_expiry_date.json​​​​
    
  3. 出力内容を ​se-checksum.txt ファイルで検証する

認証文書の暗号化解除

ユーザーデータに公開RSA鍵(属性: attestationPublicKey )が含まれる場合、認証文書( se-checksums.txt )は指定された鍵で暗号化されます。 暗号化は、契約暗号化と同じプロセスで行われます。 詳しくは、 契約の暗号化 を参照してください。 パブリック RSA 鍵自体も、契約のように暗号化できます。

暗号化された認証文書は、 se-checksums.txt.enc という名前になります。

docker コンテナーの場合は、docker コンテナーに /var/hyperprotect をマウントすることで decrypt-attestation.sh ファイルにアクセスできます。 以下に例を示します。

 volumes:
      - "/var/hyperprotect/:/var/hyperprotect/:ro"

Podman コンテナーの場合、 decrypt-attestation.sh ファイルにアクセスするには、 Podman コンテナーに /var/hyperprotect をマウントします。 以下に例を示します。

 volumeMounts:
     - name: attestation
       readOnly: true
       mountPath: /var/hyperprotect:Z,U

認証フローの理解

以下の図は、監査員の観点から、デプロイメントが予期されるものであることを検証するための認証の 2 つのシナリオを示しています。 図の左側は、サード・パーティーの認証局をルートとする監査員による信頼の確立を示しています。 使用される鍵はすべて Hyper Protect Crypto Service に保持され、サード・パーティーの認証局に基づいて証明書チェーンに署名されます。 Hyper Protect で使用されるビルド環境は、 IBM Secure Execution Technology を使用して、信頼できる実行環境で実行されます。

結果として、図の最後に表示されるセキュアな実行イメージが生成されます。これは、暗号化されたセキュアな実行イメージです。 ダイアグラムの右側に、デプロイメントの検証の概要が示されます。 そのために、監査員は、 IBM Hyper Protect インスタンスの暗号化されたワークロード契約に、監査員のみが制御権を持つシークレットの公開鍵を含めます。 このようなシークレットは、Hyper Protect Crypto Service、HSM、または単なるランダム・キーなどの適切な手段によって保護される可能性があります。 IBM LinuxONE 上の Linux 用の IBM Secure Execution を通じて提供される信頼された実行環境で実行される Hyper Protect ブートローダのみが、 IBM Cloud Hyper Protect Virtual Servers IBM Cloud® Virtual Private Cloud 用の安全な実行イメージを実行できます。 ブート・ローダーには、契約を暗号化解除するための秘密が含まれています。

ブート時に、いくつかのコンポーネントのハッシュとコードの測定が取得され、認証レコードに追加されます。 この認証レコードをさらに保護するために、レコードは監査員が提供した公開鍵を使用して暗号化されます。 これにより、監査員のみが認証レコードを復号することができ、エンクレーブにデプロイされたワークロードが、VPC インスタンスの Hyper Protect Virtual Servers にデプロイされることが予期されるワークロードの予期される改ざんされていないバージョンであることを検証できます。

caption-side=bottom"
認証プロセスを示す図※認証プロセスを示す
※認証プロセス※認証プロセス

次のステップ