-
Notifications
You must be signed in to change notification settings - Fork 0
Design
This document tries to adopt a nomenclature consistent with other popular transparency ecosystems, like Sigsum or Tessera.
The terms "transparency proof", or simply "proof", are used to indicate the cryptographic proof of inclusion, for data added to a transparency log.
The term "claim" indicates a piece of data, or information, asserted subject to verification publicly logged into a "transparency statement".
The proof of a transparency statement provides the means to verify the integrity of the log itself, while the claim is the actual data being asserted and verified within that log.
The boot policy is the set of rules that are defining whether a "boot bundle" should be loaded by the bootloader.
The term "boot bundle" refers to the set of artifacts involved in the boot
process, as for example a Linux kernel and its ram disk (initrd).
When an artifact is created a claim about a subset of its characteristics is made, the claim is then submitted to the transparency log infrastructure, which can return a "proof" that such log has been appended.
External parties can act as monitors of the log and independently verify the truthfulness of a claim.
The consistency between the policy rules and the content of the public
claim associated to the artifact are checked on-the-fly by the bootloader
during boot, with the assistance of the functions exposed by the
boot-transparency API.
As an example, the bootloader could refuse to boot any kernel claiming a version older than one specified in the policy. This could prevent downgrade to unsecure versions affected by public known vulnerabilities.
Alternatively, the boot policy could define a signature quorum, and refuse to boot any kernel which has not been signed by a sufficient number of signers in the claim.
Further examples might be enforcing boot of exclusively non-tainted Linux kernels (e.g. without 3rd party closed blobs) or Open Source operating systems.
Detailed information on the claiming model and the bootloader policies are illustrated in Claim Specifications and Policy Specifications.
Detailed information on the API exposed by the boot-transparency to
the bootloader is illustrated in section
boot-transparency API.
By enabling transparency within the bootloader, kernel or OS developers can submit (i.e. append in the public log) claims about the artifacts they are building, distributing or verifying.
The correspondent proof of inclusion must be provided to the bootloader along with the boot bundle containing all artifacts involved in the boot process.
The "statement proof" contains all the information needed by the boot-transparency
library to verify that a certain claim has been effectively included in the public
log.
The witnessing quorum support, guarantees log consistency and its append-only evolution, full technical details on the logic applied by the bootloader to verify a transparency proof is illustrated in Proof verification.
The verification logic aims to be independent of the chosen underlying transparency engine (e.g. Sigsum or Tessera) (see Proof verification for exceptions).
Visual overview of the transparency system (this representation is very similar to the "System Overview" illustrated in Sigsum official documentation):
+-----------------+
+----------| OS developers |
| | or distributors |
| | (Submitter) |----------+
| signed +-----------------+ | boot artifacts and claimed data
| checksum ^ | +
| | | proof of logging
v | v
+---------+ proof | ///
| Log |-----------+ Distribution
+---------+ ///
^ | | |
| | leaves | |
| | proofs | | proof of logging
| | boot artifacts | | +
| | and claimed data | | boot artifacts and claimed data
| | | |
| | +---------+ | |
| +--------->| Monitor |<---------------+ |
| +---------+ |
| cosign | v
+---------+ | +----------+
| Witness | v | Verifier |
+---------+ alarm +----------+
Log maintains the append-only tree where each leaf corresponds to a signed checksum of a claim. The log leaves are signed with the submitter's key, while the tree head is signed with the log key. The log is also collecting the cosignatures from witnesses.
Witness certify with the cosigning that later tree head is consistent with the tree heads cosigned previously.
Submitter signs and submits claims, more precisely checksums of claims, that will be included as new leaf to a log. The submitter should also collect the cosigned tree head and an inclusion proof that ties the submitted leaf. The submitted leaf, cosigned tree head, and inclusion proof should be used to assemble the proof of logging.
Distribution infrastructure makes available the binaries, or more in general, the boot artifacts, their source code where applicable, and the correspondent claims, along with the proof that such claims have been transparently logged.
Verifier receives from distribution the boot artifacts, their claimed
properties, and the proof of logging. If the proof is valid
and complies with the witnessing transparency policy, the
verifier can safely proceed in checking the content of the
correspondent claim in the upper verification layers (i.e. in
case of boot-transparency the matching of claimed properties for
the artifacts and what specified within the boot policy).
In this simplified model: the proof verification could be
performed off-line and the verifier could also be the believer.
In other words, the verifier is the same component that decides
whether, or not, perform a consequent action based on the claims.
Monitors monitors are continuously (operating on-line) monitoring the log tree (both its head and logged leaves). There are two classes of monitors: the ones operating "only" at transparency layer, and the ones that will also analyze the actual content inside the claims. The ones operating at transparency layer should periodically request the latest tree head and corresponding leaves from the monitored logs, to ensure that the tree heads includes recent cosignatures by trusted witnesses, and all the leaves that make up the published tree heads. The second class of monitors could retrieve from distributors the associated claims and other data as the booting binaries, source code, or the binary signing keys, to verify the truthfulness of the claimed properties. This latter class of monitors requires more specialized logic and binary analysis capabilities. Among others, these monitors would also need to check the validity of inner signatures within the claimed data, and similarly to the verifiers, they would need to access the signing public key from the Distribution.