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