Analysis of Remote Attestation

1. Lavina Jain, Jayesh Vyas Analysis of Remote Attestation

2. Presentation Outline • Remote Attestation Protocol proposed by IBM • Remote Attestation Protocol that we propose • Protocol model on Murphi • Analysis and Attacks • Conclusion

3. Client/Attestator Kernel Measurement list (ML) Hardware TPM PCR Keys The Big Picture (Recap) Server/ Challenger Dynamic/Run-time measurements Application Post - boot Integrity of kernel, applications, libraries, files Remote Attestation OS Validate Auth Extend PCR with OS image AIK credential request BIOS Trusted Third Party Pre - boot Extend PCR with BIOS image CRTM AIK Credential Reset PCR Hardware

4. Remote Attestation Protocol (as proposed by IBM) Client/Attestator 1. 160-bit Nonce, N Attestation service Challenger 4. Integrity Response { SigAIK (PCR, N), ML, AIKcert } 5. Integrity Validation N 2. Quote Request SigAIK (PCR, N) 3. Quote Response Ver (SigAIK (PCR, N), AIKpub) = true/false Authentication on top of SSL is not secure, prone to MITM attack!! TPM PCR Keys Assumption: A secure session is set up between the client and the server.

5. Integrity Measurement Architecture (IMA) Kernel Hooks (Measurement Agents) Insmod Loader /bin/sh, /bin/perl Update PCR_Extend Measurement list Kernel Boot Up PCR_Extend(OS) BIOS TPM PCR PCR_Extend(BIOS) CRTM Reset PCR Hardware

6. S PKs/ SKs C AIKpub/ AIKpvt C, Nc Ns, SIGCA(S, PKs) Three-step Protocol AIKcert obtained from TTP EPKs(Secret, ML), SIGCA(C, AIKpub) SIGAIKpvt(PCR, hash(Nc, Ns, Secret)) TPM Quote Response SIGSKs(Nc, AIKpub) Four-step SIGAIKpvt(Ns, PKs) Five-step Remote Attestation Protocol (as we propose) Rational Construction using Murphi, with inputs from Prof. John and Prof. Dan.

7. Murphi Model • Entities modeled in Murphi: • Client – Attestator, who wants to attest it’s platform to remote server. • Server – Challenger, wants to determine it’s trust in client. • Intruder – Malicious entity on network. • Attacker – Malicious entity on client. • Super Attacker – Capable of hardware attacks on TPM (Eg. PCR Reset). • Assumptions: • CRTM(BIOS boot block) that initiates chain of measurements is trusted. • TPM is trusted. • CPU is trusted. • Memory cannot be hacked at runtime (e.g. via DMA). • Flags that can be set or reset to study the behavior of protocol: • FOUR_STEP: Run four-step protocol. • FIVE_STEP: Run five step protocol. • CERT_FORGED: Intruder can forge a certificate issued by CA. • SUPER_ATTACKER: Enable hardware attacks when this flag is true. • TPM_COMPROMISED: TPM on intruder is compromised (she knows AIKpvt). • SERVER_NONCE_PREDICTABLE: To model predictable nonces.

8. Murphi Model (contd.) • Behavior of model: • Both client and intruder are equipped with a TPM chip. • Intruder is malicious, so TPM quote response always contains an invalid PCR value on intruder. • If attacker is active on client, then TPM quote response contains an invalid PCR value. • If super attacker is active on client, then TPM quote response contains a valid value. • Client always sends a valid measurement list (ML), because an attacker/super attacker can always modify ML to reflect a valid value. • Invariants: • Authentication invariants. • Secrecy invariants: • Client and server should share the same session secret. • Intruder should not learn any session secret. • Remote attestation invariants: • If server attests a client, then attacker should not be active on that client. • Server must not attest an intruder.

9. Attacks Three-step protocol • Authentication and secrecy invariants fail. • Remote attestation invariants fail if intruder is allowed to forge certificates, super attacker is active or TPM is compromised. Four-step protocol • Client authentication invariant fails, but server authentication invariant does not fail. • Secrecy invariants still fail because of MITM attack. • Remote attestation invariants fail as in 3-step protocol. Five-step protocol • Authentication invariants do not fail in any case. • Secrecy invariants do not fail until intruder is allowed to forge certificates. • Remote attestation invariant fail as in 4-step protocol. Conclusion • The proposed protocol refuses to attest a malicious client unless: • Certificates can be forged. • Hardware attack on TPM is possible. • TPM is compromised.

10. Step 3: Signature using fake AIKpvt and fake certificate in step 3 Fake Certificate in step 2 Client Intruder Server Fake Signature in step 4 Fake Signature in step 5 Attacks (Certificate Forging) • Intruder can forge certificates or can convince client/server to trust on forged certificates. • Most severe attack! • Can generate fake signatures over PCR and Nonces, which look like a signatures from a real TPM. • Can impersonate as a server to a client and vice versa, and learn secrets. • All attacks are possible: Authentication attacks, secrecy attacks and attestation attacks. • Example: MITM Attack

11. Hardware Attacks and Attacks on IMA • Attacker’s objective is to hide the presence of a malicious software running on client • Possible ways: • Bug in Integrity Measurement Architecture (IMA): It did not measure the malicious software and put it in PCRs. • Reset PCRs without rebooting the system, and push known good values into it. • Hardware attacks like changing a running process’s image (through DMA). • Break the TPM and retrieve secret key used for signing PCR. • Consequence: An attacker is able to start a malicious software without letting its fingerprints go into the PCRs. • Modeled as SUPER_ATTACKER in Murphy. • Attack: A client running a malicious software gets attested by server.

12. TPM on Intruder Compromised • Intruder breaks the TPM and retrieves AIKpvt. • Intruder can attest itself to the server. • Can it do more harm? • No other attack found. • Encouraging because if one TPM is compromised, it does not compromise the security of other systems.

13. Predictable Server Nonce • Server uses a bad source of randomness, and so its nonce is predictable. • Client can pre-compute signature over that nonce and PCRs before a malicious application starts (that is when PCRs have trustworthy value) • But a client that does so is itself malicious! • So two hosts need to collude to mount an attack. Intruder 3. Give the malicious Attestor, signature generated in step 1 1. Get sign over NS, NC, Secret (Normal Attestation) 2. Start a malicious Attesting service on client, which uses precomputed NS and secret Client Server 4. Normal Attestation, but Server’s nonce (NS) is already known to client/attacker

14. Conclusions • The proposed protocol for remote attestation is secure under the following assumptions: • CRTM and CPU are trusted • TPM adheres to TCG’s specifications • IMA (Integrity Measurement Architecture) is bug free • A running process behavior or image cannot be changed (e.g. via DMA) • A malicious platform can be attested by: • Forging certificates • Hardware attacks (DMA, resetting PCRs) • Breaking the IMA and retrieving keys • Predicting server/challenger’s nonce • Attacks were found and confirmed by modeling the protocol on Murphi.

15. References • 1. Trusted Computing Group, http://www.trustedcomputing.org • 2. Reiner Sailer, Trent Jaeger, Xiaolan Zhang, Leendert van Doorn, “Attestation-based Policy Enforcement for Remote Access”, In Proceedings of the 11th ACM conference on Computer and Communications Security, October 2004. • 3. Reiner Sailer, Xiaolan Zhang, Trent Jaeger and Leendert van Doorn, “Design and Implementation of a TCG-Based Integrity Measurement Architecture”, In Thirteenth Usenix Security Symposium, pages 223-238, August 2004. • 4. H. Maruyama, T. Nakamura, S. Munetoh, Y. Funaki, Y. Yamashita, “Linux with TCPA Integrity Measurement”, IBM Research Report, Tokyo Research Laboratory, Japan, Jan. 2003. • 5. D. Safford, J. Kravitz, and L. van Doorn, “Take Control of TCPA”, Linux Journal, pages 50-55, August 2003. • 6. Karim Faez, Ashkan H. Karimabad, “Open-Source Applications of TCPA Hardware”, In International Journal of Computer Science and Network Security, Vol. 7, No. 3, March 2007. • 7. Murphi description language and verifier, http://verify.stanford.edu/dill/murphi.html