Filmmakers Ask Nikon and Canon to Sell Encrypted Cameras
wired.com
wired.com
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).
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.
Concealing ALL photos will still need to be an option for some, though: plausible deniability of "did you take pictures of X" when questioned :)
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).
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.
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.
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".
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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
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).
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.
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.
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.
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.
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.
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".
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.
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.
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).
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.
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.
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.
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
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.
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 ! :)
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.
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...
I thought the days of wandering around with a camera while having a recorder on a shoulder strap were left behind in the eighties.
IIRC FileVault stores a "forgot my disk" password with iCloud, which is likely subject to subpoena. That assumes there's no law enforcement/nation-state investigative service backdoor in FileVault. The built-in, OS level disk encryption is likely insufficient, so why use a Mac at all here?
You could just offboard the footage to a machine running a Free version of Linux running LUKS and then after shooting and in a secure location and manner give the files to somebody to do the video editing on the Mac.
The disk encryption is actually quite adequate on a Mac.
We also have no evidence of any backdoors in the encryption in Apple products, and quite a bit of recent evidence that there are no such backdoors.
They had all already stopped relying on any closed system to keep their communications secure. They were all using Tails to communicate through Tor without leaving a minimal unencrypted footprint. At the point where you are relying on Tor to communicate and are explicitly using Tails to keep your communication secret then why would you start relying on a Macbook, running a proprietary OS, with non-open crypto, to hold your secrets if you're already scared the neo-Stazi are going to break down the door and steal your unlocked, decrypted Linux machine that you have all of the trust in the world in? For that reason alone you would skip the Mac.
Then high quality, professional shots are hidden while the kind of photos you might take as a tourist are sitting there openly.
It'd be detectable if you knew what to look for, but a) you likely can use more subtle activation techniqies (photo knocking?) and b) a lot of security checks aren't that sophisticated.
Back when Microsoft rolled out Windows Mobile 7, they made use of this automatically. This caught many a new user off guard, and hilariously the only devices that could non-destructively unlock said cards were Nokia Symbian phones.
https://en.wikipedia.org/wiki/Secure_Digital#Card_password
I don't know what degree of protection that gives you.
Looks like SecureMMC supports actual encryption, not just password protection.
Also, while some enterprising card supplier is at it, they might as well implement a TrueCrypt-style hidden volume solution. That, methinks, would be most useful (for a very, very small subset of their customer base).
After all, as has been pointed out already - chances are the people who can inspect your camera would also have ways(tm) to make you come up with the password.
[edit] But then I hadn't thought about legacy devices.
Minor nitpick:
signed and encrypted using that public key
You don't sign things with a public key, it's your private key you sign with.
You can also always plug the camera to a laptop and use it as a capture device basically.
That's if you want "one-way" encryption (i.e. once the photo is taken you can't retrieve it again until the private key is present).
The private key needs to be in memory as long as you are filming/camera is on since otherwise you can't really encrypt the data so you can't film.
If you want to decrypt the data, you need the private key corresponding to the public key that this was encrypted with, but that can be left at home, but you never need it before that, so you can leave it at home if you want and you won't be able to access it until you get home.
A symmetric key is 256 bits, an HD video is on the order of hundreds of millions to billions of bits, so even if your public key crypto system were 100,000x slower than the symmetric crypto system, it's still going to be negligible compared to the cost of decrypting the remainder of the data. See https://en.wikipedia.org/wiki/Hybrid_cryptosystem
For this reason, public/private key systems for data at rest is probably not particularly ineffcient relative to your suggestion of a symmetric FDE, plus it has the additional benefit that if you want to operate without the ability to decrypt data at rest, you have that option (by leaving the private key at home, since you only need the public key to write new data).
It's true that TLS as implemented on the internet encrypts with a private key and decrypts with a public key, but this is not universal. Encrypted PGP communications, for example, work the opposite way.
Encrypting with a public key is a common technique if you want to ensure that only one person or device can decrypt it, which is what is desired here. It doesn't prove authenticity, unless you also sign the message with your own private key, but that's not the goal -- protection of the message from unwanted actors (and yourself even under compulsion) is the goal.
Edit: Google's Vault [0] is a custom hardware implementation of this concept.
[0] https://techcrunch.com/2015/05/29/googles-project-vault-is-a...
Having said that, it's not inconceivable that camera makers can solve this problem (a) cheaply and (b) in a way that is "off by default" for most consumers but available if needed. But I'm not holding my breath.
I think it's far more likely that we'll see the quality of phone photo/video quality become "good enough" for security-sensitive users to abandon standalone cameras entirely than that we'll see camera encryption catch up in the other direction.
at least that is probably what trump has been telling himself at night since everyone turned him down to perform at his inauguration speech.
for everyone else. kinda a big incentive.
Also, my guess is compared to other features they work on this would be fairly trivial, or at least in the same ballpark. And I think it would immediately give the camera a certain cache that would signal "professional" or "serious" that would increase its value, regardless of whether or not the user really needs it.
Without meaning to be dismissive of the large numbers of people who do need these types of cameras (I have close loved ones who are professional photojournalists who rely on having the best cameras), I think a large proportion of people who who buy them don't need them relative to what's on decent phones today. They're just a status symbol for them anyway.
While I do share many of the photos I take, I don't just dump the entire SD card to Facebook, I want to pick and choose which photos I share.
As for kids... most people are just posting it straight to Facebook anyway. Again, some might care about privacy, but not enough to make it a real premium feature, I suspect.
Naturally people want to pick and choose which photos they share, but that doesn't mean they are worried enough about the ones they didn't choose falling into the wrong hands to pay a premium and put up with cumbersome decryption procedures - they just don't like those photos as much.
Ultimately, people drop thousands on a pro camera in order to shoot beautiful pictures, not because they want to write their firmware, so you have a chicken-and-egg situation. And while a few people do write amazing firmware - Magic Lantern being an excellent example - that's a liability on a commercial shoot. I might use ML on an art or micro/no-budget project, but as a producer I'd probably nix the idea; you absolutely don't want to be locked into someone's quirky personal workflow to the extent that you can't fire them if they turn out to be shitty photographers or hard to work with on set.
Of course not many people are going to literally write their own firmware, but I can see it being compelling to be able to expand your range of codecs, LUTs etc in a relatively cheap camera, and not have to put up with what the manufacturer thought you'd like.
As for ML, I think it's unlikely to destroy your shoot if you stick to the basics like the focusing and exposure tools (I forget what it actually offers tbh). RAW and more experimental features are probably a bad idea on anything serious, but then so is using a consumer Canon camera.
Longer version: Since I last posted about this on HN (check my comment history), I put the project on ice, and then started it again a year ago.
Follow @ZifraTech on Twitter for more information. Our website (zifra.tech) is not up yet.
The product looks and feels like a memory card, and identifies as such to a laptop, camera, dictaphone, or other device.
The biggest functional difference is that all files written to the card are automatically encrypted on-the-fly. Files written during the same session can be read back by the host device (decrypted on-the-fly). As soon as the card is removed from the host, or the power is turned off, all files are hidden and unreadable until decrypted by a private key, which is intended to be stored elsewhere, for instance the user's laptop.
The crypto primitives used are Curve25519 and ChaCha20.
I'm building an open standard for encryption and ownership of notes. Would love any feedback/help.
See https://standardnotes.org for the full spec. Or follow along @standardnotes on Twitter.
If you'd like to contribute, ping me.
Can you link to the class on your github for this?
I'm transitioning from using a standard of 3000 iterations of PBKDF2 to a variable amount per user (CryptoJS can't handle more than 3000, WebCrypto can, not universal yet though)
And also as mentioned before, just recording to an encrypted macbook or any other laptop might also work already, just the size might be a problem.
There are two strategies of surrender when a defeat in imminent.
Political surrender: You fight till your last breath and make it difficult for the other party to win.
Military surrender: When defeat is imminent it makes sense to surrender without a fight and cut need-less losses.
I think journalists when confronted with a certain defeat must embrace second type of surrender instead of first.
There have been many great options presented in these comments for hiding/exfiltrating/locking the data.
The problem with the idea is that it works only if every single photo/video player in the world agrees to respect the metadata in the file, _in spite of the wishes of the owner of the computer running the player_. Be careful what you ask for.
In theory, adding a copyright notice to EXIF is just as effective -- though everything is already legally copyrighted the moment it's fixed in a medium, regardless of notice. So you already have what you're asking for, and you can see how well it's working.
See also RFC 3514.
Also there is an option for custom firmware on SD card [2] but probably kills the speed too much.
[1] http://chdk.wikia.com/wiki/CHDK_in_Brief [2] http://hackaday.com/2013/12/29/hacking-sd-card-flash-memory-...
Ironically I think the best way of getting this actually built would be to sell it as in-camera DRM. The requirement - no viewing without authorization - is almost identical.
This kind of thing is a very tricky use case, because suddenly the camera is a safety-critical device. That is, if people are relying on their software to encrypt images, they may take photos that if revealed to the wrong people at the wrong time may get them killed.
Thankfully she entered it correctly the third time, but it kinda changed my opinion on remote bricking. I don't want someone to want to kill me just so they can make $400 before I can brick the device.
Professional photographers have insurance, so most of them probably rather would loose a camera than having one lock up by accident when needed, or any complications added to robberies.
Right now, at least some the large manufacturers don't even have registries for stolen devices in case they turn up or get sent to service, that's something that could be improved easily.
The form factor of an embedded Linux box with an Ethernet port, an SSD, and a hardware power switch would be pretty tiny. It could be done in the shape of an autowinder.
Making encryption happen in the camera seems like solving the wrong problem - you really want to exfiltrate to secondary, offsite storage at high speed in a secure manner.
Or lose the functionality. Photographers lived for a century without a preview window.
Uploading it to offsite secure storage is much harder to solve for fieldwork since you can't be assured of having a high bandwidth connection to anywhere secure.
Edit: maybe the solution is a "panic button" assumes everything is fine until you press it, at which point it locks everything down until its opened by some much more cumbersome means