document AFI / FBoM (Auditable Firmware Implementation, Firmware Bill of Materials)

[orangecms]

Auditable Firmware Implementation

Goal

AFI aims to supply a standard for certifying firmware auditability.

Specification

AFI manifest struct v1:

• AFI (manifest) version
• source ref (commit hash)
• config ref (build config hash, e.g. script with env vars)
• output ref (artifact hash)

Add length and type to each ref for flexibility, support multi-hash, signatures, etc, similar to TPM 2.0 log entries.

The refs must be resolvable, can be a QR code etc in a GUI or TUI provided

• by OEMs pointing to product URLs if they like, strongly encouraged
• by communities pointing to their project website/mainboard docs

Providing sources, schematics and board view files under OSI/CC licenses and adding repository references is encouraged for sustainability and open auditability. At least there must be release notes with accompanying hashes (similar to checksums often found besides file downloads) to verify the AFI hashes against, which is one way to resolve the hashes.

At least one third party must provide a correspondig verification (attestation).
Note: An external verifier reading a firmware image from an offline device is the only actual guarantee to check integrity. Such a verifier could be flashrom plus some extra tool, potentially Fiedka.

The SLSA framework addresses some of those issues a bit more. Key points lie in reasoning:

• What does a feature defend against?
• How does it do that?
• Why does it do it that way?
  Note that AFI looks from the perspective of an artifact. Anything defined by SLSA is a precondition. The goal of AFI is to be able to trace back to the origins.

See also

• UEFI Forum - Firmware Integrity Measurements and Attestation
• UEFI Forum - Traceable Firmware Bill of Materials Overview
• oreboot - Design vboot system
• https://github.com/hughsie/python-uswid

Related Discussions

• LVFS Community Meeting 2022 01 28
• SLSA "being different"

[orangecms]

related analysis issues from Fiedka:

• annotation, BoM, saving data fiedka/fiedka#69
• SBoM features fiedka/fiedka#60

[orangecms]

As pointed out by @twelho, the whole thing only makes sense when mandating reproducibility at least.

We should make this clear in the spec, and ideally, add bootstrappability as well.

[orangecms]

Also see CycloneDX/specification#129

[orangecms]

The wording is somewhat crucial. What I propose to phrase as "auditable" here is called "transparent" in https://rfd.shared.oxide.computer/rfd/0552.

Note that transparency has two meanings, which is why I hesitate to use the term without elaboration:
It may mean that everything is clear in detail, or that some details are hidden.
The former is what Oxide describe, and also the idea behind https://en.wikipedia.org/wiki/Certificate_Transparency.
An example for the second meaning is https://en.wikipedia.org/wiki/Location_transparency.