I am working with an embedded system that accepts firmware updates only if they are validly signed by a particular 2048-bit RSA private key (the embedded system's bootloader knows the corresponding public key).
On the publishing side, the signature is generated by:
- computing the SHA-256 hash of the firmware image
- padding it according to EMSA-PKCS1-v1_5 (which involves prepending a fixed 1792-bit string)
- signing the concatenated 2048-bit value by exponentiation with the RSA private key
On the embedded side, the signature is verified by:
- independently (re-)computing the SHA-256 hash of the received firmware image
- recovering the concatenated 2048-bit value from the signature by exponentiation with the RSA public key
- verifying that the first 1792 bits of the value exactly match the expected padding string
- verifying that the last 256 bits of the value (i.e. the SHA-256 hash computed on the publishing system) exactly match the hash computed on the embedded system
So, the question:
Is step #3 (verifying the EMSA-PKCS1-v1_5 padding) important to the security of the system?
(This is a theoretically-motivated question; I want to educate myself. It's not a significant added cost on the embedded side to verify the padding.)
P.S. I've attempted to search for existing questions/answers already, and Attacking RSA signature verification that ignores padding is very close. In that case though, I gather that the implementation basically searched the entire recovered 2048-bit value for a substring matching the recomputed SHA-256 hash; and the possibility of having garbage data after the hash specifically made attacks like this Kindle HDX hack possible.
In this case I'm specifically wondering whether it's a bad idea to simply ignore/remove the first 1792 bits (assumed to be the padding) and only compare the last 256 bits to the expected hash. Does that open the possibility for the same type of attack? Or for different attacks?