[PATCH v3] Provide more details of exactly how configuration signatures are calculated
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@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@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.
Signed-off-by: Martin Bonner martingreybeard@gmail.com
Does it matter that v3 is signed off by martingreybeard@gmail.com but emailed by martin.bonner@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.)
Hi
On Thu, Aug 4, 2022 at 8:29 AM Martin Bonner Martin.Bonner@entrust.com wrote:
Signed-off-by: Martin Bonner martingreybeard@gmail.com
Does it matter that v3 is signed off by martingreybeard@gmail.com but emailed by martin.bonner@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.)
Can you just git commit --amend --author="Martin Bonner martin.bonner@entrust.com" --sighoff="Martin Bonner martin.bonner@entrust.com"? and then use git send-email?
[sendemail] smtpserver = smtp.gmail.com smtpserverport = 587 smtpencryption = tls smtpuser = Martin Bonner martingreybeard@gmail.com smtppass = ************ suppresscc = self
What is your scope? using gmail to send and confirm the corporate work?
Michael
-- Martin Bonner
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Martin Bonner Sent: 03 August 2022 17:32 To: u-boot@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
- It is (I think) a valid patch file
- It has come from my corporate email address (which surprisingly forces less mangling than gmail).
- 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@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@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.
Hi Martin
On Wed, Aug 3, 2022 at 9:55 PM Martin Bonner Martin.Bonner@entrust.com wrote:
The only changes from [PATCH v2] are
- It is (I think) a valid patch file
- It has come from my corporate email address (which surprisingly forces less mangling than gmail).
- 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@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@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@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.
participants (2)
-
Martin Bonner -
Michael Nazzareno Trimarchi