Firmware image Checksums

Although MD5 is used to valid the checksum of firmware images, I believe the firmware images themselves are digitally signed using RSA; I can only speak from personal experience on this though...I recall sometime during 4.0 MR3 patch 7-11 period Fortinet uploaded a set of firmwares that either had no RSA signatures or had a problem with them, to their ftp site then quickly replaced them a few hours later with correct RSA signatures. 

As for MD5 itself, I still see companies like Cisco still using it to validate their firmwares (though in Cisco's case they do offer digitally signed firmwares).

Even juniper  offers   md5/sha checksum for there images files.

I don't know much about RSA signatures and google wasn't my friend today.

Is this a fair summary:

- Given any MD5 hash, it's possible to alter the image and still match the hash, but MD5 is a reasonable tool to quickly check for transmission errors;

- The images have RSA signatures. These are checked by the unit when loaded eg syslog "The image does have a valid RSA signature". This would detect both transmission error or an altered image.

- Hence the combination of the two covers both accident and malice?

Does the image fail to load if the signature check fails?

Can the signature be verified other than loading it into hardware?

I don't know much about RSA signatures and google wasn't my friend today. Is this a fair summary: - Given any MD5 hash, it's possible to alter the image and still match the hash, but MD5 is a reasonable tool to quickly check for transmission errors;

No , that's the purpose of the md5 hash, could the hash match something else ( collisions ) yes, the probability is yet to be determine. A few Chinese math genius have computed this. You hash the file, you will get the same hash over and over again.

- The images have RSA signatures. These are checked by the unit when loaded eg syslog "The image does have a valid RSA signature". This would detect both transmission error or an altered image. - Hence the combination of the two covers both accident and malice?   Does the image fail to load if the signature check fails? Can the signature be verified other than loading it into hardware?

Where are you finding the RSA signatures at? I never seen a RSA sign public-available for any fortinet images. The checksum check provides the checksum for all images, but none are a RSA.sign. I could be wrong but that's what I know.

Cisco and Juniper both do not provide pubic rsa.sign for there images. Both they do provide md5  ( cisco+juniper ) and sha hashes ( juniper). So the probability of any corruption could be checked via both hashes if available. If you doubt the md5 hash , you could open a ticket and have support compute the sha1 or other sha  hash.

or

If they are in a good mode, they could craft a rsa.sign , provide you the hashed rsa.sig and you  could compare. I'm only  guessing here  ( I never tried YMMV )

IMHO, if you download via  a secured HTTPs site from fortinet directly. Didn't use  FTP, and compare the md5 hash. Than you should be okay.

You hash the file, you will get the same hash over and over again.

if you download via  a secured HTTPs site from fortinet directly. [..] you should be okay

Where are you finding the RSA signatures at?

msg="[..] loaded an image [..] The new image does have a valid RSA signature."

Yes, but MD5 is broken. Given a file and it's md5 hash, you can make changes to the file in such a way that the hash remains the same ie md5(F1) = md5(F2) - so the hash fails its job. My point is that this is malicious and for an accidental change to the file the risk of the hash matching must be negligible (although still non-zero).

Can you actually demonstrated this? You have proof such as a ; study or cases or white-paper? Or are you speculating ?

If you modify a file, the resulting hash will  always be "changed", there's no way around this, regardless if it's  md5 , sha1 or sha256.

If  fortinet would provide more than 1 hash in the same fashion as  juniper or heck  a hash+sign like with our linux kernels sources;) , than your fears would be  squash.  Current practices for file sanity checks is to use SHA2 or better but half of the world has not move this way due to the md5  being readily available or known. Even tehe various us.gov hve moved away from md5/sha1 but we are talking about a gov agency with classified or TS data, we are talking bout a firmware image running an appliance ( a very big difference )

Funny thing as I'm writting this reply, the ftp/http linux kernel sources have been providing 2 forms of hash and a sign for decades to include a change-log details and have used SHA2 . Maybe the mfg'er & vendors should be using linux-kernel  concept for setting the example ;)

So it strange none of the major security  vendors have deployed this, or see this a big security risk or the sky if falling.

note:  I 'm  a pfsense user and test and even pfsense  distributions deploys a md5 and sha256 hash for ALL of there builds but no rsa signatures 

The unit itself reports about the RSA via syslog during a firmware update:

FWIW

So that means the all of the  *.out binary has the rsa.sign included in the "firmware" that your questioning. So that would not be a 100% sure means for integrity check.  If you where concern and want to scrutinize , than the signature should be externally craft after construction of the final binary & available for download and comparison. This is why I said,  fortinet has NOT made public  available rsa.sign for any of the firmware we receive.

So have anyone actually spoke up to Fortinet about the images delivery and the lack of  signatures?And gotten there input ?

A collision is not what your describing here when you write the following, ( pay attention to the bold letterings ).

Yes, but MD5 is broken. Given a file and it's md5 hash, you can make changes to the file in such a way that the hash remains the same ie md5(F1) = md5(F2) - so the hash fails its job.

If you take a file that's hash with md5 or any other message-digest, you will not be able to modify it without changing the hash. 

A collision is where "any two hash operations on "different" data will result in the same computed hash. A totally different issues.

This is why md4, md5 and sha0 have been determine to  not be 100% reliable. The math genius and professors all calculating and performing analysis to determine if collision attacks exist in all algorithm. It's probably  a matter of time before they find a flaw in sha2 for example ( probably decades or  centuries ;)

That was what I was trying to point out, that what you wrote could be mistakenly Interpet is not correct!