Speed Cameras and Other Items

Thanks to Bruce Schneier for pointing me toward a story on weaknesses in MD5 killing a case involving speed cameras. Excerpts from this story provide some details:

"Sydney [Australia] magistrate Lawrence Lawson threw out a speeding case after the RTA [Roads and Traffic Authority] said it had no evidence that an image from a camera had not been doctored.

Mr Lawson had adjourned the case in June, giving the RTA eight weeks to produce an expert to prove pictures from a speed camera on Carlingford Rd, Epping, had not been altered after they were taken.

But RTA lawyers yesterday told Hornsby Local Court they could not find an expert and the case was thrown out...

The case revolved around the integrity of a mathematical MD5 algorithm published on each picture and used as a security measure to prove pictures have not been doctored after they have been taken.

Mr Miralis argued that the RTA had to prove the algorithm it used was accurate and could not be tampered with."

Good grief. The prosecution in the case appears to have lost because they framed the issues incorrectly. If the battleground was the lack of collisions in MD5, of course the RTA would lose. Determining what is required to tamper with speeding camera images is a completely different subject.

This case exemplifies the difference between capturing packets and performing network foreniscs. Most people do the former, which opens their methodology and network-based "evidence" for questioning should it be scrutinized by a clueful defense attorney. One of the reasons I have introduced new material on network forensics in my latest book and training is to elevate the network forensics practice to the point where we have a chance of surviving a clueful defense attorney.

Speaking of forensics, those of you who like your forensics of the Windows host-based variety should check out a new post by Harlan Carvey on his Forensic Server Project.

Those of you who argue with me on the meanings of security terms will enjoy this post at Gunnar Peterson's blog. His Sherlock Holmes post was intriguing as well.

Update: A forensics expert who wishes to remain anonymous sent me a link to the following:

Computer Records and the Federal Rules of Evidence

"Computer records can be altered easily, and opposing parties often allege that computer records lack authenticity because they have been tampered with or changed after they were created...

The courts have responded with considerable skepticism to such unsupported claims that computer records have been altered. Absent specific evidence that tampering occurred, the mere possibility of tampering does not affect the authenticity of a computer record."

Comments

Anonymous said…
Hi

IIRC (read it somewhere) the issue was not that the MD5 had colissions and stuff...the issue was that it was possible to modify the image AND the MD5 hash and there was no way to technically prove that the image AND the hash that was originally appended to it were not modified after the image being taken...

or is it the same that you were saying? ;)

By the way, your blog is great!
Anonymous said…
I would heavily doubt that. Without having thought things through thoroughly I'd suggest that the secondary documents/images/... would have a lot of superfluous and redundant information to get both MD5 hashes to match up. While the output (the visible image and/or the printed document) would show no sign of this tampering and redundant information it should be possible to analyze it.
Just remember that the two meaningful documents with the same MD5 hash were PostScript documents. It's possible to hide *a lot* in PostScript.
Anonymous said…
Richard,

Thanks for the mention!

H. Carvey
"Windows Forensics and Incident Recovery"
http://www.windows-ir.com
http://windowsir.blogspot.com

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics