[PATCH] Provide more details of exactly how configuration signatures are calculated

Wed Jul 20 17:01:02 CEST 2022

Hi Martin,

On Wed, 20 Jul 2022 at 02:46, Martin Bonner <martingreybeard at gmail.com> wrote:
>
> OK.  I've just realized there is an important warning missing from
> this (if you verify a configuration signature outside u-boot, you
> _must_ verify the hashes for the kernel, fdt, and ramdisk images match
> too).  What is the protocol for handling that?  Submit a new patch
> with title "[Patch v2] ..."?

Yes when the images are loaded, the hash for each is verified. If that
is not done then you can change the images.

Yes you can do a v2 patch. See patman.

>
> I will hold off submitting that in case there are other comments that
> need to be addressed.
>
> Martin
>
> On Wed, 20 Jul 2022 at 08:23, Martin Bonner <martingreybeard at gmail.com> wrote:
> >
> > There are a couple of uncertainties still remaining:
> > - The "hashed-nodes" property is created by mkimage in image order.
> > What happens if somebody manipulates a signed image to change the
> > order?  Does it make any difference?  Do u-boot and fit_check_sign

If the wrong nodes are hashed then the signature will not match. If
you change it deliberately, then you still need to get the signature
right, which you cannot do without the private key.

For the order, it should not matter as I believe the fdt_region code
works through the DT in sequential order.

> > handle it in the same way?  (My preference would be that both fail the
> > signature on the grounds that there is no good reason for the nodes to
> > be out of order, and it suggests an attacker is trying to be clever.)

You could perhaps get the offsets of the paths and check that they are
in increasing order of offset.

> > - What happens if the image contains a DTB_NOP tag?  Is it included or
> > not?  (Again, I would fail the signature if it does.)

It should be included if the properties of that node are included by default.

> >
> > Martin
> >
> > On Wed, 20 Jul 2022 at 08:14, Martin Bonner <martingreybeard at gmail.com> wrote:
> > >
> > > I have just spent a week reverse-engineering this, so I thought I'd
> > > contribute the work back to the community
> > >
> > > diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
> > > index 61a72db3c7..61cdd55e40 100644
> > > --- a/doc/uImage.FIT/signature.txt
> > > +++ b/doc/uImage.FIT/signature.txt
> > > @@ -382,6 +382,25 @@ verified later even if the FIT has been signed
> > > with other keys in the
> > >  meantime.
> > >
> > >
> > > +Details
> > > +-------
> > > +The signature node contains a property ('hashed-nodes') which lists all the
> > > +nodes that the signature was made over.  The image is walked in order and each
> > > +tag processed as follows:
> > > +- DTB_BEGIN_NODE: The tag and the following name are added to the signature if
> > > +  the node or its parent are present in 'hashed-nodes'
> > > +- DTB_END_NODE: The tag is added to the signature if the node or its parent are
> > > +  present in 'hashed-nodes'
> > > +- DTB_PROPERTY: The tag, the length word, the offset in the string table, and
> > > +  the data are all included if the node is present in 'hashed-nodes' and the
> > > +  property name is not 'data'.
> > > +- DTB_END: The tag is always included.
> > > +
> > > +In addition, the signature contains a property 'hashed-strings' which contains
> > > +the offset and length in the string table of the strings that are to be added
> > > +to the signature (this is always done at the end).

There is an fdtgrep tool which actually shows you what is going on.
You can use the -A and -a options, for example, along with the same
settings that the signature code is using.