SEDAT:Security Enhanced Device Attestation with TPM2.0

Abstract

Remote attestation is one of the ways to verify the state of an untrusted device. Earlier research has attempted remote verification of a device's state using hardware, software, or hybrid approaches. Majority of them have used Attestation Key as a hardware root of trust, which does not detect hardware modification or couterfiet issues. In addition, they do not have a secure communication channel between verifier and prover, which makes them susceptible to mordern security attacks. This paper presents SEDAT, a novel methodology for remote attestation of the device via a security enhanced communication channel. SEDAT performs hardware, firmware, and software attestation. SEDAT enhances the communication protocol security between verifier and prover by using the Single Packet Authorization (SPA) technique, which provides replay and Denial of Service (DoS) protection. SEDAT provides a way for verifier to get ondemand device integrity and authenticity status via a secure channel. It also enables the verifier to detect counterfeit hardware, change in firmware, and software code on the device. SEDAT validates the manufacturer's root CA certificate, platform certificate, endorsement certificate (EK), and attributes certificates to perform platform hardware attestation. SEDAT is the first known tool that represents firmware, and Integrity Measurement Authority (IMA) event logs in the Canonical Event Logs (CEL) format (recommended by Trusted Computing Group). SEDAT is the first implementation, to the best of our knowledge, that showcases end to end hardware, firmware, and software remote attestation using Trusted Platform Module (TPM2.0) which is resilient to DoS and replay attacks. SEDAT is the first remote verifier that is capable of retrieving a TPM2.0 quote from prover and validate it after regeneration, using a software TPM2.0 quote check. All source code, tools, and kernel patches are open-sourced via BSD 2-Clause License.

Firmware Integrity Protection: A Survey

“…We can for example mention the Evil Maid attack [46] which consists in capturing the device while it is left unattended (for example in a hotel room) and then making the desired alterations on the system. We can also note that protecting the system from these attacks is seldom considered [47], [48], [49], [50].…”

“…It is the element which is considered as de facto secure. In the case of secure boot this element can be a piece of software like a first stage bootloader [109], [110] or a hardware module like a TPM [46], [50], [111], [112], a smartcard [112], [113] or another hardware module [114], [115]. The next layer is measured by the current one then this measurement is verified.…”

“…TPM can be used as storage for cryptographic material and only allow its reading under certain conditions as in the approach of Hudson et al [46]. It can also be used to measure the integrity of the boot chain layers [50], [112], [124]. TPM have the advantage of being factory-integrated on recent generalpurpose computers and can be implemented on a large number of others.…”

“…The final value of a PCR is thus a chain of hashes of all the pieces of data that have been measured since the TPM was powered up, thus ensuring the integrity of the entire chain if the last hash is equal to the known good value. This method is used by Trammell Hudson [46] and Avani et al [50]. The main drawbacks of using an hardware TPM module are the usage of dedicated hardware increasing the cost of the final system, the reliance on a TPM chip manufacturer and the compatibility issues that may potentially exist with some platforms.…”

“…The first idea is to use a ROM to store the first piece of code which will be executed and which will do the first measurement [50], [91], [114], [116]. The approaches of Adnan et al [109] and Haj-Yahya et al [55] store the First Stage BootLoader (FSBL, ie.…”