Firmware Transparency demo design
This doc gives an overview of the design for this Firmware Transparency (FT)
demo.
Threat model
- Insider risk:
An attacker has privileged control over what gets built into firmware
images, or is able to leverage/coerce action from legitimate employees.
- Subvert code-review process (force push)
No access to firmware signing key, but can attempt to quietly modify
the source tree.
Notes:
- should be visible with code-review enforcement, commit audit etc.
- FT enables impact to be known (how many, and which builds were
affected)
- Build firmware from patched tree
Able to modify source tree prior to build pipeline, no direct access to
firmware signing key, but pipeline will result in signed firmware.
Notes:
- Patched builds must be logged, or they are useless.
- FT enables discoverability for automatic detection if reproducible
builds are possible, and manual forensic inspection if not. Either
way, evidence is publicly available.
- Full control of signing key.
Able to sign arbitrary firmware images outside of any existing controls
or audit.
- External/down-stream supply chain:
This group of attacks is mostly mitigated through the use of signed
firmware.
- Compromised firmware download server (e.g. CDN)
Can replace/modify firmware update files made available for download/
distribution.
- DoS/block updates
- Rollbacks
- On-path adversary for firmware downloads
Can intercept and modify firmware update downloads.
- Device-local risk
- Compromised local-machine used to update device firmware
Attacker can modify downloaded firmware update files, and run arbitrary
code on local machine used to update firmware on target device.
- Can DoS/block updates
- Rollback updates?
- Physical access to low-level interfaces on target device
Attacker has arbitrary access to the device whose firmware is to be
updated.
- TODO(al): flesh this out.
Claimant Model
To help reason about the security properties of the demo system, we’ll frame
the problem in terms of the
claimant model.
Assumptions/Requirements
All firmware metadata & image bytes are publicly available.
For now, we’ll keep things simple and assume that firmware is made freely
available by the vendor.
Model
This model builds in the idea of a firmware manifest file while commits to the
contents of the firmware image along with some metadata.
SystemFIRMWARE:
SystemFIRMWARE talks only about the claims inherent in the signature
over the firmware made by the firmware vendor.
- ClaimFIRMWARE
I, Vendor, claim that the firmware described by this manifest:
- has cryptographic hash X
- is unique for the specified {device, class, version} tuple
- is functionally correct, and without known attack vectors
- StatementFIRMWARE: signed firmware manifest file
- ClaimantFIRMWARE: firmware vendor
- BelieverFIRMWARE:
- firmware update client
- target device bootloader/rom
- VerifierFIRMWARE: third parties
These entities would check for any invalidation of the claims above.
There are many possible types of entity who may have an interest in
performing this role, e.g.:
- vendor themselves (“has my identity been compromised?”)
- other vendors
- AV/analysis companies/organisations with large security teams
- security researchers
- large organisations who already regularly look at firmware for their
fleet
- governments
- ArbiterFIRMWARE:
There’s no official body, but invalidated claims would affect reputation,
possibly draw recourse through law.
**SystemFIRMWARE_LOG**:
SystemFIRMWARE_LOG talks only about the claims made by the log
operator(s), and is the basis for providing discoverability into
SystemFIRMWARE above.
- ClaimFIRMWARE_LOG:
I, log operator, make available:
- A globally consistent, append-only log of
StatementFIRMWARE
- All firmware preimages corresponding to the
StatementFIRMWARE stored in the log.
- StatementFIRMWARE_LOG: log checkpoint (“Signed tree head”)
- ClaimantFIRMWARE_LOG: log operator
Possible operators might be:
- Chip IP licensor
- SoC vendor
- system integrator
- members of relevant consortia
- BelieverFIRMWARE_LOG:
- BelieverFIRMWARE
- VerifierFIRMWARE
- VerifierFIRMWARE_LOG:
Possible log verifiers (who can check the log claims above?):
- other log operators
- other entities from list of claimants above
- interested enthusiasts
- log verifiers from other Transparency ecosystems (e.g. CT, golang, etc.)
- ArbiterFIRMWARE_LOG:
Who can kick a log out for misbehaving?
Overview
The design for the demo consists of a number of different entities which play
the roles described in the claimant model above, these are shown in the
following diagram:
Diagram source
@startuml overview
!include ./diagrams/puml/style.puml
package "FT Log" #LOG_COLOUR_4 {
FA5_SERVER(personality,FT Personality,rectangle,LOG_COLOUR_0) #LOG_COLOUR_2
FA5_FILE(cas,Firmware\nImages,database,LOG_COLOUR_0) #LOG_COLOUR_2
personality -right-> cas
package "Trillian" #LOG_COLOUR_3 {
FA5_SITEMAP(log,Log,rectangle,LOG_COLOUR_0) #LOG_COLOUR_1
FA5_FILE(metadata,Firmware\nmetadata,database,LOG_COLOUR_0) #LOG_COLOUR_1
log -right-> metadata
}
personality -down-> log
}
package "Firmware Vendor" #VENDOR_COLOUR_2 {
FA5_USER_TIE(publisher,Firmware Publisher,rectangle,VENDOR_COLOUR_0) #VENDOR_COLOUR_1
FA5_EYE(vendor_monitor,Firmware Vendor Monitor,rectangle,VENDOR_COLOUR_0) #VENDOR_COLOUR_1
publisher -right--> personality: Publish firmware
vendor_monitor -right----> personality: Observe firmware
}
package "Device" #DEVICE_COLOUR_2 {
FA5_COGS(update,Update client,rectangle,DEVICE_COLOUR_0) #DEVICE_COLOUR_1
FA5_MOBILE_ALT(device,Device,rectangle,DEVICE_COLOUR_0) #DEVICE_COLOUR_1
update -down-> device: Update
update -right----> personality: Verify consistency
}
package "Observers" #OBS_COLOUR_2 {
FA5_EYE(monitor,FT Monitor,rectangle,OBS_COLOUR_0) #OBS_COLOUR_1
monitor -down----> personality: Observe firmware
}
publisher -[dotted]----> update: Update available
@enduml
For clarity, the mapping of actors to the claimant model roles, along with
software provided by the demo used to fulfil those roles, are listed explicitly
here:
Firmware vendor:
Uses the publisher
to publish
firmware metadata & images to the log, and create an “OTA” update bundle:
Also uses the ft_monitor
to
check for unexpected firmware apparently issued by the vendor, so additionally
plays the following roles:
- BelieverFIRMWARE_LOG
- VerifierFIRMWARE
- VerifierFIRMWARE_LOG (when used with STH Witness)
Update client:
Uses the flash_tool
to verify
and install the update bundle provided by the vendor onto the device.
- BelieverFIRMWARE
- BelieverFIRMWARE_LOG
- VerifierFIRMWARE_LOG (when used with STH Witness)
Target device (toaster):
Device implementations:
These implementation rely on most of the same verification logic as the
flash_tool
to verify the
proofs stored alongside the firmware in the device.
- BelieverFIRMWARE
- BelieverFIRMWARE_LOG
Log:
Uses the ft_personality
along with Trillian to provide the
discoverability that Firmware Transparency leverages.
STH Witness:
May use the ft_witness
to
support verification of log operator, by enabling detection of log split views.
Interested Observers:
Use the ft_monitor
to
both verify the log operator’s claims, and support verification of the
firmware vendor claims.
- VerifierFIRMWARE
- VerifierFIRMWARE_LOG
There are no Arbiters in the demo.
Caveats/Scope
For the purposes of the demo, the “on device” enforcement will be implemented
at the bootloader level.
Clearly, in a production system we’d expect to see this enforcement implemented
inside mask ROM, or some other similarly secure location, however for the
purpose of demonstrating the required functionality the bootloader will serve
well enough.