This repository contains attestation services assembled using Veraison components.
This section contains the instructions for creating a test deployment of Veraison services and trying out the end-to-end attestation flow using sample inputs. You have two options for the deployment: either via Docker, or natively.
This should work on most Linux systems. You need to perform the following setup:
- Install git
- Install Docker, and make sure that the current user is in the
dockergroup. - Install jq
- (optionally) Install tmux -- this only needed if you want to use it.
On Ubuntu you can do this with:
sudo apt install git docker.io jq tmux
sudo usermod -a -G docker $USER
newgrp docker
You can build, deploy, and start Veraison services with the following sequence of commands:
git clone https://github.com/veraison/services.git
cd services
make docker-deploy
The whole process might take a few minutes. Once the above finishes, Veraison
services should be running inside Docker containers. You can use the deployment
frontend script to check their status (you can set it up by sourcing the
deployment's env.bash):
source deployments/docker/env.bash
veraison status
The veraison command allows starting and stopping veraison services and
viewing and manipulating Veraison logs and stores. See the output of veraison -h for the full list of available commands.
Warning
The docker deployment is not suitable for production. It is only intended to be used in development environments. It is not hardened and cannot handle high traffic volumes.
Clone and cd into the repo:
git clone https://github.com/veraison/services.git
cd services
Please see the native deployment README for the full description of dependencies. We have bootstrap scripts for Ubuntu, Arch, and MacOSX that ensure that the required dependencies are installed.
make bootstrap
This will invoke the system package manager via sudo, so you may be prompted for your password.
If you are on a different OS, please look at one of the scripts under deployments/native/bootstrap/ and install the equivalent packages for your system (on MacOS, they should be available via brew).
Veraison will be deployed into the directory specified by VERAISON_ROOT
environment variable (or into ${HOME}/veraison-deployment if it is not set).
export VERAISON_ROOT=${HOME}/veraison-deployment
You can build, deploy, and start Veraison services with the following sequence of commands:
make native-deploy
The whole process might take a few minutes.
You can interact with the deployment via the frontend,
${VERAISON_ROOT}/bin/varaison. You can alias the script to just veraison by
source an env file from the deployment:
source ${VERAISON_ROOT}/env/env.bash
(there is an equivalent env.zsh for zsh).
If you are on a Linux distribution with systemd or on MacOSX, Veraison services should be running as user systemd units/launchd user agents. Otherwise, you can run the services inside virtual terminals with
veraison start-term
(If you have tmux installed, and would prefer to use a tmux session rather than
multiple terminals, you can use veraison start-tmux instead.)
Important
Windows Subsystem for Linux (WSL) users: WSL does not support user
systemd services or spawning virtual terminals, so Veraison will not be
running after make native-deploy, and veraison start-term command will
not work (it will say "no suitable terminal found"). So the only option for
running veraison under WSL is using veraison start-tmux (or by manually
launching service executables).
You can interact with the deployment via the frontend script. Please see the script help for details:
veraison -h
Please see deployments/native/README.md for more detailed explanation and step-by-step manual deployment instructions.
An example of an end-to-end provisioning and verification flow exists
within end-to-end directory. This can be used to quickly check the
deployment (alternatively, you can use make integ-test to run the integration
tests).
Note
see end-to-end/README.md for a more detailed explanation of the flow.
Note
There are versions of the script for native and docker deployments. Listings below assume docker deployment; if you're using the native deployment, change script suffix to "-native"
Before evidence can be attested, trust anchors and reference values need to
provisioned. These are contained within
end-to-end/inputs/psa-endorsements.cbor and can be provisioned with
end-to-end/end-to-end-docker provision
If this does not return an error, the values have been successfully provisioned. You can verify this by checking the contents of the Veraison stores with
veraison stores
You should see a list of JSON structures of the provision values.
You can now verify the evidence with
end-to-end/end-to-end-docker verify rp
This should output the EAR attestation result. The "rp" means you're verifying as the Relying Party; you can also specify "attest" to verify as an attester.
Provisioning service provides a REST-based API for external trusted supply chain actors (for example, Endorsers) to provision Reference Values, Endorsed Values (known as Endorsements), and Trust Anchors into Veraison Trusted Services.
This service acts as a frontend for accepting a CoRIM payload containing Endorsements and Trust Anchors. On the back end it communicates with VTS which receives the payload and uses Attestation Scheme (e.g. PSA) specific decoders to extract, store, retrieve, and manage the Endorsements and Trust Anchors. The API details are documented under Endorsement Provisioning Interface. This service accept a variety of Endorsement Formats. For now, PSA (Profile 1 & Profile 2), CCA, TPM and Parsec (CCA and TPM) based Endorsements are supported.
Refer to scope for full set of services that shall be provided by the provisioning service.
Verification service provides a REST-based API for external Attesters or Relying Parties (known as Challengers) to submit Attestation token, containing Attestation Evidence claims. On the back end, it communicates with VTS to appraise the received Evidence and receive the Attestation Verification Results, which are then passed to the challenger.
This service acts as a frontend for accepting a variety of attestation token formats. For now, PSA (Profile 1 & Profile 2), CCA and TPM-based attestation tokens are supported.
The API is based on the Challenge/Response Interaction Models as documented in challenge-response
Veraison Trusted Services (VTS) backend provides core services to the
Verification and Provisioning frontends. On the Provisioning path, it receives
a CoRIM payload from the Provisioning frontend, invokes
Attestation Scheme (e.g. PSA) specific logic to decode the payload and generate
Endorsements and Trust Anchors, and saves them in the corresponding stores. On
the Verification path, it invokes Attestation Scheme specific logic to parse
attestation token and extract evidence claims. From these claims, it constructs
a logical index/key to fetch the trust anchors required to verify the token
signature, and the associated Endorsements (golden values) used to appraise
the evidence claims. Upon evaluation, it populates the Attestation Result and
communicates it to the Verification frontend.
More details about the VTS can be found under VTS
The key-values store is the Veraison Storage Layer. It is used to store both Endorsements and Trust Anchors.
KV Store details can be found under kvstore