SPL FIT configuration signature verification

Mon Sep 14 22:55:46 CEST 2020

I am putting the signature on the image itself, rather than the configuration. Since there are no separate components, signing the configuration is not of much use here I think. Maybe signing configuration would work too? Anyway, my uboot.its is this:

...
	images {
		firmware at 1 {
			description = "ARM U-Boot";
			data = /incbin/("u-boot-dtb.bin");
			type = "firmware";
			arch = "arm";
			os = "u-boot";
			compression = "none";
			load = <0x800000>;
			entry = <0x0>;
			signature at 1 {
				algo = "sha384,rsa4096";
				key-name-hint = " boot-stage1-v1";
			};
		};
	};

	configurations {
		default = "config at 1";
		config at 1 {
			description = "armada-388-aprisalte";
			loadables = "firmware at 1";
		};
	};
};

But note that for the SPL to correctly verify the signatures, the SPL dtb needs to have the key also. mkimage will automatically update a dtb to contain the public part of a key when you sign a FIT, but you then need to make sure that dtb is then included in your SPL. If there is a key present, with required = "image", then the image booted must be signed with that key. If the SPL is ignoring this required field and allowing unsigned images to boot, then that would be a bug I think. 

Here I have decompiled the dtb that my SPL is using:

...
        signature {

                key-boot-stage1-v1 {
                        required = "image";
                        algo = "sha384,rsa4096";
                        rsa,r-squared = <0x8008ac2e 0x171f64ee 0x7e8fa7f5 0xb550da7 0x8775b52d 0x9f885500 0x73e8c91f 0xcf44a748 0x837b273 0x9cb9353a 0x479b1318 0xd9e4cb08 0x21093864 0x
959cfe96 0xbf9ef56b 0xfbef6ab0 0x64805a9d 0x95a515bb 0x7cb10f21 0x2fa48c81 0xfcb06544 0xff2b3886 0x14d1f056 0x652b1ff 0x6b32b385 0x5560e4b2 0xd20de2b9 0x2fc1b3b0 0xf3742141 0x17e02330
0x1241cd50 0xc6eeab65 0xc53eb0f 0x11c83ce9 0xf47f067 0x290a2e45 0x78fc694b 0x923e2948 0x770508fc 0x546fe411 0xb5798524 0xcc32251e 0x42494a36 0xa0db8b48 0x4a17c54d 0xad664c1a 0x794f77ce
 0xe1394aeb 0xa04a9a97 0x666cc8ae 0xc8eb14aa 0x788cc505 0x14b9f3bb 0xdfd88ba2 0xb1e227c5 0x1e368f71 0x51a803ff 0x964d8465 0x1651f936 0x8cf01191 0xc7eb754f 0xf4345e81 0x7a499309 0x912e9
a87 0x1e25d9e4 0xd8a709f0 0x69b3ae07 0x4efdb6be 0xbb51072d 0x1dde78f5 0x55b0ee98 0xc994dba2 0x1f9dc907 0xaece46e3 0x8f3eeabb 0x39150a1f 0x2098a8f3 0x20079209 0x836153c 0xa35cc018 0x4ae
41cef 0x2097467d 0x3848d40 0x9411a9da 0x1d5fa5e7 0x90accfcb 0x91e68bd4 0x46a4e185 0xb4fe7a2 0xf1c28e97 0xe2b6ca6f 0x35a215ab 0xeffd4d76 0x4562f261 0xd0273f6c 0xe6d6bc1 0x315ccaab 0x966
07ec9 0x8160cf19 0x8e75f4b5 0x6ef7926a 0x5fe9f4f3 0xae7008c0 0xdc5f1ca8 0x2b949aeb 0xbc6900ec 0x1aebf641 0xb182aa92 0xeedf95a7 0x396e9456 0xb9d1b82 0x2364860e 0xfeabcb34 0xe0878845 0x4
9e96c26 0x493bd139 0x9c9fa36f 0x396d6b27 0xa565f8 0xbeacb276 0x95dc9bd1 0x82b96121 0x2b8b1d2d 0xf8f5b9de 0xb063d7fe 0xb3c26564 0x992a8f12 0xe5c0e63e>;
                        rsa,modulus = <0xfbe4cdde 0x6db9cf6 0x499b67ee 0xf9227480 0xda5b5506 0x77a3fd2e 0x3410499c 0x4e425357 0xea5227cc 0x41fdb8f7 0x1f627aaa 0x56ea26cd 0xa01da3ef 0xf
3c06502 0xd224005 0x5408337d 0xea37f35a 0x44d51d92 0x194017e8 0x47206b41 0xfa8c3894 0x4bc39db6 0x43ef7ef2 0x5d27b172 0xe763e2e4 0x2492cef1 0xf04b1e1e 0x3fa99c37 0x52ef1aaa 0x8c89d4ca 0
xc62a7d35 0xfc9684f3 0xb97ecf08 0xbaa0696c 0x39f915b 0xadc85f39 0x4ba9660 0xfede9060 0x5d484ec 0x66a3e0c6 0xb0af9918 0x78b0c5a5 0x6f35ff71 0x556f37bf 0x816c792a 0xcb7d3043 0xda8423b3 0
xa617f2e2 0xb11b0ece 0x8f0bfcfd 0xb634c840 0x1cd651be 0xfbdd95ee 0xc6920755 0x60162e20 0xc6c71ea9 0xda163adc 0xcf89b517 0xf6a5cd14 0x17d88e6d 0x84408768 0x73afd01d 0x1905d143 0xaf7a81d
f 0x721a8ba9 0xe02b8b2e 0x971a2fc1 0x8a19695 0x3d73c6bb 0xeae0d698 0xf98f9b4 0xb4776341 0xf365771a 0xd6438e74 0x60eec95e 0xe68f8f94 0xe1045a50 0x6bf39f3a 0x6774cb2f 0x9d3057fd 0x2697dd
97 0x9864076c 0xefc69ada 0x15a7012d 0xe048460 0x38fcf53a 0xf8fb99e5 0x87e50339 0x45a26244 0x136f52d2 0x3d3aa391 0x44a9316f 0xd48bad9f 0xd25ca4b8 0xba5bc90b 0xed200184 0x7e60def9 0x5dec
06da 0x492cd94a 0x7c3f12e6 0xf1510063 0x6eaeb317 0x848eb08a 0xee3090db 0xfd674a2d 0xd4e6c411 0x87040635 0x6960d5ec 0xa4eef21e 0xc1f780c3 0xb5383670 0xb83a14d3 0x8ff8257a 0xb0ef5b9e 0x2
35d69c3 0xef880725 0x9c1d3a02 0x9606f664 0x58361801 0x211d285 0x91191bdb 0x2bd8be38 0x5f08f508 0x4a236ed2 0xdc549932 0x7bbbde7c 0x26570e1b 0x41e44e0d>;
                        rsa,exponent = <0x0 0x10001>;
                        rsa,n0-inverse = <0x467c4f3b>;
                        rsa,num-bits = <0x1000>;
                        key-name-hint = "boot-stage1-v1";
                };
        };
...

-----Original Message-----
From: Andrii Voloshyn <a.voloshyn at d.mobilunity.com> 
Sent: Monday, 14 September 2020 6:45 pm
To: Reuben Dowle <reuben.dowle at 4rf.com>
Cc: u-boot <u-boot at lists.denx.de>
Subject: RE: SPL FIT configuration signature verification

Hi Reuben,

    Thanks for your reply. 
So, in your 'its' file for second stage u-boot, do you define signature in images section as follows:

    images {
        uboot {
            description = "U-Boot Secondary";
           signature {
            };
        };

        configurations {
        };
   };

or in configuration section (signed configuration feature), as follows?:

    images {
        uboot {
            description = "U-Boot Secondary";
        };

        config-1 {
            description = "";
            loadables = "uboot";
            signature {
                    algo = "";
                    key-name-hint = "";
                    sign-images =  "loadables";
            };
   };

When I define signatures in images section, SPL U-Boot checks signatures of the second stage u-boot as expected, on the other hand, when configuration is signed it doesn't check it.
Microsoft added their own patch a couple of years ago to fix this (https://github.com/neilsh-msft/u-boot.ms-iot/commit/6ea7fab742eadddf4982695f3cbafeda079e4134), but it is not in the mainline. I am wondering if this has been fixed in the mainline since then, or I need to patch u-boot similar way Microsoft did?

Cheers,
Andy

---- On Mon, 14 Sep 2020 01:01:46 +0300 Reuben Dowle <reuben.dowle at 4rf.com> wrote ----

 >
 > Yes, it is possible to do this. The SPL will check its own DTB to check which signatures are required.
 >
 >  When the FIT that the SPL will load is created with mkimage, you also pass the SPL's dtb file, which will be patched to include the required signatures.
 >
 >  I am not sure if the config system has ability to specify this. My build process separates the signing from the normal uboot build (so that I can keep the private keys more secure), so I am manually calling mkimage. The command I am using to generate my second stage signed u-boot FIT file which is loaded by SPL:
 >
 >  mkimage -f uboot.its -K u-boot-spl.dtb -k keys -r u-boot.fit  >  >  The updated u-boot-spl.dtb needs to be available for the SPL to load at startup - often by appending this dtb to the end of the SPL binary. In my case I do this:
 >  cat u-boot-spl-nodtb.bin u-boot-spl-pad.bin u-boot-spl.dtb > u-boot-spl.bin  >  >  >  Reuben Dowle  >  Software Architect  >  Phone:
 >
 >  Fax:
 >  E-Mail:
 >  Website:
 >  +64 4 499 6000
 >
 >  +64 4 473 4447
 >  reuben.dowle at 4rf.com
 >  Https://www.4rf.com
 >
 >
 > 
 >   
 >
 >
 > -----Original Message-----
 >  From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Andrii Voloshyn  >  Sent: Saturday, 12 September 2020 12:18 am  >  To: u-boot <u-boot at lists.denx.de>  >  Subject: SPL FIT configuration signature verification  >  >  Hi there,  >  
 >         Is it possible to make SPL U-Boot to verify signature located in configuration section of FIT image, and do not continue in case the signature is missing or doesn't match?
 >  Asking because I couldn't find any configuration option for that, and I have FIT image with signature but SPL U-boot doesn't check it at all, it only checks signatures for images if present.
 >
 >  Thanks
 >
 >  Cheers,
 >  Andy
 >
 >
 > The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).