Analysis of Remote Attestation
Lavina Jain, Jayesh Vyas
Presentation Outline
•
•
•
•
•
Remote Attestation Protocol proposed by IBM
Remote Attestation Protocol that we propose
Protocol model on Murphi
Analysis and Attacks
Conclusion
The Big Picture (Recap)
Client/Attestator
OS
BIOS
Extend PCR
with BIOS image
CRTM
Reset PCR
Measurement
list (ML)
Server/
Challenger
Remote
Attestation
Validate
Auth
Hardware
Extend PCR
with OS image
Hardware
Pre - boot
Integrity of kernel,
applications,
libraries, files
Kernel
Post - boot
Dynamic/Run-time
measurements Application
TPM
PCR
Keys
AIK
credential
request
AIK
Credential
Trusted
Third Party
Remote Attestation Protocol (as proposed by IBM)
Client/Attestator
1. 160-bit Nonce, N
TPM
PCR
Challenger
SigAIK (PCR, N)
3. Quote Response
N
2. Quote Request
Attestation
service
4. Integrity Response
{ SigAIK (PCR, N), ML,
AIKcert }
5. Integrity
Validation
Ver (SigAIK (PCR, N),
AIKpub) = true/false
Authentication on top
of SSL is not secure,
prone to MITM attack!!
Keys
Assumption: A secure session is set up between the client and the server.
Integrity Measurement Architecture (IMA)
Insmod
Measurement
list
Loader
/bin/sh, /bin/perl
Kernel Hooks
(Measurement
Agents)
Kernel
Boot Up
BIOS
TPM
PCR
CRTM
Hardware
Remote Attestation Protocol (as we propose)
C, Nc
Ns, SIGCA(S, PKs)
Three-step
Protocol
AIKcert obtained from TTP
C
EPKs(Secret, ML), SIGCA(C, AIKpub)
SIGAIKpvt(PCR, hash(Nc, Ns, Secret))
AIKpub/
AIKpvt
TPM Quote Response
S
PKs/
SKs
SIGSKs (Nc, AIKpub)
Four-step
SIGAIKpvt (Ns, PKs)
Five-step
Rational Construction using Murphi, with inputs from Prof. John and Prof. Dan.
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.
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.
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.
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
Step 3: Signature
using fake AIKpvt
and fake certificate
in step 3
Fake Certificate in
step 2
Client
Intruder
Fake Signature in
step 4
Server
Fake Signature in
step 5
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.
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.
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.
1. Get sign over
NS, NC, Secret
(Normal
Attestation)
2. Start a
malicious Attesting
service on client,
which uses
precomputed NS
and secret
Intruder
3. Give the
malicious Attestor,
signature
generated in step
1
Client
Server
4. Normal Attestation, but
Server’s nonce (NS) is already
known to client/attacker
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.
References
1. Trusted Computing Group, http://www.trustedcomputing.org
2. Reiner Sailer, Trent Jaeger, Xiaolan Zhang, Leendert van Doorn, “Attestationbased 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