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