Update ssh-key-exchange.md

Fix broken links.

Author: jlarrew

docs/ssh-key-exchange.md

@@ -6,8 +6,8 @@ In this example, a Guest Owner will request a new guest instance from a remote c
 
 The following diagram shows the high-level component relationships:
 
-[design]: docs/images/remote-attestation-design.jpg "Remote Attestation Design"
-![design](docs/images/remote-attestation-design.jpg)
+[design]: images/remote-attestation-design.jpg "Remote Attestation Design"
+![design](images/remote-attestation-design.jpg)
 
 **Cloud Provider CLI/VMM**
 * This component includes the user interface to the Cloud Provider's infrastructure as well as the backend virtual machine manager that is responsible for launching guest images.
@@ -93,7 +93,7 @@ Untrusted components are assumed to be malicious and may be conspiring with each
 
 ## Cloud-init user-data integrity
 
-Since our threat model considers all cloud-provider infrastructure to be untrusted, it must be noted that the user-data provided to cloud-init has no integrity protection. Thus, it is possible for a malicious actor to alter the guest configuration, run arbitrary commands, or prevent key commands from running. One way to address this is to perform the attestation flow in this example earlier in the boot process, such as in the initrd, and make use of a measured boot scheme to protect the initrd. Future examples in this repository will demonstrate this approach. See [Future Work](#future-work) below.
+Since our threat model considers all cloud-provider infrastructure to be untrusted, it must be noted that the user-data provided to cloud-init has no integrity protection. Thus, it is possible for a malicious actor to alter the guest configuration, run arbitrary commands, or prevent key commands from running. One way to address this is to perform the attestation flow in this example earlier in the boot process, such as in the initrd, and make use of a measured boot scheme to protect the initrd. Future examples in this repository will demonstrate this approach. See [Future Work](../README.md#future-work).
 
 ## Identity
 In this example, the Guest Owner verifies the SNP attestation report with the following series of checks:
@@ -106,8 +106,8 @@ In this example, the Guest Owner verifies the SNP attestation report with the fo
 
 In the SEV-SNP architecture, the identity of the guest instance is established by the ID Block, which contains the public portion of a key pair that identifies the Guest Owner. This key is called the ID key. The ID block also contains the expected launch measurement of the guest instance. This ID block is copied into guest memory by the SEV-SNP firmware during the launch sequence and binds the Guest Owner's identity to that guest instance. If the ID block is present for a guest instance, then the attestation report generated by the SEV-SNP firmware will contain the hash of the ID key as well as the expected launch measurement. In this way, the attestation report attests to both the identity of the guest instance as well as the launch integrity.
 
-This example does not yet configure the ID block when launching the guest, so the ID key and the launch measurement are currently set to 0 in the attestation report. As such, they are not checked by the Guest Owner. To realize the full security promise of SEV-SNP, production environments must configure these fields during launch. Similarly, Guest Owners should validate these fields in the attestation report in addition to the checks listed above. Future updates to this repository will demonstrate how to do this. See [Future Work](#future-work) below.
+This example does not yet configure the ID block when launching the guest, so the ID key and the launch measurement are currently set to 0 in the attestation report. As such, they are not checked by the Guest Owner. To realize the full security promise of SEV-SNP, production environments must configure these fields during launch. Similarly, Guest Owners should validate these fields in the attestation report in addition to the checks listed above. Future updates to this repository will demonstrate how to do this. See [Future Work](../README.md#future-work).
 
 ## Disk Image Protection
 
-While SEV-SNP provides strong confidentiality and integrity guarantees for data in use, these protections do not extend to data at rest. Specifically, the virtual disk that contains the guest's root filesystem is typically implemented as a file under the control of the hypervisor. Since the hypervisor is untrusted in this example, a complete solution would include an encrypted disk image to protect the confidentiality of the filesystem. Future examples in this repository will demonstrate how to use the attestation flow to setup a secure communication channel early in the guest boot sequence and receive the key to unlock an encrypted disk. See [Future Work](#future-work) below.
+While SEV-SNP provides strong confidentiality and integrity guarantees for data in use, these protections do not extend to data at rest. Specifically, the virtual disk that contains the guest's root filesystem is typically implemented as a file under the control of the hypervisor. Since the hypervisor is untrusted in this example, a complete solution would include an encrypted disk image to protect the confidentiality of the filesystem. Future examples in this repository will demonstrate how to use the attestation flow to setup a secure communication channel early in the guest boot sequence and receive the key to unlock an encrypted disk. See [Future Work](../README.md#future-work).