1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
# Measured Boot
Measured boot feature was initially implemented as an extension of Google
Verified Boot. However, the two features were decoupled since then and use of
measured boot no longer requires enabling vboot.
In most cases TPM eventlog is initialized during bootblock before TPM gets set
up, hence digests are not measured into TPM immediately, but are only cached in
the event log. Later, as part of TPM setup, the cached events are applied onto
TPM device. The behaviour is different if TPM_MEASURED_BOOT_INIT_BOOTBLOCK
kconfig is set, which moves TPM initialization into bootblock.
## SRTM
A measured-based trust chain is one that begins with an initial entity that
takes the first measurement, referred to as the "Core Root of Trust for
Measurement" (CRTM), before control is granted to the measured entity. This
process of measurement and then passing control is referred to as a transitive
trust. When the CRTM can only ever be executed once during the power life-cycle
of the system, it is referred to as a "Static CRTM" (S-CRTM). Thus the trust
chain constructed from the S-CRTM is referred to as the Static Root of Trust for
Measurement (SRTM) trust chain. The theory is that as long as a proper
transitive trust is conducted as more code is allowed to execute, a trustworthy
record showing the provenance of the executing system may be provided to
establish the trustworthiness of the system.
## IBB/CRTM
The "Initial Boot Block" (IBB) is a one-time executed code block loaded at the
reset vector. Under measured boot mode, the IBB measures itself before measuring
the next code block making it an S-CRTM for the measured boot trust chain, an
SRTM trust chain. Since the IBB measures itself and executes out of DRAM, it is
said to have a "Root of Trust" (RoT) that is rooted in software.
## S-CRTM Hardening
To address attacks that took advantage of the IBB being self-referential with
both the "Root of Trust for Verification" (RTV) and "Root of Trust for
Measurement" (RTM) being rooted in software, hardening was implemented by CPU
manufactures. This was accomplished by introducing RoT, typically an RTV, to an
external entity provided by the manufacture that could be validated by the CPU
at boot. Examples of this are Intel's BootGuard and AMD's Hardware Validated
Boot (also known as Platform Secure Boot). These solutions work by having the
IBB invoke the manufacture provided RoT as early as possible, for which the CPU
has already validated or validates when invoked. The RoT will then validate the
IBB, thus moving the root for the respective trust chain, typically the
verification trust chain, into hardware.
It should be noted that when Intel BootGuard was originally designed, it
provided a measurement mode that resulted in the ACM (Authenticated Code
Module) becoming the S-CRTM for the SRTM trust chain. Unfortunately, this was
never deployed and thus relying on "Root of Trust for Verification" (RTV)
signature check as the only assertion rooted in hardware.
## Known Limitations
At the moment measuring IBB dynamically and FMAP partitions are not possible but
will be added later to the implementation.
Also SoCs making use of VBOOT_RETURN_FROM_VERSTAGE are not able to use the
measured boot extension because of platform constraints.
### Measurements
To construct the coreboot SRTM trust chain, the CBFS files which are part of the
IBB, are identified by a metadata tag. This makes it possible to have platform
specific IBB measurements without hard-coding them.
#### CBFS files (stages, blobs)
* CBFS data is measured as raw data before decompression happens.
* CBFS header is excluded from measurements.
* Measurements are stored in PCR 2.
#### Runtime Data
* CBFS data which changes by external input dynamically. Never stays the same.
* It is identified by VBOOT_MEASURED_BOOT_RUNTIME_DATA kconfig option and
measured into a different PCR 3 in order to avoid PCR pre-calculation issues.
![][srtm]
[srtm]: srtm.png
### TCPA eventlog
coreboot makes use of its own TCPA log implementation. Normally the eventlog
specification can be found via the TCG homepage:
[UEFI Specification](https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/)
[BIOS Specification](https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf)
Both of them are not representing firmware measurements in a generalized way.
Therefore we have to implement our own solution.
We decided to provide an easy to understand TCPA log which can be read out
from the operating system and firmware itself.
#### Table Format
The first column describes the PCR index used for measurement.
The second column is the hash of the raw data. The third column contains
the hash algorithm used in the operation. The last column provides
information about what is measured. First the namespace from where the data
came from, CBFS or FMAP, then the name used to look up the data
(region or file name).
#### Example:
```bash
PCR-2 e8f2b57c9ec5ea06d1bbd3240a753974d4c3e7c8cd305c20a8ea26eed906dc89 SHA256 [FMAP: COREBOOT CBFS: bootblock]
PCR-2 309a5fcb231d3a39127de2521792f332f9a69e05675ec52535d2dcded756dc19 SHA256 [FMAP: COREBOOT CBFS: fallback/verstage]
PCR-2 0fbba07a833d4dcfc7024eaf313661a0ba8f80a05c6d29b8801c612e10e60dee SHA256 [FMAP: RO_VPD]
PCR-2 431681113ed44cbf6f68a12c6e5687e901052f1d728a4777b2ad36e559962047 SHA256 [FMAP: GBB]
PCR-2 f47a8ec3e9aff2318d896942282ad4fe37d6391c82914f54a5da8a37de1300c6 SHA256 [FMAP: SI_DESC]
PCR-3 237f6f567f8597dbdff0a00690d34d21616af0dbe434b9a2d432b136c012765f SHA256 [FMAP: SI_ME]
PCR-2 7d2c7ac4888bfd75cd5f56e8d61f69595121183afc81556c876732fd3782c62f SHA256 [FMAP: SI_GBE]
PCR-0 62571891215b4efc1ceab744ce59dd0b66ea6f73 SHA1 [GBB flags]
PCR-1 a66c8c2cda246d332d0c2025b6266e1e23c89410051002f46bfad1c9265f43d0 SHA256 [GBB HWID]
PCR-2 ceca357524caf8fc73f5fa130f05a75293031962af884e18990d281eb259f5ff SHA256 [FMAP: FW_MAIN_B CBFS: fallback/romstage]
PCR-2 548a097604e0a975de76f98b04c7f0b0ddec03883dd69179e47a784704a1c571 SHA256 [FMAP: FW_MAIN_B CBFS: fspm.bin]
PCR-2 1e86b27008818244c221df2436b0113bd20a86ec6ec9d8259defe87f45d2f604 SHA256 [FMAP: FW_MAIN_B CBFS: spd2.bin]
PCR-2 05d78005fcfc9edd4ca5625f11b1f49991d17bdb7cee33b72e722bc785db55ae SHA256 [FMAP: FW_MAIN_B CBFS: fallback/postcar]
PCR-2 c13e95829af12a584046f1a6f3e1f6e4af691209324cfeeec573633399384141 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/ramstage]
PCR-2 a6ec2761b597abd252dba2a7237140ef4a5a8e0d47cad8afb65fa16314413401 SHA256 [FMAP: FW_MAIN_B CBFS: cpu_microcode_blob.bin]
PCR-2 c81ffa40df0b6cd6cfde4f476d452a1f6f2217bc96a3b98a4fa4a037ee7039cf SHA256 [FMAP: FW_MAIN_B CBFS: fsps.bin]
PCR-2 4e95f57bbf3c6627eb1c72be9c48df3aaa8e6da4f5f63d85e554cf6803505609 SHA256 [FMAP: FW_MAIN_B CBFS: vbt.bin]
PCR-3 b7663f611ecf8637a59d72f623ae92a456c30377d4175e96021c85362f0323c8 SHA256 [FMAP: RW_NVRAM]
PCR-2 178561f046e2adbc621b12b47d65be82756128e2a1fe5116b53ef3637da700e8 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/dsdt.aml]
PCR-2 091706f5fce3eb123dd9b96c15a9dcc459a694f5e5a86e7bf6064b819a8575c7 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/payload]
```
#### Dump TCPA eventlog in the OS:
```bash
cbmem -L
```
#### Get CBFS file and print the hash
```bash
cbfstool coreboot.rom extract -r COREBOOT -n fallback/romstage -U -f /dev/stdout | sha256sum
```
#### Get FMAP partition and print the hash
```bash
cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum
```
## DRTM
Certain hardware platforms, for example those with Intel TXT or AMD-V, provide
a mechanism to dynamically execute a CRTM, referred to as the "Dynamic
CRTM" (D-CRTM), at any point and repeatedly during a single power life-cycle of
a system. The trust chain constructed by this D-CRTM is referred to as the
"Dynamic Root of Trust for Measurement" (DRTM) trust chain. On platforms with
Intel TXT and AMD-V, the D-CRTM is the CPU itself, which is the reason for these
capabilities being referred to as having a "Root of Trust" (RoT) rooted in
hardware.
To provide as an authority assertion and for the DRTM trust chain attestations
to co-exist with the SRTM trust chain, the TPM provides localities, localities
1 - 4, which restrict access to a subset of the Platform Configuration
Registers (PCR), specifically the DRTM PCRs 17 - 22. The mechanism to assert
authority for access to these localities is platform specific, though the
intention was for it to be a hardware mechanism. On Intel x86 platforms this is
controlled through communication between the CPU and the PCH to determine if
the "Dynamic Launch" instruction, `GETSEC[SENTER]`, was executed and that the
CPU is in SMX mode. For AMD x86 platforms, this controlled with the APU with a
similar enforcement that the "Dynamic Launch" instruction, `SKINIT`, was
executed.
## Platform Configuration Register
Normally PCR 0-7 are reserved for firmware usage. In coreboot we use just 4 PCR
banks in order to store the measurements. coreboot uses the SHA-1 or SHA-256
hash algorithm depending on the TPM specification for measurements. PCR-4 to
PCR-7 are left empty.
### PCR-0
_Hash:_ SHA1
_Description:_ Google vboot GBB flags.
### PCR-1
_Hash:_ SHA1/SHA256
_Description:_ Google vboot GBB HWID.
### PCR-2
_Hash:_ SHA1/SHA256
_Description:_ Core Root of Trust for Measurement which includes all stages,
data and blobs.
### PCR-3
_Hash:_ SHA1/SHA256
_Description:_ Runtime data like hwinfo.hex or MRC cache.
|
