Skip to main content

Policy Introduction

The policy is an augmentation of the baseline BRSKI protocol, which facilitates network owners in determining policies for allowing devices onto the network and granting permissions to trust different entities. Implemented as a Rust library, the policy provides methods for the registrar to assess whether a manufacturer of devices should be trusted to validate the idevID of connecting devices, if a device can be trusted to onboard to the network, and whether a device is vulnerable. Data used to evaluate the policy is stored in an SQLite database, and information is submitted to the database through verifiable credentials (VCs).

The policy allows a network owner to enter users into their organization and set their permission levels. This enables users to trust other users to issue trust to additional users or to connect devices.

There are 5 components of the policy infrastructure:

  • a set of schemas defining the structure for claims submitted to the registrar as VCs. These are used with our vc toolchain to initialize schemas on a tdx volt instance.
  • a Rust library providing functions to evaluate the policy. These functions take an idevID and the path to the SQLite database.
  • a VC REST API connected to a tdx volt, used to sign and verify VCs. One instance runs on the registrar, and another on an agent's machine wishing to submit information to the registrar. Both instances connect to the same tdx volt instance, which may run on the registrar or another remote machine. When a claim is submitted to this REST API, the route specifies the schema to use, and the body contains the VC claim. It verifies that the claim data matches the specified schema, and if so, returns a signed VC containing the claim information.
  • a Registrar REST API running on the registrar, receiving VCs from agents. It submits the VC to the locally running VC REST API to verify that the VC was signed by an instance of the VC REST API. If verification is successful, the data in the SQLite database is updated to reflect the changes in the claim contents. If the referred entities exist, the changes are made, and a response is sent to the agent informing them accordingly. If the referred entities do not exist or the request would not result in a change, the response informs the agent accordingly.
  • a demo web app used for demonstration purposes to act as a network owner. It allows interactive delegation of trust or distrust in a manufacturer or device, binding a device to a device type, and setting a device type to vulnerable or not vulnerable by binding it to a demonstrator critical vulnerability. It also allows the demonstrator to view the state of the selected manufacturer, device, and device type.