How does this demo transform a passphrase (for disk encryption) to a keyfile (for disk decryption)?

[StanPlatinum]

Great work!

I spend a week studying the code, especially the Guest Disk Encryption part.

I notice that the demo is using LUKS command (cryptosetup) to do the root partition encryption.
One thing I didn't understand is that I entered the password manually when encrypting (see https://github.com/AMDESE/sev-guest/blob/main/scripts/create-luks-qemu-img.sh#L233), but when decrypting, I had to find the key in the Attestation Report to decrypt it... How is this done?

Could anyone enlighten me? Thanks!

[jlarrew]

Hi StanPlatinum,

Thanks for the feedback! I need to add a write-up of how the disk encryption demo works.

When a SNP guest is launched, the Guest Owner can optionally supply a binary blob of information called the Identity Block. The Identity Block contains the public portion of an Identity Key that is used to uniquely identify this guest instance from other instances in the cloud. The Guest Owner maintains a database that maps the Identity Key supplied during guest launch to the disk decryption key for that VM. In the demo, I simply use a directory full of key files as the "database". Each file is named after the SHA-384 fingerprint of the guest Identity Key, and the file contains the (plaintext) disk decryption passphrase that was setup during the initial disk encryption. See scripts/create-key-db-entry.sh to see how this is done. The fingerprint of the Identity Key is calculated using the sev-host-identity command here:

sev-guest/scripts/create-key-db-entry.sh

Line 47 in abf9d1b

local id=$(sev-host-identity -g ${pubkey} | \

If the Guest Owner receives an attestation report with a valid signature (with the VCEK), then they know that this report came from genuine AMD hardware with SEV-SNP enabled. Further, if the report contains the expected SHA-384 fingerprint of the guest Identity Key, then they have assurance that the cloud instance that sent this report is indeed their intended guest.

Along with the attestation report, the guest is expected to send the public portion of a RSA key to be used for wrapping secrets intended for the guest. The SHA-384 fingerprint of this public key should also be included in the (signed) attestation report. If the hash of the public key in the attestation report matches the hash of the public key that was sent to the Guest Owner along with the report, then the Guest Owner can safely use the public key to encrypt any secrets intended for the guest.

Looking at the code, I see that I actually forgot to check the hash of the RSA public key against the value in the report. Whoops! Expect to see a patch with that fix soon. ;)

Sincerely,
Jesse

[StanPlatinum]

Hi Jesse,

Thanks for the reply!!

So if I understand correctly, this send_report function does not only send the report to Guest Owner's attestation server but also would get a decryption key as a response, right?

And you would like to make this procedure more secure by adding an integrity check against the RSA public key (for encrypting the passphrase), right?

Best,
Stan

[jlarrew]

Hi Stan,

The concern here is more about authentication than integrity. More specifically, we want to assure the Guest Owner that this public key belongs to their guest and not to an adversary trying to discover the disk decryption passphrase. Including the hash of the public key (generated by the guest) in the attestation report gives the Guest Owner assurance that the SNP guest owns the private portion of this key pair, so the Guest Owner knows who will be able to decrypt the pass phrase.

If the Guest Owner skips this check, then a Man-In-The-Middle attack is possible where the attestation report is intercepted and the public key replaced by an attacker's key. However, the Guest Owner can detect this by checking that the fingerprint of the public key they received matches the fingerprint in the attestation report.

Sincerely,
Jesse

[StanPlatinum]

Thanks for the explanation, Jesse.

But I thought that only the one who has a private key can decrypt the disk decryption passphrase. Would that be an authentication check?

Sorry, I may not fully understand the flow... Could you share some links about the attestation workflow in this demo?

Thanks,
Weijie

[StanPlatinum]

Hi Jesse,

I noticed that here you have specified an SSH public key. Is that "the hash of the public key in the attestation report" you mentioned earlier?

Thanks!

[jlarrew]

Hi Weijie,

Yes, that's the public key that I was referring to earlier. If a file name is given as input to sev-guest-get-report (using the -f option), then it will hash the contents of the file and ask the SEV firmware to include the hash in the attestation report. SHA-384 is used by default, but you can change the digest algorithm (using the -d option) to any algorithm name supported by OpenSSL.

Sincerely,
Jesse