As a preface, I have to say that I am a noob in this area. Having said that, I will ask the question.
I have a situation where I need to validate and protect against tampering a handful of large binary files (~1GB each with ~10GB total) distributed on an embedded system (think Android Tablet). These original files will have a need to have a hash which can ensure that the files have not been tampered with.
Now, the challenge is that these files can be updated with a patch periodically downloaded from a webserver. These patch files will also be distributed with a hash which will ensure that the patch is authentic. (The files will be downloaded over a secure connection.)
Finally the patch needs to be applied to the original files on the embedded system which will then result in the need to regenerate the hash for the newly patched files so that they can be subsequently verified in the future.
There are several challenges:
- Since these are large files running in an embedded system, the 'recommended' algorithms for hashing like SHA256 may prove to be too expensive to compute at runtime on a mid-range embedded system. The back of the napkin calculation says that may take upwards of several minutes to compute. Since this verification must occur every time an application launched to read this data, it must be very fast for 10GBs of data - less than 5 seconds.
- Since the patch is being applied on the embedded system, the actual hash for the newly patched file must be computed on the embedded system itself.
I was thinking that we could simply compute a faster, "weak" hash (like MD5) on the large files first. Then I would make a server request (with mutual auth) to encrypt the MD5 hash with a private key and return an encrypted hash to the embedded system. Then whenever I want to verify the file integrity, I would use the public key to decrypt the encrypted hash and then verify the hash against the actual files.
Any thoughts on this approach? Does my idea work?
Thanks for your thoughts.