doc/uImage.FIT/verified-boot.txt

   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
  67 crypto provided by some modern SOCs. If the public key can ben changed, then
  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 --------------------------
  90 The FIT format is alreay widely used in U-Boot. It is a flattened device
  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