Attestation

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 (HPCR) image, the image uses an initial file system that is protected by encryption and signed by IBM Secure Execution (SE). 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, 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 to ensure that the record can be viewed only by the compliance authority, and 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 and this has been signed by the IBM Digicert intermediate cert (which in turn 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 IBM Hyper Protect Virtual Servers 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 that is a part of the image TAR file.

• Validate the attestation certificate by following the instructions here.

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

   openssl x509 -pubkey -noout -in ibm-hyper-protect-container-runtime-24.9.1-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
  

  Note: 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/
|-- cidata
|   |-- meta-data
|   |-- vendor-data
|-- se-checksums.txt
|-- se-signature.bin
|-- se-version
|-- user-data.decrypted

sha256sum <file>

24.11.0
Machine Type/Plant/Serial: 8562/02/4C588
Image age: 7 days since creation.
Ultravisor CUID: 0x1735c76d5a3d3b3e1bb7cb9f0c9ebe75
Host HKD: HKD-3931-0271A28.crt
HKD is valid until: Dec 26 17:35:32 2024 GMT
AP device present: true
Number of configured APs: 2
d58c9f54ed661428a43ecfc73a0496ccffa3bd11bc67d91527eeb6d88801134b AP(1):secret 
e0ee64acef428031783ba31387c6803a620290a9172defcdc19e49a33d831505 AP(2):secret
080f817231fe4bc40021d24e20af9f1135a36711047212f9374664b86ab406ac baseimage
ad65a3820d4a233c84e6d201ce537b8020435ccefe26682809da5ef9b176b8ae root.tar.gz
50330413a1f80e0abb51116ea4861527f4444b7ba27de975f167a60955a8963f /dev/disk/by-label/cidata
e033c938bf6bd79f50b50d54d577c2909b4304c633501e3d67c5eb6b49570be2 cidata/meta-data
1ca7ac0518344d5e7646d41fa768dad0deaf402576e44e2a0f9c298538ade3da cidata/user-data
cb0535727a27ffe986bce98de8eb1b2c1fafb8033e19b783eefe107b7cc61f65 cidata/vendor-data
a344bd0107382a6e019a0789dc2c43c75ea21342489a8800aa2e5ba140e5d820 attestationPublicKey
3ec698881c8f79cfd8b911516e3a7c008cc6923767e46481479a88934e9bb932 contract:env
1e8afc52b452b7439a8fe9d7d4950fbed2457bc091a4d83136c6a795b4d28c03 contract:workload

080f817231fe4bc40021d24e20af9f1135a36711047212f9374664b86ab406ac baseimage

ad65a3820d4a233c84e6d201ce537b8020435ccefe26682809da5ef9b176b8ae root.tar.gz

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

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