AMD SEV's mode has changed over time (as AMD moved from SEV, to SEV-ES, to SEV-SNP). Each time, some academic has managed to reverse engineer the mode. This paper (published 2020) has documented the developments and reverse engineered the mode in SEV-ES. https://arxiv.org/pdf/2004.11071.pdf
Re:Confidential VMs
by jiripospisil on Tuesday July 14, 2020 @09:41AM
(#23831824)
Another paper that mentions AES in the ECB mode is "Secure Encrypted Virtualization is Unsecure!" [0]
Simple picture to demonstrate: [1]. Simply put, ECB does not use different salt every block.
[1] https://ctf-wiki.github.io/ctf-wiki/crypto/blockcipher/mode/...
They document a "physical address based tweak". My understanding is that this is xoring a function of the physical address with each 128bit block before going into AES-ECB (and that function is that same for every VM on your system).
Re:Confidential VMs
by CodesInChaos on Tuesday July 14, 2020 @10:03AM
(#23832067)
The XTS/XEX modes would be a proper way to implement this. They use the same concept of xoring an address based tweak into the message.
Two subtle but important features of these modes are:
1. the tweak is xored both before and after the permutation
2. the tweak is derived from a secret and the address in a secure way
(I don't know if AMD chose such a secure mode, or used some insecure homebrew tweaking scheme)
I only saw that in "A Comparison Study of Intel SGX and AMD Memory Encryption", which per my grandparent comment, is not a trustworthy source (they reference the whitepaper, and the whitepaper doesn't say anything about it).
Is that documented in an actual AMD source, or even talk?
As far as I know, the whitepaper is all you will find publicly.
It does mention the tweak (on page 4), only if you want the details and don't trust the third-party papers, you will have to reverse-engineer that yourself =]
Fair enough. That's what I assumed, but the HN crowd is pretty resourceful too.
SEV is targeted to the VM instances, with a single key per VM.
SME is applicable to the entire server, similar to total memory encryption with a single key for all host kernel/machine. SME is not super applicable to the cloud, more suitable for a single server environments.
That doesn't tell me what mode of AES it is, that's key management.
AES 128bits
Respectfully, I know that. That doesn't say if its ECB, CTR, XTS, etc. What mode AMD uses makes has huge implications on what it is good for and not good for.
The answer to your question: The AES mode AMD SEV uses is similar to XEX. AMD computes a tweak value based on the physical memory address and performs an xor-encrypt-xor operation. The tweak algorithm used on Rome (2nd gen EPYC) is based on GF math and uses a random value that is changed on each boot.
I have been reading though all of AMD's documents, and I cannot find what mode of AES that SEV (or SME) uses. I find it extremely odd that this is not called out in any of AMD's documents, and frankly a bit worrisome.
For the record, "A Comparison Study of Intel SGX and AMD Memory Encryption" [1] claims a modified version of AES-ECB is what SEV uses, BUT their reference links to AMD's whitepaper [2], which does NOT say anything about their mode, so I do not consider [1] to be a trustworty resouce.
[1] https://caslab.csl.yale.edu/workshops/hasp2018/HASP18_a9-mof...
[2] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory...