Skip to content

workPlan

Jump to bottom Edit New page
Perry Alexander edited this page Jan 6, 2015 · 56 revisions

Demonstrations

Basic demonstrations getting to a basic system by the end of summer 2014.

Demonstration 1:

This is an exceptionally naïve appraisal that uses a traditional asymmetric key, k, rather than an AIK or EK for signing and assumes the appraiser has a public key for the target’s TPM.

  1. Appraiser sends a request <d,n> to an attestation agent for PCRs
    • d - desired PCRs
    • n - nonce
  2. Attestation agent creates a quote sign{q,n}{k}
  3. Attestation returns the quote
  4. Appraiser checks the returned evidence
    • checks the signature
    • checks the nonce
    • checks PCR values
  5. Provide an argument for correctness

Assumptions:

  • Every VM has an associated assymetric key, k, whose public key is known to other VMs.
  • Every VM has a known communication path to every other VM.

Demonstration 2:

This continues to be naïve, but uses an attestation protocol and returns an evidence package. The evidence package integrity is guaranteed and linked to the quote by the hash returned in the quote. The quote is used to evaluate the data and the data in turn used to evaluate the target system.

  1. Appraiser sends a request <d,n> to an attestation agent for PCRs
    • d - desire evidence
    • n - nonce
  2. Appraiser selects a protocol based on d
  3. Attestation agent executes the protocol
    • Gather evidence, e, from application
    • Creates an evidence package, sign{<e,n>}{k}
    • Creates a quote sign{q,#<e,n>}{k}
  4. Attestation returns the quote and evidence
  5. Appraiser checks the returned quote and evidence
    • checks the signature of the quote
    • checks the evidence package using #<e,n>
    • checks n
    • checks e
  6. Provide an argument for correctness

Assumptions:

Same as Demo 1

Demonstration 3:

Repeat Demonstration 2 using an AIK and a Certificate Authority. Specifically, build an implementation of the Privacy CA-based described in our verification papers.

This continues to be naïve, but uses an attestation protocol and returns an evidence package.

  1. Appraiser sends a request <d, pcrSelect, n> to an attestation agent for PCRs
    • d - desire evidence
    • pcrSelect - TPM structure(TPM_PCR_SELECT) that specifies the PCR registers to include in the quote
    • n - nonce
  2. Attestation selects a protocol based on d
  3. Attestation agent executes the protocol
    • Gather evidence, e, from application
    • Creates an evidence package, sign{<e,n>}{k}
    • Creates a quote, sign{pcrComposite}{k} (Note: #<e,n> is included as "external data" input to tpm_quote command)
  4. Attestation returns the evidence package and quote
  5. Appraiser checks the returned quote and evidence
    • checks the signature of the evidence package
    • checks the signature of the quote ( Note: This involves building the TPM structure TPM_QUOTE_INFO which includes #pcrComposite and #<e,n>. Successful verification of the signature of this structure ensures multiple things: 1) the identity of the Attestation agent that produced the quote, 2) the integrity of the evidence package, and 3) the integrity of the pcrComposite. )
    • checks n
    • checks contents of pcrComposite (against "golden" value)
    • checks contents of e (against "golden" values)
  6. Provide an argument for correctness

Assumptions:

Demonstration 4:

Repeat Demonstration 2 using an AIK and a Certificate Authority. This will be the first real protocol that we do. First, the Attestation Manager must generate and certify an AIK from its associated TPM

  1. Attestation Manager generates a new AIK using the TPM
  2. AM sends its platformID and the AIK to a dummy Certificate Authority (CA)
  3. CA produces a certificate by signing the AIK with its private key: sign{AIK}{CA} (call it caCert)
  4. CA creates a session key K and encrypts caCert with K
  5. CA encrypts {K, AIK} with EK from Attestation Manager associated with provided platformID
  6. CA returns encrypt{caCert}{K} and encrypt{K, AIK}{EK} to Attestation Manager
  7. Attestation Manager extracts the session key K from the second part of the previous message(using tpm_activate_identity command) and uses K to decrypt the first message to obtain caCert

The attestation protocol now behaves almost as before with some changes:

  1. Appraiser sends a request <d, pcrSelect, n> to an attestation agent for PCRs
    • d - desire evidence
    • pcrSelect - TPM structure(TPM_PCR_SELECT) that specifies the PCR registers to include in the quote
    • n - nonce
  2. Attestation selects a protocol based on d
  3. Attestation agent executes the protocol
    • Gather evidence, e, from measurer
    • Creates an evidence package, {<e,n>}
    • Creates a quote, sign{pcrComposite, #(<e,n> | caCert)}{AIK} (Note: #(<e,n> | caCert) is included as "external data" input to tpm_quote command)
  4. Attestation returns the evidence package, quote, and signed AIK(caCert) generated by the CA. (Note: For now, the caCert and evidence package integrity are assured by passing them as input to the tpm_quote command. In a future demo, we may want to explore alternative mechanisms(such as enveloping signing keys).
  5. Appraiser checks the returned quote and evidence
    • checks the signature of the quote ( Note: This involves building the TPM structure TPM_QUOTE_INFO which includes #pcrComposite and #(<e,n> | caCert). Successful verification of the signature of this structure ensures multiple things: 1) the identity of the Attestation agent that produced the quote, 2) the integrity of the evidence package, 3) the integrity of caCert, and 4) the integrity of the pcrComposite. )
    • checks caCert signature
    • checks n
    • checks contents of pcrComposite (against "golden" value)
    • checks contents of e (against "golden" values)
  6. Provide an argument for correctness
  7. Manual migration (open for discussion)

Note that signing of the quote and evidence hash is now done using the AIK generated by the TPM and certified by the dummy CA. Note also that we need to get the measurer formally hooked into the attestation process.

Experiments

  1. Successful end-to-end protocol execution with all checks
  2. Bad evidence detected by Appraiser using E
  3. Bad AIK certification detected by Appraiser
  4. Bad AIK signature on response from Attestation agent
  5. Bad Attester identified by Appraiser using PCR composite

Are there others we can identify?

Assumptions

  1. CA's public key and address are well known to all actors in the protocol
  2. CA knows the Attestation Managers public EK and identity a priori
  3. Golden hash values for PCRs and golden measurements are known by the Appraiser

Are there other assumptions that should be documented?

Goals of the demonstrations:

  • Demonstrate basic functionality and explore implementations
  • Develop arguments for correctness as we build implementations
  • Develop requirements for our EDSL for trust
  • Identify what we've missed and what we don't need

Demonstration 4:

Repeat Demonstration 2 using an AIK and a Certificate Authority. This will be the first real protocol that we do. First, the Attestation Manager must generate and certify an AIK from its associated TPM

  1. Attestation Manager a new AIK using the TPM
  2. Send the AIK to a dummy Certificate Authority (CA)
  3. CA signs the AIK with its private key
  4. CA encrypts sign{AIK}{CA} with EK from Attestation Manager
  5. CA returns encrypt{sign{AIK}{CA}}{EK} to Attestation Manager
  6. Attestation Manager decrypts package to obtain sign{AIK}{CA}

The attestation protocol now behaves almost as before with some changes:

  1. Appraiser sends a request <d, pcrSelect, n> to an attestation agent for PCRs
    • d - desire evidence
    • pcrSelect - TPM structure(TPM_PCR_SELECT) that specifies the PCR registers to include in the quote
    • n - nonce
  2. Attestation selects a protocol based on d
  3. Attestation agent executes the protocol
    • Gather evidence, e, from measurer
    • Creates an evidence package, sign{<e,n>}{AIK}
    • Creates a quote, sign{pcrComposite}{AIK} (Note: #<e,n> is included as "external data" input to tpm_quote command)
  4. Attestation returns the evidence package, quote and signed AIK generated by the CA. (Note: The signed AIK and evidence package integrity must be assured by signature or other mechanism that must be determined.)
  5. Appraiser checks the returned quote and evidence
    • checks the signature of the evidence package
    • checks the signature of the quote ( Note: This involves building the TPM structure TPM_QUOTE_INFO which includes #pcrComposite and #<e,n>. Successful verification of the signature of this structure ensures multiple things: 1) the identity of the Attestation agent that produced the quote, 2) the integrity of the evidence package, and 3) the integrity of the pcrComposite. )
    • checks sign{AIK}{CA}
    • checks n
    • checks contents of pcrComposite (against "golden" value)
    • checks contents of e (against "golden" values)
  6. Provide an argument for correctness
  7. Manual migration (open for discussion)

Note that signing of the quote and evidence hash is now done using the AIK generate by the TPM and certified by the dummy CA. Note also that we need to get the measurer formally hooked into the attestation process.

Experiments

  1. Successful end-to-end protocol execution with all checks
  2. Bad evidence detected by Appraiser using E
  3. Bad AIK certification detected by Appraiser
  4. Bad AIK signature on response from Attestation agent
  5. Bad Attester identified by Appraiser using PCR composite

Are there others we can identify?

Assumptions

  1. CA's public key and address are well known to all actors in the protocol
  2. CA knows the Attestation Managers public EK and identity a priori
  3. Golden hash values for PCRs and golden measurements are known by the Appraiser

Are there other assumptions that should be documented?

Goals of the demonstrations:

  • Demonstrate basic functionality and explore implementations
  • Develop arguments for correctness as we build implementations
  • Develop requirements for our EDSL for trust
  • Identify what we've missed and what we don't need

On Site Demonstration

January 15, Sterling Rd facility

Goals

ToDo

Slides - Draft by 1/12

  • Intro and big picture - @perry
  • Refine to implementation - @perry
  • Protocol execution - @adam @perry
    • protocol description
    • protocol semantics
    • step-by-step execution
  • Measurement - @jason @prasad
    • mechanism
    • measured application
  • Appraisal - @adam @perry
  • Communication - @justin @andy @paul
    • mechanism e.g. vchan
    • JSON structures
  • Stepwise demonstration - @adam @perry
    • step-by-step execution (see above)

Software - Draft by 1/12

  • Demonstration software - @adam @justin @jason @paul

Logistics

  • Contact information to Tim - @perry
  • Travel plans
Add a custom footer
Add a custom sidebar

Clone this wiki locally