Skip to content

Lead verifier support #366

@thomas-fossati

Description

@thomas-fossati

We want to add support for multi-verifier arrangements in Veraison, starting with the hierarchical pattern described in draft-deshpande-rats-multi-verifier.

This involves adding "lead verifier" capabilities to the existing services.

Ideally, the lead verifier should use the same challenge-response API as the verification service.

Similarly, the core of the "multiple appraisal" business logic should be implemented as part of the Veraison TCB, i.e. in the VTS component. Note that the attestation results produced by the lead verifier must be signed by the Veraison service’s private key, which is only accessible to the VTS.
Note that while the appraisal of individual “component" evidence is delegated entirely to the “downstream" verifier, any intra-collection binding and cryptographic check that applies to composite evidence as a whole must be checked by the lead verifier.
(Note also that the same Veraison node could act as its own “downstream" verifier in a shallow recursive arrangement, dealing with composite evidence within the same node.)

As we cannot know in advance which APIs the “downstream" verifiers support, the connector logic must be designed to allow for extensibility. This can be achieved using Veraison's plugin system.

This results in an architecture that looks roughly like this:

   .--------------------------------------------------------------------------------------------.
  |  Lead Verifier            .----------------------------.                                     |
  |                           | Composite Evidence parsers |                                     |
  |                           |  .----------------------.  |                                     |
  |                           | | CMW collection         | |                                     |
  |                           |  '----------------------'  |                                     |
  |                           |  .----------------------.  |                                     |
  |                           | | EAT submod             | |                                     |
  |                           |  '----------------------'  |     .----------------------------.  |
  |                           '-------------+--------------'     | Component Verifier clients |  |
  |                                      CE |                    |  .----------------------.  |  |
  |                                         | {CE_i, ce_i-type}  | | VRSN                   | |  |
  |  .----------.                 .---------+--------.           |  '----------------------'  |  |
  |  |          |  CE, ce-type, n |                  | CE_i, n   |  .----------------------.  |  |
<--->+ REST API +-----------------+    CE Handler    +-----------+ | Intel TA               | +<---->
  |  |          | EAR             |                  | {AR_i}    |  '----------------------'  |  |
  |  '----------'                 '--+------------+--'           |  .----------------------.  |  |
  |                                  | parser     | client       | | NVIDIA                 | |  |
  |                          ce-type |  ce_i-type |              |  '----------------------'  |  |
  |                        .---------+-.    .----+-----.         '----------------------------'  |
  |                       | CE parsers |    | Dispatch |                                         |
  |                       | table      |    | table    |                                         |
  |                        '-----------'    '----------'    * CE (Composite Evidence)            |
   '--------------------------------------------------------------------------------------------'

Tasks Breakdown

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions