CHARRA: CHAllenge-Response based Remote Attestation with TPM 2.0

This is a proof-of-concept implementation of the "Challenge/Response Remote Attestation" interaction model of the IETF RATS Reference Interaction Models for Remote Attestation Procedures using TPM 2.0. The IETF Remote Attestation Procedures (RATS) working group standardizes formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to relying parties. Given the security and privacy sensitive nature of these assertions/claims, the working group specifies approaches to protect this exchanged data.

This proof-of-concept implementation realizes the Attesting Computing Environment—a Computing Environment capable of monitoring and attesting a target Computing Environment—as well as the target Computing Environment itself, as described in the RATS Architecture.

Quickstart

The following assumes that Docker and its buildx component (and Docker Compose) are installed and configured on your system. Please see INSTALL.md for details, also for manually building CHARRA. All commands are to be executed in Bash.

For Docker, build the image and run the container with:

./docker/build.sh
./docker/run.sh

With Docker Compose do:

docker-compose build --build-arg uid="${UID}" --build-arg gid="${UID}"
docker-compose run --rm charra-dev-env

Inside the container, change to the ~/charra/ folder, build it, and run it (you can use your arrow keys to navigate the Bash history; it is already populated with all the commands):

cd ~/charra/
make -j
./generate-ak.sh
(bin/attester --config charra-attester-config.yml &); sleep .2 ; bin/verifier --config charra-verifier-config.yml ; sleep 1 ; pkill -SIGINT attester

Using the Quicktest Script

Inside the container, you can test compilation and execution of CHARRA as well as all code examples by running:

./test-charra-and-tpm2-tss.sh

CHARRA Container Flavors

Besides the default Dockerfile, there are some more container flavors available:

• Dockerfile:
  • Development environment based on Ubuntu with, e.g., man pages, debug tools, etc.
  • Build it with: ./docker/build.sh
  • Run it with: ./docker/run.sh
• Dockerfile.app:
  • Runtime environment based on Ubuntu with only necessary dependencies
  • Build it with: ./docker/build.sh app
  • Run it with: ./docker/run.sh app
• Dockerfile.alpine:
  • Development environment based on Alpine with, e.g., man pages, debug tools, etc.
  • Build it with: ./docker/build.sh alpine
  • Run it with: ./docker/run.sh alpine
• Dockerfile.alpine.app:
  • Runtime environment based on Alpine with only necessary dependencies
  • Build it with: ./docker/build.sh alpine.app
  • Run it with: ./docker/run.sh alpine.app

How it Works: Protocol Flow

The following diagram shows the protocol flow of the CHARRA attestation process.

.----------.                                    .----------.
| Attester |                                    | Verifier |
'----------'                                    '----------'
     |                                                |
     | <----- requestAttestation(nonce, keyID, pcrSelection)
     |                                                |
tpmQuote(nonce, pcrSelection)                         |
     | => evidence                                    |
     |                                                |
 evidence ------------------------------------------> |
     |                                                |
     |      appraiseEvidence(evidence, nonce, referencePcrs)
     |                           attestationResult <= |
     |                                                |

Changelog

You find the changelog in CHANGELOG.md.

Next Steps

• Allow verifier to perform periodic attestations, e.g., perform attestation every 10 seconds.
• Refactor and implement forward-declared (but not yet implemented) functions.
• Use non-zero reference PCRs.
• "Extended" TPM Quote using TPM audit session(s) and TPM PCR Read operations.
• Make CHARRA a library (libcharra) and make attester and verifier example code in example folder.
• Add *_free() functions for all data transfer objects (DTOs).
• Introduce semantic versioning as CHARRA develops along the way to become stable.

The order of the list is entirely arbitrary and does not reflect any priorities.