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

[Martin Bonner]

> Signed-off-by: Martin Bonner <martingreybeard at gmail.com>

Does it matter that v3 is signed off by martingreybeard at gmail.com but emailed by martin.bonner at entrust.com?

*I* know that they are the same person, but you only have my word for that.  (OTOH, you can compare this patch to v2 and see they are the same.)

-- 
Martin Bonner


-----Original Message-----
From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Martin Bonner
Sent: 03 August 2022 17:32
To: u-boot at lists.denx.de
Subject: [EXTERNAL] [PATCH v3] Provide more details of exactly how configuration signatures are calculated

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
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

-- >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.