Hacker News Reader

Comment by jfindley | Hacker News Reader

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

View on HN

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.

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

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.

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.

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

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

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.

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

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

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.

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.

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

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

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.

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

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.

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.

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

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.

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

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

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

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

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

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

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.

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)

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.

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.

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.

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

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

https://guardianproject.info/apps/camerav/

https://blog.witness.org/2013/01/how-informacam-improves-ver...

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.

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.

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:

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

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.

Those exist https://store.nikon.co.uk/accessories-accessories-for-dslr-c...

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.

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.

Reply on news.ycombinator.com