About the contract

A contract file can have the following four valid high-level sections:

• workload is a mandatory section.
• env is a mandatory section.
• attestationPublicKey is an optional section. You can provide a public RSA key as part of the contract, which is used to encrypt the attestation document and the attribute must be named as attestationPublicKey.
• envWorkloadSignature contains the signature of the other sections of the contract.
• boot is a mandatory section. This section contains Secure Execution Header (sehdr), which is used to initialize and validate secure boot operations in IBM CCCO.

The two primary sections in a contract are the workload and env sections. These two sections are needed because the information that is added into the contract comes from two different personas, namely the Solution Provider or Data Owner.

The Data Owner persona works closely with the Environment Operator. This persona receives the workload information (preferably an encrypted workload section) from the Solution Provider persona. The Data Owner then creates the env section of the contract. The env section has information that is specific to the IBM Cloud environment. Usually, it is information that the Solution Provider persona does not have and does not need to know. An example is information about the IBM Cloud Logging instance, which the Data Owner persona creates, before they add information to the env section of the contract.

One of the most important sections of the contract, the workload section can have multiple subsections and the purpose of the subsections is to provide information that is required for bringing up the workload.

This section is created by the Solution Provider persona.

The workload section is the parent section that can have the following subsections:

• type: workload. Declares that this YAML defines a workload configuration. This subsection is mandatory.
• confidential-containers. This subsection is mandatory.
• auths. This subsection is optional.
• volumes. This subsection is optional.

The following snippet shows a high-level sample of the workload section of the contract. The minimum that a workload section needs is the confidential-containers section. The other sections can be added based on the requirement.

type: workload
confidential-containers:
  regoValidator:
    policy: ${encoded_policy}
 

The env section is also one of the most important sections in a contract. The env section of a contract deals with information that is specific to the cloud environment and is not known to the Solution Provider persona. This section is created by the Data Owner persona.

The subsections for the env section are:

• type: env. This subsection is mandatory.
• logging. This subsection is mandatory.
• confidential-containers. This subsection must be used only when you are creating the contract with sealed secret.
• signingKey. This subsection is used to provide a key to verify the contract signature.
• host-attestation. This subsection is used to specify one or more host key documents required for attestation. This subsection is mandatory for Bare Metal deployments and optional for Peer Pod deployments.
• volumes. This subsection is optional.

The minimum that a env section needs is the logging section. The other sections can be added based on the requirement. The following snippet shows a high-level sample of the env section of the contract with logrouter.

type: env
logging:
  logRouter:
    hostname: ${PUBLIC_INGRESS_ENDPOINT}
    iamApiKey: ${IAMAPIKEY}
    port: 443
host-attestation:
  ${HKDNAME}:
    description: KEY-1
    host-key-doc: ${HKDVALUE}
signingKey: "${SIGNING_KEY}"
 

You can encrypt the contents of a contract. Although you can use the contract without encryption, it is recommended that you encrypt the contract. It is also recommended that you initially try to use a non-encrypted contract for testing purposes, and after it works as expected, you can use an encrypted contract for your production environment.

You can decide which sections of the contract need encryption. For example, you can choose to encrypt only the workload section, or encrypt only the env section.

When the IBM CCCO VM boots, the bootloader decrypts the contract. It takes the value of each of the sections in the contract and decrypts it if it is encrypted. If it finds that a section is not encrypted, it considers it as it is without any decryption. You must use the IBM CCCO contract encryption key to encrypt the contract before you pass it as an input.

The encryption and attestation certificates are signed by the IBM intermediate certificate and this is 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.

Contract signature is essential to ensure a confidential environment for the workload. You can choose to sign a contract before it is passed as input. Contracts that are in plain text or encrypted can be signed. Validation of the contract signature is done by the IBM Confidential Computing Containers for Red Hat OpenShift Container Platform image.

The purpose of this signature feature is to ensure that the workload and env sections are always used together and are not tampered with by a third party. Another optional feature in contract signature is setting expiry of contract using signing certificate. Using this feature, if a IBM CCCO VM is booted after the certificate has expired, the VM will fail to boot. The signature of the workload and the env sections are added as the value to the envWorkloadSignature section.

Following are the two sections in a contract that are relevant while creating and adding a contract signature:

• envWorkloadSignature: This is section where the signature of the other sections of the contract is added. This section is not required for a contract that is not signed.

• signingKey: This is a subsection that must be added to the env section of the contract. This holds the value to the user-generated public key or certificate, whose corresponding private key was used to create the contract signature. Public key or certificate can also be parsed as base64 string.

Complete the following steps to create the contract signature:

1. Use the following command to generate key pair to sign the contract:

   $ openssl genrsa -aes128 -passout pass:test1234 -out private.pem 4096
   $ openssl rsa -in private.pem -passin pass:test1234 -pubout -out public.pem
    

   Note: "test1234" is the passphrase to generate keys; however, you can use your own.

2. Utilise the following command as an example to get the signing key:

   $ key=$(awk -vRS="\n" -vORS="\\\n" '1' public.pem)
   $ echo ${key%\\n}
    

3. If you want to pass the signing key as base64 optionally, use the following command:

   $ key=$(cat public.pem | base64 -w 0)
   $ echo $key
    

4. If you want to enable contract expiry optionally, refer to the steps mentioned in the following:

   a. Use the following command to generate a certificate request:

   $ openssl req -new -key private.pem -passin pass:test1234 -out csr.pem
    

   b. The command generates the certificate. Utilise the following steps to generate the certificate:

   1. Use the following command to generate private key for CA:

      $ openssl genrsa -out personal_ca.key 2048
       

   2. Generate a self-signed CA certificate using the following command:

      $ openssl req -new -x509 -key ca.key -out personal_ca.crt
       

   3. Use the following command to sign CSR with self signed CA certificate along with number of days for the certificate to be valid.

      Note: The end date of the generated certificate is the contract expiry date.

      $ openssl x509 -req -in csr.pem -CA personal_ca.crt -CAkey personal_ca.key -CAcreateserial -out certificate.pem -days 365
       

   c. Use the following command as an example to get the certificate:

   $ certificate=$(awk -vRS="\n" -vORS="\\\n" '1' certificate.pem)
   $ echo ${certificate%\\n}
    

   d. Use the following command as an example to optionally get the certificate in base64 format:

   $ certificate=$(cat certificate.pem | base64 -w 0)
   $ echo $certificate
    

5. Create the env.yaml file according to the following examples:

   • If signingkey is a public key:

     type: env
     logging:
       logRouter:
         hostname: ${PUBLIC_INGRESS_ENDPOINT}
         iamApiKey: ${IAMAPIKEY}
         port: 443
     signingKey: "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvLaeSA8Nc3p99HNUMwon\n5lMMALAsIxRRpWUaEZ5IcUky2sgCi/rSmxU2sm6FK/BmCftk33f5W2BsYHdY9R/0\nELZ9A4POQcJsPF3ronU2QHwnRjcqYuUFXmf1VqfPPLpELriFNoCb2FN2zCa+VUmu\n+fGhroZ3Fr9kBPwJhGr917E5jeCQ+MzsGkulcTvr0SfvThiZQQ/KlU0R35ThamF3\n8C0F5IQBpqDUwDFmWvD5lF2SmprpluDBFEj8LLfLxvW9M2Qwku6nGUnnFReg3vNH\n7IF0SRr1K1AdO5hEmevCdyG9hgTdUY6dXcjntiN/kbqXErILknvzDnb4jyPZZRdK\ndrOzVt8hjbdmkS396SrMFtA++QrV3GNZl5zCscpn6d8S7BEA8mDzroo2UAbrypVP\n9l9AmzUnmnPCpZQySUUHoY0xG2vgMSA50CWH7Uwjmpixr02Td4/LU8fE7NWCO6ci\nx4++ANSaxu+uuZ2Pe1OjjgV98r06ZUs38eaxptLZqLpn3N6w8WAJxGwSLapZwNtP\ng2spUXu2Eh/TN5t4/ly5iXOsyIy8IPtTrUPX7rpaaqFZ72P6BJLj3WLEvOG/eF/8\nBTjrsZAjb8YjkO1uGk10IPa63sniZWe5vlm9w9UKy2uGuy6RhWxwoVHRRbfhboQF\nsO20dsVwgTZn8c46HMD2PoMCAwEAAQ==\n-----END PUBLIC KEY----"
      

   • If signingkey is a certificate:

     type: env
     logging:
       logDNA:
         hostname: syslog-a.eu-gb.logging.cloud.ibm.com
         ingestionKey: cfae1522876e860e58f5844a33bdcaa8
         port: 6514
     signingKey: "-----BEGIN CERTIFICATE-----\nMIIFETCCAvkCFBAMxyO6Cl7BNKBGxtlAzHpI2oiNMA0GCSqGSIb3DQEBCwUAMEUx\nCzAJBgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRl\ncm5ldCBXaWRnaXRzIFB0eSBMdGQwHhcNMjQwMTMwMDM1ODMzWhcNMjQwNTA5MDM1\nODMzWjBFMQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UE\nCgwYSW50ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIICIjANBgkqhkiG9w0BAQEFAAOC\nAg8AMIICCgKCAgEAv5h6i7Fn1DMUM+3AnPPZUNMe1ss3KL/AmUmptwlAPErVoH1k\naiqTUsSNjXctj+nk95I+e2nugw/HlaVT1eRgEtvjssheXKboFn+zW/i31Nq9USgQ\nZA325VtchYlgJLXMPaH/ukBUr0UI4LnjC/dNdAQzKwWPNF2Jlv5wKX8OBVOQO9Df\nExVmcEkKDoh0nZk5eOA8vzJGhfr8TvQx9FQFsP4OXTwQgcdZV26mLm0bMkqEt3o5\n8OSpisqNGY1XnMHjOWNqSbErkpbIKEFAQSnWmzEvJdHsQX+7eTF7CisHJREseT4s\nUSuIFBZKXbS3qq6EL/EYviu0EGnY/rkJJcIRb8hycqHRgoITT2bWT7PSMUyXoX3G\nVKfp/xKFhkYzoRDSb5S0lh8sugmoRkioAkw6G56CP2hablPZRUMmUKceFfOG/k4L\nei8qJtbfQJ9BlCNRPpjqY3sGSdeXI4zefyQ8xxcus9Sl5wXZV86lz2lO/fz3Cvpd\n0eKvfv5uXyvF3O36lrlEERmSukaZYaEJECjxOUeafc7E1DVyIaMpc2SOum1crwMG\nRKhnU1JShDON0yClnKOlACfjFIpdpEMpE4lLps1x+PXV+x21zGBMUvXYa4xpbyWR\nK1gfMWmuvGOivl9y0mPSIeyJ9R/7bSRAbcYJR4N99TrtWxZU1yQi7HSRV5cCAwEA\nATANBgkqhkiG9w0BAQsFAAOCAgEAg006zJ4ZKwT8moOOl3PdThFUcf8rrIlec9Iy\nqPcWSqt5UTeYLIe58oGhhQmcaIRUOQaib5JqH2ukzqpo+gsJ3zZb3eIn4FB7cKef\nLqaiemOveEe1/qSwAGqMZyZELssiOflhnJdzuYSRWO8DO6Q6JMqQthDcw20budjO\nzP4nhXQqT+s8ljzqSJW77hDbrNAezTz/0SJFDtaMBs5UweX//7/4sXtJ8kBIBSxd\n7y4w8tuuxUaXOtYMjNrJAYLwFVeeO8CFURpbEuv7ABT0k8U4E8C6j4U4Jysx4XVP\nZj36rIAtvctchh0yAhHz8whXe1tvaFw9wzRDATnThFAuJG4Z07K2/rlDP9kO9wmn\ng8hHxKeqQMJDp29e0sGkz8oDi6Mz24k9CqFJJ0CUz1ntz7rrDkA3QwQbFRzk938y\n3rSfePO5qXlUQ9mm05hYr1EKKceTLEowc4XOouNLlUWGiRshRR1szMw5C29prFJ2\nyYuV9tBaFYkq7dnh8JnmrreEvAnsKyyECxMmtV/W701OSUYBcThwgAo+hkEeOJ+/\nwrOS7yoJqDF1y+5LLQJmUlrLCPXem3ZTa4UMe1p2g7ge7Dg6Zud9NDBcMigdHByt\nJP/i9PcJSEWrccWJ1ajToUCZ0wqfJ3Z4KqoEd0fadQhb32AuDUbu7E12EUFNPGIH\n8rQKbDU=\n-----END CERTIFICATE-----"
      

   • If signingkey is a base64 encoded signing key or certificate:

     type: env
     logging:
       logDNA:
         hostname: syslog-a.eu-gb.logging.cloud.ibm.com
         ingestionKey: cfae1522876e860e58f5844a33bdcaa8
         port: 6514
     signingKey: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tXG5NSUlGRVRDQ0F2a0NGQkFNeHlPNkNsN0JOS0JHeHRsQXpIcEkyb2lOTUEwR0NTcUdTSWIzRFFFQkN3VUFNRVV4XG5DekFKQmdOVkJBWVRBa0ZWTVJNd0VRWURWUVFJREFwVGIyMWxMVk4wWVhSbE1TRXdId1lEVlFRS0RCaEpiblJsXG5jbTVsZENCWGFXUm5hWFJ6SUZCMGVTQk1kR1F3SGhjTk1qUXdNVE13TURNMU9ETXpXaGNOTWpRd05UQTVNRE0xXG5PRE16V2pCRk1Rc3dDUVlEVlFRR0V3SkJWVEVUTUJFR0ExVUVDQXdLVTI5dFpTMVRkR0YwWlRFaE1COEdBMVVFXG5DZ3dZU1c1MFpYSnVaWFFnVjJsa1oybDBjeUJRZEhrZ1RIUmtNSUlDSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DXG5BZzhBTUlJQ0NnS0NBZ0VBdjVoNmk3Rm4xRE1VTSszQW5QUFpVTk1lMXNzM0tML0FtVW1wdHdsQVBFclZvSDFrXG5haXFUVXNTTmpYY3RqK25rOTVJK2UybnVndy9IbGFWVDFlUmdFdHZqc3NoZVhLYm9Gbit6Vy9pMzFOcTlVU2dRXG5aQTMyNVZ0Y2hZbGdKTFhNUGFIL3VrQlVyMFVJNExuakMvZE5kQVF6S3dXUE5GMkpsdjV3S1g4T0JWT1FPOURmXG5FeFZtY0VrS0RvaDBuWms1ZU9BOHZ6SkdoZnI4VHZReDlGUUZzUDRPWFR3UWdjZFpWMjZtTG0wYk1rcUV0M281XG44T1NwaXNxTkdZMVhuTUhqT1dOcVNiRXJrcGJJS0VGQVFTbldtekV2SmRIc1FYKzdlVEY3Q2lzSEpSRXNlVDRzXG5VU3VJRkJaS1hiUzNxcTZFTC9FWXZpdTBFR25ZL3JrSkpjSVJiOGh5Y3FIUmdvSVRUMmJXVDdQU01VeVhvWDNHXG5WS2ZwL3hLRmhrWXpvUkRTYjVTMGxoOHN1Z21vUmtpb0FrdzZHNTZDUDJoYWJsUFpSVU1tVUtjZUZmT0cvazRMXG5laThxSnRiZlFKOUJsQ05SUHBqcVkzc0dTZGVYSTR6ZWZ5UTh4eGN1czlTbDV3WFpWODZsejJsTy9mejNDdnBkXG4wZUt2ZnY1dVh5dkYzTzM2bHJsRUVSbVN1a2FaWWFFSkVDanhPVWVhZmM3RTFEVnlJYU1wYzJTT3VtMWNyd01HXG5SS2huVTFKU2hET04weUNsbktPbEFDZmpGSXBkcEVNcEU0bExwczF4K1BYVit4MjF6R0JNVXZYWWE0eHBieVdSXG5LMWdmTVdtdXZHT2l2bDl5MG1QU0lleUo5Ui83YlNSQWJjWUpSNE45OVRydFd4WlUxeVFpN0hTUlY1Y0NBd0VBXG5BVEFOQmdrcWhraUc5dzBCQVFzRkFBT0NBZ0VBZzAwNnpKNFpLd1Q4bW9PT2wzUGRUaEZVY2Y4cnJJbGVjOUl5XG5xUGNXU3F0NVVUZVlMSWU1OG9HaGhRbWNhSVJVT1FhaWI1SnFIMnVrenFwbytnc0ozelpiM2VJbjRGQjdjS2VmXG5McWFpZW1PdmVFZTEvcVN3QUdxTVp5WkVMc3NpT2ZsaG5KZHp1WVNSV084RE82UTZKTXFRdGhEY3cyMGJ1ZGpPXG56UDRuaFhRcVQrczhsanpxU0pXNzdoRGJyTkFlelR6LzBTSkZEdGFNQnM1VXdlWC8vNy80c1h0SjhrQklCU3hkXG43eTR3OHR1dXhVYVhPdFlNak5ySkFZTHdGVmVlTzhDRlVScGJFdXY3QUJUMGs4VTRFOEM2ajRVNEp5c3g0WFZQXG5aajM2cklBdHZjdGNoaDB5QWhIejh3aFhlMXR2YUZ3OXd6UkRBVG5UaEZBdUpHNFowN0syL3JsRFA5a085d21uXG5nOGhIeEtlcVFNSkRwMjllMHNHa3o4b0RpNk16MjRrOUNxRkpKMENVejFudHo3cnJEa0EzUXdRYkZSems5Mzh5XG4zclNmZVBPNXFYbFVROW1tMDVoWXIxRUtLY2VUTEVvd2M0WE9vdU5MbFVXR2lSc2hSUjFzek13NUMyOXByRkoyXG55WXVWOXRCYUZZa3E3ZG5oOEpubXJyZUV2QW5zS3l5RUN4TW10Vi9XNzAxT1NVWUJjVGh3Z0FvK2hrRWVPSisvXG53ck9TN3lvSnFERjF5KzVMTFFKbVVsckxDUFhlbTNaVGE0VU1lMXAyZzdnZTdEZzZadWQ5TkRCY01pZ2RIQnl0XG5KUC9pOVBjSlNFV3JjY1dKMWFqVG9VQ1owd3FmSjNaNEtxb0VkMGZhZFFoYjMyQXVEVWJ1N0UxMkVVRk5QR0lIXG44clFLYkRVPVxuLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLVxu
      

A notification about the expiry of the contract will be sent to your logging service.

Timelines for the notification are as follows:

• On the first of every month
• Everyday for 30 days before the expiry
• Once in every 4 hours if the contract is about to expire in 7 days
• Each and every hour if the contract has already expired or is about to expire in a day

Encryption and Attestation certificate expiry warning logs

CCCO continuously monitors the validity of encryption and attestation certificates and generates warning logs through the configured logging service when certificates are approaching expiry or have already expired. These logs inform users about certificate status so they can upgrade the instance to the latest image level. Following is the notification schedule:

• 30 days before expiry: CCCO generates a warning once every 24 hours, indicating that the certificate will expire in one month.

  Example:

  HPL12011W: The Encryption certificate is going to expire -> Warning: The encryption certificate will expire on 12 February 2026 at 16:17:41 UTC, over 20 days. Upgrade to the latest image to unlock the latest features and avoid potential security vulnerabilities!!!

• 7 days before expiry: As the expiry date nears, CCCO increases log frequency and issues warnings every 12 hours, emphasizing the need for prompt renewal.

  Example:

  HPL12011W: The Encryption certificate is going to expire -> Warning: The encryption certificate will expire on 27 January 2026 at 16:17:41 UTC, over 4 days. Upgrade to the latest image to unlock the latest features and avoid potential security vulnerabilities!!!

• After certificate expiry: Once a certificate has expired, CCCO continues to log warnings every 4 hours until the CCCO image is upgraded with a valid certificate.

  Example:

  HPL12013W: The Encryption certificate has expired -> Urgent: The encryption certificate expired on 15 June 2025 at 17:15:59 UTC, over 7 months. Immediate upgrade to the latest image is required to unlock the latest features and prevent serious security breaches!!!

Encrypting the attestation document is the optional feature that can be used with contract. The attestationPublicKey is the user provided public key used to encrypt the attestation document. This can be provided as a public RSA key or base64 encoded of the public RSA key as a part of the contract.

• If you use the plain text public RSA key for the attestationPublicKey in the yaml file, use the following example:

  attestationPublicKey: "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvLaeSA8Nc3p99HNUMwon\n5lMMALAsIxRRpWUaEZ5IcUky2sgCi/rSmxU2sm6FK/BmCftk33f5W2BsYHdY9R/0\nELZ9A4POQcJsPF3ronU2QHwnRjcqYuUFXmf1VqfPPLpELriFNoCb2FN2zCa+VUmu\n+fGhroZ3Fr9kBPwJhGr917E5jeCQ+MzsGkulcTvr0SfvThiZQQ/KlU0R35ThamF3\n8C0F5IQBpqDUwDFmWvD5lF2SmprpluDBFEj8LLfLxvW9M2Qwku6nGUnnFReg3vNH\n7IF0SRr1K1AdO5hEmevCdyG9hgTdUY6dXcjntiN/kbqXErILknvzDnb4jyPZZRdK\ndrOzVt8hjbdmkS396SrMFtA++QrV3GNZl5zCscpn6d8S7BEA8mDzroo2UAbrypVP\n9l9AmzUnmnPCpZQySUUHoY0xG2vgMSA50CWH7Uwjmpixr02Td4/LU8fE7NWCO6ci\nx4++ANSaxu+uuZ2Pe1OjjgV98r06ZUs38eaxptLZqLpn3N6w8WAJxGwSLapZwNtP\ng2spUXu2Eh/TN5t4/ly5iXOsyIy8IPtTrUPX7rpaaqFZ72P6BJLj3WLEvOG/eF/8\nBTjrsZAjb8YjkO1uGk10IPa63sniZWe5vlm9w9UKy2uGuy6RhWxwoVHRRbfhboQF\nsO20dsVwgTZn8c46HMD2PoMCAwEAAQ==\n-----END PUBLIC KEY----"
   

• If you use the base64 encoded signing key for the attestationPublicKey in the yaml file, use the following command and example.

  $ base64 -w0 <public RSA key file>
   

  • Replace <public RSA key file> with the path to your actual public RSA key file.

    attestationPublicKey: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUJpRENDQVM2Z0F3SUJBZ0lSQUxCMXBPYlpEQlRRc09GSFlxazMzaWd3Q2dZSUtvWkl6ajBFQXdJd0tqRW8KTUNZR0ExVUVBeE1mZFhNdWFXTnlMbWx2TDNCeVlXSm9ZWFF4TWpNdmJYa3RhR0Z3Y205NGVUQWVGdzB5TWpBMApNVE14TURFd01ETmFGdzB6TWpBME1UQXhNREV3TUROYU1Db3hLREFtQmdOVkJBTVRIM1Z6TG1samNpNXBieTl3CmNtRmlhR0YwTVRJekwyMTVMV2hoY0hKdmVIa3dXVEFUQmdjcWhrak9QUUlCQmdncWhrak9QUU1CQndOQ0FBU1AKWGsrelE2MlFZNjI3MWQ1cTBMZHY3SGc3QzZkMGZOUlRsQmJXekhOWWFDZzlpU0piYnVNdjVBY0JmMjlqQi83eApqYzhzVitxMksyemtkTHV4QWxGWm96VXdNekFPQmdOVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJCkt3WUJCUVVIQXdNd0RBWURWUjBUQVFIL0JBSXdBREFLQmdncWhrak9QUVFEQWdOSUFEQkZBaUIzd0JTa0IxaXAKZHZZYlBMbFBmS3RZT0hsYnZzUllKa0FZM2hnY0xuNWhwQUloQUt6cmhsU3p4K1I5bmdtMTBlZVkyaFNCRmgrawpMWHp6SFkwaktTVzhyM1FhCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
     

• If you encrypt the attestationPublicKey in the yaml file, you must follow the same steps as mentioned in the Contract encryption.

To decrypt the attestation document, follow the instructions in the Decrypting the attestation document.

Complete the following steps to prepare the signature:

If you have got the encrypted user-data.yaml from the Creating the encrypted workload section of a contract, and Creating encrypted env section of a contract sections, skip to step 3.

1. Get the encrypted workload.yaml and encrypted env.yaml files.

2. Add them into the user-data.yaml file:

   workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............
   env: hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
    

3. Create the contract.txt file. Add the value of workload first then add the value of env from the user-data.yaml file.

   hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
    

   Note: Ensure that there is no space or new line after workload and before env. Also, ensure that there is no new line or space at the end of the file. It is recommended to cross-check the binary content of the contract.txt file with tools such as hexdump. In the binary file dump, make sure that you do not see the 0a ASCII value as the last entry.

4. Use the following command to generate the signature:

   $ echo $( cat contract.txt | tr -d "\n\r" | openssl dgst -sha256 -sign private.pem | openssl enc -base64) | tr -d ' '
    

5. Add the signature into the user-data.yaml file.

   workload: hyper-protect-basic.js7TGt77EQ5bgTIKk5C0pViFTRHqWtn..............
   env: hyper-protect-basic.VWg/5/SWE+9jLfhr8q4i.........
   envWorkloadSignature: Icbm1D/CVpLNYkWRC9e .....
    

The boot is a mandatory section, which is required to securely initialize the workload within the IBM CCCO environment. This section is critical for establishing a trusted execution environment and ensuring the integrity of the secure boot process. This section enables secure execution by leveraging IBM Secure Execution technology.

This section is created by the Data Owner persona.

The boot section contains the following subsections:

• sehdr. This subsection is mandatory, which contains the Secure Execution Header, a base64-encoded string that includes the necessary details to run a workload securely in a Logical Partition (LPAR). It ensures the workload operates in a protected environment. You can obtain sehdr information from the IBM CCCO installation directory.

The following snippet shows a high-level sample of the boots section of the contract.

boot: |
    sehdr: SUJNU2VjRXgAAAEAAAAEELNhItLSxFZd/T9JIgAAAAAAAAAAAAAA................