lavina jain jayesh vyas l.
Download
Skip this Video
Download Presentation
Analysis of Remote Attestation

Loading in 2 Seconds...

play fullscreen
1 / 15

Analysis of Remote Attestation - PowerPoint PPT Presentation


  • 247 Views
  • Uploaded on

Lavina Jain, Jayesh Vyas. Analysis of Remote Attestation. Presentation Outline. Remote Attestation Protocol proposed by IBM Remote Attestation Protocol that we propose Protocol model on Murphi Analysis and Attacks Conclusion. Client/Attestator. Kernel. Measurement list (ML). Hardware.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Analysis of Remote Attestation' - hang


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

Presentation Outline

  • Remote Attestation Protocol proposed by IBM
  • Remote Attestation Protocol that we propose
  • Protocol model on Murphi
  • Analysis and Attacks
  • Conclusion
slide3

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

slide4

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.

integrity measurement architecture ima
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

slide6

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.

slide7

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.
slide8

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.
slide9

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.
slide10

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
slide11

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.
slide12

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.
slide13

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

slide14

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.
slide15

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