attestation: Update kernel module and proxy for AES-GCM, other small changes

Cargo.toml

@@ -59,8 +59,8 @@ release = { path = "release" }
 virtio-drivers = { path = "virtio-drivers" }
 
 # crates.io
-aes = "0.8.4"
 aes-gcm = { version = "0.10.3", default-features = false }
+aes-kw = { version = "0.2.1", default-features = false }
 arbitrary = "1.3.0"
 base64 = { version = "0.22.1", default-features = false }
 bitfield-struct = "0.6.2"
@@ -69,12 +69,13 @@ clap = { version = "4.4.14", default-features = false }
 cocoon-tpm-crypto = { version = "0.1.0", default-features = false }
 cocoon-tpm-tpm2-interface = { version = "0.1.0", default-features = false }
 cocoon-tpm-utils-common = { version = "0.1.0", default-features = false }
+concat-kdf = "0.1.0"
 gdbstub = { version = "0.6.6", default-features = false }
 gdbstub_arch = { version = "0.2.4" }
 igvm = { version = "0.4.0", default-features = false }
 igvm_defs = { version = "0.4.0", default-features = false }
 intrusive-collections = "0.9.6"
-kbs-types = { version = "0.10.0", default-features = false }
+kbs-types = { version = "0.14.0", default-features = false }
 libfuzzer-sys = "0.4"
 log = "0.4.17"
 p384 = { version = "0.13.0" }

Documentation/docs/developer/ATTESTATION.md

@@ -36,14 +36,169 @@ is fresh and legitimate. The negotiation phase returns the parameters that SVSM
 should include in its attestation evidence based on the underlying attestation
 server and protocol.
 
+In the negotiation phase, a `NegotiationRequest` is sent from SVSM to the proxy.
+An example `NegotiationRequest` is shown below.
+```json
+{
+    "version": [0,1,0],
+    "tee": "snp",
+}
+```
+
+- `version`: The SVSM attestation protocol version to use. In place to ensure
+backwards compatibility with updated protocol versions should modifications
+occur. The API follows [SemVer](https://semver.org/) and is represented as a
+tuple [MAJOR, MINOR, PATCH]. The current version is 0.1.0.
+- `tee`: The TEE hardware architecture that SVSM is running on.
+
+The proxy will then complete the negotiation phase with the remote attestation
+server and reply with a list of negotiation parameters that must be included in
+the attestation evidence.
+
+A `NegotiationResponse` is sent from the proxy to SVSM.
+An example `NegotiationResponse` is shown below.
+```json
+{
+    "challenge": "oFlY92ZdS3ymzxokYuDzxw==\",
+    "params": [
+                "EcPublicKeyBytes",
+                "Challenge"
+              ]
+}
+```
+- `challenge`: The challenge nonce returned by the remote attestation server
+that will likely need to be hashed into the attestation evidence to ensure
+freshness. Represented as variably-sized array of bytes.
+- `params`: The negotiation parameters. Each `NegotiationParam` represents some
+form of data that must be hashed into the attestation evidence. This hash will
+be reconstructed by the remote attestation server when the evidence is presented
+from SVSM.
+
+The valid negotiation parameters are as follows:
+- `Challenge`: The bytes represented in the `challenge`.
+- `EcPublicKeyBytes`: The byte buffers of the public key's x and y coordinates
+(in that order).
+
+SVSM can then collect the attestation evidence (with the negotiation parameters
+embedded within the report data) and continue to the attestation phase.
+
 ### Attestation Phase
 
-With all relevant data embedded in TEE evidence, SVSM sends its evidence to the
-remote server for evaluation. Upon successful attestation, the proxy will obtain
-an encrypted secret (only decryptable by SVSM's TEE private key) for SVSM to
-use. For example, SVSM could use this secret to unlock encrypted persistent
+With all relevant data embedded in the TEE evidence, SVSM sends the evidence to
+the remote server for evaluation. Upon successful attestation, the proxy will
+obtain an encrypted secret (only decryptable by SVSM's attestation private key)
+for SVSM to use. For example, SVSM could use this secret to unlock encrypted
 storage.
 
+In the attestation phase, an `AttestationRequest` is sent from SVSM to the proxy.
+An example `AttestationRequest` is shown below.
+```json
+{
+    "tee": "snp",
+    "evidence":{
+        "Snp":{
+            "report": "AwAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAEAAAADAAAAAAAY0QUAAAAAAAAAAAAAAAAAAAAHZTCHj6
+                       luB8MACrYnlqNmLuBgdclkh4UqGAMdZfMHZ+uVHytFLnvJXLkPx3xMf8p
+                       B7faGTY+Mlwi96geujAbfPKa1C+9Kt7Hts/t0Vp+TKQachyjYCZLBhTV2
+                       f7zI05r0HlwonTiV/mva7ZwxvdGaAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAACcdt0ZPBJrpXFX6RTFjSItibRTVsXM
+                       Rn/pL/wbViPO6///////////////////////////////////////////A
+                       wAAAAAAF9EZAQEAAAAAAAAAAAAAAAAAAAAAAAAAAACd3vUWsdS5AAdRkM
+                       51mXGLWEdB7w3CkS2L4/AmeQQPCKQFLcC81HJoD2st3/01IHaqOwGz3Xd
+                       Lb57uqDPWYLxpAwAAAAAAGNEdNwEAHTcBAAMAAAAAABjRAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+InMMSLac18ai1bi
+                       1kJZISAv0MXt7fBB9do732UwrcjUaxCNxZun8fsAWKXU1LPcAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAz+KTpyaINiKXdTAYhGTMl+g05It+QVEsrZ
+                       5Vc1LHpng+KO4uFLFw0PLiXbNTwGU8AAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+                       AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=\",
+            "certs_buf": null
+        }
+    },
+    "challenge": "oFlY92ZdS3ymzxokYuDzxw==\",
+    "key":{
+        "x": "AeFSAOU2/rtNV4VS0uTr5M729jAU1RIZ+p90kRRbIac6x56y40bG39gc+oxykTITDL
+              gQER79+kVluCC+Lt6QSfaU\",
+        "y": "AcBKVeKrw0p+7Nv/JuZMn+zuuQAhpSawoRq3g6Rhc9soXzsPlVLblIEw9muXSNUWbv
+              fNrLHrmw+qy8lR1o/Kvkys\"
+    }
+}
+```
+
+- `tee`: The TEE architecture that the evidence should be interpreted as.
+- `evidence`: The attestation evidence (i.e. report) from the TEE processor.
+Based on the underlying TEE architecture (SEV-SNP being represented in the
+example).
+
+Valid evidence formats are the following:
+- `Snp`: SEV-SNP
+    - `report`: Attestation report bytes.
+    - `certs_buf`: Optional byte buffer representing SEV-SNP certificate chain
+                   (ARK, ASK, VEK) set by the host hypervisor.
+
+- `challenge`: The original challenge nonce given in the `NegotiationResponse`.
+- `key`: The EC public key that will be used to encrypt secret payloads received
+from the remote server upon a successful attestation. Public key x and y
+coordinates supplied.
+
+The proxy will forward the evidence and metadata to the remote attestation
+server for evaluation. Upon successful attestation, the proxy should be able to
+retrieve some secret payload from the remote server. The proxy will retrieve
+this secret and reply to SVSM with an `AttestationResponse`.
+An example `AttestationResponse` is shown below.
+```json
+{
+    "success": true,
+    "secret": "aQ8Kt1EqRlj54Me3\",
+    "decryption":{
+        "epk":{
+            "x": "AeFSAOU2/rtNV4VS0uTr5M729jAU1RIZ+p90kRRbIac6x56y40bG39gc+oxykT
+                  ITDLgQER79+kVluCC+Lt6QSfaU\",
+            "y": "ASrjxo2XfkkkNTiq174Uhj++eNgwzt1iA/hRrYA/6tn8i4ZgPjIiBT0EybAvn8
+                  p3JQQmw6QKM38Ck5saMZcWF/4/\"
+        },
+        "wrapped_cek": "wucVMB63/N1jXTtIwF8WIbMU88X2NicJKwkyTX6eE4M4Fu1ZLcLIyA==\",
+        "aad": "ZXlKaGJHY2lPaUpGUTBSSUxVVlRLMEV5TlRaTFZ5SXNJbVZ1WXlJNklrRXlOVFpI
+                UTAwaUxDSmxjR3NpT25zaVkzSjJJam9pVUMwMU1qRWlMQ0pyZEhraU9pSkZReUlz
+                SW5naU9pSkJaVVpUUVU5Vk1sOXlkRTVXTkZaVE1IVlVjalZOTnpJNWFrRlZNVkpK
+                V2kxd09UQnJVbEppU1dGak5uZzFObmswTUdKSE16bG5ZeTF2ZUhsclZFbFVSRXhu
+                VVVWU056a3RhMVpzZFVORExVeDBObEZUWm1GVklpd2llU0k2SWtGVGNtcDRiekpZ
+                Wm10cmEwNVVhWEV4TnpSVmFHb3RMV1ZPWjNkNmRERnBRVjlvVW5KWlFWODJkRzQ0
+                YVRSYVoxQnFTV2xDVkRCRmVXSkJkbTQ0Y0ROS1VWRnRkelpSUzAwek9FTnJOWE5o
+                VFZwalYwWmZORjhpZlgw\",
+        "iv": "Aqy5VLobeoLXAdiq\",
+        "tag": "FKsIBoVn03SsONln0y66sw==\"
+    },
+    "token":{
+        "Jwt":"test-token"
+    }
+}
+```
+- `success`: Indicates if attestation was ultimately successful.
+- `secret`: The encrypted secret payload.
+- `decryption`: ECDH-ES-A256KW data needed to perform the handshake and derive
+the AES key for the encrypted payload. Data is formatted for decryption with
+ECDH-ES+A256KW, described in RFC 7518, section 4.6.2.
+- `token`: Token returned from server that contains the claims validated in the
+attestation. Could be serialized in JSON (JWT) or CBOR (CWT).
+
+With a successful attestation, SVSM can now use the secret payload for some
+purpose (for example, to unlock some persistent state required for booting the
+OS) and continue with execution.
+
 ## Attestation Host Proxy
 
 As there exists multiple protocols for TEE attestation, the host proxy is built
@@ -106,8 +261,7 @@ SEV-SNP machine with an SVSM-enabled kernel.
     git clone https://github.com/coconut-svsm/kbs-test.git
     cd kbs-test
     MEASUREMENT="$(${SVSM}/bin/igvmmeasure --check-kvm ${SVSM}/bin/coconut-qemu.igvm measure -b)"
-    HEX_EXPECTED_MEASUREMENT="$(echo $MEASUREMENT | xxd -p)"
-    cargo run -- --measurement $HEX_EXPECTED_MEASUREMENT
+    cargo run -- --measurement $MEASUREMENT --secret $HEX_SECRET
     ```
     This will run the `kbs-test` server at <http://0.0.0.0:8080>.
 

aproxy/Cargo.toml

@@ -5,10 +5,11 @@ edition = "2021"
 
 [target.'cfg(all(target_os = "linux"))'.dependencies]
 reqwest = { version = "0.12.9", default-features = false, features = ["blocking", "cookies", "json"] }
-kbs-types = "0.10.0"
+kbs-types.workspace = true
 
 [dependencies]
 anyhow = "1.0.93"
+base64 = { workspace = true, features = ["std"] }
 clap = { version = "4.5", features = ["derive"] }
 libaproxy.workspace = true
 serde.workspace = true