[Cryptography] Photojournalists & filmmakers want cameras to be encrypted

[Jan Dušátko]

Dne 17.12.2016 v 1:16 Ray Dillinger napsal(a):
>
> On 12/16/2016 03:15 PM, Tom Mitchell wrote:
>> On Thu, Dec 15, 2016 at 6:43 PM, Ray Dillinger <bear at sonic.net> wrote:
>>> Whether contents are encrypted or not, crypto hardware is very
>>> much worthwhile to build into cameras, because such hardware
>>> could also do crypto authentication for evidentiary purposes.
>
>> Evidentiary is not a consumer camera. My SWAG is evidentiary is
>> less than 1% of high quality cameras and perhaps 100% of cell phones.
> It's journos who are asking for this, and their cameras are definitely
> part of that 1%.  A reporter who can show that her footage isn't
> tampered can limit the degree to which people are able to credibly deny
> or discredit her story.
>
> Now think evidence again.  Outside of journalism and investigation
> contexts, you don't know in advance which cameras are going to be used
> to record something that becomes evidence. A random college student at a
> demonstration takes footage of an incident of police brutality using
> whatever camera they happen to be carrying, and either is, or isn't,
> able to convince reporters/school officials that the incident wasn't
> faked, or convince police higher-ups that it can't be credibly denied.
>
> 				Bear

Everything is about risks and mitigation, but there are lack of useable
equipment. May I'm wrong about, but there are my view on the security,
privacy, unforgivable and provable (of choice) authorship, easy to
detect/defeat any altering. Using "swarm of cameras" or "online
connected cameras" are solution for special cases (hard to defeat in
method that thousands of people agreed of something fake), but general
purpose devices (any recorders for audio/video) missing.

1) provable authenticity of media
- when, where and which items used
2) provable author (better provable on demand)
- who, when, where and which items used
3) security of data
- there are FAT, not the ruberhoose filesystem
- files are readable by anyone with appropriate technology
4) security of media
- SD/SDHC/SDXC (secure digital, can someone use it)
- tamperproof encryption chip with some private values (almost
tamperproof, it is hard to design and expensive)

Risks for each case:
1) Data can be easily modified or defeated...
2) Authorship can be easily forget ...
3) Stole data/pictures/videos, can be easily checked and captured by
anyone, anyone can see the data ...
4) Stole the media/modify data and cryptography signatures ...

I not sure if there are something more than notes only:
- Plaintext data in EXIF are useless, because can be easily modified.
Also, doesn't avoid the tampering/modification.
- hash/hmac or chain of hashes/hmacs cannot avoid modification, because
can be computed again (in case that you have appropriate key, also the
chained HMAC). This mean, hash function are good against random
modification, but for proper procedure digital signature required. And
digital signatures require another mechanisms ...
- best to use some challenge-response mechanism or tamperproof hardware
(what is 100% tamperproof?)
- challenge-response mechanism can help, but better to use 3rd party,
for example certificate authority (X.509 or distributed by blockchain)

Do someone know the solution about?

Jan

-- 
Jan Dušátko

Phone:		+420 602 427 840
e-mail:		jan at dusatko.org
SkypeID:	darmodej
GPG:		http://www.dusatko.org/downloads/jdusatko.asc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161217/6ec645e2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jan.vcf
Type: text/x-vcard
Size: 242 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161217/6ec645e2/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161217/6ec645e2/attachment.sig>