Re: fit_check_sig not hashing everything.
Hi Martin, On Fri, 8 Jul 2022 at 01:11, Martin Bonner wrote: > > On Thu, 7 Jul 2022 at 17:29, Martin Bonner > wrote: > > > I have a 30MB FIT image as input, and I have added some debug to > > hash_calculate in rsa-checksum.c to print the amount of data being hashed. > > The answer is a rather scary "1106 bytes"! ... > > > > Can anyone clarify what is happening? > > > > Never mind. I have found fit_image_check_hash in image-fit.c (yay for gdb > read watchpoints!) So the algorithm is basically "verify that the hashes > of each image is correct", then calculate a hash which includes the hashes > of the images (but not their data), and sign that. (I think it's > overcomplicated, and complexity is the enemy of security - but it's much > too late to change that.) Some reasons: - it is faster to hash things only once (i.e. use the image hash we already have) - It is faster to hash smaller things (i.e. the meta data) This of this as a tree of hashes... Regards, Simon
Re: fit_check_sig not hashing everything.
On Thu, 7 Jul 2022 at 17:29, Martin Bonner wrote: > I have a 30MB FIT image as input, and I have added some debug to > hash_calculate in rsa-checksum.c to print the amount of data being hashed. > The answer is a rather scary "1106 bytes"! ... > > Can anyone clarify what is happening? > Never mind. I have found fit_image_check_hash in image-fit.c (yay for gdb read watchpoints!) So the algorithm is basically "verify that the hashes of each image is correct", then calculate a hash which includes the hashes of the images (but not their data), and sign that. (I think it's overcomplicated, and complexity is the enemy of security - but it's much too late to change that.) Martin
fit_check_sig not hashing everything.
I am running fit_check_sig on windows to understand in more details how it works. What I really want, is a _precise_ description of exactly which bytes of a FIT image are fed into the hash function (and in which order) in order to calculate the hash value. I then want to reproduce that hash function in python (using the "fdt" module) in order to sign the FIT image offline. I am expecting to have to reverse engineer this description (signature.txt isn't nearly detailed enough for me), and that's fine (although if anyone wants to prove me wrong, that would be wonderful). I have a 30MB FIT image as input, and I have added some debug to hash_calculate in rsa-checksum.c to print the amount of data being hashed. The answer is a rather scary "1106 bytes"! The good news is that I have also added debug to print out the offset within the FIT image of the regions being hashed (actually in fit_config_check_sig in image-sig.c), and used this to zero a single byte of the FIT image well away from the offsets (allegedly) being hashed - and the verification fails (yay!). So clearly I don't understand what is going on (!). Can anyone clarify what is happening? One slightly strange thing I notice is that fit_config_check_sig appears to be called four! times. I am working with 2020.1, and cannot easily upgrade to the latest because the signature nodes contain @. Debug: Verifying Hash Integrity ... In fit_config_verify MJB fit_config_verify_required_sigs In fit_config_verify_sig MJB Verifying signature for node hash@1 MJB Verifying signature for node signature@1 sha256,rsa4096:ultra-insecure Verifying 8 regions: 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00 04 (offset=38 len=180) 00 00 00 03 00 00 00 07 00 00 00 30 6B 65 72 6E (offset=4cee04 len=244) hash@1 region (offset=4d5b30 len=176) 00 00 00 03 00 00 00 08 00 00 00 30 72 61 6D 64 (offset=1d4d7b4 len=184) 00 00 00 01 63 6F 6E 66 40 31 00 00 00 00 00 03 (offset=1d4d880 len=124) 00 00 00 02 00 00 00 01 73 69 67 6E 61 74 75 72 (offset=1d4d910 len=20) 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 (offset=1d4dc70 len=20) 64 65 73 63 72 69 70 74 69 6F 6E 00 6E 73 68 69 (offset=1d4dc84 len=158) Total bytes hashed = 1106+ ## Loading kernel from FIT Image at 6e2b ... Using 'conf@1' configuration Verifying Hash Integrity ... In fit_config_verify MJB fit_config_verify_required_sigs In fit_config_verify_sig MJB Verifying signature for node hash@1 MJB Verifying signature for node signature@1 sha256,rsa4096:ultra-insecure Verifying 8 regions: 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00 04 (offset=38 len=180) 00 00 00 03 00 00 00 07 00 00 00 30 6B 65 72 6E (offset=4cee04 len=244) hash@1 region (offset=4d5b30 len=176) 00 00 00 03 00 00 00 08 00 00 00 30 72 61 6D 64 (offset=1d4d7b4 len=184) 00 00 00 01 63 6F 6E 66 40 31 00 00 00 00 00 03 (offset=1d4d880 len=124) 00 00 00 02 00 00 00 01 73 69 67 6E 61 74 75 72 (offset=1d4d910 len=20) 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 (offset=1d4dc70 len=20) 64 65 73 63 72 69 70 74 69 6F 6E 00 6E 73 68 69 (offset=1d4dc84 len=158) Total bytes hashed = 1106+ OK Trying 'kernel@0' kernel subimage Description: Linux Kernel Created: Mon Apr 4 09:12:26 2022 Type: Kernel Image Compression: gzip compressed Data Size:5041417 Bytes = 4923.26 KiB = 4.81 MiB Architecture: PowerPC OS: Linux Load Address: 0x Entry Point: 0x Hash algo:sha256 Hash value: d36fb92a4af6184ddb42619691323f8b45f84fdb77f5cc65d0d0cebd115eb6f3 Verifying Hash Integrity ... sha256+ OK Uncompressing Kernel Image Unimplemented compression type 1 ## Loading fdt from FIT Image at 6e2b ... Using 'conf@1' configuration Verifying Hash Integrity ... In fit_config_verify MJB fit_config_verify_required_sigs In fit_config_verify_sig MJB Verifying signature for node hash@1 MJB Verifying signature for node signature@1 sha256,rsa4096:ultra-insecure Verifying 8 regions: 00 00 00 01 00 00 00 00 00 00 00 03 00 00 00 04 (offset=38 len=180) 00 00 00 03 00 00 00 07 00 00 00 30 6B 65 72 6E (offset=4cee04 len=244) hash@1 region (offset=4d5b30 len=176) 00 00 00 03 00 00 00 08 00 00 00 30 72 61 6D 64 (offset=1d4d7b4 len=184) 00 00 00 01 63 6F 6E 66 40 31 00 00 00 00 00 03 (offset=1d4d880 len=124) 00 00 00 02 00 00 00 01 73 69 67 6E 61 74 75 72 (offset=1d4d910 len=20) 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 (offset=1d4dc70 len=20) 64 65 73 63 72 69 70 74 69 6F 6E 00 6E 73 68 69 (offset=1d4dc84 len=158) Total bytes hashed = 1106+ OK Trying 'fdt@0' fdt subimage Description: Flattened Device Tree blob Created: Mon Apr 4 09:12:26 2022
