Re: [U-Boot] Extract RSA Keys from image
On Tue, Feb 19, 2019 at 9:31 AM wrote:
> I am working on an application needing the ability to update to a verified
> image from the running kernel/application.
>
> We can follow the "normal" verified image boot sequence, where the chain
> of trust is verified from U-Boot to image to execution, etc, but unsure how
> to verify a new image after already running.
>
> Is there a way to extract the public key hash from the U-Boot image so
> that we can compute a hash on an upgrade image and verify a match? Either
> an existing tool, or some means that is accessibly from a Linux kernel that
> we could use to grab this information.
>
> I've done a lot of googling, and I have not seen any means to get to this
> once the image is already booted and running.
>
> Thank you for any guidance you can provide for this.
>
> Jeridiah Welti
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
I'll take a stab at answering this since I recently went through
implementing verified boot. The public key data used to verify the boot
images isn't passed on for use inside those images. However it would be
possible to get them. The public key is usually stored in the device tree
of the object doing the verification (SPL or u-boot). This device tree is
stored as an object inside the FIT boot image. The FIT boot image is
simply another device tree which contains configuration, device trees and
binary executables.
Within a running Linux image, you could read the u-boot FIT image (or SPL
FIT image if CONFIG_SPL_FIT_SIGNATURE is used) from wherever it's stored.
Use dtc tools to find the traverse to the /images/fdt-1/data object. This
data object is the device tree containing the public key that u-boot used
to verify the kernel (or in case of SPL, this is the public key used to
verify u-boot). Use dtc tools again to decode the device tree blob and
traverse to /signature/[signature name]. This node will have your public
key in the format:
key-somekeyname {
required = "image";
algo = "sha256,rsa2048";
rsa,r-squared = <0x1874a2f>;
rsa,modulus = <0x4a7b31eb>;
rsa,exponent = <0x0 0x10001>;
rsa,n0-inverse = <0x93a4cd16>;
rsa,num-bits = <0x800>;
key-name-hint = "somekeyname";
};
-Doug
--
This email and any attachments are for the exclusive use of the
intended recipient(s) and may contain confidential and/or privileged
information. Inadvertent disclosure of this message does not constitute a
waiver of any privilege, right or remedy. If you are not the intended
recipient, please do not directly or indirectly use, disclose or distribute
this message, and please contact the sender and delete this email, any
attachments and all copies. Climate and its affiliates may use, read or
archive email communications (including attachments) through its computer
network, as permitted by applicable law. Climate and its affiliates (or an
external service provider) may also scan emails and attachments on its
computer network to ensure systems operate efficiently and to minimize
security risks. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] SPL_FIT_SIGNATURE on am3358
I'm having trouble getting verified boot working in SPL on an am3358 based platform. The problem I hit is when fit_image_verify_with_data() calls fit_image_verify_required_sigs(). The 5th argument (sig_blob) is gd_fdt_blob() which resolves to NULL. This argument should be the FDT containing the public keys. I assume this happens because SPL_OF_CONTROL isn't enabled. As far as I can tell, SPL_OF_CONTROL isn't working on am33xx boards; enabling it causes SPL to loop infinitely in i2c init (tried on my custom hardware as well as Beaglebone Black). So the public key needs to be found elsewhere. I can keep a separate FDT with the public key stored in a read-only location. My question is what is the 'right' way to load it? Is there an interface for populating gd_fdt_blob() with my own FDT (without SPL_OF_CONTROL enabled)? Or should I modify fit_image_verify_with_data() to get the FDT from elsewhere (and probably other similar calls as well)? -Doug -- This email and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and/or privileged information. Inadvertent disclosure of this message does not constitute a waiver of any privilege, right or remedy. If you are not the intended recipient, please do not directly or indirectly use, disclose or distribute this message, and please contact the sender and delete this email, any attachments and all copies. Climate and its affiliates may use, read or archive email communications (including attachments) through its computer network, as permitted by applicable law. Climate and its affiliates (or an external service provider) may also scan emails and attachments on its computer network to ensure systems operate efficiently and to minimize security risks. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Proposed fastboot changes
On Tue, Jan 15, 2019 at 4:12 AM Alex Kiernan wrote: > On Mon, Jan 14, 2019 at 8:49 PM Douglas Zobel > wrote: > > > > I've made some changes to the fastboot handlers to meet my needs. If > there is interest, I can prepare patches and submit them upstream. The > changes are: > > > > BUGFIX: Currently the 'fastboot format [partition]' command (run from > PC) formats the partition smaller than expected. Change > getvar_partition_size() to return partition size in # of bytes instead of > the current behavior of # of blocks. The 'fastboot format [partition]' > command expect u-boot to return the size in number of bytes in order to > format the partition correctly. > > > > Make the a fastboot oem command handler with a dynamic lookup like the > base fastboot command handler currently is. This would allow easily adding > new oem commands in the baseline software (such as below). It would also > allow for board files to extend the oem handler to handle OEM specific > cases. I would use a weakly defined default oem command handler (empty > function) which a board file can optionally override to handle board > specific commands. > > > > Currently the 'fastboot oem format' command (gpt write mmc # > $partitions) is supported. I'd like to add a 'fastboot oem verify' (gpt > verify mmc # $partitions) to help the flashing PC detect when a board needs > to be re-formatted. > > > > I'd no need for it, but when I did all of the changes to add UDP > support, my intention was that you'd implement oem command using > linker lists, at that point you can plug in whatever you need. > > I don't understand what you mean by linker lists. Can you give an example? -- This email and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and/or privileged information. Inadvertent disclosure of this message does not constitute a waiver of any privilege, right or remedy. If you are not the intended recipient, please do not directly or indirectly use, disclose or distribute this message, and please contact the sender and delete this email, any attachments and all copies. Climate and its affiliates may use, read or archive email communications (including attachments) through its computer network, as permitted by applicable law. Climate and its affiliates (or an external service provider) may also scan emails and attachments on its computer network to ensure systems operate efficiently and to minimize security risks. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Proposed fastboot changes
I've made some changes to the fastboot handlers to meet my needs. If there is interest, I can prepare patches and submit them upstream. The changes are: BUGFIX: Currently the 'fastboot format [partition]' command (run from PC) formats the partition smaller than expected. Change getvar_partition_size() to return partition size in # of bytes instead of the current behavior of # of blocks. The 'fastboot format [partition]' command expect u-boot to return the size in number of bytes in order to format the partition correctly. Make the a fastboot oem command handler with a dynamic lookup like the base fastboot command handler currently is. This would allow easily adding new oem commands in the baseline software (such as below). It would also allow for board files to extend the oem handler to handle OEM specific cases. I would use a weakly defined default oem command handler (empty function) which a board file can optionally override to handle board specific commands. Currently the 'fastboot oem format' command (gpt write mmc # $partitions) is supported. I'd like to add a 'fastboot oem verify' (gpt verify mmc # $partitions) to help the flashing PC detect when a board needs to be re-formatted. -Doug -- This email and any attachments are for the exclusive use of the intended recipient(s) and may contain confidential and/or privileged information. Inadvertent disclosure of this message does not constitute a waiver of any privilege, right or remedy. If you are not the intended recipient, please do not directly or indirectly use, disclose or distribute this message, and please contact the sender and delete this email, any attachments and all copies. Climate and its affiliates may use, read or archive email communications (including attachments) through its computer network, as permitted by applicable law. Climate and its affiliates (or an external service provider) may also scan emails and attachments on its computer network to ensure systems operate efficiently and to minimize security risks. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
