5. Related Work

5.1 Software based Attestation

There have been several proposals for software-based attestation. One early example is Pioneer  \cite{Seshadri:2005:PVC:1095809.1095812} that provides device attestation without relying on a secure co-processor or any specialized hardware. It computes a checksum of device memory using a function that includes side-effects (e.g., status registers) in its computation, such that any emulation of this function incurs a timing overhead that is sufficient to detect cheating. Attestation that relies on time-based checksums has also been adapted to embedded devices in \cite{5270348},\cite{adrian2010},\cite{Li:2011:VVI:2046707.2046711}. However, some assumptions that form the basis for these solutions have been \cite{Shankar:2004:SES:1251375.1251382} challenged and several attacks on these (and similar) schemes have been proposed. Moreover, Kovah et al. \cite{Kovah:2012:NRT:2310656.2310679} showed that some time-based attestation schemes may be vulnerable to Time Of Check, Time Of Use(TOCTOU) attack. Alternative (non-time-based) approaches rely on filling the entire memory of the prover with random data to ensure an absence of malicious code. Although the timing is not essential here, this approach is still limited to one-hop attestation since it lacks the means to authenticate a remote prover. In general, all current software-only solutions rely on strong assumptions about the capabilities of the adversary and only work if the verifier communicates directly to the prover, with no intermediate hops. While applicable to specific settings, (e.g., attestation of computer peripherals), this approach is not viable for attestation performed over a network. 

5.2 Hardware based Attestation

An early example of this approach is Secure Boot \cite{Arbaugh:1997:SRB:882493.884371}. In it, system integrity is verified at boot time: the root of trust is a small bootloader which computes a hash of the content loaded into memory, and compares this to a signed hash stored in secure ROM. A device is only allowed to boot if the two hashes match. Nowadays, trusted platform modules (TPM) are present in many commercial systems, from phones to laptops. A TPM can compute an integrity checksum over the memory at boot time and send this checksum to be validated by a remote verifier. TPM can also protect a limited amount of data against a compromised operating system, e.g., hide an encryption key unless the Platform Configuration Registers (PCRs) are in a specific state. A TPM can store integrity measurements in PCRs in protected memory. Overall, security is based on two properties: (1) PCRs are accessible only via an API provided by the TPM and (2) measurements in the PCRs can only be extended, each new extension is computed using a cryptographic hash of the previous PCR value and the new measurement. The root of trust is the BIOS that performs the very first extension upon boot. Several concrete architectures have been proposed that rely on a TPM as a foundation \cite{5270348}.

6. Conclusion

In conclusion, in this report, we analyze the remote attestation protocol and successfully built a simulator to analyze the issues of the protocol and vulnerabilities. In our work, we identified that the original protocol was vulnerable to replay attack and man-in-the-middle attack which we presented a formidable solution. However, the modified version is not a complete solution as it doesn't provide protection against more complex attacks such as a combination of DDoS + replay type attacks. In summary, we have done the following: