Slashdot Mirror
Canon's Image Verification System Cracked
TJNoffy writes "The H Security's H-online reports that 'Hacker Dmitry Sklyarov has succeeded in extracting the secret signing key from numerous digital SLR cameras and has used it to sign modified images which Canon's latest OSK-E3 security kit verifies as legitimate. Canon's Original Data Security System is intended to show whether changes have been made to photographs and to verify date and location information. The system is primarily used for ensuring the integrity of evidence, for reporting accidents and for construction records.'"
I didn't even know such technology existed!
I thought they just posted it on /b/ asking "reel or phake?"
And they just tallied the number of "Photoshoped" responses versus the total responses.
What?
Is this a Canon-only feature, or on Nikon cameras too?
Beware: In C++, your friends can see your privates!
This could be a very big deal, if you can use it to establish reasonable doubt. *Many* police agencies use Canon. The traffic light and speeding cameras in Arizona are Canons. Of course, at your trial they will use the whole "controlled chain of custody" argument to say the images could not have been tampered with and the signing will be irrelevant, but who knows?
-fb Everything not expressly forbidden is now mandatory.
With TPM chips being cracked previously, after apparently being tamper-proof, even if they implemented it using an algorithm that was suitable for the job (i.e. not use SHA but ECC or RSA) it would still be possible to get the signing key. It's flawed in the same way DRM is flawed, you can't give someone else the key and not give them the key at the same time.
I dream of a nation where a man is not judged by his skin color but by an number assigned by a credit rating agency.
Anyone who uses a hash, instead of something asymmetric like RSA, for "signing" doesn't know what they are on about. I would have hoped that Canon could afford better programmers.
It doesn't matter; if you can extract the software inside the camera, you can do anything the camera does. It doesn't matter whether they use SHA, RSA, or ROT-13.
The correct solution would be to put the key in a tamper-resistant hardware cryptographic processor, and secure the firmware on the camera against running unverified code. Canon did neither.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Which is...completely unrelated to the article. You might consider reading the summary, or even the headline.
It's flawed in the same way DRM is flawed, you can't give someone else the key and not give them the key at the same time.
You also can't give everyone the same key without the cracking of one person's device cracking everybody's device. B-b
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
...is not a secret key.
At the time of his arrest, Dmitry Sklyarov was a 27-year-old Russian citizen, Ph.D. student, cryptographer and father of two small children (a 2-1/2 year old son, and a 3-month-old daughter).
Dmitry helped create the Advanced eBook Processor (AEBPR) software for his Russian employer Elcomsoft. According to the company's website, the software permits eBook owners to translate from Adobe's secure eBook format into the more common Portable Document Format (PDF). The software only works on legitimately purchased eBooks. It has been used by blind people to read otherwise-inaccessible PDF user's manuals, and by people who want to move an eBook from one computer to another (just like anyone can move a music CD from the home player to a portable or car).
Dmitry was arrested July 17, 2001 in Las Vegas, NV, at the behest of Adobe Systems, according to the DOJ complaint, and charged with distributing a product designed to circumvent copyright protection measures (the AEBPR). He was eventually released on $50,000 bail and restricted to California. In December 2001, was permitted to return home to Russia with his family. Charges have not been dropped, and he remains subject to prosecution in the US.
Although Dmitry is home now, the case against Elcomsoft is continuing (to the detriment of the company), Dmitry's actions in Russia are controlled by a US court, and DMCA is still the law (to the detriment of everyone). This site will carry updates as they come...
Source: http://www.freesklyarov.org/ (for those who don't remember 2001's Defcon incident)
|/usr/games/fortune
I think alot of the cameras are video now as a photo is poor next to have a video of you not stopping for the red light.
I'd still get broken eventually. I'd rather not rely on the camera - instead have it hash the picture, then immediately transmit the hash to five different legal firms. This would add a significent expense, of course - but if people feel they'll have a need to prove in court their photo wasn't tampered with, they should be prepared to pay a premium for a camera that comes equipped with a mobile phone network interface.
What they should have done was have exactly as you stated -- a tamper resistant CPU, akin to smart cards. This would have a private key generated and stored on the chip. Canon would have a certificate that would sign the private keys (so someone couldn't just fake a private key with a hacked camera body.)
This way, if camera "A" got compromised, every other Canon camera out there would still be protected. It appears that the method they used, if one camera got hacked, every one was broken open because they all used the same private key.
Really, cryptographic jiggery-pokery is a problem best solved outside the camera. Generating an MD5 or SHA1 onboard is fine(even if you don't care about the crypto, it's a nice check against memory card corruption, and most nicer cameras have the entire frame in memory at some point before writing it to the card so the hashing should be fast); but leaving the crypto to a removable, interchangeable, person/organization unique crypto smartcard would really be the way to go.
That way, you wouldn't need to trust the camera(other than to be not broken, calculating false MD5s would be useless and swiftly detected), plus you could easily swap out the high-value portion of the hardware so that multiple authorized users could share a camera, and their cards could be physically protected when not in use.
How do those firms know they're getting the original picture?
The providence has to start at the camera.
That doesn't seem particularly relevant, the main problem here is that everything required to do the signing can be extracted from of the camera.
It's a simple necessity that, regardless of precisely how the signature is generated, all the information required to generate signatures is inside the camera and someone with the desire and resources can pull it out.
I think the only protection would be each camera having a unique key and being constructed in such a fashion so that getting at the crypto information and functionality requires taking the camera apart in a tamper evident and non-reversible fashion.
Then proof would consist of the the signed photos and verification that the corresponding camera is still intact and functional.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
"providence" should, of course, have been "provenance".
Cracking one chip doesn't mean that they all are cracked. The concept is sound, and all it takes is another rev of the chip to have better anti-tamper protection. For example, one cryptographic token maker, someone had a website about being able to use hot water to pop the case in two for access to the chip. They (IIRC) learned their lesson and started using poured epoxy with no seams before putting the case on. None of their newer tokens have been cracked, as far as I know.
Right now, TPM chips have no physical protection, it is even stated prominently on sites that this is the case. However, eventually they will end up going the route of HDCP chips, and being epoxy-blobbed to the motherboard and/or put in a more tamper resistant package.
Because we all know smart cards have never been cracked. There aren't people that churn out smart cards, and all smart cards are oh so impervious to hardware based attacks.
They relied on chains of custody and affidavits by the photographer, that's how.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
What Canon can do?
-With current available models nothing
-With future models blah... blah... blah...
-Hire people who really understands security
Having been on that side of the industry, there's no way Canon's putting a smart card chip in camera. Why? Cost mostly. And then there's the significant problem of communicating from the camera OS to the smart card chip. And then there's the significant increase in the cost of manufacturing.
They aren't going to hire anyone either. This decision was made long ago and the constraints are still cost and calendar. Both extraordinarily tight.
Canon will generally defame Skylarov to any agency that feigns interest and be generally dishonest about the whole thing.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Aren't they using cards that can only be written once? How about going back to using mini CDs?
For justice, we must go to Don Corleone
It depends on the smart card. I'd love to see someone extract a private key out of a CAC, for example. There are other smart cards which have been completely compromised, but newer ones made within the past couple years are getting to the point of having decent security.
Nothing is 100% secure, but CACs are good enough for the DoD, and that says something.
Where legal certainty is required
Publish the original picture encrypted with the photographer's PUBLIC key in a public place or file it with 5 different legal firms. Only the photographer can decrypt it, at least for the time being (*cough*quantumcomputer*cough*).
Then using an independent set of hardware/software have the photographer retrieve the encrypted copy, decrypt it, print it out with the meta-data in human-readable form and a signed digest in a human-readable form, attach a human-readable affidavit saying "I took this photo at this date and location and the metadata is true and accurate" and have him store that with his files. Have witnesses if it's that important.
If there are any questions then the affidavit and printouts should authenticate the original.
For things that won't go to court
For things that won't go to court such as your newspaper that is trying to enforce professional integrity, you don't need this level of trust. For those cases just have the photographer take today's images and append meta-data to each one consisting of a digitally signed signed digest of the photograph and a digitally signed statement describing the circumstances of the photograph, e.g. "Joe Smith, December 2 Acme Hardware Store Grand Opening, for The Village News." Sure, it won't stop fraudulent use of "unprotected" pictures but it will deter re-use of pictures that are "protected."
Couple this with every news and stock photo agency putting similar "signed histories" on all of their existing works and publishing the digests of the digests, it will make it very very difficult for someone to re-use a several-year-old photo in an illustration and take credit for it without a big risk of being caught.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Windows is good enough for the DoD. That says something too.
You don't seem to have a very good knowledge of cryptography yourself... Good signature algorithms use both a hash and something asymmetric.
Most signature algorithms start with a hash of the original file, because signing a big document would require a lot of computations. This does not reduce the security of the signature, as long as you don't use a broken hash function (and even if your hash function is as broken as MD5, the impact in this kind of scenario would be quite limited). Note that it is actually necessary to do some some kind of preprocessing of the message because RSA has bad multiplicative properties.
BTW, I don't see any mention of the algorithm used by Canon in TFA but they mention a key and hash functions do not have a key, so they're not just hashing the picture (which would indeed by stupid).
They blew it entirely if every camera has the same signing certificate as well. What they should have is a root CA, and intermediate CA which issues certificates to each camera based on their serial number. This would also imply the certificate is not part of the software but perhaps burned into an eeprom on the camera . Then the signed photos "bogus or not" would have the serial number of the camera. To forge the photo and have it appear to come from a particuler camera still may not be that difficult, but a single compromise doesn't compromise the integrity of the entire system.
In a certain sense you are right that you can't give people the key and not give them the key at the same time. In the same sense public key cryptography does not work because you are giving people the (private) key, just in a form (the public key) that isn't easily accessible. Yet, public key cryptography does work because accessing the private key from the public key is so difficult that it isn't worth the bother. In the same way, you can make cameras where extracting the key is so difficult that it isn't worth the bother. Especially if each individual camera has its own key.
The DoD is hardly an ideal model of security. I'll leave it at that.
https://www.eff.org/https-everywhere
It depends on the smart card. I'd love to see someone extract a private key out of a CAC, for example. There are other smart cards which have been completely compromised, but newer ones made within the past couple years are getting to the point of having decent security.
Nothing is 100% secure, but CACs are good enough for the DoD, and that says something.
Wikileaks got their leaked data via DoD.
I've got to second the above posters.
though FAR from secure,
for the DoD, CAC's are "good enough".
The TPM is a joke when it comes to security processors. effective tamper detection and response are not possible at the price point TPMs in COTS PC's sell for.
Cracking one chip doesn't mean that they all are cracked.
Whilst it is true that future updates might be harder to crack, this doesn't diminish the impact of this particular hack - the image authentication on every Canon EOS camera that has already been sold is now untrustable, and can be challenged in court.
That's not true, if I wait till after it's been copied off the camera that means I only know what was submitted is free of tampering from that time on. I have no clue what was done to it before you submitted it. This is why the encryption needs to be on the camera.
letting an idiot know they are an idiot is not a game... it's a responsibility. - by Kristopeit, M. D. (1892582)
.
Requiem for the American Dream
For verification you need a private key + a public key. The public key is a hash of the photograph itself. The private key is known only to Canon. The private key absolutely must exist on the camera in order for it to generate a signature of the photo (generated from hash + public key).
For verification all the Canon software needs to do is perform the same operation the camera would have: combine a hash of the photo with the private key and generate a signature. If the two signatures match, the photo is verified.
This is pretty much how any verification system of this type will work. There aren't any practical alternatives.
The article didn't come out and say how they did it, but it said they obtained the key from the camera itself. If you can get the key off the camera, the whole system is broken. It doesn't matter what kind of hash function you used, if you have the private key you can generate a valid signature from any image you want - edited or not.
My guess is that the firmware wasn't secured or sufficiently tamper resistant. The key must exist on the camera, so Canon must take steps to ensure the key is inaccessible. They did not do a good enough job of this, and now their verification system is worthless. They'll have to start all over now.
hash functions do not have a key
Somebody doesn't know how hash functions work. For a hash of a file, the key is the file itself. The key is whatever you used to generate the hash - they don't happen by magic. Often for authentication the key itself is a hash - the signature is a hash of a hash. In the case of Canon's image verification, at least half of the key is a hash, the other half is also probably a hash (since they are so nicely random and can be generated from crazy things), but it may not be. Technically just concatenating the public key and the private key is a hash function (albeit an ultra simple one) which generates a new hash, from which a hash function generates the final signature. A hash of a hash of two hashes. That's all these are.
The point here is that hashes do not exist without a key. If it has no key, it's just a random number with no meaning behind it.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Actually the only way is a chemically reacting substrate known as film. Try faking a a real photo and getting that past forensics. Snarf!
The equivalent glass from Nikon or Sony (formerlyMinolta) is also not cheap. Sigma/Tamron are a bit better, but often a step down in quality.
You want to talk breathtakingly expensive, look at Leica, or Hasselblad.
you can't give someone else the key and not give them the key at the same time.
You obviously don't know how one-way hashes work (encryption is a two-way or reversible hash, and what you said is true for encryption).
Can you take an MD5 checksum of a file and generate the file? Of course you can't. The checksum does not contain anywhere near the same amount of information as the file contains. But that checksum is a repeatable signature of that file, and you'll notice immediately if it has been tampered with even slightly, because the checksums won't match.
By the same token, if you take a 256bit hash of a photo, multiply it by a 256bit secret key, and take a 256bit hash of the resulting number, then the key does not exist in the resulting hash (we'd call it a signature now, because it is repeatable if you have the key and a copy of the raw image). Parts of the key may exist in the hash (it's quite possible none of the key made it into the final hash), but you took a 256bit hash of a 64kbit number, so 99% of the information wasn't used in the final signature, yet you still got a unique 256bit signature out of the process. In other words, you can't take a ten megabyte file, turn it into a one megabyte file, and expect to reproduce the ten megabyte file using only the one megabyte file and the algorithm used to get it that small. You can take the ten megabyte file and reproduce the one megabyte file all day long, but you can't go backwards. You've permanently lost information, and in the case of signatures, that is by design.
It's easy to take two keys and produce a third key that is unique (can only be generated by the two keys) yet does not actually contain the two keys used to generate it.
What these guys have done is actually get a hold of the private key (the public key is a hash of the image) from the camera. If you have the private key you can break any authentication system, no matter how good your algorithms are.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
What if you just put a smart card reader on the camera, and use insert-smart-card-issued-correctly-here with it?
Bullshit.
The private key is never shared, and when you generate a hash from the private key, information in the key is lost making it impossible to reproduce.
If that were not true nobody would bother with encryption, because it would be immediately reversible.
You can always brute force decrypt a key, but it is very difficult. The process works by guessing what the private key is and generating a signature, then seeing if it matches the true signature. Do this enough times and you'll eventually find the private key. Since you are looking 3.4^38 possible combinations, though, anything beyond 128bits is impossible to brute force in a practical sense (you could do it, but it would take decades). In a few years that won't be true, which is why we already have 256bit and 512bit encryption algorithms, and work is always being done to create bigger and badder encryption algorithms, but it is true right now.
Again these work by guessing the key, the key itself is not contained in the signature. In fact the public key isn't even in the signature generally, but it is public so of course you have ready access to it (in this case the public key is a hash of the raw image).
The problem in this case is with the security of the camera. They key must be contained on the camera or the camera won't be able to create the initial signature. So these Russian blokes simply broke into the camera and stole the key. They warned Canon before they did this that there were serious flaws with the security of their cameras, but apparently Canon wasn't responsive enough, so they went ahead and broke into the camera, got the key, and generated a half dozen obviously faked photos that Canon's software verifies as legitimate.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
For verification you need a private key + a public key. The public key is a hash of the photograph itself. The private key is known only to Canon. The private key absolutely must exist on the camera in order for it to generate a signature of the photo (generated from hash + public key).
For verification all the Canon software needs to do is perform the same operation the camera would have: combine a hash of the photo with the private key and generate a signature. If the two signatures match, the photo is verified.
You're rambling, and it's a bit obvious you don't understand how PKI works. Verification does NOT require the private key. You need the public key, and the public key of any root or intermediate certs used to create the certificate in the camera.
you can't give someone else the key and not give them the key at the same time.
You obviously don't know how one-way hashes work (encryption is a two-way or reversible hash, and what you said is true for encryption).
I think you misunderstand me. My point is that for the camera to be able to perform said signing, the camera itself must contain the private key.
Any method of attempting to conceal that key is flawed once someone else (i.e. someone who purchased the camera) is in possession of it. It may be difficult to do, but it is by no means impossible.
I dream of a nation where a man is not judged by his skin color but by an number assigned by a credit rating agency.
With TPM chips being cracked previously, after apparently being tamper-proof
TPM chips were never claimed to be tamper-proof. One of the fundamental design assumptions was that they would not be secure against someone with access to the hardware. It's right in the documentation. This isn't because it's not possible to make it very hard to tamper with a chip, it's because it's expensive to make a strongly tamper-resistant device.
Of course, it probably is impossible to make a completely tamper-proof device, no matter how much money you put into it, but you can make it hard enough that it's extremely difficult/expensive to successfully tamper. If in addition to that you make the key inside each device unique, so that spending the money to successfully compromise one device ONLY compromises that device, you can achieve a very high level of security. But that's expensive and difficult, which is why the Trusted Computing specifications never even attempted to go there.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
You seem to believe that you disagree with me though your post makes it clear that you don't. It's a little strange.
Timing. That's why it has to be immediate. Photoshopping takes time - if the photo hash arrives minutes after the events it's supposed to be recording, then it may be tampered with.
And how do they know when the picture was taken? Think detectives are finished going over a crime scene a few minutes after getting there? Of course not. Even if they're done on-scene relatively quickly (large crimes can take days or longer), they'll box all the evidence up and take it back to the lab. Maybe they'll get to it by the end of the week. Maybe not.
Basically, courtworthy photos are being produced long after there's been time to do some photoshopping.
Also, there's always the old classic trick: Print out, place in front of camera, illuminate evenly. Would have to do some optical trickery to alter the focal distance, or just use a really big card.
Image and video are a bit more difficult to modify than written text, but especially now in digital times they can be forged and changed almost as easily. People really should give up the idea that they reflect reality anymore than some text that some guy wrote.
Whether you trust something to be authentic representation of certain situation should rely on other things than digital signatures. These problems are messy and we have been battling them with written text for ages. It's a question of trust and there are no easy solutions.
To forge the photo and have it appear to come from a particuler camera still may not be that difficult, but a single compromise doesn't compromise the integrity of the entire system.
I don't think so. Having a per-camera private key doesn't make this setup more secure, because if a key can be extracted from one camera, it can also be extracted from another camera of the same model by the same procedure. So a compromise should be viewed as a per-model one, not per-device, and thus a per-model private key is as good for the purposes of proving the authencity of the photo as a per-device key.
The resolution of chemical film is high, but far from infinite and it's still just a 2D plane ... with a printed 2D image of sufficient resolution, a good lighting setup and a good lens you can get anything you want on film ... modelling the original camera and the development process is just that, a modelling problem. A solvable problem.
That would be the idea. The smartcard would be directly connected to the camera, and a required part of the image-saving processs(if crypto were desired, if you just wanted to happy snap, it would be irrelevant); but would be removable, and would be where all the cryptographic secrets live, and so could be easily subjected to whatever physical security measures suit the organization using it(unlike a mass-market camera, which is going to be physically avaiable to anybody with a few hundred or few thousand dollars and/or fast fingers...)
The camera would take the image, do a SHA1 or MD5(since, having the image in RAM would make it fast for the camera, even with a largish image) and then, if a smartcard is present, pass the image hash to the smartcard to be signed and returned and written to flash along with the image. The private key is never exposed to the camera, and the only "secret" you could learn from buying a camera of the same model is what ASIC they are using to do an off-the-shelf hashing algorithm on a low power budget. And, the moment Agent Smith removes his smartcard from the camera, there is absolutely nothing sensitive remaining in that camera body.
They should throw him in jail the next time he comes to America.
(A secret jail would be better)
That would only work with time-sensitive data. Pictures taken of a crime scene? Photochop them, do the hash-and-send, then claim that you took the picture at the time when you actually just sent it.
Is it that all he did was extract the signing key from the camera itself and insert it into exif data? If so, all you would need is any valid key and you could replace any metadata you wanted for anything you wanted with any number of utilities.
Take a photo with normal camera. Photoshop it. Get it printed professionally. Point security enabled camera at photo and shoot a "secure" copy.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC