Hacker News new | past | comments | ask | show | jobs | submit login
Filmmakers Ask Nikon and Canon to Sell Encrypted Cameras (wired.com)
320 points by SonicSoul on Dec 14, 2016 | hide | past | favorite | 207 comments

I'm not certain this has been thought through sufficiently. If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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).

A decade or so ago I spoke to a tech guy at an environmental group, who told me about how the people he worked with during demonstrations had cameras that transmitted the pictures to a portable wifi hotspot that someone (often he did it himself) brought with them in a backback with a laptop and a variety of directional antennas to ensure they could have someone far enough away for police to be unaware of them.

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.

They were probably using Eye-Fi SD cards. Didn't the cards send your data through a third-party server? I think they cards are now obsolete or unsupported.

Transcend make WiFi SD cards as well, which support direct connection, run Linux, and are rootable to do cool things like upload files via FTP to a user-controlled server: https://github.com/alejandroliu/sdwifi

Yeah, Eye-Fi cards are supposed to work with an app on your laptop or phone that uploads pictures to their servers. You can run your own server to pose as the app and intercept the pictures, though.

I don't know what specifically they used, but I believe it was before Eye-Fi

Yeah, though it's often easier to expense assets than add more salaries, which is why I wonder if some sort of auto-wifi upload, which can be supplemented by a satphone <-> wifi bridge if required, might be more of a realistic proposition for warzone journos than an extra person hiding somewhere in the back of the convoy. And of course, these days, public wifi is much more widely accessible in many parts of the world, so it's only in the most remote or hostile environments that you'd need this.

> only in the most remote or hostile environments

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).

One-way encryption to a private key which is kept overseas back home. None of the data can be decrypted on foreign ground no matter what the authorities demand. Automatically upload data home over a secure link when there's a connection.

We should be able to implement that on the SD card level. We could also make it selective and hide encrypted photos from the camera so there is no evidence that the system is in place.

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.

I'm pretty sure this is trivially implementable in CHDK [1]. Already, with the hacker-enabled RAW mode (this is on Canon P&S cameras), it saves a RAW copy of the image to the SD that never shows up in the camera browser. If you delete the JPG using the camera, the RAW file is still there, but not visible to the camera.

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).

[1] http://chdk.wikia.com/wiki/CHDK

Simpler, store two images, one encrypted, one not. You can only review and delete the unencrypted one. Your decrypter back at home could automatically remove the deleted images so you don't have to review as much if there were no problems.

Good idea for most cases!

Concealing ALL photos will still need to be an option for some, though: plausible deniability of "did you take pictures of X" when questioned :)

IIRC some "wifi" SD cards run some form of linux, so it might be possible to hack in some encryption.

I thought about that, but that would mean it's then probably not possible to review the images you've taken to ensure that you got the shot you wanted.... I guess you could keep a second copy in a buffer somewhere, but I think however you handle this you either sacrifice a lot of usability or add quite a large vulnerability...

There may be a more elegant solution I haven't thought of, however.

My camera has a RAM buffer that images are stored in before it's flushed to the flash card. That doesn't help with reviewing 2 hours of video footage, but it does let you review the photo you just took before it's wiped from RAM.

All serious cameras do - but it's typically fairly small and most image review happens from the sd/cf card, not the buffer. I think if you have instant review on (I don't ever use this setting) then it MIGHT happen from buffer, but I'm not certain.

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.

> it's then probably not possible to review the images you've taken to ensure that you got the shot you wanted

Well, photographers in the film era managed to get by.

But why should they believe that you really don't have the access to the key? You might end up with torture :/

Also, they could hold you captive and demand that you have someone at home send the key in exchange for your freedom.

> But why should they believe that you really don't have the access to the key? You might end up with torture :/

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".

Please list your alternative solution for storing photos where capture/torture is not a possibility.

I'd have to say that selectively keeping inconspicuous photos and transferring the "incriminating" ones via the internet (as suggested by others) seems to be the best possible course of action.

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.

If you're caught though there's a good chance you were seen taking pictures and those pictures not being present is going to be quite obvious. Also, if camera makers add this feature than those confiscating camera equipment will know about it.

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.

Public key encryption does feel like it could be a useful approach. Rather than putting the burden on camera manufacturers, it could be implemented on a portable hard drive with SD card reader. (Turns out these already exist, just not with encryption: https://www.wdc.com/products/portable-storage/my-passport-wi...)

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.

> None of the data can be decrypted on foreign ground no matter what the authorities demand.

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.

This would force the authorities to call back to the journalist's home base. Meaning that their employer will now know that the journalist is being detained and lawyers can be contacted. This is probably one of the safest ways to do it. And if that became standard the authorities would know that the journalist doesn't have the password. As for reviewing the photos you could do it once they are uploaded, or just be able to display the last photo taken. There are ways to make that convenient and secure.

"Of course, officer, I can show you the photos I took on this camera. No, I can't show you on the camera. You need to give me access to a computer and let me type stuff for awhile!"

More like "I don't have access to the pictures officer. You need to contact these people." Then they likely destroy the camera.

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.

>If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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.

A valid point, that certainly happens in a lot of cases. However, I think the main thrust of the open letter is more of a "protecting sources" concern rather than a "preserving the footage from being seized/destroyed" one. In that view

encrypted camera -> authorities cant get in -> they just smash it instead

is a beneficial outcome.

Many phones function this way now, automatically uploading photos to Google's or Apple's servers. I know it's not really as good as uploading it to a rogue operator's secret vault in the side of a mountain, but it does provide the basic protection from device destruction discussed here (and you could probably configure a Dropbox-style private cloud to upload to the mountainside vault anyway (something like OwnCloud may already do this?)). Many professional cameras have wifi capabilities, either as an add-on or built-in, that can be configured to transfer photos from the camera to the phone. You can then set that directory as a cloud backup target and it should take care of the matter.

This was exactly my thought. Encryption doesn't inherently protect availability, and by far the more common occurrence (at least the stories I've heard, from independent journos covering the US, or abroad in places like North Korea or China) is deletion. To the point where I was advised that, if I started shooting protests domestically, I should always carry a spare memory card (loaded with innocuous shots) and get good at discretely swapping them out.

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).

> As mentioned, a "satellite camera" that transmitted all pictures somewhere else and stored nothing is a much more worthwhile goal.

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.

An ordinary DSLR will shoot 4-10 frames a second. A mirrorless camera will often shoot 2x that or more. Any current model will shoot 2k-4k video. That means streaming can easily hit gigabit+ requirements. Ordinary Wifi doesn't do that.

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.

I suspect I must be horribly misreading your post, because no matter how many times I read it, all your objections seem extremely silly. Please accept my apologies and correct me where I'm misinterpreting you you, but":

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?

I guess we interpreted the article differently. The case study in the article was a journalist in an hotel room shooting video of Edward Snowden.

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)

[2]: https://en.wikipedia.org/wiki/Transport_Layer_Security

[3]: http://paulgraham.com/disagree.html

It's hard to take you at your worldly-wise word when you completely ignored his point that photojournalism doesn't require optimal photo/video quality (and it's very high bandwidth demands) to be effective. Refusing to acknowledge someone's argument and trying to out-nerd them isn't very civil either.

It's a fair point and why I stopped and grilled some chicken a few hours ago instead of going deeper down the XKCD386 rabbit hole.

I feel that. It's easy to get carried away in an environment where social cues are so attenuated.

For me, old habits sometimes come back. If there had not been return fire to the second comment, it might have been deleted.

> 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.

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.

> Locally encrypting files would require the user to enter a password every time they switched the camera on. Which is a usability nightmare.

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.

Not trying to nitpick, but it wouldn't necessarily be the case that you would have to enter a password. You could encrypt against an HOTP on the device and perform secure key erasure for the N-1th photo and previous. You'd then have a server which would be able to decrypt based on a one time shared secret (the HOTP root).

You couldn't even quickly stream a good set of photos from your camera in many parts of the western world. It's an interesting solution when it fits, and WLAN memory cards and cameras with WLAN are available for that, but once you go more clandestine or remote it is likely not an option.

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

> Wartime journalists typically don't need huge images

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.

> That's pretty demeaning. Wartime photographers need quality as much as others.

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.

You're talking about stills. The data requirements for video are massive. For me, in London, the most practical solution is still usually to hand the editor a USB drive in person.

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.

> maybe heavily compressed 720p would be acceptable

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.

But they do not, in general, use professional journalists who record footage using cell phones.

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.

It's probably not a good idea to hypothesize about attacks on individuals; you might want to rewrite your post. Of course TV stations want incoming footage to meet broadcast quality standards - having worked in narrative film for a while I fully agree that better is better because while you can go down in quality for lower bandwidth it's basically impossible to go back up again.

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.

> You're talking about stills. The data requirements for video are massive.

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.

I accept that your argument is more reasonable if you're talking about stills, but the article is about video, and presumably that's what everybody else here is talking about.

> 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).

> I accept that your argument is more reasonable if you're talking about stills, but the article is about video, and presumably that's what everybody else here is talking about.

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...

You're right, it does mention photojournalism, I should have read it more carefully. Apparently we've been at least somewhat at cross-purposes.

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.

I am a former employee of a news agency you have all heard of. 2.7MP is plenty for a news image, tho' more is better - this is what our people were shooting with Nikon D1/D1h. A satellite phone at even modem-speed will blow your budget faster than you can blink if you use it to send full resolution photos...

"I'm not certain this has been thought through sufficiently."

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.

Understanding the goal one wishes to achieve may not always be the same as understanding the best way to use technology to achieve that goal. Indeed, it's very possible to both have a real problem worthy of being addressed and no good solution to it.

> I'm not certain this has been thought through sufficiently. If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

You're basically dismissing the usefulness of encryption as a whole (on phones and anywhere else).

Err. I think he's just stressing physical security is the first line of defense and proposing a solution in a case where it is compromised. (Sure, if they can physically hold you, then they can hack into the server via your camera and delete uploaded pictures, but that's a harder task than breaking a locally secret based encryption)

You can MiTM a phone without people ever knowing. If police steal a camera they may as well take the key holder too.

It could just be stolen, but both cases would be helped by uploading and deleting.

This was my instinctive reaction too, but I don't think it's true. Confiscating equipment is not in the same realm as indefinite detention.

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.

See reply from lb1lf below. The world is not as tightly constrained by rules as you seem to think - a truck full of heavily armed militia in the middle of a civil war are not going to give a damn what the US' diplomatic policies might or might not be.

There needs to be an explicit mode for using 'secure' storage. If you dial in a code that is incorrect it just shows an empty partition. But if you don't put it in 'secure mode' (i.e. just press play) it will show the holiday snaps.

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.

I liked that feature of truecrypt. Does anything else these days have a deniable encryption feature?

Is there place on the USB handshake to push a key?

Nothing official. And if it had any other USB modes it wouldn't look like a plain SD card anymore. But you could use a knock protocol to talk to it.

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.

> I'm not certain this has been thought through sufficiently. If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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.

This is about protecting the subject of the photos, not necessarily the photographer.

I can't believe how many people are missing this point.

You can already automatically upload things using an eye-fi card or other accessories sold to pro photogs - they're far from perfect, but this functionality has been on the market for several years now. It would work better if there were a cheap, robust, and universal wi-fi mesh networking standard in wide use (hint hint to bored developers).

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.

Uploading images via WiFi has been a common feature of pro cameras for a couple of years. I've used this capability at times but it's limited in terms of the amount and rate of data that can be transferred this way.

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".

eye-fi's are great - I have several - but at least for me they don't actually solve this particular issue, as they only transfer the image to your phone/tablet.

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.

Thanks for the feedback. I hadn't used one for a few years and my memory of their capabilities was hazy.

>I'm not certain this has been thought through sufficiently. If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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 ! :)

Encrypt pictures using a public key stored on the SD card have the secret key known only to your lawyer who lives in another country.

Too slow. RSA encryption is very expensive. Also, RSA keys are enormous.

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.

> Too slow. RSA encryption is very expensive.

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).

Give lawyer x, encrypt the first picture under H(x), the second under H(H(x)), and so on. Always delete the key after you use it so that the data can not be recovered without x.

It should be possible to have one or more decoy passwords. Under pressure the journalist reveals a decoy password. When entered, the camera presents the view of an SD card with various information that is okay to reveal to the authorities. The real information protected by a different password is still protected.

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.

Not sure why you've been downvoted for this comment - it's not a bad idea at all.

Duress sacrifices are a known and familiar concept. There are a couple of flaws with the concept:

* 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.

As for the authenticity,

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 fortunate they were shown to be broken. Because they inherently are -- it's DRM all over again. If it wasn't publicly known they were broken, then people might put more faith in them when they shouldn't.

I'm not sure I understand your dislike of this idea.

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.

It's not tricky, it's basically impossible. It's the holy grail for some: being able to remotely attest to the exact bits of software being run on trusted hardware.

>A side issue is that being able to prove authenticity would be valuable...

The first time I heard about CameraV & InfomaCam apps I tought: Why regular cameras don't have this?



This of course has the challenge that you need a network, and if you're taking pictures in a hostile country such a network would be problematic. That said, there is an interesting fuzzing defense here.

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.

> I'm not certain this has been thought through sufficiently. If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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

Dictatorships thrive in austere environments. They are no friends of internet access. You might want to travel to more austere environments. Like small towns in Kansas. Or the Philippines.

You are correct that access can be coerced. However, it's a question of cost and thresholds and consequences.

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.

> If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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).

> If an organization is in a position to confiscate the camera from a journalist, they're almost certainly ALSO in a position to extract the encryption password from the journalist.

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.

In this situation you could give the journalist an encrypted camera take photos without giving him the ability to decrypt it.

I think it's a step towards protection for the photographer/journalist. having your camera seized doesn't automatically mean authorities have the right to look at its contents. if they choose to do something unlawful or unethical to extract the contents at least this puts another challenge in their wake.

This wouldn't be an issue in a number of jurisdictions.

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.

thats why it should be a technical impossibility to recover them in the field.

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.

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.

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.

Plausible deniability works both ways.

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.

did you rtfa?

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.

Oh, I read the article all right, no worries.

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.)

but you seem to be talking about situations where concealed camera equipment is more suitable, or even just your run of the mill phone.

bit strawman?

what they are asking for isn't technically difficult or even that expensive to develop.

Concealed camera equipment is, to the best of my knowledge, mostly avoided for conflict reportage purposes; the constraints on quality are simply too limiting. (Besides, I guess it often falls in under my earlier comment - that simply being there is seen as suspicious; camera gear won't make much of a difference in that case.)

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.

but thats the 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.

-I'd respectfully suggest that your idea of a strawman differs from mine.

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.

->This is a good idea, but it is obvious it needs quantum cryptography to succeed

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?

> 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).

> did you rtfa?

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:



Doesn't seem that hard. Two passwords could be used. One normal password and a remote password kept at home. A special feature could lock the data so that only the remote password could unlock it. It could also work with a hand strap that locked when separated.

> they're almost certainly ALSO in a position to extract the encryption password

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.

Blockchain them photos!

> 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.

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.


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.

Could this be accomplished at the storage level instead of at the camera level? Could an SD card have an onboard encryption engine? We have cards with built-in wifi already.

I was thinking the same thing; would make for simple retrofit to any camera currently in existence.

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.

Well i could have sworn that the S in SD stands for Secure, and involves locking a card to a device.

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.

"A host device can lock an SD card using a password of up to 16 bytes, typically supplied by the user."


I don't know what degree of protection that gives you.

Looks like SecureMMC supports actual encryption, not just password protection.

We also have professional cameras that can be tethered to a laptop and record directly to the encrypted disk. Encrypted camera storage sounds cool, but the filmmaker of Citizen Four could have just tethered to her MacBook.

But it wouldn't be locked out until the MacBook was shut down. Until then, the keys would be available in memory, and effectively unencrypted. Not much protection against immediate physical seizure.

Standard procedure here would be to have the computer plugged into AC power with no battery so you can yank the power the moment anything remotely like a raid to seize happens.

How do you do this with something without a removable battery, like your average (modern) macbook?

Obviously, you wouldn't do this on a Macbook, and not just because the battery is not removable.

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.

No, that's not correct. FileVault does not store any password with iCloud unless you tell it to. Otherwise, it generates a 24-character password that you have to write down, and that is the only key, other than the user's password, of course.

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.

Take a look at Snowden, Poitras, and Greenwald's communications and the recording of the footage for Citizenfour as an example here.

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.

> could have just

I thought the days of wandering around with a camera while having a recorder on a shoulder strap were left behind in the eighties.

External recorders are still normal for professional video work, but not so much for run and gun documentary stuff.

You would need to enter a password, somehow...

Would you though? I could easily see a card with a crypto accelerator that only has a public key to encrypt one-off random AES keys for each photo/video/file. You set it up at home, leave the private key there, go do your filming/photographing. Now no one can decrypt your files except you after you get home download your encrypted files and run them through some trivial decryption program.

It might even be possible to use multiple key-combos and select one depending on the circumstances. Perhaps this way the adversary gets some info and sets you free again.

You could do something like key off image size/type, and have all your RAW format encrypted to a hidden volume while any of the JPEG settings saved to a normal volume.

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.

How about an SD card in to which SmartCard, the size of a micro SIM card, can be inserted. The SmartCard holds a public key, and any files written to the SD card are signed and encrypted using that public key. Decrypting the files would be accomplished with the corresponding private key which is kept separate on a different hardware device and using a PC.

Technically you don't even need a second memory card. Some SD cards have suitable processors in them already.

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...

I don't think you need new hardware for this. Just a place you can drop your public key on the camera.

[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.

Re: your nitpick.

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.

I wasn't mentioning this nitpick from a TLS point of view, I raised it as a PGP thing which is more likely to be the use-case per the point of the article.

Public key crypto for data is also pretty darn inefficient just have an FDE for the storage many cameras come with pcie based storage interfaces.

You can also always plug the camera to a laptop and use it as a capture device basically.

I don't know how inefficient it really is as implemented, I think generally you just generate an AES key or something, use it to encrypt the photo, then encrypt the AES key with the public key and flush it from memory.

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).

Yes, you usually have your symmetric key and your key encryption key, doing data at rest with public key isn't really efficient since then you need to store and protect the private key as long as the data encryption key is in use, so you usually use some key derivation algorithm for your kek which means that your kek is derived or otherwise protected by a password.

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.

I don't think that's true. You definitely don't need a private key, you create a symmetric key from whatever randomness source you have, held in memory while you are using it to encrypt the data. The first thing you do is encrypt the symmetric key with the public key, then the rest of the data is encrypted as you go using the symmetric key.

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.

The DEK needs to be available in memory while the data is being encrypted on the fly e.g. being recorded, if it's encrypted already it's useless.

Yes, the symmetric key (generated on the fly) is in memory while the data is being recorded, this is the case for every encryption technique. In the public/private scheme, once the symmetric key is no longer needed, you discard it permanently and files are only accessible using the private key, which you never had.

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).

So you cannot review what you shot immediately on the camera.

This is a great idea for the public good, but unfortunately there just isn't much economic imperative for the camera companies to invest in it. Security-sensitive filmmakers and journalists represent a vanishingly small niche, not a meaningful market. For the rest of users, photos taken on stand-alone cameras are generally meant to be shared, not strongly protected, meaning encryption is at best a "nice to have" not a "need to have" or perhaps even a "want to have". And that means that if it comes at the price of even a tiny degree of inconvenience, consumers will refuse it.

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.

Reasonable point, but I'd argue that the purchasers of dedicated cameras are already not the general market, who will just be using their phone camera anyway. For purchasers of these cameras, I think the cameramakers going down this route would be a clear signal that they care about the users' freedom of speech and security concerns and are taking their use seriously.

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.

Yes, but the market for high end cameras is an incredibly small niche anyway - small enough that it's not that hard for buyers to have direct contact with business decision makers. If Canon/Nikon won't do it, someone like BlackMagic will.

There's also (possibly) the Axiom open source camera, if it ever sees the light of day.

I highly doubt it will - developing cameras for professional use is fairly capital-intensive and commercial offerings have such a huge head start that the open source proposition isn't very compelling to cinematographers. The best camera is the one you have in your hands right now, not the one that sounds like it would be great in the future. Even Red camera almost choked on its own hype about the Scarlet and had to do a marketing pivot to get into the mid-price bracket.

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.

I dunno, everything looks like vapourware until it exists. For the time being I think they're supported by EU funds and they do still seem to be making progress. I would not bet my house on it appearing though.

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.

Agreed with everything, but bear in mind that producers are basically business managers; they're not that interested in the technical arguments but in minimizing their liability towards investors if things go bad on a project. Every producer I've ever worked with has been very conservative about innovating on workflow or depending on anything too non-standard because they don't want to be held hostage to any individual crew member, and workflow problems have killed many a project in post-production.

There's still a benefit to the average consumer -- if I lose my camera or SD card, I don't neccessarily want the finder to be able to retrieve all of the photos of my kids, or that "racy" photoshoot my wife and I did that one time in the bedroom...

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.

The average consumer isn't using a standalone camera for their, um, bedroom work... they're using their phone. I'm sure there are some people who get into that sort of stuff enough to use high quality camera gear, but again - vanishingly small niche market.

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.

yeah, the great and the good of film and photography giving you their backing means nothing these days.

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.

This is already possible on Samsung NX series cameras https://sites.google.com/site/nxcryptophotography/

Interesting discussion of this idea on the Stack Exchange photo site (from 2013): https://photo.stackexchange.com/questions/33902/do-any-dslrs...

Free Software extensions for cameras such as Magic Lantern http://www.magiclantern.fm/ exist. I wonder if it's possible to add encryption support there, before images are written to the SD card?

The article references http://www.magiclantern.fm/forum/index.php?topic=10279.msg99... which is old, experimental, somewhat faffy, and a bit buggy.

Also looks (at first glance) like it's only for stills (".CR2 and .JPG").

Maybe, but I think the cameras are already working at full tilt just to encode the file. Also I don't think you can run ML on anything professional, and Canon's consumer range are increasingly poor value for video.

They'd have to add at least an AES engine to the chips, but that's really not a big factor in terms of transistors or power usage. (Although, if they're using some ARM cores somewhere, they probably already have one or two of these lying around).

We're talking about Magic Lantern, which is a third party firmware hack that's not supported by Canon, so they can't do anything to the hardware. I suppose it is possible the processor accidentally supports some encryption primitive(s).

With hindsight this was a slightly stupid thought as you could just encrypt the file after writing it. Although that could mean it stayed unencrypted if somebody seized the camera while you were still recording.

I'm developing a solution to this problem.

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.

Its nice that you are promoting your project but instead of a clickbait title to encourage traffic to your site it would be helpful to add a few details here as to what the project is.

Fair enough :)

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.

If you're starting a new startup, it's now honestly unacceptable to not have encryption come standard.

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.

"Encryption keys are generated by stretching the user's input password using PBKDF2. The resulting 512 bit key is then split in two - the first half is sent to the server as the user's password, and the second half is saved locally as the user's master encryption key. This way, the server can never calculate the encryption key."

Can you link to the class on your github for this?

It's handled by the client: https://github.com/neeto-project/neeto-web-client/blob/maste...

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)

Well with many cameras people usually record 4k video to an external device, connected to the video output of the camera anyway (like Atomos Shogun). Adding an encryption to this external device might be a better approach.

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.

Sounds like a bad bad idea to me. When authorities realize that you have outwitted them they are going to beat you up, torture you or simply kill you. In countries like Pakistan, Turkey, India or China you body might later be found floating in some gutter somewhere. A better idea would be to simply hand over the camera to cops and save your skin.

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.

The whole point is to use technological means so the situation is not "certain defeat".

There have been many great options presented in these comments for hiding/exfiltrating/locking the data.

Magic Lantern has had some support for this for a while now: http://www.magiclantern.fm/forum/index.php?topic=10279.0

It's mentioned in the article and elsewhere in this thread. It looks to be just for stills, as well as being "old, experimental, somewhat faffy, and a bit buggy" according to another poster here.

I wonder if, while they're adding encryption, they could also add user-controllable DRM. That way when you post a photo or video, you can specify the rights of (and prices for) those who download it. One of the things that's always felt evil about DRM to me is that it currently only protects the big guys. What if DRM could protect (and pay) everyone who creates content? So we have no more of this: https://www.theguardian.com/media/2009/jun/11/smith-family-p...

That's not really DRM. At best it's DRE (digital rights expression, a term I just made up). DRM controls the computer showing the content.

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.

That's a strawman. The classic DRM solution is to create a new format with some secret knowledge required to play it. Only players that respect the metadata are given the secret required to support the codec.

If you want to circumvent the adblock blocker, just disable js for their webpage. uMatrix is a useful extension for that.

The solution already exists: there are Android-based cameras like Samsung Galaxy NX which can use encrypted camera apps for Android with nice sensor and lenses.

professions seldom use cameras other than main Japanese brands.

I think with custom firmware on camera[1] it can be possible, although would be hard.

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-...

Next week: NSA Demands Back Door To Encrypted Cameras.

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.

They should also provide a way to upload the media in a safe place while keeping some non trivial photos previously tagged as innocuous on a visible partition so that there is some form of plausible deniability. An empty memory card would immediately raise alerts, as probably would do one containing nothing but kitten images.

To piggyback this topic - I think cameras should feature an equivalent of iCloud lock. These are things worth thousands of dollars, and are dead easy to sell on once stolen. I would sign a petition that would convince camera makers to add a theft protection like above. Am I missing something here? The same should go for expensive lenses that should have a coded list of bodies they are permitted to work with.

My friend went to Washington DC for a vacation and got mugged with a gun. The muggers made her enter her iCloud password (which she was having trouble remembering) so they could turn off the "find my iPhone" feature so they could sell the iPhone. When she stumbled for the second time, one of the two guys said "let's just shoot her and get out of here" the implication being that by the time the cops had come they would have offloaded the iPhone to someone else.

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.

In such scenario you should be able to have a secondary password. Once you type it in, your phone unlocks but is also getting flagged (should look exactly like normal unlock). I know it would be scarry thing when you're at gunpoint..

The whole experience is just too real for me. Fuck up your password = death. I'd rather just have my thumbprint or something I can't screw up unlock it easily.

That's still a little strange considering that once she reports it stolen, US carriers will blacklist the IMEI and make it unusable here.

Cameras don't phone home regularly (some nowadays have WLAN, but far from all, and it is mostly for communication with a phone), so there is no good way to get a lock-signal to them without adding a mechanism extra for that. Offline schemes with timeouts or something still have a risk of going wrong.

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.

It could be a proximity sensor at home, a token of some kind, that you need to touch your camera with, say once a month to keep it going. A stolen camera like this would become useless after a month. Once it becomes common knowledge, it could deter buyers and thieves..

Canon cameras already have ethernet ports. I'd much rather the camera support iSCSI so that I can mount a network block device and save to that. I wouldn't trust any consumer electronics crypto support.

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.

What's the point of encrypting a video data stream if it's going to local storage that could be destroyed or taken by someone else, effectively depriving whoever shot the video of the footage?

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.

Sometimes not being caught having the video is more important than for the video to survive. E.g. you might lose the story but keep your life.

Exfiltration in real time requires more bandwidth than you would have most of the time. It makes no sense to choose a "better" solution if it doesn't work.

Put some cache memory on the camera where the last X pictures are held in clear text.

Or lose the functionality. Photographers lived for a century without a preview window.

I think the point of encryption was detailed in the article -- she didn't want her sources to be revealed if the video was seized.

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.

Seems like it would also make it really hard to view your photos - i.e. What happens to that little screen on the camera?

Not necessarily - my iPhone is encrypted by default and yet still manages to show me a photo after I take it. Just like an encrypted phone (or any encrypted device), an encrypted camera would simply have to have a locked/unlocked state.

True, but password entry on a camera seems like a cumbersome process (especially for a strong password), and a bio-metric lock doesn't seem very useful in the situation where you are in custody with your camera.

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

Yes, something like that is one plausible solution - people who care can e.g. map one of the function keys on their dSLR to perform this task, and no one else will be affected.

A hidden encrypted disk partition on SD card with sensitive content and a normal partition with tourist content on the same card. It is good?

I've seen self encrypting SSDs, and I'm wondering why SD Cards with hardware encryption aren't already available. Is there a technical limitation that would render it impossible to build a storage card that has the ability to encrypt/decrypt data transparently to the device it is installed in?

I think some kind of hidden, backup card slot would be also great feature for a number of photojournalists

When may tear the camera down to find a hidden SD card, it's even harder to explain your innocence.

Why don't these filmmakers just use an iPhone to shoot their documentaries instead?

iPhones have come a long way and can stand in for a DSLR in some cases, but not every filmmaker will be able to use an iPhone for their artistic vision

Why do you think?

most of the android/ios devices that are out there have had this capability for many years. Typical resolutions of 16 - 41 megapixel are common today. Why not use these cameras?

There's a huge difference in quality between a $200 smartphone and a $6,000 high end DSLR camera.

Not just image quality. But just very diferentes capabilities, like super telephoto lenses, ultra wide, instant focus, accurate focus tracking, easy manual exposure, external flash sync and the list goes on and on.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact