Attestazione

Il sito IBM Cloud Hyper Protect Virtual Servers per VPC è deprecato. A partire dal 28 febbraio 2026, non sarà più possibile creare nuove istanze. Le istanze esistenti saranno supportate fino al 20 febbraio 2027. Tutte le istanze ancora esistenti a quella data saranno eliminate. È possibile distribuire nuovamente i carichi di lavoro utilizzando IBM Confidential Computing Container Runtime(precedentemente noto come Hyper Protect Virtual Servers ) o IBM Confidential Computing Container Runtime for Red Hat Virtualization Solutions(precedentemente noto come Hyper Protect Container Runtime for Red Hat Virtualization Solutions). Per informazioni sulla migrazione dei dati, consultare la guida Migrazione. Per ulteriori informazioni, vedere l'annuncio di deprezzamento del servizio.

L'attestazione è un processo che si avvia automaticamente alla creazione dell'istanza virtuale e garantisce che l'immagine dell'istanza del server virtuale sia stata effettivamente creata da IBM e che non sia stata modificata. Questo processo fornisce anche informazioni e consente la convalida di tutti i dati forniti all'istanza al momento della distribuzione.

Quando crei un'istanza del server virtuale utilizzando l'immagine IBM Hyper Protect Container Runtime, l'immagine utilizza un filesystem iniziale protetto dalla crittografia e firmato da IBM Secure Execution. Per ulteriori informazioni, vedi Confidential computing with LinuxONE. Per ulteriori informazioni sul processo di attestazione, vedi questo video.

Il processo di boot crea una chiave di codifica del disco root univoca per garantire la protezione del disco root. Per eseguire l'attestazione, l'immagine dell'istanza del server virtuale contiene una chiave di firma dell'attestazione e l'hash della partizione root al momento della build. Il processo di avvio convalida la partizione root. Se l'hash della partizione root non corrisponde, il processo di avvio non continua perché presuppone che l'immagine sia stata modificata prima dell'avvio. La chiave di firma di attestazione è una chiave RSA 4 K casuale firmata da una chiave root IBM gestita in Hyper Protect Crypto Services. La chiave root IBM è firmata da Digicert.

Durante la distribuzione dell'istanza del server virtuale nel Cloud, viene creato un record di attestazione. Contiene gli hash dei seguenti elementi:

• L'immagine di base originale
• La partizione root al momento del primo avvio
• La partizione root al momento della build
• Le opzioni di inizializzazione cloud

Il record di attestazione è firmato dalla chiave di attestazione. Come livello di protezione aggiuntivo, puoi fornire una chiave pubblica durante la distribuzione, rispetto alla quale il record di attestazione è crittografato. L'hash di questa chiave pubblica viene aggiunto al record di attestazione in modo che il record possa essere visualizzato solo dall'autorità di conformità. L'autorità attesa può essere facilmente identificata attraverso questo hash.

Prima di caricare un carico di lavoro nella tua istanza, devi convalidare il record di attestazione. Una volta creata un'istanza, è possibile convalidare il record di attestazione all'interno dell'istanza creata. La propria istanza deve avere accesso alla directory /var/hyperprotect. In tal caso, seguire queste procedure:

• Il record di attestazione è firmato dalla chiave di firma attestazione.
• La chiave di firma di attestazione può essere confermata dal certificato intermedio IBM. ILIBM il certificato intermedio è firmato daDigiCert, che è dimostrato dal certificato radice diDigiCert, completando così la catena della fiducia.

I certificati di crittografia e di attestazione sono firmati dal certificato intermedio IBM, che è firmato dal certificato intermedio IBM Digicert. Il certificato intermedio IBM Digicert è firmato da DigiCert Trusted Root G4. Per ulteriori informazioni sui certificati, vedere DigiCert Certificati di autorità radice affidabili.

Utilizzare la seguente procedura per convalidare il record di attestazione e gli hash:

• Ottieni il record di attestazione se-checksums.txt e il file di firme se-signature.bin dal tuo Hyper Protect Virtual Servers per l'istanza VPC. Per farlo, puoi implementare il contenitore per fornire il record di attestazione e il file di firma. Il record di attestazione e il file di firma vengono resi disponibili per il contenitore nella directory /var/hyperprotect.
• Ottieni il certificato di attestazione IBM. La seguente tabella elenca le date di scadenza per i certificati di attestazione in base alla versione dell'immagine.

A partire dal 25 marzo 2025, i collegamenti dei certificati vengono modificati.

• Convalidare il certificato di attestazione seguendo le istruzioni qui.

• Estrarre la chiave pubblica di attestazione dal certificato di attestazione utilizzando il seguente comando:

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

• Verificare la firma del record di attestazione:

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

  La verifica della firma deve essere eseguita su un file di attestazione decodificato.

• È ora possibile utilizzare gli hash dal record di attestazione per la convalida.

Nel caso in cui sia stata fornita una chiave pubblica per crittografare il record di attestazione, il seguente script potrebbe aiutare a decrittografare il 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

Nel caso di un contenitore docker, è possibile accedere al file decrypt-attestation.sh montando /var/hyperprotect nel contenitore docker. Ad esempio,

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

Nel caso di un contenitore Podman, è possibile accedere al file decrypt-attestation.sh montando /var/hyperprotect nel contenitore Podman. Ad esempio,

 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

Comprensione dei flussi di attestazione

Il seguente diagramma mostra due scenari per l'attestazione dal punto di vista del revisore per convalidare che la distribuzione è quella prevista. Il lato sinistro del diagramma mostra la creazione dell'attendibilità da parte del revisore che è radicato su un'autorità di certificazione di terze parti. Qualsiasi chiave utilizzata viene conservata in un Hyper Protect Crypto Service e firmata in una catena di certificati basata sull'autorità di terze parti. L'ambiente di build utilizzato da Hyper Protect è in esecuzione in un ambiente di esecuzione attendibile utilizzando IBM Secure Execution Technology.

Il risultato è un'immagine di esecuzione protetta visualizzata alla fine del diagramma, che è un'immagine di esecuzione protetta crittografata. A destra del diagramma, viene delineata la convalida della distribuzione. Per questo, il revisore include nel contratto del carico di lavoro crittografato dell'istanza IBM Hyper Protect, la chiave pubblica di un segreto, su cui solo il revisore ha il controllo. Tali segreti potrebbero essere protetti con mezzi appropriati, come un Hyper Protect Crypto Service, HSM o solo una chiave casuale. Solo il bootloader Hyper Protect eseguito nell'ambiente di esecuzione fidato fornito tramite IBM Secure Execution per Linux su IBM LinuxONE, può eseguire l'immagine di esecuzione sicura di IBM Cloud Hyper Protect Virtual Servers per IBM Cloud® Virtual Private Cloud. Il bootloader contiene il segreto per decodificare il contratto.

Durante l'avvio vengono presi diversi hash di componenti e misure di codice che vengono aggiunti al record di attestazione. Per proteggere ulteriormente questo record di attestazione, il record viene codificato con la chiave pubblica fornita dal revisore. In tal modo, solo il controllore è in grado di decodificare il record di attestazione e può convalidare che il carico di lavoro distribuito nell'enclave è la versione prevista e non modificata del carico di lavoro che si prevede di distribuire in Hyper Protect Virtual Servers per l'istanza VPC.

di attestazione*