There was some interesting news yesterday about the cracking of an image authentication mechanism built into Nikon cameras. The hack was announced in what seemed to me like a rather adolescent post on the ElcomSoft company blog:
ElcomSoft Co. Ltd. researched Nikon’s Image Authentication System, a secure suite validating if an image has been altered since capture, and discovered a major flaw. The flaw allows anyone producing forged pictures that will successfully pass validation with Nikon’s Image Authentication Software. The weakness lies in the manner the secure image signing key is being handled in Nikon digital cameras.
In order to “fix” the problem, Nikon would have to redesign the way the signing key is being stored in the camera. They would have to hire someone who knows security well, which is what they should’ve done from the very beginning. They would have to publicly admit the existence of the problem in their old cameras. They would have to revoke the old signing key via an update to Nikon Image Authentication Software. They would have to generate a new signing key.
ElcomSoft has previously hacked the same feature in Canon cameras, so at a minimum, we can conclude that Nikon is not alone in hiring engineers who don’t know about security. But in fact, I don’t think that’s the problem; instead, I think this entire feature is doomed to failure regardless of the skill of the engineers implementing it. Fundamentally, the feature is oversold and doesn’t actually promise what people want it to promise.
In addition to being found in high-end DSLRs, checksum protection is a common feature in digital video recorders (DVRs), especially those intended for law enforcement use. (We’ve implemented it ourselves in CaseCracker.) Regardless of the product, the goal is always to prove that a particular file — whether a still image or a video clip — wasn’t altered after it was recorded. This is especially desirable if the file is going to be used for legal or evidentiary purposes.
Let’s start by looking at the problem Nikon is trying to solve. Assume the customer is a police department, and assume the Nikon camera is being used to record crime scene photos. The police want to defend against an accusation that, after a particular picture was taken, somebody malicious edited it in order to frame an innocent person.
So Nikon is trying to devise an algorithm that an attacker cannot apply to his edited photo, and then overwrite the original checksum (which is stored in the JPEG EXIF data) with the one from the modified version. Meanwhile, the algorithm needs to be self-contained — it must run entirely inside the camera. Which is in the attacker’s possession.
Here’s a simplified diagram of how this is usually implemented:
The way the system is supposed to work is that the camera takes the digital source file, runs some “magic formula” over it, includes the time and date that it is running the magic formula, and then stores the resulting checksum. In Nikon’s case, ElcomSoft says the “magic formula” is two SHA-1 hashes run over, respectively, the image data and the metadata, and then encrypted with a private key hardcoded into the camera, using a 1024-bit RSA encryption algorithm.
(One obvious attack vector with all these systems is the security of the clock reference since on most cameras the attacker can simply change the time and date on the camera and shoot any doctored photo he desires. Setting this aside, however.)
To make the system work, Nikon had to rely on keeping the “magic formula” and the private key secret. The problem is that, because the private key must be hardcoded into the system, it’s hard to keep it very secret because it is discoverable by a clever attacker using a debugger.
So that’s why, in my opinion, all checksum protection features boil down to a case of security through obscurity. Sure, the checksum protection moves the bar by making it slightly harder to maliciously edit photos or video. But it doesn’t prevent it.
The only true way to prove that video hasn’t been edited since the time of recording is to subject the recording to the same rigorous chain-of-custody procedures used for other evidence.
I will be the first to admit that I’m not “someone who knows security well;” ElcomSoft can sneer away at me, and I will nevertheless manage to get to sleep tonight. But I can only come up with two ideas for things a vendor implementing this feature might do to make it more secure, other than what Nikon did:
- One, the vendor could move the checksum algorithm down into an ASIC on the camera instead of running it in software. This approach implies higher development costs and much less ability to modify the feature in the future, but it would make it harder (though not impossible!) to hack.
- Two, if we could assume the camera is always connected to the internet, the camera could send the SHA-1 checksum of the picture to a secure, trusted server; the server would then apply a timestamp and store the checksum. This approach raises some big privacy issues, and once you have a law enforcement camera on the internet, you have some other attack vectors to worry about. We’re probably a few years away from having ubiquitous enough network connectivity for this, but it’s really the only bulletproof way I can see to solve this problem.
If you can see other solutions that I’m missing, please leave a comment!
