1

I'm doing a tiny bit of research and am wondering if there are any methods currently known for securing a sender such that it can be conclusively determined that a file has not been tampered with after it was created. I don't work in cryptography and only have a passing knowledge of the topics but I'm well aware of the hashing algorithms. My question is more about verifying that someone hasn't attacked and manipulated the system that performs the hash. We trust the hash that is provided to us but how can we verify the provider of the hash wasn't corrupted?

For example, assume a device takes a photo or video and automatically hashes (and possibly digitally signs?) the image or video produced, so that a recipient can hash the received image and verify the hash matches the one produced by the device. Consider a scenario where someone records an image with this device but wants to provide a falsified image after the fact. Is it possible to prevent them from doing so? i.e. do we have a method to prove that person A tampered with the image and/or the device after the fact, and that the image absolutely should no longer be trusted?

Improve this question
2
  • 1
    i've always found it silly when the document and hash come from the same server; how can you detect a fault in that case? Like when the sha is right next to the download link: useless – dandavis Jul 6 '17 at 18:47
  • Yes I've always wondered about that too. If a file is served from a third-party server over an unsecure link but the hash is provided from a separate server over a secure link then there is at least some reasonable reliance. But all a dedicated attacker has to do is compromise the server providing the hash, and there's no way that I know of to verify if that kind of tampering has occurred. And that's really what I'm looking for, verifying that a file and its claimed hash were not replaced by an attacker. – Dave Jul 6 '17 at 19:02
3

Normal hashing methods act as integrity checks for checking if a file is corrupt. In this context corrupt does not mean tampered with, but that something got lost in transit. It's totally possible for an attacker to change the hash on a compromised device.

To add to Douglas's solution to use an external log server: A solution to this is to use an HMAC. Here you create a hash with a secret. If both parties share the secret and the secret is now known to the attacker, you can detect if the file has been tampered with. However, if the device is compromised the attacker might got a hold of the secret, which would destroy this security layer. The same goes for signing with a secret key.

https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

If you can make it expensive you can start thinking about an HSM, which is a device created for the task you are describing. From Wikipedia:

HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection.

https://en.wikipedia.org/wiki/Hardware_security_module

Improve this answer
3
  • Ah ok thanks, I remembered the basic concept but forgot the term HMAC. I found this excellent answer on Crypto.SE that outlines hash vs MAC vs digital signatures. According to it since the sender and receiver must know the shared key, if the key is publicly viewable for public verification of the file then someone could take that key, alter the file, and regenerate a new hash disguising the attack. So then it seems digital signatures may be the way to go. crypto.stackexchange.com/questions/5646/… – Dave Jul 6 '17 at 17:22
  • The digital signature generally uses an asymmetric key, with the private part doing the signing, and the public part used for verification of the signature. Protecting the private key becomes the paramount issue -- if the key is compromised, the signature is useless. If someone has achieved root on your system, and the private key is just in some 600 directory someplace, they have your key and can put whatever they want out there, and masquerade it as coming from you. HSMs or auth-protected USB keys that are only attached when something is to be signed. – rip... Jul 7 '17 at 3:28
  • IRTYM not known to the attacker – dave_thompson_085 Jul 7 '17 at 3:55
2

You could immediately upload a hash of the image to a server you control as soon as the image is taken. That ensures that when you get the image later, you can verify it was taken at the point you got the hash, or earlier, and hasn't been modified in the mean time.

Doesn't prevent someone hacking the device to destroy the image, or taking the image earlier and only uploaded the hash later.

It also requires a continuous network connection for your device.

Improve this answer
2
  • That's pretty much along the lines I was thinking. If it caches the image/etc in another device while offline and then batch uploads the data periodically that introduces another attack point. That raises the question of can one device verify that it still has the authentic original data? If an attacker can break into the device and change the image but not the hash we can detect it, but if they can change the hash as well to whatever they want then we can't really prevent that. That's the crux of what I'm trying to find out, if there are ways to even detect if that happened. – Dave Jul 6 '17 at 16:45
  • And to clarify, I'm looking at a third party verifying this data when it doesn't trust the individual possessing the device. i.e. verifying the possessor didn't falsify the data they produced. There's no way I can think of to get around trusting the device itself though. – Dave Jul 6 '17 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.