All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] Signed FIT image boots without public key
@ 2018-05-25 11:46 Nelson, Mark
  2018-05-25 14:11 ` Teddy Reed
  0 siblings, 1 reply; 2+ messages in thread
From: Nelson, Mark @ 2018-05-25 11:46 UTC (permalink / raw)
  To: u-boot

Let me preface this by saying I'm using the xilinx-u-boot repo based on the 2017.4 tag.

I've been studying how to sign FIT images, using mkimage. I successfully signed an image and verified the signature as follows:

${UBTOOLS4}/mkimage -T multi -A arm64 -O linux -f images/linux/fitimage.its -K images/linux/public.dtb -k ${SEC_KEYSTORE} -r images/linux/image_secure.ub

${UBTOOLS4}/fit_check_sign -f images/linux/image_secure.ub  -k images/linux/public.dtb

I'm signing the configuration in the fitimage.its as follows:
                conf at 1 {
                        description = "Boot Linux kernel with FDT blob + ramdisk";
                        kernel = "kernel at 0";
                        fdt = "fdt at 0";
                        ramdisk = "ramdisk at 0";
                        signature at 1 {
                                algo = "sha256,rsa2048";
                                key-name-hint = "linux_rsa_priv";
                                sign-images = "kernel", "fdt", "ramdisk";
                        };
                };



However, when I tested booting the FIT image without providing the public key in Uboots control fdt, it booted successfully. It obviously should not boot a signed image without the key information. When I looked into this, I found that there are two routines called to verify required signatures when booting: fit_image_verify_required_sigs() and fit_config_verify_required_sigs(). The latter is for verifying the signatures in configuration nodes. Each of these routines begins with this logic:
       /* Work out what we need to verify */
       *no_sigsp = 1;
       sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
       if (sig_node < 0) {
             debug("%s: No signature node found: %s\n", __func__,
                   fdt_strerror(sig_node));
             return 0;
       }

The problem is that if the fdt signature node(with the public key info) is not provided, this simply returns 0 for success, and the boot process continues successfully after it checks the hashes of the images. To fix the problem, I simply changed fit_config_verify_required_sigs() to return sig_node instead. If the signature is not there, the returned value is FDT_ERR_NOTFOUND, and the boot processing ends with:
Bad Data Hash
ERROR: can't get kernel image!

Notice that I didn't change the logic in fit_image_verify_required_sigs(), because I'm not including signatures on the images, just hashes. In that case, I want it to ignore the fact that it didn't find a signature node.

But surely, this solution is not the correct way. I know that IMAGE_ENABLE_VERIFY is used to gate access to fit_image_verify_required_sigs(), but there is nothing gating access to fit_config_verify_required_sigs() that I can see. I don't see any way to tell u-boot which signature method it should be using to verify: images or configs. It would seem that an additional preprocessor directive is needed. Am I missing something?


[cid:image002.png@01D357D5.908FF380]<http://www.commscope.com/>
Mark Nelson
Principal Engineer
CommScope
250 Apollo Drive, Suite 100
Chelmsford, MA  01824
Mobile: 352-444-0150

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5730 bytes
Desc: image001.png
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180525/bb151ee2/attachment.png>

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [U-Boot] Signed FIT image boots without public key
  2018-05-25 11:46 [U-Boot] Signed FIT image boots without public key Nelson, Mark
@ 2018-05-25 14:11 ` Teddy Reed
  0 siblings, 0 replies; 2+ messages in thread
From: Teddy Reed @ 2018-05-25 14:11 UTC (permalink / raw)
  To: u-boot

I also use the verified-boot features for several boards. The behavior
you're describing is my understanding too.

But I think the expectation: "do not enforce signature checks if there
are no public keys" is OK. The expectation "enforce a signature check
if there's a signature" doesn't seem complete to me.

On Fri, May 25, 2018 at 7:46 AM, Nelson, Mark <Mark.Nelson@commscope.com> wrote:
> Let me preface this by saying I'm using the xilinx-u-boot repo based on the 2017.4 tag.
>
> I've been studying how to sign FIT images, using mkimage. I successfully signed an image and verified the signature as follows:
>
> ${UBTOOLS4}/mkimage -T multi -A arm64 -O linux -f images/linux/fitimage.its -K images/linux/public.dtb -k ${SEC_KEYSTORE} -r images/linux/image_secure.ub
>
> ${UBTOOLS4}/fit_check_sign -f images/linux/image_secure.ub  -k images/linux/public.dtb
>
> I'm signing the configuration in the fitimage.its as follows:
>                 conf at 1 {
>                         description = "Boot Linux kernel with FDT blob + ramdisk";
>                         kernel = "kernel at 0";
>                         fdt = "fdt at 0";
>                         ramdisk = "ramdisk at 0";
>                         signature at 1 {
>                                 algo = "sha256,rsa2048";
>                                 key-name-hint = "linux_rsa_priv";
>                                 sign-images = "kernel", "fdt", "ramdisk";
>                         };
>                 };
>
>
>
> However, when I tested booting the FIT image without providing the public key in Uboots control fdt, it booted successfully. It obviously should not boot a signed image without the key information. When I looked into this, I found that there are two routines called to verify required signatures when booting: fit_image_verify_required_sigs() and fit_config_verify_required_sigs(). The latter is for verifying the signatures in configuration nodes. Each of these routines begins with this logic:
>        /* Work out what we need to verify */
>        *no_sigsp = 1;
>        sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
>        if (sig_node < 0) {
>              debug("%s: No signature node found: %s\n", __func__,
>                    fdt_strerror(sig_node));
>              return 0;
>        }
>
> The problem is that if the fdt signature node(with the public key info) is not provided, this simply returns 0 for success, and the boot process continues successfully after it checks the hashes of the images. To fix the problem, I simply changed fit_config_verify_required_sigs() to return sig_node instead. If the signature is not there, the returned value is FDT_ERR_NOTFOUND, and the boot processing ends with:
> Bad Data Hash
> ERROR: can't get kernel image!
>
> Notice that I didn't change the logic in fit_image_verify_required_sigs(), because I'm not including signatures on the images, just hashes. In that case, I want it to ignore the fact that it didn't find a signature node.
>
> But surely, this solution is not the correct way. I know that IMAGE_ENABLE_VERIFY is used to gate access to fit_image_verify_required_sigs(), but there is nothing gating access to fit_config_verify_required_sigs() that I can see. I don't see any way to tell u-boot which signature method it should be using to verify: images or configs. It would seem that an additional preprocessor directive is needed. Am I missing something?
>

The suggestion of a build-time option to enforce a signature check
regardless of the availability of public keys is interesting. A
complementary build option to choose image or config could work too.

This could enforce a failure if (A) there are no public keys available
and also (B) there are no signatures available for verifying. I am
interested in others' thoughts!

>
> [cid:image002.png at 01D357D5.908FF380]<http://www.commscope.com/>
> Mark Nelson
> Principal Engineer
> CommScope
> 250 Apollo Drive, Suite 100
> Chelmsford, MA  01824
> Mobile: 352-444-0150
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>



-- 
Teddy Reed V

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-05-25 14:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-25 11:46 [U-Boot] Signed FIT image boots without public key Nelson, Mark
2018-05-25 14:11 ` Teddy Reed

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.