Slashdot Mirror
Camera Makers Resist Encryption, Despite Warnings From Photographers (zdnet.com)
An anonymous reader shares an article from the security editor of ZDNet:
A year after photojournalists and filmmakers sent a critical letter to camera makers for failing to add a basic security feature to protect their work from searches and hacking, little progress has been made. The letter, sent in late 2016, called on camera makers to build encryption into their cameras after photojournalists said they face "a variety of threats..." Even when they're out in the field, collecting footage and documenting evidence, reporters have long argued that without encryption, police, the military, and border agents in countries where they work can examine and search their devices. "The consequences can be dire," the letter added.
Although iPhones and Android phones, computers, and instant messengers all come with encryption, camera makers have fallen behind. Not only does encryption protect reported work from prying eyes, it also protects sources -- many of whom put their lives at risk to expose corruption or wrongdoing... The lack of encryption means high-end camera makers are forcing their customers to choose between putting their sources at risk, or relying on encrypted, but less-capable devices, like iPhones. We asked the same camera manufacturers if they plan to add encryption to their cameras -- and if not, why. The short answer: don't expect much any time soon.
Although iPhones and Android phones, computers, and instant messengers all come with encryption, camera makers have fallen behind. Not only does encryption protect reported work from prying eyes, it also protects sources -- many of whom put their lives at risk to expose corruption or wrongdoing... The lack of encryption means high-end camera makers are forcing their customers to choose between putting their sources at risk, or relying on encrypted, but less-capable devices, like iPhones. We asked the same camera manufacturers if they plan to add encryption to their cameras -- and if not, why. The short answer: don't expect much any time soon.
not excusing the camera makers here, but couldn't this be designed into an SD card?
If you're a photojournalist leaving a dangerous field assignment then there's a high likelihood you will be stopped and searched. If you hand over your camera and it comes up with a prompt for an encryption password then your camera and its media will be confiscated or destroyed in front of you. There go your photos.
As for protecting sources, why would you photograph them if you didn't intend to publish the photos anyway, which would still put them in danger?
Correct. Camera companies are in competition to sell cameras. Adding an expensive option that very few people would want to use would just handicap that company in the sales competition.
It looks like it's possible using Magiclantern open-source firmware for Canon cameras: https://www.magiclantern.fm/fo...
still, they're called film cameras. Nobody can see the pictures before the film is processed, and good luck to find a shop that still processes films nowadays.
Slashdot, fix the reply notifications... You won't get away with it...
If you're not doing anything wrong you shouldn't have anything to worry about. Don't you hate it when people say that?
The lack of encryption means high-end camera makers are forcing their customers to choose between putting their sources at risk, or relying on encrypted, but less-capable devices, like iPhones.
Or, you know, pulling the memory card out of the camera and hiding it.
I've seen wifi SD cards for cameras, so it should be easy to have your high-end camera send it's pictures to your smart phone, tablet, etc. as soon as you take it, then the photojournalist can simply delete the local copy on the camera. when your camera is searched, no images are found, they are all on your secure, encrypted smartphone, and who knows, maybe the smartphone could sync with a cloud service to get the images out of the region moments after captured?
Ken
Agreed. The number of folks who are interested in using encryption on a camera is a very very small slice of the consumer base.
I've worked as a photographer in a news organization. Even with my time there, never was there any case for encryption. Having the entire camera industry switch to encryption would be having the 1% of actual use cases drive the cost and performance factors for the 99%.
Lets see one company make a single camera that has encryption. If it sells like hotcakes to news organizations, fine. but I'll be willing to bet that it the sales will be minuscule because it's not a feature that needs to exist for realistic situations.
Warning: Teh poster of this messaeg is lysdexic
You're presenting a false dichotomy and are apparently completely ignorant of the profession. Journalists reporting from crisis & war zones, on violent crime and from regimes with undue process have always been taking risks, and they have always weighed them against the obligation to report the story. It's part of the job, but only a small number of journalists work in this field and are willing to take the risks. Despite all that, dozens of journalists are killed every year while doing their work, just so you can get their news in your comfy living room. You should to tone down your attitude and show respect where it's due.
Good luck when you're stopped by the police/military in some shit-hole country. Encrypted files? No problem, just beat them until they decrypt.
It's not themselves they're trying to protect - if they wanted to stay safe then they wouldn't be in that line of work. They're trying to protect their sources and their evidence.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Wow... just wow. In every conflict on earth you have a side that opposes covering aspects of the conflict at one time or another. According to your bizarre logic journalists could never get any footage from any war zone anywhere without 'taking sides' and 'no longer being journalists'. The world does not work the way you think it does.
By the way, in many cases war correspondents who miscalculate their risks can be happy if they end up in prison. Often they are killed. But I guess the beheading of James Foley by ISIS was just alright from your point of view, because he was 'taking side'. Retard.
> I've always wondered what would happen in such a
> regime if the password you give them doesn't work
> for them because it's biometrically keyed to work
> only for you?
Similar issue: A company I used to work for always but ALWAYS required travel with loaner laptops only. (Didn't matter if it was just to LA, or all the way to China. And, by his own decree, the policy included everyone up to and including the CEO.). All of the important data was on an encrypted partition, with just the basic OS unencrypted. Tricky bit was: we used a split-key system where the traveling employee had to:
1) Plug in his USB key, input the PIN on the USB, and its password on the computer to unlock his half of the key.
then
2) Connect to the company VPN, from which he would fetch the other half of the key, which was only stored in RAM and never swapped to disk.
Only with both parts of the key could the encrypted partition be accessed. And we always suspended VPN access while the employee was en route; making it literally *impossible* for him/her to give up the secured data, even to "rubber hose decryption". If some airport security goon got the notion in his little head that he wanted to see the contents of the laptop, he could go tell it to a real LEO, who could tell it to a judge, who could issue a subpoena or warrant, which our lawyers could fight. The ASG itself could go get bent. That data was OURS, not the employee's, and certainly not the airport's.
It was an issue only once while I worked there. An employee was returning from Singapore & vicinity; and some ASG wanted to see the contents of his laptop. After explaining the situation that the data was privileged and protected to them, our guy actually called up InfoSec, put him on speaker with the airport goon, and reportedly grinned ludicrously as InfoSec told the ASG not just that we wouldn't be unlocking the laptop, but also exactly what we thought of him, his kind, his agency, his "mission", his manhood and the lack thereof, his family and it's canine/porcine pedigree, and so on (Said InfoSec guy had been an army drill instructor in his past. So he had the talent. And I understand that the looks on the faces of the other overhearing travelers was fairly priceless.); with an admonition to not-so-kindly go fuck himself sideways with some rusty farm implements and to call legal if he had a problem and could somehow conjure up the mental wherewithal to operate a telephone himself. The laptop did stay at the airport; but not for long. Legal wrote a nastygram, in blood, on asbestos paper, and delivered by a black raven. And I think it only took about a month or so to get it back.
Imagine all the people...
In 2000 and at the end of their 25th. independence celebrations I took some pics of the Angolan government plane being boarded by some VIP's. :). (Olympus C-900 Zoom)
Within seconds security confiscated my camera.
A good hour later they came back explaining they could not get the film out, indeed they had never seen a digital camera
So I showed them the photo's and deleted the ones' they objected to.
Little did they know or understand I had already taken more pictures on a different card.
A couple of hours later when back in South Africa I undeleted the photo's from the affected card.
I'm afraid these days such won't work any more...
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
It looks like it's possible using Magiclantern open-source firmware for Canon cameras: https://www.magiclantern.fm/fo...
Interesting. But it should be pointed out that the implementation is very badly done from a security perspective. I only spent a few minutes looking at it and found several showstoppers in both design and implementation. Among them:
1. The basic file encryption algorithm is a stream cipher construction using a simple LFSR as the stream generator. This is almost certainly trivial to break; standard LFSRs are in no way designed for cryptographic security. I suspect the LFSR was used for performance, and I'm sure it does in fact perform much better than, say, AES in CTR mode (where AES is used to generate a bitstream XORed with the plaintext in the same way the LFSR output is). While no good stream cipher is likely to match the LFSR performance, there are several that would provide moderate performance and high security, such as ChaCha20 -- or perhaps even a reduced-round variant like ChaCha12 or even Salsa20/12.
Note that someone has contributed an XTEA implementation which is much better, security-wise, than the LFSR but actually slower than AES. If you're going to do that, just use AES.
2. Even if the LFSR-based encryption algorithm were good, it uses 64-bit keys, which is just too small. Oddly enough, when you use the provided RSA mode for asymmetric write-only encryption (decryption can only be done on your PC), the author seems to recommend a 4096-bit RSA key size, which is roughly equivalent to a ~160-bit symmetric encryption key, and which is quite slow. It makes no sense to use such a huge, slow RSA key to protect small symmetric keys.
3. Password hashing uses the same LFSR plus some shifting and masking. Almost certainly insecure, and there's really no reason at all not to use a good password hashing algorithm like Argon2, or at least scrypt.
4. In asymmetric mode, the code appears to use random padding for RSA operations. There are really good reasons for the PKCS#1 v1.5 and RSA-OAEP padding modes that are normally used. It's possible that a very careful analysis of this implementation may show that under certain operational assumptions random padding is okay... but I seriously doubt that any such careful analysis has been done. I would never bother doing anything of the sort and would simply use OAEP. (Or, better yet, avoid RSA and instead use an elliptic curve algorithm -- less tricky to use correctly, faster, smaller keys and even the provides possibility to derive keys from passwords. There's really no reason to use RSA for anything anymore unless you have to interoperate with legacy infrastructure that already uses it.)
5. RSA key generation is done on-device, with the private key written to the SD card, then later deleted. You can't actually delete things from SD cards, not with any confidence. Much better to do keygen off device so only the public key ever exists on the SD.
6. A glance at the RSA key generation code throws up a number of red flags. I suspect the key generation is buggy.
7. I didn't find the random number generator, but given all of the above, I'd be shocked to find that it's actually good. A bad RNG can easily destroy the security of the best cryptographic design.
When I get some time (ha!) I'm going to see if I can get ML running on my 70D and hack together a better version, using Curve25519 ECDH and ChaCha20 with 128-bit keys, with asymmetric keygen done off-device, and a decent PRNG plus the best seeding mechanism available. To make it more usable, I'll see if I can keep the last few dozen per-file keys in RAM, which will allow the photographer to look at the images on the camera, until the camera is turned off. More paranoid users should be able to disable the retention of keys in RAM.
Sounds like a fun project. One which I may or may not get to before 2025 or so...
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It wasn't so bad as you might think. Our lawyers were mostly full-time on-staff. While we brought in dedicated specialists from law firms when needed; for routine matters like griefing ASGs, our salaried guys could generally keep the requite steady stream of bile flowing as part of their 9-5. Also, due to the nature of the business, a number of said lawyers in addition to many of our execs, had contacts in the federal government and knew exactly who to go over-their-heads to, so as to expedite the shit rolling downhill to the ASGs. (Our CEO had had a very bad experience with the TSA not long after it got started... circa 2003 or so... which left him with something of a burning hatred of the agency. So various surliness, circumvention, uncooperativeness, and outright hostility towards it, and the various TLS spinoffs comprising the rest of the ASGs, while not mandatory, was actively encouraged.). Finally, the laptops themselves were insured.
And at the end of the day, the laptop is nowhere near as valuable as the data; and not just for our own sake. For a decent number of our customers, including the part of the federal government we directly dealt with, we were contractually obligated to protect said data. And releasing it to some ASG yahoo was NOT part of those contracts (Not even with the feds.). And the penalties for leaking it would have been well in excess of the cost of eating a laptop, assuming we never got it back and insurance never paid out.
Imagine all the people...