secure boot（三）secure boot的签名和验签方案

ubuntu:~/uboot-nextdev$ fdtdump u-boot.dtb | less
/dts-v1/;
....
/ { #address-cells =; #size-cells =; compatible = "rockchip,rv1126-evb", "rockchip,rv1126";
        model = "Rockchip RV1126 Evaluation Board";
        // signature节点由mkimage工具自动插入生成，节点里保存了RSA-SHA算法类型、RSA核心因子参
   //数等信息。
        signature {
         key-dev {
    required = "conf";
          algo = "sha256,rsa2048";
          rsa,np =;
          rsa,c =;
          rsa,r-squared =;
          rsa,modulus =;
          rsa,exponent-BN =;
          rsa,exponent =;
          rsa,n0-inverse =;
          rsa,num-bits =;
          key-name-hint = "dev";
};
};

签名方案

上一节内容提到过，在secure boot中一般使用RSA签名方案。

要完成对镜像的签名，就必须使用私钥。而私钥一般是存在服务器上的，在本地PC上只存公钥。要想完成对镜像的签名，就必须把所有镜像上传到服务器重新打包。这种方案上传的文件太多，比较繁琐。下面我们介绍一种常用的签名方案。

在PC上，存放一把公钥和临时私钥，公钥是打包进dtb中的，安全启动时使用。临时私钥是为了生成签名数据。

在本地打包时，使用临时私钥对非安全镜像签名，将签名数据上传到服务器使用真正的私钥进行二次签名。将二次签名的数据和非安全镜像打包在一起，就得到了安全镜像。安全启动时，从dtb中拿出公钥对安全镜像进行校验即可。

这样既可以保证私钥的安全，又避免了上传所有镜像签名的繁琐。

签名镜像+签名配置

在secure boot中，除了对各个独立镜像签名外，还要对FIT Image中的配置项进行签名。

有些情况下，已经签名的镜像也有可能遭到破坏。例如，也可以使用相同的签名镜像创建一个FIT image，但是，其配置已经被改变，从而可以选择不同的镜像去加载（混合式匹配攻击）。也有可能拿旧版本的FIT Image去替换新的FIT image（回滚式攻击）。

下面举个例子。

/ {
 images {
  kernel@1 {
   data = for kernel1>
   signature@1 {
    algo = "sha1,rsa2048"; # kernel image镜像的哈希值，由mkiamge工具自动生成 value = <...kernel signature 1...>
   };
  };
  kernel@2 {
   data = for kernel2>
   signature@1 {
    algo = "sha1,rsa2048";
    value = <...kernel signature 2...>
   };
  };
  fdt@1 {
   data = for fdt1>;
   signature@1 {
    algo = "sha1,rsa2048";
    vaue = <...fdt signature 1...>
   };
  };
  fdt@2 {
   data = for fdt2>;
   signature@1 {
    algo = "sha1,rsa2048";
    vaue = <...fdt signature 2...>
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
  };
  conf@1 {
   kernel = "kernel@2";
   fdt = "fdt@2";
  };
 };
};

两个kernel image 都已经被签名了，但是，攻击者可以很容易的将kernel1 和fdt2 作为configuration 3去加载。

configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
  };
  conf@1 {
   kernel = "kernel@2";
   fdt = "fdt@2";
  };
  conf@3 {
   kernel = "kernel@1";
   fdt = "fdt@2";
  };
 };

攻击者可以拿到签名的镜像，并且镜像是正确的。这种组合式攻击会给设备带来很大风险。

因此，为了解决这个问题，除了给镜像签名外，我们可以把配置选项也签名，每个镜像都有自己的签名，在给配置选项签名时，把镜像的hash值也包含进去。具体例子如下：

/ {
 images {
  kernel@1 {
   data = for kernel1> hash@1 {
    algo = "sha1";
    value = <...kernel hash 1...>
   };
  };
  kernel@2 {
   data = for kernel2> hash@1 {
    algo = "sha1";
    value = <...kernel hash 2...>
   };
  };
  fdt@1 {
   data = for fdt1>; hash@1 {
    algo = "sha1";
    value = <...fdt hash 1...>
   };
  };
  fdt@2 {
   data = for fdt2>; hash@1 {
    algo = "sha1";
    value = <...fdt hash 2...>
   };
  };
 };
 configurations {
  default = "conf@1";
  conf@1 {
   kernel = "kernel@1";
   fdt = "fdt@1";
   signature@1 {
    algo = "sha1,rsa2048"; # 对配置项签名，由mkimage工具自动生成 value = <...conf 1 signature...>;
   };
  };
  conf@2 {
   kernel = "kernel@2";
   fdt = "fdt@2";
   signature@1 {
    algo = "sha1,rsa2048";
    value = <...conf 1 signature...>;
   };
  };
 };
};

如上所示，除了给所有镜像添加了hash值，还为每个配置添加了签名。mkimage将会对configurations/conf@1签名(/images/kernel@1, /images/kernel@1/hash@1,/images/fdt@1, /images/fdt@1/hash@1)。签名会被写入  /configurations/conf@1/signature@1/value。

$ make O=sandbox sandbox_config
$ make O=sandbox
$ O=sandbox ./test/vboot/vboot_test.sh
/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
Build keys do sha1 test Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
Signature check OK
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK do sha256 test Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
Signature check OK
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK

Test passed