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