Attestierung

Die IBM Cloud Hyper Protect Virtual Servers für VPC ist veraltet. Ab dem 28. Februar 2026 können Sie keine neuen Instanzen mehr anlegen. Bestehende Instanzen werden bis zum 20. Februar 2027 unterstützt. Alle Instanzen, die zu diesem Zeitpunkt noch existieren, werden gelöscht. Sie können Ihre Workloads mit IBM Confidential Computing Container Runtime(früher bekannt als Hyper Protect Virtual Servers ) oder IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions(früher bekannt als Hyper Protect Container Runtime for Red Hat Virtualization Solutions) neu bereitstellen. Informationen zur Datenmigration finden Sie in der Anleitung zur Migration. Weitere Informationen finden Sie in der Ankündigung zur Abschaffung des Dienstes.

Die Beglaubigung ist ein Prozess, der standardmäßig bei der Erstellung einer virtuellen Instanz beginnt und sicherstellt, dass das Image der IBM virtuellen Serverinstanz tatsächlich von erstellt und nicht verändert wurde. Dieser Prozess stellt auch Informationen bereit und ermöglicht die Überprüfung aller Daten, die der Instanz zum Zeitpunkt der Implementierung zur Verfügung gestellt wurden.

Wenn Sie eine virtuelle Serverinstanz mithilfe des IBM Hyper Protect Container Runtime-Image erstellen, verwendet das Image ein anfängliches Dateisystem, das durch Verschlüsselung geschützt und von IBM Secure Execution signiert ist. Weitere Informationen finden Sie unter Confidential computing with LinuxONE. Weitere Informationen zum Attestierungsprozess finden Sie in diesem Video.

Der Bootprozess erstellt einen eindeutigen Rootplattenverschlüsselungsschlüssel, um den Schutz der Rootplatte sicherzustellen. Zum Ausführen der Attestierung enthält das Image der virtuellen Serverinstanz einen Attestierungssignierschlüssel und den Hashwert der Rootpartition zur Erstellungszeit. Der Bootprozess validiert die Rootpartition. Wenn der Hashwert der Rootpartition nicht übereinstimmt, wird der Bootprozess nicht fortgesetzt, da er davon ausgeht, dass das Image vor dem Booten geändert wurde. Der Attestierungssignierschlüssel ist ein zufälliger RSA-4-K-Schlüssel, der von einem IBM Rootschlüssel signiert wird, der in Hyper Protect Crypto Servicesverwaltet wird. Der Rootschlüssel IBM wird von Digicert signiert.

Während der Implementierung der virtuellen Serverinstanz in der Cloud wird ein Attestierungsdatensatz erstellt. Es enthält Hashwerte der folgenden Elemente:

• Das ursprüngliche Basisimage
• Die Root-Partition zum Zeitpunkt des ersten Bootvorgangs.
• Die Rootpartition zur Buildzeit
• Die Optionen für die Cloudinitialisierung

Der Attestierungsdatensatz wird vom Attestierungsschlüssel signiert. Als zusätzliche Schutzebene können Sie während der Bereitstellung einen öffentlichen Schlüssel bereitstellen, für den der Attestierungsdatensatz verschlüsselt wird. Der Hash dieses öffentlichen Schlüssels wird dem Bescheinigungsdatensatz hinzugefügt, so dass der Datensatz nur von der Compliance-Behörde eingesehen werden kann. Die erwartete Behörde kann anhand dieses Hashes leicht identifiziert werden.

Bevor Sie eine Workload in Ihre Instanz hochladen, müssen Sie den Attestierungsdatensatz validieren. Nach der Erstellung einer Instanz können Sie den Attestierungsdatensatz in der erstellten Instanz validieren. Ihre Instanz muss Zugriff auf das Verzeichnis /var/hyperprotect haben. Ist dies der Fall, gehen Sie wie folgt vor:

• Der Attestierungsdatensatz wird mit dem Signierschlüssel der Attestierung signiert.
• Der Signierschlüssel für die Attestierung kann durch das IBM Zwischenzertifikat bestätigt werden. DerIBM Das Zwischenzertifikat ist unterzeichnet vonDigiCert, nachgewiesen durch das Stammzertifikat vonDigiCert, Dadurch wird die Vertrauenskette geschlossen.

Die Verschlüsselungs- und Bescheinigungszertifikate werden von dem IBM Zwischenzertifikat signiert, das von dem IBM Digicert Zwischenzertifikat signiert wird. Das IBM Digicert-Zwischenzertifikat ist von DigiCert Trusted Root G4 signiert. Weitere Informationen zu den Zertifikaten finden Sie unter DigiCert Trusted Root Authority Certificates.

Gehen Sie wie folgt vor, um den Attestierungsdatensatz und die Hashwerte zu validieren:

• Rufen Sie den Attestierungsdatensatz se-checksums.txt und die Signaturdatei se-signature.bin von Ihrer Hyper Protect Virtual Servers for VPC-Instanz ab. Dazu können Sie Ihren Container implementieren, um den Attestierungsdatensatz und die Signaturdatei bereitzustellen. Der Attestierungsdatensatz und die Signaturdatei werden Ihrem Container im Verzeichnis /var/hyperprotect zur Verfügung gestellt.
• Rufen Sie das Attestierungszertifikat IBM ab. In der folgenden Tabelle sind die Ablaufdaten für die Attestierungszertifikate basierend auf der Version des Image aufgelistet.

Ab dem 25. März 2025 werden die Zertifikatsverknüpfungen geändert.

• Überprüfen Sie das Attestierungszertifikat, indem Sie die Anweisungen hier befolgen.

• Extrahieren Sie den öffentlichen Schlüssel der Bescheinigung aus dem Bescheinigungszertifikat mit dem folgenden Befehl:

  openssl x509 -pubkey -noout -in ibm-hyper-protect-container-runtime-1-0-s390x-29-attestation.crt > contract-public-key.pub
  

• Überprüfen Sie die Signatur des Attestierungsdatensatzes:

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

  Die Signaturprüfung muss für eine entschlüsselte Attestierungsdatei durchgeführt werden.

• Sie können jetzt die Hashwerte aus dem Attestierungsdatensatz zur Validierung verwenden.

Falls Sie einen öffentlichen Schlüssel für die Verschlüsselung des Attestierungsdatensatzes angegeben haben, kann das folgende Script beim Entschlüsseln des Datensatzes hilfreich sein.

  #!/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

Im Falle eines Docker-Containers kann auf die Datei decrypt-attestation.sh zugegriffen werden, indem /var/hyperprotect im Docker-Container angehängt wird. Beispiel:

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

Bei einem Podman-Container kann auf die Datei decrypt-attestation.sh zugegriffen werden, indem /var/hyperprotect im Podman-Container angehängt wird. Beispiel:

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

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

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

87cba102a31c9131a5e04c4d555ef93ff4294aa28faedecb7b94bb726e6a9f4a baseimage

334549f6dfcf8e0e2132c0eb9a5281e9e0b335e319fe2f66158be5b524acdc48 baseimage

f8614f9f6a39302b97b0a590e14b2e64affddb0f98ef459bf0f8c7f185c98bd5 baseimage

f73df7d02327896fbda67f6e7368c3e27fe5e15b580cdfdb60e7310afeed5b75 baseimage

14d2a725746bf9a6cbf9847e09422f5a97609d03f15b373519a16015619f227d baseimage

3e13f7658ef790dbc040e90ff4f8d537c9c10da879b0b16df9e98265c7b5170a baseimage

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

44d9ccbb009ba581a391ec569f4cce97b365c5ca63c47574c3a3168ddb4115b3 root.tar.gz

692f9724bb6c6fb855d6724c903e080998997b3a8aa2350fd5cb95b1c967ea92 root.tar.gz

f700d860d931d953bffa6a7f2593ec53074a757c0184bcfbea0648de7f2b501b root.tar.gz

3c5866a25d0e64c47e56ba29238b96435c6a81933d4e19bf3bc0704c0504d16b root.tar.gz

a93839d82b98323665740a12ca2b30107bd8488e02eb411a6db6c17703b9b5cf root.tar.gz

84ae048bc5d88e99f6ec13b4c4ba3e2ffe5f10285f7dd71a65ea99eaa1838ce0 root.tar.gz

ff09f53f19d0f82ca24d4f2d5277c851516734c3d55ae7f8db47cde378a51ec9 root.tar.gz

024ff109be23e1e4e7b9f07dc553afc60a5a93645939eedf2a936930cc8a44ae root.tar.gz

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

d879515efa1fb1b94bf00f3e03855539d169c54f4beb4dad3fff91b39467c461 contract:attestationPublicKey

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

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

Informationen zu Attestierungsabläufen

Das folgende Diagramm zeigt zwei Szenarien für die Attestierung aus Sicht des Prüfers, um zu überprüfen, ob die Implementierung erwartet wird. Die linke Seite des Diagramms zeigt die Vertrauensbildung durch den Prüfer, der auf einer Zertifizierungsstelle eines anderen Anbieters verwurzelt ist. Jeder verwendete Schlüssel wird in einem Hyper Protect Crypto Service aufbewahrt und in einer Zertifikatskette signiert, die auf der Berechtigung eines anderen Anbieters basiert. Die von Hyper Protect verwendete Buildumgebung wird in einer vertrauenswürdigen Ausführungsumgebung mit IBM Secure Execution Technology ausgeführt.

Das Ergebnis ist ein sicheres Ausführungsimage, das am Ende des Diagramms angezeigt wird. Dies ist ein verschlüsseltes sicheres Ausführungsimage. Rechts neben dem Diagramm wird die Validierung der Implementierung beschrieben. Dazu schließt der Prüfer in den verschlüsselten Workloadvertrag der IBM Hyper Protect-Instanz den öffentlichen Schlüssel eines geheimen Schlüssels ein, den nur der Prüfer steuern kann. Solche geheimen Schlüssel können mit geeigneten Mitteln wie einem Hyper Protect Crypto Service, einem HSM oder nur einem Zufallsschlüssel geschützt werden. Nur der Hyper Protect Bootloader, der in der vertrauenswürdigen Ausführungsumgebung ausgeführt wird, die durch IBM Secure Execution für Linux auf IBM LinuxONE bereitgestellt wird, kann das Secure Execution Image von IBM Cloud Hyper Protect Virtual Servers für IBM Cloud® Virtual Private Cloud ausführen. Das Bootladeprogramm enthält den geheimen Schlüssel zum Entschlüsseln des Vertrags.

Beim Booten werden mehrere Hashes von Komponenten und Codekennzahlen ausgeführt und zum Attestierungsdatensatz hinzugefügt. Zum weiteren Schutz dieses Attestierungsdatensatzes wird der Datensatz mit dem öffentlichen Schlüssel verschlüsselt, den der Prüfer bereitgestellt hat. Dadurch ist nur der Prüfer in der Lage, den Beglaubigungsdatensatz zu entschlüsseln, und er kann prüfen, ob die in der Enklave implementierte Workload die erwartete und nicht manipulierte Version der Workload ist, die in der Hyper Protect Virtual Servers for VPC-Instanz bereitgestellt werden sollte.