Is there a feature that can be implemented that would watermark the capture frames to prevent tampering of the frames? In the US, before we could use any video in a court proceeding, we would need to be able to prove the images captured haven't been tampered with. The only systems that alow this in the digital format (as opposed to time lapse vcrs) are propritary software application usually on windoze.
I have a couple of business owners that would need this beofre implementing zoneminder as their solution.
Scott
Watermarking
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
As I understand it watermarking adds a sort of checksum to to the digital file. This checksum would not match if someone were to manually edit the file.
In the case of a the jpegs created for the frame captures, I would suspect that a key that is specific for the server, combined with another key that is not repeatable would be used to create a checksum that would be embedded intot the frame captures. If an image were to be edited, the new values of the image's content wouldn't math up to the checksum.
Here in the states, the video security software sellers tout that since their encryption scheme is propritary, no one can alter the files content without specific knowledge of how the file was watermarked, hence the inabilty for a defense lawyer to discredit the image.
I would assume to create such a watermark in the open source world, there would have to be some sort of independent key that would not be alterable on the image.
I don't know if this helps explain it or not. I just know that I have been told by some businesses tha they have been discouraged to use an open source solution without this feature due to this problem.
The police here may use the video as a source to identify a perpetrator, but if there is no other evidence, they will not prosecute.
Here is a link to an article that explains the problem in a bit more detail:
http://www.afrlhorizons.com/Briefs/0001/IF9905.html
Regards
Scott
In the case of a the jpegs created for the frame captures, I would suspect that a key that is specific for the server, combined with another key that is not repeatable would be used to create a checksum that would be embedded intot the frame captures. If an image were to be edited, the new values of the image's content wouldn't math up to the checksum.
Here in the states, the video security software sellers tout that since their encryption scheme is propritary, no one can alter the files content without specific knowledge of how the file was watermarked, hence the inabilty for a defense lawyer to discredit the image.
I would assume to create such a watermark in the open source world, there would have to be some sort of independent key that would not be alterable on the image.
I don't know if this helps explain it or not. I just know that I have been told by some businesses tha they have been discouraged to use an open source solution without this feature due to this problem.
The police here may use the video as a source to identify a perpetrator, but if there is no other evidence, they will not prosecute.
Here is a link to an article that explains the problem in a bit more detail:
http://www.afrlhorizons.com/Briefs/0001/IF9905.html
Regards
Scott
MD5
I guess a MD5 checksum could resolve this question. The checksum could be stored either on database or in the picture file properties. I also guess that this kind of checksum in each file could lead to a huge load... Anyway this could be optional..
Watermarking...
Hi,
Actually the checksum isn't enough due to the fact that it is required by the courts and law in most countries it seems, that the images rcorded need to have a embedded watermark and a special viewer (mod) that would show if and where a image has been touched up or altered since the recording phase.
Having a checksum for the recorded image is not accepted as a watermark.
What is done for proper watermarking is where a checksum is written on the fly into the LSB (least Significant Bit) of the image as it is processed and recorded. This has next to no effect on the image itself but now a viewer written to check the correct values are encoded in the LSB of each BYTE of the image file can pick out if there has been any alterations.
There is a paper on the net at the following link that describes the application and possible algorythms etc...
http://www.afrlhorizons.com/Briefs/0001/IF9905.html
To be able to submit images recorded by the system into court correct watermarking has to be done. This I can confirm for Australia, USA and most of Asia even. I would also say this is the case for europe.
Regards,
Deano
Regards,
Actually the checksum isn't enough due to the fact that it is required by the courts and law in most countries it seems, that the images rcorded need to have a embedded watermark and a special viewer (mod) that would show if and where a image has been touched up or altered since the recording phase.
Having a checksum for the recorded image is not accepted as a watermark.
What is done for proper watermarking is where a checksum is written on the fly into the LSB (least Significant Bit) of the image as it is processed and recorded. This has next to no effect on the image itself but now a viewer written to check the correct values are encoded in the LSB of each BYTE of the image file can pick out if there has been any alterations.
There is a paper on the net at the following link that describes the application and possible algorythms etc...
http://www.afrlhorizons.com/Briefs/0001/IF9905.html
To be able to submit images recorded by the system into court correct watermarking has to be done. This I can confirm for Australia, USA and most of Asia even. I would also say this is the case for europe.
Regards,
Deano
Regards,
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
-
1,3,7-Trimethylxanthin
- Posts: 2
- Joined: Tue Apr 26, 2005 4:34 pm
I fail to see how this could work - if somebody modifies the recording, he can then simply regenerate the watermark, unless the watermarking algorithm is kept secret, which is impossible since ZoneMinder is open source. A site-specific secret (i.e. a variable parameter to the algorithm) will afford protection against tampering by third parties, but not against the owner/operator of a ZM setup, which is probably the main concern.
Proprietary software might seem more secure, but actually isn't: the developers might be involved directly in some cases or they could be bribed, it shouldn't be too hard to reverse engineer the algorithm, or you might be able to simply transplant the code into an application of your own (it might already be in a DLL or a similar kind of reusable library).
Failing all that, you could just feed manipulated footage to the system, set the clock to the desired time, and get perfectly watermarked image data.
So either there is a clever, hard to overcome way to link a water mark to its creation time (it would be very interesting to see how this is done, if it can be done), or watermarking just doesn't work (vendor claims that their crypto is safe because it's proprietary are usually a sure snake oil indicator), and hence it is stupid and actually dangerous to rely on it.
On the other hand, if you have direct footage of a criminal activity (e.g. a burglar forcing open a door), then you'll likely have tens or hundreds of frames, and manipulating such a number of frames in a consistent, convincing manner is at least very difficult, and the time of the event is probably not that important. I suppose the interesting cases are those where the video provides only circumstantial evidence (e.g. something is reported as stolen and surveillance footage shows a stranger walking on the premises at around the same time), but as I said I can't think of any trustworthy way of doing watermarking.
Proprietary software might seem more secure, but actually isn't: the developers might be involved directly in some cases or they could be bribed, it shouldn't be too hard to reverse engineer the algorithm, or you might be able to simply transplant the code into an application of your own (it might already be in a DLL or a similar kind of reusable library).
Failing all that, you could just feed manipulated footage to the system, set the clock to the desired time, and get perfectly watermarked image data.
So either there is a clever, hard to overcome way to link a water mark to its creation time (it would be very interesting to see how this is done, if it can be done), or watermarking just doesn't work (vendor claims that their crypto is safe because it's proprietary are usually a sure snake oil indicator), and hence it is stupid and actually dangerous to rely on it.
On the other hand, if you have direct footage of a criminal activity (e.g. a burglar forcing open a door), then you'll likely have tens or hundreds of frames, and manipulating such a number of frames in a consistent, convincing manner is at least very difficult, and the time of the event is probably not that important. I suppose the interesting cases are those where the video provides only circumstantial evidence (e.g. something is reported as stolen and surveillance footage shows a stranger walking on the premises at around the same time), but as I said I can't think of any trustworthy way of doing watermarking.
-
lazyleopard
- Posts: 403
- Joined: Tue Mar 02, 2004 6:12 pm
- Location: Gloucestershire, UK
Sometimes legal requirements do end up being determined by folk who havn't got a full grasp of the technicalities. I wouldn't mind betting this is one of them. The challenge is to find some scheme that'll satisfy the legal requirements. Presumably the main aims of watermarking would be:
- To confirm that an image has not been tampered with since it was recorded
- To confirm that an image was recorded on the particular system
- To confirm that an image was recorded at the time it claims to have been recorded
Rick Hewett
-
jameswilson
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
I know nothing about the legal issues relating to watermarking. However I have a thought on a method of determining if an image has been editted.
I have played a little with a tool called outguess. From the outguess manpage:
Editing the jpeg will destroy the embedded information, so it can be used to demonstrate that the image hasn,t been tampered with.
http://www.outguess.org/
It's also kind of fun to play with.
Ross
I have played a little with a tool called outguess. From the outguess manpage:
So outguess can in effect "sign" a jpeg in a way that cannot be detected by any method that I am aware of. A password is required to extract the hidden "information" "signature" "message" or whatever.Outguess is a universal steganographic tool that allows the insertion
of hidden information into the redundant bits of data sources.
Editing the jpeg will destroy the embedded information, so it can be used to demonstrate that the image hasn,t been tampered with.
http://www.outguess.org/
It's also kind of fun to play with.
Ross
-
1,3,7-Trimethylxanthin
- Posts: 2
- Joined: Tue Apr 26, 2005 4:34 pm
-
jameswilson
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
I would assume nothing but if you tried to put an image back into zm wouldnt the event number be out of sequence. All digital systems are affected by this, as previously posted you could reset the time record what you need then put the time back. Unfortunatly old analogue video is even easier to edit, so a simple 'watermarking' would suffice. If someone spends enough time on anything it could be circumvented. From my point of view i just want the images to be watermarked, checksummed whatever. I have yet to have any evidence from our machines (non zm) questioned for editing. What i have had issues with is clients not logging when the export video, not logging changing tapes etc. We have more of a problem with the DPA than with people editting videos.
1,3,7-Trimethylxanthin wrote:
But the solution is far simpler. You filter events of interest and ftp them off site to a system where you have no admin access. Then if you edit an image locally you change its md5sum, if you then upload it you change the mtime of the file. As long as the checksums match and the mtimes account for the filtering and transfer delay, the file is unaltered.
OK I see your point. Nothing prevents you if you have the image in your possesion and know the key the "signature" was encrypted with.Please read my posting above - what prevents you from simply recreating the embedded information after editing the jpeg?
But the solution is far simpler. You filter events of interest and ftp them off site to a system where you have no admin access. Then if you edit an image locally you change its md5sum, if you then upload it you change the mtime of the file. As long as the checksums match and the mtimes account for the filtering and transfer delay, the file is unaltered.
Hi,
Typically the watermarking is done when the image is being created (ie. the Jpeg is created). To do this you would have to edit or rewrite the JPEG creation function / library to perform the watermarking function.
This would impose an additional load on the CPU and the application which is not a good thing.
Another way to do it is with a hardware based solution and have the capture card do the watermarking - very expensive and could be more complex.
I have seen details on such cards but not really looked at them hard or with much interest in the past.
The Checksum is easy to do but doesn't meet the requirement as stated for watermarking. But at least it is a start.
If someone has information on how the JPEG's are created I can probably get one of our developers to work on this issue, but he would need some information and help understanding what is happening in the code so he doesn't waste time.
We would then post it back for testing. Anyone understand how the JPEGs are created?
I am not a Software guy - I just develop and design products.
Regards,
Deano
Typically the watermarking is done when the image is being created (ie. the Jpeg is created). To do this you would have to edit or rewrite the JPEG creation function / library to perform the watermarking function.
This would impose an additional load on the CPU and the application which is not a good thing.
Another way to do it is with a hardware based solution and have the capture card do the watermarking - very expensive and could be more complex.
I have seen details on such cards but not really looked at them hard or with much interest in the past.
The Checksum is easy to do but doesn't meet the requirement as stated for watermarking. But at least it is a start.
If someone has information on how the JPEG's are created I can probably get one of our developers to work on this issue, but he would need some information and help understanding what is happening in the code so he doesn't waste time.
We would then post it back for testing. Anyone understand how the JPEGs are created?
I am not a Software guy - I just develop and design products.
Regards,
Deano