[U-Boot] verified boot against a chain of public keys

I am about to embark on the task of adding support for importing and using multiple keys in the verified boot process. Does u-boot already support this? Has anybody (else) thought about it?
Basically, I would like to add the ability to import a public key into u-boot, which must be signed by the (one of) the existing key(s), and use that key to validate the image that I want to boot (or additional keys I would like to import). In essence, I would like to add a signature chain to u-boot that can be loaded at runtime.
I am about to dive into the code and see if I think this is a good or bad idea from the perspective of the code, but, in parallel, I thought I should ask for some perspective from the community.
It seems to me that I could package up the key to be imported into a .dts file, sign that using mkimage, and "boot" it into u-boot with the "bootm" command. (I would prefer to use a "loadkey" command, just to make things clear.). It seems like most of the machinery I need should already be there.
It also seems like it should be pretty easy to teach u-boot to support having multiple keys in memory (using the key-name-hint), and, in fact, that capability may already be there. (I'll know shortly after I start digging further into the code).
Anyway, back to the opening paragraph... Does u-boot already support anything like this? Do folks think this is a good idea? a bad idea? a difficult idea? an easy idea?
Any thoughts?
--wpd

On Mon, Aug 12, 2019 at 8:01 AM Patrick Doyle wpdster@gmail.com wrote:
I am about to embark on the task of adding support for importing and using multiple keys in the verified boot process. Does u-boot already support this? Has anybody (else) thought about it?
I now see that lib/rsa/rsa-verify.c actually checks against multiple public keys compiled into the device tree. I guess I could use fit commands to add more nodes with keys to the device tree, but that seems a bit cumbersome. Plus, they wouldn't be verified against the existing key(s).
Still plugging away...
--wpd
participants (1)
-
Patrick Doyle