]>
Commit | Line | Data |
---|---|---|
041bca5b SG |
1 | U-Boot Verified Boot |
2 | ==================== | |
3 | ||
4 | Introduction | |
5 | ------------ | |
6 | Verified boot here means the verification of all software loaded into a | |
7 | machine during the boot process to ensure that it is authorised and correct | |
8 | for that machine. | |
9 | ||
10 | Verified boot extends from the moment of system reset to as far as you wish | |
11 | into the boot process. An example might be loading U-Boot from read-only | |
12 | memory, then loading a signed kernel, then using the kernel's dm-verity | |
13 | driver to mount a signed root filesystem. | |
14 | ||
15 | A key point is that it is possible to field-upgrade the software on machines | |
16 | which use verified boot. Since the machine will only run software that has | |
17 | been correctly signed, it is safe to read software from an updatable medium. | |
18 | It is also possible to add a secondary signed firmware image, in read-write | |
19 | memory, so that firmware can easily be upgraded in a secure manner. | |
20 | ||
21 | ||
22 | Signing | |
23 | ------- | |
24 | Verified boot uses cryptographic algorithms to 'sign' software images. | |
25 | Images are signed using a private key known only to the signer, but can | |
26 | be verified using a public key. As its name suggests the public key can be | |
27 | made available without risk to the verification process. The private and | |
28 | public keys are mathematically related. For more information on how this | |
29 | works look up "public key cryptography" and "RSA" (a particular algorithm). | |
30 | ||
31 | The signing and verification process looks something like this: | |
32 | ||
33 | ||
34 | Signing Verification | |
35 | ======= ============ | |
36 | ||
37 | +--------------+ * | |
38 | | RSA key pair | * +---------------+ | |
39 | | .key .crt | * | Public key in | | |
40 | +--------------+ +------> public key ----->| trusted place | | |
41 | | | * +---------------+ | |
42 | | | * | | |
43 | v | * v | |
44 | +---------+ | * +--------------+ | |
45 | | |----------+ * | | | |
46 | | signer | * | U-Boot | | |
47 | | |----------+ * | signature |--> yes/no | |
48 | +---------+ | * | verification | | |
49 | ^ | * | | | |
50 | | | * +--------------+ | |
51 | | | * ^ | |
52 | +----------+ | * | | |
53 | | Software | +----> signed image -------------+ | |
54 | | image | * | |
55 | +----------+ * | |
56 | ||
57 | ||
58 | The signature algorithm relies only on the public key to do its work. Using | |
59 | this key it checks the signature that it finds in the image. If it verifies | |
60 | then we know that the image is OK. | |
61 | ||
62 | The public key from the signer allows us to verify and therefore trust | |
63 | software from updatable memory. | |
64 | ||
65 | It is critical that the public key be secure and cannot be tampered with. | |
66 | It can be stored in read-only memory, or perhaps protected by other on-chip | |
a724b7e0 | 67 | crypto provided by some modern SOCs. If the public key can be changed, then |
041bca5b SG |
68 | the verification is worthless. |
69 | ||
70 | ||
71 | Chaining Images | |
72 | --------------- | |
73 | The above method works for a signer providing images to a run-time U-Boot. | |
74 | It is also possible to extend this scheme to a second level, like this: | |
75 | ||
76 | 1. Master private key is used by the signer to sign a first-stage image. | |
77 | 2. Master public key is placed in read-only memory. | |
78 | 2. Secondary private key is created and used to sign second-stage images. | |
79 | 3. Secondary public key is placed in first stage images | |
80 | 4. We use the master public key to verify the first-stage image. We then | |
81 | use the secondary public key in the first-stage image to verify the second- | |
82 | state image. | |
83 | 5. This chaining process can go on indefinitely. It is recommended to use a | |
84 | different key at each stage, so that a compromise in one place will not | |
85 | affect the whole change. | |
86 | ||
87 | ||
88 | Flattened Image Tree (FIT) | |
89 | -------------------------- | |
a724b7e0 | 90 | The FIT format is already widely used in U-Boot. It is a flattened device |
041bca5b SG |
91 | tree (FDT) in a particular format, with images contained within. FITs |
92 | include hashes to verify images, so it is relatively straightforward to | |
93 | add signatures as well. | |
94 | ||
95 | The public key can be stored in U-Boot's CONFIG_OF_CONTROL device tree in | |
96 | a standard place. Then when a FIT it loaded it can be verified using that | |
97 | public key. Multiple keys and multiple signatures are supported. | |
98 | ||
99 | See signature.txt for more information. | |
100 | ||
101 | ||
102 | Simon Glass | |
103 | sjg@chromium.org | |
104 | 1-1-13 |