-
Notifications
You must be signed in to change notification settings - Fork 1
Home
The ratsd project seeks to solve a problem common to any ecosystem that requires remote attestation RFC9334 for identity-proofing and/or provisioning. The focus is to provide a plug-in architecture with convenient abstractions to compose attestation plugins to represent a node's entire measured topology. The goal is to have a common architecture and protocol for communicating through layers of trusted services.
The RATS architecture illustrates a composite attester in figure 4:
.-----------------------------.
| Verifier |
'-----------------------------'
^
|
| Evidence of
| Composite Device
|
.----------------------------------|-------------------------------.
| .--------------------------------|-----. .------------. |
| | Collect .---------+--. | | | |
| | Claims .--------->| Attesting |<--------+ Attester B +-. |
| | | |Environment | | '-+----------' | |
| | .--------+-------. | |<----------+ Attester C +-. |
| | | Target | | | | '-+----------' | |
| | | Environment(s) | | |<------------+ ... | |
| | | | '------------' | Evidence '------------' |
| | '----------------' | of |
| | | Attesters |
| | lead Attester A | (via Internal Links or |
| '--------------------------------------' Network Connections) |
| |
| Composite Device |
'------------------------------------------------------------------'
Figure 4: Composite Device
Every Attester is a Lead Attester of its environment, but environments can nest. A composite environment can contain sub-environments that must bring together sub-environments' attesters by a lead attester. The Attesting Environment and each of Attester B, C,... can in theory all use ratsd to produce evidence provided they're Linux environments.
As a baseline, ratsd has default implementations of its conceptual components, but they are all designed to be pluggable provided they use the prescribed interfaces.
Some conceptual components are open coded to include implementors of supported interfaces as configured or discovered from the filesystem. Examples of interfaces are in the form of
- a cli binary with standard flags and input/output formats
- a shared object that implements certain symbols with C linkage ABI and signature
- RPC formats over a connection on a unix domain socket or a TLS connection
- REST API
- gRPC
- ttRPC
Frontend: ratsd the process runs a REST API façade over a Unix domain socket to an attester that is identified as the lead.
Leaf: Every attester plugin is at least a "leaf" attester, in that it can take a challenge and produce evidence of its target environment in a supported format.
service Attester {
rpc GetFormats(GetFormatsRequest) returns (GetFormatsResponse) {
option (google.api.http) = {
post: "/v1/formats"
body: "*"
};
}
rpc GetEAT(GetEATRequest) returns (GetEATResponse) {
option (google.api.http) = {
post: "/v1/eat"
body: "*"
};
}
}
message Format {
oneof format {
uint32 coap_type = 1; // Must be 0..65535
// String format is an IANA Content Type.
string content_type = 2;
}
}
message GetFormatsRequest {
// If empty, requests the list of all supported types.
// If non-empty, limits the response to at most the specified types.
repeated Format wanted = 1;
}
message GetFormatsResponse {
// The supported Formats in preference order.
// The first will be used if GetEATRequest does not specify a format.
repeated Format supported = 1;
// Byte size supported for the report data.
uint32 report_data_size = 2;
}
message GetEATRequest {
// Optional to allow a default format.
Format format = 1;
bytes request_data = 2;
}
message GetEATResponse {
bytes eat = 1;
string error = 2;
}
The default format for the ratsd lead attester is application/eat+cwt; eat_profile="veraison:detached,default:2024"
Compositor: Through configuration or discovery through directory enumeration, a compositor combines a list of attesters.
The design space is large for how request_data to the compositor should be translated to request_data to sub-attesters.
The result format may not change, but the profile by which to judge its contents does change.
Supported profiles for a given format are expressed with different values to the Content Type parameter profile.
The default for the ratsd compositor is to perform detached attestation.
Each sub-attester is given the same request_data either truncated or zero-padded to the challenge size of the attester, and the results are combined in a conceptual message wrapper.
eat = {
&(eat_nonce: 10): request_data
&(eat_profile: 265): "veraison:detached,default:2024"
&(measurements: 273): [["application/cmw+cbor", combined-results]]
}
The combined results use labels for each sub-attester that are assigned by configuration or by plugin basename. Two attesters must not share the same label. The content type used for each sub-attester–if not configured–is its preferred format. The default profile has no prescribed topology of sub-attesters.
The security benefit of a more complex attestation scheme that threads the output of one as input to another is negligible. In both cases of detached and threading, the compositor is still trusted to enumerate all attesters it knows of and to represent their evidence as attached to the target environment. Any missing attester is still missable. Any misrepresented attester as local is an issue with trust in the compositor itself.
There is no need for a composite attestation if devices are only given access to the node once first measured into the root of trust for measurement, such as with SPDM.
All means of providing signed measurements of system components SHOULD be coordinated through ratsd. Whereas ratsd does offer a means to proof itself up a boot stack and extend its own logs, it is not meant as a control handover point.
Once a ratsd daemon is started, there can be multiple conceptual layers of computation that execute concurrently.
That said, any authorized user on the node can run kexec (if Linux) to replace the kernel, and measurement of that activity SHOULD be coordinated with a ratsd plugin to provide the relevant measured context to the DPE or TPM before handing over control.