Said person would either have internet access or suitable storage and decent odds of getting away without interference if police decided to confiscate or destroy cameras.
It's not hard to get some extra protection if you have the funds. A bigger issue is probably that a lot of the time even people operating in warzones often operate on shoestring budgets with little certainty as to whether or not they'll manage to sell their stories. Adding extra tech or a second person hiding in the distance isn't necessarily economically viable for a lot of people.
Aka "the overwhelming majority of the world". Dude, you struggle to get decent 4G in the UK outside big cities...
I do agree that the "immediate background upload" model is superior to encryption; it's also definitely harder from a logistic perspective. One feature does not exclude the other though -- in fact, uploading an already encrypted stream would be highly preferable in order to thwart interception (which is a massive problem everywhere, including patriot-act US and snoopers-charter UK).
For example: after attempting to delete an image the next image is stored unencrypted. That way you can take pictures of non sensitive targets and build a false trail alongside the shadow encrypted images. When a camera is inspected scrolling through the image viewer will look normal.
So what you'd want to add, for safety's sake, is to make the camera save this RAW in a custom format (and folder and naming structure) that is inconspicuous, but can be read by your custom RAW software. E.g. save the RAWs in some scientific data format and say you're a student and those files are from some old class assignment you had to transfer.
I estimate it would take a dedicated hacker less than a month to put together on their spare time.
Without transmission capability, you can never guard against deletion (they could just confiscate or destroy the SD).
Concealing ALL photos will still need to be an option for some, though: plausible deniability of "did you take pictures of X" when questioned :)
There may be a more elegant solution I haven't thought of, however.
Anyway - yes on the face of it this seems possible - but most pros I know will shoot a large chunk of images and review afterwards in a batch - they typically don't review often enough for this to really work, otherwise they'd risk missing shots while reviewing, which is why I thought that in practice it might be hard to implement this well enough without compromising security.
Well, photographers in the film era managed to get by.
Also, they could hold you captive and demand that you have someone at home send the key in exchange for your freedom.
On http://security.stackexchange.com/a/83059/6870 you can find a basic idea how you can create keys that you cannot have access to. There is of course some work to be done to fit it to the "camera scenario".
Aside from that it seems better to allow the authorities immediate access to all photos without encryption. You might lose the pictures but I think you'll have a better chance at avoiding personal harm.
I don't really see how you can technologically avoid personal harm if you're in a war zone [or similar] taking imagery that some people don't want publishing and you're captured in that process. Harming you is the standard way of stopping you continuing to defy such people.
Not being able to destroy the images taken is good, but it's not going to save cameras and people from being smashed up IMO.
This would allow the photographer to review photos on the camera until satisfied, then simply plug the SD card into the portable hard drive. All files would be automatically encrypted and saved to the hard drive, and the SD card would be wiped. The files on the hard drive can't be decrypted without the private key, stored at home.
You may have trouble convincing the local authorities of this. In some circumstances, it may be better to be able to provide a decryption key so they can review your photos and leave your kneecaps alone.
That ensures that sources are more protected than an unencrypted storage. See cases presented in the article. Better to have the footage destroyed than releasing the identity of your sources. But nice non sequitur.
Usually its not even that. "Authorities" almost always simply destroy everything if there's even a hint of suspicion that something they didn't want filmed was. Having the camera be encrypted would simply guarantee that everything was trashed no matter the contents.
As mentioned, a "satellite camera" that transmitted all pictures somewhere else and stored nothing is a much more worthwhile goal.
encrypted camera -> authorities cant get in -> they just smash it instead
is a beneficial outcome.
I think a bluetooth pairing with your phone that automatically synced shots, though a massive battery suck, would be a better option than satellite (and easier to package in the camera body; bluetooth units are tiny), and certainly more helpful than encryption.
To be clear, I'm not saying encryption wouldn't be useful; I absolutely thing it would (and it's the business I'm in anyways, but for IoT and not cameras). But I think auto-sync has a much, much larger addressable market, and I think it also would have a larger immediate impact. You could also set it up such that the data is only stored on the camera until it is uploaded, and then immediately deleted, making it significantly more difficult for authorities to recover (if you zero the bits out properly, etc etc).
you can do this right now with inmarsat BGAN streaming, but are you prepared to pay between $5 to $20 per megabyte? that can add up quick.
In addition, pushing over WiFi requires power to broadcast a radio signal. That power comes at the price of less shooting time. It also broadcasts the photographer's location and is susceptible to jamming.
Even without jamming the images are vulnerable to manipulation via Man in the Middle attacks. Of course the solution is to encrypt the image transmission...and that necessary step is what people close to the problem are asking for.
1) The images can quite easily be uploaded in the background. Wartime journalists typically don't need huge images at highest quality settings - you can make your files pretty small (few MB or less), so they are quick to upload.
2) The power requirements for wifi aren't THAT high, but none the less, there's a simple and elegant solution - the user can take additional batteries in their pocket.
3) Jamming every wifi channel on both frequencies over an entire city is a crazy idea. No-one does this.
4) MiTM attacks... uh, what? You envisage a scenario where in the back of that toyota hilux filled with heavily armed young men there's going to be someone on their laptop, sniffing for wifi signals, trying to find out if they might belong to a journalist, somehow intercepting and modifying the images then uploading them to the original destination....? Even if that IS what you mean, there's again a trivial solution - the uploads can take place over TLS.
I'm trying hard to view your post in a positive light, but I'm finding it difficult - can you perhaps expand on your points?
It also seems that we conceptualize war zones in diverse ways. For me, when there are combatants in technicals [1] it's perhaps better not to assume good manners and wifi etiquette are prevalent social behaviors.
TLS or Transport Layer Security [2] is a protocol to secure network communications using encryption. Building encryption into the cameras is what the concerned journalists are asking for.
As an aside, calling someone else's reasoning "silly" can easily be interpreted as uncivil and not in keeping with Hacker News guidelines. I've found Paul Graham's essay How to Disagree provides a useful perspective. [3]
[1]: https://en.wikipedia.org/wiki/Technical_(vehicle)
You misunderstand - it's nothing to do with etiquette, it's simple practicality. "Jamming" wifi over a city or town sized area simply isn't a technically feasible thing to do, which is why it doesn't ever happen. To be effective you'd need a device on every other block, more or less (urban environments need very high jamming density, mfr range claims tend to assume no obstructions). The level of organization this would require is simply astronomical, and it's nonsensical to think that somehow a government in the grip of a civil war is going to do this.
> TLS or Transport Layer Security [2] is a protocol to secure network communications using encryption. Building encryption into the cameras is what the concerned journalists are asking for.
Please try to avoid being overly patronizing - I'm perfectly well aware of what TLS is. There is a huge difference, however, between implementing a TLS-encrypted TCP request (e.g. simple file upload over HTTPS), and encrypting files locally. There's more levels of difference than I can reasonably cover in a HN post, however to pick one from the giant list: Locally encrypting files would require the user to enter a password every time they switched the camera on. Which is a usability nightmare. And they can't leave it on the whole time, as they may not get the chance to turn it off when the camera is demanded at gunpoint. I don't think I can stress enough how much professional journalists would not accept constantly having to enter and reenter a password to use their camera.
> As an aside, calling someone else's reasoning "silly" can easily be interpreted as uncivil and not in keeping with Hacker News guidelines. I've found Paul Graham's essay How to Disagree provides a useful perspective. [3]
Interpretations can vary. I apologize if I offended you, however at least by my reading of the essay, it's not covered in the guidelines. Calling an argument silly is not a personal attack, it's an observation that none of the arguments presented made any real sense.
This isn't true: you could use asymmetric crypto and encrypt the photos/video with the journalist's public key, leaving the private key at home. Encrypting to a private key does not required a shared secret. This prevents the journalist from decrypting the photos even if pressed to by authorities, assuming that "home" doesn't include the authorities' jurisdiction.
If you have access to a slow connection once per day or every few days, or a fast connection to return to you have to carry material with you for at least some time, in which you'd want it to be encrypted, and could easily use a secondary device to actually transmit it (phone, laptop). And material that is to large probably still needs walking out. If you are in a "going to visit Snowden" (or staying with any other target in hiding) scenario, you are probably travelling without a connection for their safety, otherwise you are not going to get access.
In remote locations you are limited to sat phones which are expensive, slow and probably monitored, if you even are allowed to possess one. And their security is debatable for all I know.
What I dislike about the suggestion for standard encryption features is that it becomes sort of obvious that there might be encrypted data and how to destroy it. Ways of hiding it are even more important, and obviously can't be "standard". Tricky to solve.
//EDIT: removed uncivil language
That's pretty demeaning. Wartime photographers need quality as much as others.
> Jamming every wifi channel on both frequencies over an entire city is a crazy idea
They do blanket-block the internet though (recently Turkey, again), without which wifi loses a lot of functionality.
> You envisage a scenario where in the back of that toyota hilux
No, no. The scenario is of local state actors sitting in their aircon office, monitoring network traffic in a certain hotspot; if they identify a stream of compromising media, they censor it by corrupting the stream. Yes, TLS fixes that; but if you have that sort of crypto features, you can make sure the images are encrypted on storage media in the first place.
I'm not sure why you find this to be demeaning. The cameras used by journalists (canon 1dx ii/nikon d5) have dramatically lower resolution than cameras used by, for example, landscape photographers. This is for a number of very good reasons, but one of these is because there's no demand for anything else. 20Mp is more than enough - indeed many don't even shoot at this, but opt for smaller images for faster processing and upload.
You don't need huge images for news (print or online) - in both cases the final image is small, and the DPI/resolution is low. The idea that huge image sizes somehow equate to image quality is much of the time a marketing idea - all you need is enough resolution for your output format. If that's a newspaper (online or offline), small JPEGs are fine. If your output format is a gallery image, or a building-sized advert, then yes, you want 50MP+ RAW images - but guess what? They aren't shooting for that.
Yes, maybe heavily compressed 720p would be acceptable for some war journalism, but that's still going to be impossible to live stream reliably from almost anywhere in the world. And unless you're getting something spectacular, no mainstream TV station will want to use your crappy footage.
Also remember that what you're replacing here is the transfer of pre-edited footage, of which there is likely to be a huge amount. You refer to files of "a few MB or less" elsewhere, which suggests you haven't really thought about what's required here.
Edit: I don't mean to suggest this could never work, I mean satellite have been a thing for years. But at this point local storage is still vastly more practical for almost everybody.
Edit2: Also I agree with brudgers that you came across as gratuitously uncivil.
News networks often run cell phone videos sent in by eye witnesses/viewers/etc (or even video via sat phone), so the bar for quality probably isn't that high.
If you get a good angle of the Trump assassination you can record it on whatever device you want and people will want it. If you're recording interviews with civilians while nobody's being bombed or shot at, they'll want reasonably professional looking footage.
On the other hand if the footage is coming from an actual war zone such as Aleppo or the future smoking ruins of Atlanta then news organizations will take whatever they can get. Absent a perfect reliable solution for moving such data around in dreadful conditions everyone is just gonna have to compromise - half a loaf is better than no bread.
The vast, vast, VAST majority of war photo journalism is stills. This may change in the future, but in general video journalism in war is handled very differently, has different operating parameters (for example tends to be conducted further back from the front lines, involves way more people, etc), and doesn't typically use SLRs at all.
> Also remember that what you're replacing here is the transfer of pre-edited footage, of which there is likely to be a huge amount. You refer to files of "a few MB or less" elsewhere, which suggests you haven't really thought about what's required here.
For some reason you appear to be shifting from photo journalism in warzones and other hostile and hazardous situations to videos taken in London... I'm not sure how this is related to the previous posts in the thread, and trying to completely shift the discussion then claiming that I haven't thought about what's required seems somewhat disingenuous at best.
> For some reason you appear to be shifting from photo journalism in warzones and other hostile and hazardous situations to videos taken in London
My point was that the measures you suggest for worst case scenarios do not even make sense in best case scenarios (London being a highly developed first world capital city).
The article is not "about video". The article mentions both, and if you read the original letter[0], you'll find it does too.
> My point was that the measures you suggest for worst case scenarios do not even make sense in best case scenarios (London being a highly developed first world capital city).
Making sense for London is irrelevant. Read the actual letter[0] - it talks about, and only about "...the most dangerous parts of the world", and protecting against "authoritarian governments or criminals". Obviously, if that's not what you're doing, then different solutions might be better.
0: https://freedom.press/news/over-150-filmmakers-and-photojour...
My point about was that video journalism is likely to generate huge quantities of data, which is inconvenient to transfer even in relatively favourable circumstances, let alone adverse ones. Perhaps we can agree that comms infrastructure is going to be no better in most war zones than in London.
150 documentary filmmakers are requesting it, so I tend to believe they've thought through the alternatives and settled on this request as the most feasible, flexible, and worthwhile.
You're basically dismissing the usefulness of encryption as a whole (on phones and anywhere else).
It could just be stolen, but both cases would be helped by uploading and deleting.
US border control will certainly look at unencrypted equipment, but are unlikely to detain a citizen. I think the same goes for other countries who don't want to get into a diplomatic spat with the US.
It needs to have a have a default timeout on authentication, like 15 minutes, and ideally a 'zeroise' button to flush the key, or optionally erase all.
I'm reminded of those fake SD cards that say '32GB' and report 32GB but only have 128MB chips. I'd like the opposite, something that says '16GB' but has a hidden memory segment.
Another solution would be to use an EyeFi card. A while back someone hacked a different firmware onto them; at least conceptually you could do that again and have them report no data. Some details: https://www.os3.nl/_media/2013-2014/courses/ot/connor_stavro...
Using an EyeFi to immediately transfer the data to a cell phone with encrypted storage is also a consumer level solution that would just work. But of course phones come under heavy scrutiny too and they might just beat you up until you tell them the pass code.
Laura Poitras has been on the Department of Homeland Security "highest threat rating" list since 2006 and has her computer equipment seized and files copied by border agents every time she enters the United States: https://en.wikipedia.org/wiki/Laura_Poitras#Government_surve...
Poitras is a United States citizen and there is no law to compel US citizens to reveal their passwords to US border guards, presumably she knows this and does not reveal her passwords.
As regards being a position to extract the encryption password, there are a number of ways around this. One is a dual password system in which one password unlocks and the other one destroys. Another is for photojournalists to work in teams such that the person holding the camera doesn't know what the password is and thus can't give it up.
Finally, attempts to extract encryption are only as good as someone's susceptibility to fear and pain. It's not like evil people turn nice after they get what they want, so if someone is willing to use torture to extract information they're only slightly less willing to use it for pleasure; often the investigation is a mere excuse to engage in sadistic behavior. Understanding this (as opposed to being shocked that something bad could be happening to you) makes it far easier to deal with.
In a controlled studio environment, the only good way to accomplish an adequate data connection to PC/laptop has been though USB tethering. In many of the situations journalists/filmmakers are are referring to, the "upload scenario" is likely impractical to achieve.
The ideas discussed in the comments here pretty much show that there's no simple solution to the journalists' quest, but this should hardly be a surprise. As we all know assuring "computer security is a hard problem".
What's really needed IMO is some way of automatically uploading photos (perhaps only selected photos if on a very low bw connection) directly to a remote server of the user's choice. And ideally doing so in a way that is secure and proof against accusations of tampering. As much as I've tried I haven't managed to make eye-fi's do that.
Its rather odd to say someone hasn't thought something through when you haven't had any first-hand interactions with them (unless you have had them.. in which case you should detail them). Could you tell us how much time you spent thinking about it? The article is second hand reporting and is editorialized so you're only arguing against a straw-man. If you read the source document, the petition broadly speaks about "encryption features". One of those features, stated via example, is encrypting the data at source on the storage media. The features haven't been specified in any detail since a petition is not a technical specification. You're simply assuming what they are and aren't asking for.
Your own solution has deep flaws, as you yourself acknowledge. I trust the irony of the situation isn't lost on you ! :)
Much better is to derive a symmetric key from your private key exchange with your lawyer, and use that to encrypt the pictures. The camera or card could have a "wipe" switch that erases its local copy of the symmetric key, leaving only the lawyer being able to decrypt the photos that have been taken.
So use a public-key algorithm that is designed to be faster, less expensive, and use smaller keys -- e.g. NaCl's crypto_box, which uses Curve25519 under the hood: https://nacl.cr.yp.to/box.html.
> Also, RSA keys are enormous.
We're talking about devices that have as a primary goal the storage of lots of high-resolution media (photographs and video). I think you could find a couple extra KB to spare for an RSA public key... (although, again, there are better primitives than RSA that should be preferred).
The implementation of 'real' and 'decoy' passwords should be identical. The decoy isn't implemented any differently than the real. Watching the camera go through the motions to access the file system through that password should not reveal whether that password is real, because the 'real' password isn't any different than a decoy password used to access decoy files on the SD card.
Under more pressure, the journalist could reveal that the password previously given was in fact a decoy, and now the journalist will give the 'real' password -- but it may be a decoy as well. There is no way to tell.
* It's only as useful as the sacrifice data is convincing. This might be difficult in an active and rapidly shifting warzone.
* It only works in an environment where the attacker doesn't know such a thing is possible. If the attacker is willing to keep torturing until they get what they want, they will. Even if it doesn't exist.
Nikon and Canon both have a feature where the camera digitally signs each image, so that you can "prove" that they weren't modified after the fact. Unfortunately, I believe someone managed to extract the signing key from a Nikon camera and there was some other vulnerability with a Canon.
It's signing the images, not encrypting them. This isn't attempting to deny you the ability to see the pictures. Instead, it's supposed to demonstrate that an image wasn't modified after acquisition. I think it essentially takes the pixels, calculates a signature, and then stashes it somewhere in the jpeg/raw header.
I can imagine some non-evil uses for that, like crime scene or insurance photographs. Heck, it might even be useful for online selling (here's an unretouched photo--look, no scratches!)
You're right that it's tricky to protect the signing key from a-user-who-is-also-an-adversary though.
The first time I heard about CameraV & InfomaCam apps I tought: Why regular cameras don't have this?
https://guardianproject.info/apps/camerav/
https://blog.witness.org/2013/01/how-informacam-improves-ver...
Have the camera broadcast the image in parts with forward error correction to a set of passive listeners in innocuous gear distributed amongst the crew, perhaps an MP3 player, a vape stick, flashlight, a portable radio. Such that if enough of the listeners manage to get back across the border to home base they can be combined to recover the photos.
yes, autocratic regimes will default to a very easy method which does not require much training or skill: https://en.wikipedia.org/wiki/Rubber-hose_cryptanalysis
Few courts will punish law enforcement for taking your camera and looking at the images without your permission. They may be inadmissible in court (or they may be admissible) but they will have that knowledge.
Most (some?) courts will publish law enforcement for using duress or coercion to extract information which could be legally concealed using your 5th Amendment Constitutional rights.
This is basically why GBDE exists.
See s.s. 4.1 "Protecting the user" of http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
The drawback is that GBDE is for cold storage protection (which I imagine could be okay in a camera).
There's a lot of gray areas where it's very much worth it. Think of some places where police can seize your camera, make a copy of the data (perhaps in secret), but they don't dare torture you for fear of geopolitics.
As in, the authorities define what is legal as what is beneficial to them. Good luck arguing the finer points of legal doctrine with a HiLux full of grunts with Kalashnikovs, &c.
i think it would even do to have it done "offline" - i.e. any image/audio/video older than a few minutes gets encrypted and can only be decrypted at another location.
that should also be an optional mode. so you can have lots of wildlife photos and pictures of cute cats for plausible deniability.
In other words - not the kind of people you're likely to meet in many locations.
Simply _being_ in an area carrying camera gear is often enough to warrant suspicion. As concealing cameras and shooting often isn't a workable solution, plausible deniability -as to what is actually on your card, that is - you shooting can hardly be disputed- remains your best bet, IMHO.
If whoever challenging you can tell you've got photos/video but are unable to display them - well, if I were the grunt with the Kalashnikov, I'd just take that as admission of guilt, clobber you with the camera before taking the memory card and smiling my smuggest smile.
Better still if you have redundant storage so that you can give away a card while keeping your exposures.
(When younger, I practiced, practiced and practiced changing film in my SLR until I could do it in a few seconds, with the camera behind my back. Why? If I happened to attend a gig whose management had a less than enlightened photo policy, I'd just shoot a couple of quick bursts, lower my camera, change film and give the roll to my accomplice. If house security came and shook me down, I'd just shrug, sigh that they got me this time - and wait for them to ask for the film, then reluctantly rewind and hand it over.
Pretty good success rate.
They'll keep you in prison until you hand over the data. You'll hand over the data. They'll keep you in prison because they plausibly think you still have the real data.
the problem these guys are facing is not the encounter.
its that the images and video can incriminate and cause repercussions for people not at the scene but stored on the camera.
such as those guys with you ak47s you are complaining about who were helping the journalist get their story of governmental abuse of power.
or that police officer confessing his coworkers corruption.
I was just thinking of a slightly wider use case than 'I am Laura Poitras and am concerned about interference from US state actors'.
To but it differently - what would (possibly) help a poor PJ facing down a truckload of IS would also help Laura Poitras.
After all, some guys with AKs may help you get a story on the abuses of other guys with AKs - who may see things differently.
(Though I'll admit I think that is a moot point in many situations - say, reporting from Raqqa it isn't very likely that anyone you encounter would believe you if you showed them all the wonderful decoy photos you'd taken of the shot-out remains of all the touristy sights - and not a single photo showing anything which could be construed as aiding one side or the other in the conflict.)
bit strawman?
what they are asking for isn't technically difficult or even that expensive to develop.
Strawmen's got nothing to do with it; I just don't see why one should try to make a product with an unneccesarily limited set of use cases.
a) Encrypted storage would be a benefit for both Laura Poitras and just about anyone else; true.
b) Adding steganography does not put Laura Poitras at a disadvantage; however, it may provide a benefit to other users under other use cases. Also, it is not technically very difficult or even that expensive to develop.
c) To some users, the existence of encrypted, visible files could be just as bad - perhaps even worse - than unencrypted files; after all - you are basically showing the person challenging you that you've got something to hide.
So - I think adding the option of plausible deniability will add negligible complexity while making the potential user base larger, thus making a camera (or memory card) incorporating this technology more commercially viable - benefitting both the Laura Poitrases and the others. No strawman.
"This is too limited because it doesnt help people taking the camera"
when the whole problem has nothing to do with taking the camera and everything to do with what happens afterwards.
the equivelent to "there is no point in encrypting your banking transactions because it wont stop someone stealing your wallet on the street"
-> typical strawman.
A strawman would be me saying something like "This is a good idea, but it is obvious it needs quantum cryptography to succeed, and as we all know, that is hardly commercially available in a form factor you could incorporate in a digital camera, hence the idea will never fly." (Yes, this is taken almost ad absurdum - but, hey, this is the Internet, after all. :))
Me arguing that this is a good idea which could be even better at no disadvantage to Poitras et al and for negligible extra development, however, is hardly a strawman.
Then again, I may be misunderstanding you altogether; English is my third language and I am struggling to understand what you mean when you suggest that I (paraphrased) say "This is too limited because it doesn't help people taking the camera"
Even Poitras' suggestion is intended to help once someone has taken the camera; you do not need encryption or anything per se as long as the camera is in your possession. (Assuming it is offline!) - It is when someone - be it the US Govt, a competitor, your friendly neighbourhood grunt, some guerilla in a disagreeable part of the world has taken it that limiting access to the images/footage is necessary.
not a million miles from
->I think you'd still only have a solution which is workable against a very limited set of adversaries - namely, the ones who play by the rules, more or less.
which is exactly why i said "a bit strawman"
perhaps where we differ is you think encryption only keeps information safe from those who play by the rules?
-No, that is not what I think and neither is it what I've been trying to bring across.
Let's just put it on the account of poor communication skills (at either end).
You've been posting quite a few comments that break the site guidelines. We ban accounts that do this, so please read the rules and follow them:
Cue relevant XKCD: https://xkcd.com/538/
If you asked these people "how do you prevent your server logs from being seized and manipulated by hackers?" they'd just tell you "Easy! Encrypt it with a password!" Sigh.
What they really want is an easy way to log what they shoot directly to a central, hardened server geographically located in a friendly legal jurisdiction (perhaps several such jurisdictions) with no remote edit or delete permissions, deleting their local copy once the footage has been successfully logged. Given that the only way to do this with a camera under warzone conditions is to have a wire to some kind of backpack with a satellite uplink and its own power source, the next best thing is to allow the camera to stream to a laptop acting as a proxy for that central server, not leaving a copy either on the laptop or the camera.
I've thought a bit about this recently, and was excited by this news because it seemed like an opportunity to talk about it.
So, here goes.
The obstacle that is most obvious I think, is, "what if someone gets the private key out of the camera, and uses that to sign doctored images?". This is a serious problem, and I don't think it is one that can be solved by software alone. It needs a hardware solution.
The solution I propose for this, is using the technology used in the ORWL computer https://www.orwl.org/wiki/index.php?title=Main_Page .
The ORWL computer has an open source design, and it stores the data on it encrypted, with (as far as I can tell. I am not a security expert.) quite good physical security. It keeps a key stored on a region of the machine where it will be quickly deleted if tampering is detected. It has a security system which is separate from the rest of it, so that the OS being run does not need to worry about the encryption things at all.
It has sensors to detect a variety of different possible methods of intrusion, such as breaking through a barrier, sudden pressure changes, sudden temperature changes, etc. each of which will cause the decryption key to be quickly deleted. You can check the details on the wiki.
My idea is to, instead of the key that is stored in this part of memory being used to decrypt and encrypt the data on the hard drive of the ORWL pc, it would store the private key used to sign the images (or video) being recorded by the camera.
If anyone tried to get at the private key, the private key would be deleted. But the images already signed could still be verified with the public key.
Two other problems are, how do people know that a given public key corresponds to a camera with a secure system like this? What if someone just generates a keypair and claims that the public key is for one of these cameras? How can people trust that these cameras work as advertised?
For the confirming that the cameras work as advertised, the solution for this can be inherited from the ORWL pc. Although the ORWL pc is designed to delete the key upon any physical intrusion, it is also designed to be easy to take apart to inspect, and is (almost entirely?) open source. Opening it up to inspect it will of course cause the key to be deleted, but once one puts it back together again, a new key can be generated using a built in hardware Random Number Generator. This solution could, I believe, also work for this proposed camera design. I believe this is a satisfactory solution.
For the "why should I believe that this public key corresponds to a private key from a properly working camera of this kind?" question, the solution is similar, I think.
My idea is to use either a tree or web of trust sort of thing. The idea is that an organization could certify such a public key by opening up the camera, performing tests to confirm that it conforms to the specifications, close it back up, and generate the new keypair. This whole process would be recorded by cameras (or a camera) of the same kind. In this way, it could be confirmed that, given that a certain public key corresponds to a secure camera like this, that other public keys were produced by and correspond to other secure cameras like this.
If there is an exploit in this system, it should not be harder to demonstrate the flaw than to exploit the flaw, because, if one was able to get a public key verified by this system, which did not in fact belong to such a camera, then one could use it to sign something other than an image, and demonstrate the flaw.
I would appreciate any feedback on this idea.
If you read it, thank you for taking the time to read it.
edit:
apparently, some cameras have had image signing features before, but have not had the physical security to protect the private key, as described in this thread : https://news.ycombinator.com/item?id=13178138 . I did not know this.
It would be far better if the cameras automatically uploaded these photos[0], and could be configured to upload them somewhere outside of hostile reach, such as servers owned by the magazine/paper they work for.
A side issue is that being able to prove authenticity would be valuable, as the issue of faked news/images becomes more visible in the eyes of the general public. Having some sort of GPG signing of (image + gps time + gps position) would be valuable, although establishing the trust chain in practice would be quite difficult and requires some serious thought.
0: Yes, there's a question of how you get internet access in places such as the middle of a warzone, but something generic like wifi would allow individual papers to provide something like a satellite wifi bridge to enable uploads regardless of location (although the cost would obviously be large).