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

[Michael Nazzareno Trimarchi]

Hi Martin

On Wed, Aug 3, 2022 at 9:55 PM Martin Bonner <Martin.Bonner at entrust.com> wrote:
>
> The only changes from [PATCH v2] are
> 1. It is (I think) a valid patch file
> 2. It has come from my corporate email address (which surprisingly forces less mangling than gmail).
> 3. I have extended the commit message slightly
>
> Apologies for the irrelevant email footer - it is automatically added by corporate IT.
>
> Please apply with:
>     git am --scissors file.eml
>

Can you just write the Changes note in the next section like:

Describe exactly which bytes are hashed and in what order so that external
tools can calculate a valid signature.

Signed-off-by: Martin Bonner <martingreybeard at gmail.com>
---
Changes V1->V2:
1. It is (I think) a valid patch file
2. It has come from my corporate email address (which surprisingly
forces less mangling than gmail).
---
doc/uImage.FIT/signature.txt | 26 ++++++++++++++++++++++++++

> -- >8 --
>
> Describe exactly which bytes are hashed and in what order so that external
> tools can calculate a valid signature.
>
> Signed-off-by: Martin Bonner <martingreybeard at gmail.com>
> ---
>  doc/uImage.FIT/signature.txt | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
>
> diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
> index 61a72db3c7..c71280b63b 100644
> --- a/doc/uImage.FIT/signature.txt
> +++ b/doc/uImage.FIT/signature.txt
> @@ -382,6 +382,32 @@ 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 included in the signature
> +  if the node or its parent are present in 'hashed-nodes'
> +- DTB_END_NODE: The tag is included in 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 current node is present in 'hashed-nodes'
> +  and the property name is not 'data'.
> +- DTB_END: The tag is always included in the signature.
> +- DTB_NOP: The tag is included in the signature if the current node is present
> +  in 'hashed-nodes'
> +
> +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
> +included in the signature (this is done last).
> +
> +IMPORTANT:  To verify the signature outside u-boot, it is vital to not only
> +calculate the hash of the image and verify the signature with that, but also to
> +calculate the hashes of the kernel, fdt, and ramdisk images and check those
> +match the hash values in the corresponding 'hash*' subnodes.
> +
> +
>  Verification
>  ------------
>  FITs are verified when loaded. After the configuration is selected a list
> --
> Martin Bonner
> martin.bonner at entrust.com
>
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com