Subscriber Discussion

Is SHA-1 Collision Vulnerability Relevant To Video?

U
Undisclosed
•Feb 27, 2017

SHA-1 (the crypto hash algorithm) has been found to be easily vulnerable to collisions.  Two "messages" can have the same hash.  Not a good thing if the "message" were, oh, say, a video clip from a VMS that you turned over to your local cops to prosecute that punk who bashed in someone's car window in your parking not.  Also not good if your infrastructure relies on SHA-1 hashes being unique.  Google "Apache Subversion Webkit SHA-1" if you want to see how that train wreck looks.

Are people using SHA-1 hashes to assert video clips, images, etc. are authentic?  Or, worse yet, are VMS' using SHA-1 hashing to identify unique video fragments?  I can't think of a direct example but this could be an issue.  Anyone seen any updates from vendors on this?

(1)
Avatar
Brian Karas
•Feb 27, 2017
IPVM

I was reading about this over the weekend.  From what I read the example showed a PDF with a given hash, and then a PDF that was different, but able to be modified in a way that gave it the same has as the legit PDF.

I did not see anything that showed this being the kind of things that could be exploited to be able to cause a hash for any given file type (I believe you have to be able to edit data into the file that would not be visible/shown to the end user, this is easier to do in a PDF than a video file).

It seems worth being aware of, but unclear if there is any practical risk in video. 

(1)
U
Undisclosed #1
•Mar 01, 2017
IPVMU Certified

Also not good if your infrastructure relies on SHA-1 hashes being unique.

To be sure, any hash algorithm, (assuming the messages are longer than the hashes), will generate some duplicates and therefore can't be "relied upon" for uniqueness.

Of course, SHA-1 is one of the easiest to find collisions with.

I think the biggest danger to cctv with SHA-1 is the not with video streams but rather with the common use of Digest Authentication, which could theorectically allow a MITM exploit if an attack had LAN access.

Though I wouldn't consider even that much of a practical threat.

(2)
(1)
U
Undisclosed
•Mar 01, 2017

not correct.  cryptographic hash algorithms are built to generate a unique value.

digest auth for web server access is an attackable scenario so yeah, that's likely.  In modern times it's not practical to assume the camera lan is genuinely isolated.  (And the physical security director who tells you it is probably runs iTunes and DropBox on their laptop and mobile phone, participating in the infection vector population.)

(1)
U
Undisclosed #1
•Mar 02, 2017
IPVMU Certified
In reply to Undisclosed

not correct. cryptographic hash algorithms are built to generate a unique value.

Hash algorithms take a variable length 'message' and create a fixed length hash from it.  Assuming that the messages can be longer than the hash, there will be duplicates somewhere.

Using an intentionally pathological example, let's say I create an algorithm that will create a one character hash from a two character message using the domain of majuscule alphas. 

Such that message "AA" maps to hash "Z" and "BA" maps to "Y" and "CA" to "X" and so on until getting "ZA" maps to "A".

You will not be able to avoid a duplicate when generating the hash for "AB".

Cryptographic hash function

The ideal cryptographic hash function has five main properties:

...it is infeasible to find two different messages with the same hash value

infeasible != impossible, therefore there are always potential dupes.

(2)
Avatar
Ricardo Souza
•Mar 02, 2017
Motorola Solutions • IPVMU Certified

"easily vulnerable"? =p

It took a lot of resources (6500 cpu years and 110 gpu years), courtesy of Google of course, to come up with 2 pdf docs with the exact same hash and just changing the color of a square.

Using nothing new, just plain old brute force.

For a 1 second of encrypted or watermarked video, this time would increase a lot.

 

SHA-1 collision were already detected in 2004 and it seems people had forgotten about the SHA-1 deprecation timeline by Dec2016 so Google had to act =)

 

It's not like someone faked a CA root hash though....but it's a matter of time until it gets broken...

by that time everyone will already have stopped using sha-1 to encrypt vms passwords and watermarked video....i hope...

 

(1)
AT
Andrew Tierney
•Mar 02, 2017
In reply to Ricardo Souza

It's not fair to frame this as plain old brute force.

Plain old brute force would mean 2^80 attempts before finding a collision. This is not feasible currently.

The best theoretical attack against SHA1 - by weaknesses in it - takes this down to 2^61. But theoretical attakcs often can't be exploited.

The recent attack managed to get it down to 2^63.5. This is feasible. That's what makes it interesting.

Avatar
Carter Maslan
•Jan 03, 2018
Camio

Camio authenticates all recordings at the time of recording with the combo of a) SHA checksums (either SHA-1 or SHA-256) of the video itself and b) server-controlled metadata (timestamps, duration, motion regions, colors, etc...).

We haven't yet had a court challenge validity of a SHA-1 hash, but the addition of even a couple of these other metadata authentication factors (in addition to retaining playable H.264 encoding) seems sufficient to retain SHA-1 as a conveniently shorter hash alternative. That said, perhaps we'll just switch to SHA-256 as the default to avoid any debate.

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions