[PATCH] Provide more details of exactly how configuration signatures are calculated
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). + + Verification ------------ FITs are verified when loaded. After the configuration is selected a list
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 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.) - What happens if the image contains a DTB_NOP tag? Is it included or not? (Again, I would fail the signature if it does.)
Martin
On Wed, 20 Jul 2022 at 08:14, Martin Bonner martingreybeard@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).
Verification
FITs are verified when loaded. After the configuration is selected a list
-- Martin
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] ..."?
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@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 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.)
- What happens if the image contains a DTB_NOP tag? Is it included or
not? (Again, I would fail the signature if it does.)
Martin
On Wed, 20 Jul 2022 at 08:14, Martin Bonner martingreybeard@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).
Verification
FITs are verified when loaded. After the configuration is selected a list
-- Martin
Hi Martin,
On Wed, 20 Jul 2022 at 02:46, Martin Bonner martingreybeard@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@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@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.
See also here:
https://static.googleusercontent.com/media/research.google.com/en//pubs/arch...
(the slide on signing configurations, there is a video too)
Verification
FITs are verified when loaded. After the configuration is selected a list
Regards, Simon
participants (2)
-
Martin Bonner -
Simon Glass