Attestation

The IBM Cloud Hyper Protect Virtual Servers for VPC is deprecated. As of 28 February 2026, you can't create new instances. Existing instances are supported until 20 February 2027. Any instances that still exist on that date will be deleted. You can redeploy your workloads by using IBM Confidential Computing Container Runtime (formerly known as Hyper Protect Virtual Servers) or IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions (formerly known as Hyper Protect Container Runtime for Red Hat Virtualization Solutions). For information about data migration, see the Migration guide. For more information, see the Service deprecation announcement.

Attestation is a process that starts by default at virtual instance creation, ensures that the virtual server instance image is indeed built by IBM, and that it was not modified. This process also provides information and allows validation of any data that is provided to the instance at the time of deployment.

When you create a virtual server instance by using the IBM Hyper Protect Container Runtime image, the image uses an initial file system that is protected by encryption and signed by IBM Secure Execution. For more information, see Confidential computing with LinuxONE. To know more about the attestation process, see this video.

The boot process creates a unique root disk encryption key to ensure protection of the root disk. To perform attestation, the virtual server instance image contains an attestation-signing key and the hash of the root partition at build time. The boot process validates the root partition. If the hash of the root partition does not match, the boot process does not continue because it assumes that the image was modified before boot. The attestation signing key is a random RSA 4 K key that is signed by an IBM root key that is maintained in Hyper Protect Crypto Services. The IBM root key is signed by Digicert.

During deployment of the virtual server instance in the cloud, an attestation record is created. It contains hashes of the following items:

• The original base image
• The root partition at the moment of the first boot
• The root partition at build time
• The cloud initialization options

The attestation record is signed by the attestation key. As an extra protection layer, you can provide a public key during deployment, against which the attestation record is encrypted. The hash of this public key is added to the attestation record so that the record can be viewed only by the compliance authority. The expected authority can be easily identified through that hash.

Before you upload any workload to your instance, you need to validate the attestation record. After an instance is created, you can validate the attestation record within the created instance. Your instance must have access to the /var/hyperprotect directory. If so, follow these procedures:

• The attestation record is signed by the attestation signing key.
• The attestation signing key can be confirmed by the IBM intermediate certificate. The IBM intermediate certificate is signed by DigiCert, which is proven by the root certificate of DigiCert, thus completing the chain of trust.

The encryption and attestation certificates are signed by the IBM intermediate certificate, which are signed by the IBM Digicert intermediate cert. The IBM Digicert intermediate cert is signed by DigiCert Trusted Root G4. For more information about the certificates, see DigiCert Trusted Root Authority Certificates.

Use the following procedure to validate the attestation record and hashes:

• Obtain the attestation record se-checksums.txt and the signature file se-signature.bin from your Hyper Protect Virtual Servers for VPC instance. To do so, you can implement your container to provide the attestation record and the signature file. The attestation record and the signature file are made available to your container in the /var/hyperprotect directory.
• Get the IBM attestation certificate. The following table lists the expiry dates for the attestation certificates based on the version of the image.

From 25 March 2025, the certificate links are changed.

• Validate the attestation certificate by following the instructions here.

• Extract the attestation public key from the attestation certificate by using the following command:

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

• Verify the signature of the attestation record:

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

  Signature verification must be done on a decrypted attestation file.

• You can now use the hashes from the attestation record for validation.

In case you provided a public key for encrypting the attestation record, the following script might help in decrypting the record.

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

In the case of a docker container, the decrypt-attestation.sh file can be accessed by mounting /var/hyperprotect in the docker container. For example,

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

In the case of a Podman container, the decrypt-attestation.sh file can be accessed by mounting /var/hyperprotect in the Podman container. For example,

 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.5.0
Machine Type/Plant/Serial: 9175/02/C25B8
Image age: 3 days since creation.
Encryption Certificate valid until: May 18 10:47:12 2027 UTC
Attestation Certificate valid until: May 18 12:37:49 2027 UTC
805dd8786c2c181b34ce42eded40cafebd1806aa07ce721a4e71adb32622bbc0 certificate_expiry_date.json
50f93af14cc5af1585ec3d1a925fea67c25d4fc2c07a7bb0f030390ab76ff854 root.tar.gz
335d2db7919aaa0ff49dc6e415e58e3fee1dee4a5644354f8e1f5db93d56b6a0 baseimage
f576c2d782add88271154fb47ba724efa7612b0eb5d200c37eeb31dc946f56de sbom
98f3faf43cc9171cdc305f15f682af013a51395df96aee142387b95df40e1dac /dev/disk/by-label/cidata
ec5f642e1899a519aa386c4d6bd52be3506f4b98fb8aa0b9805d618396ff635b cidata/meta-data
c6d9534c5d91a8a199110c012514ce7c54391b706430ce82618c5d4f2aac5228 cidata/user-data
1cffcfefd1c8d758f2c285275714ed040c39945f80fb52638ac630fcb7b52e1c cidata/vendor-data
fdeb7096b3b6e43c8ffa77c085b1581b650dce67b45e2ea8dc6ff91aa6ac1703 contract:workload 
853809fedf71c3743667fa0c2c0826877016c94c56bae4533c950455a0b51c92 contract:env
d1eccc9b91b09a67097073cee8d9a8046a2a0bd658b88920f36c8ec4b823f050 contract:envWorkloadSignature
6d526b0cd7a320085872b919424339d0370582d63a1f3305bf29def5f582b849 contract:attestationPublicKey 

335d2db7919aaa0ff49dc6e415e58e3fee1dee4a5644354f8e1f5db93d56b6a0 baseimage

f8614f9f6a39302b97b0a590e14b2e64affddb0f98ef459bf0f8c7f185c98bd5 baseimage

f73df7d02327896fbda67f6e7368c3e27fe5e15b580cdfdb60e7310afeed5b75 baseimage

14d2a725746bf9a6cbf9847e09422f5a97609d03f15b373519a16015619f227d baseimage

3e13f7658ef790dbc040e90ff4f8d537c9c10da879b0b16df9e98265c7b5170a baseimage

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

538170f79b7bd44553847e81afce7ae14c8ea8857df243e4f8656c9d06d42c18 baseimage

50f93af14cc5af1585ec3d1a925fea67c25d4fc2c07a7bb0f030390ab76ff854 root.tar.gz

50f93af14cc5af1585ec3d1a925fea67c25d4fc2c07a7bb0f030390ab76ff854 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

ec5f642e1899a519aa386c4d6bd52be3506f4b98fb8aa0b9805d618396ff635b cidata/meta-data
c6d9534c5d91a8a199110c012514ce7c54391b706430ce82618c5d4f2aac5228 cidata/user-data
1cffcfefd1c8d758f2c285275714ed040c39945f80fb52638ac630fcb7b52e1c cidata/vendor-data

6d526b0cd7a320085872b919424339d0370582d63a1f3305bf29def5f582b849 contract:attestationPublicKey 

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

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

Understanding attestation flows

The following diagram shows two scenarios for attestation from the point of view of the auditor to validate that the deployment is the expected one. The left side of the diagram shows the establishment of trust by the auditor who is rooted on a third-party certificate authority. Any key used is kept in a Hyper Protect Crypto Service and signed in a certificate chain based on the third-party authority. The Build environment that is used by Hyper Protect is running in a trusted execution environment by using IBM Secure Execution Technology.

The result is a secure execution image that is seen at the end of the diagram, which is an encrypted secure execution image. To the right of the diagram, the validation of the deployment is outlined. For this, the auditor includes into the encrypted workload contract of the IBM Hyper Protect instance, the public key of a secret, which only the auditor has control over. Such secrets might be protected by appropriate means, like a Hyper Protect Crypto Service, HSM or just a random key. Only the Hyper Protect bootloader that is executed in the trusted execution environment provided through IBM Secure Execution for Linux on IBM LinuxONE, can run the secure execution image of IBM Cloud Hyper Protect Virtual Servers for IBM Cloud® Virtual Private Cloud. The bootloader contains the secret to decrypt the contract.

During boot several hashes of components and measures of code are taken and added to the attestation record. To further protect this attestation record, the record is encrypted with the public key that the auditor provided. By doing so, only the auditor is in the position to decrypt the attestation record and can validate that the workload that is deployed in the enclave is the expected and untampered version of the workload that is expected to be deployed into the Hyper Protect Virtual Servers for VPC instance.