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.
Cards can protect their contents from erasure or modification, prevent access by non-authorized users, and protect copyrighted content using digital rights management.
Of course, no implementation that I've come across since the format was released over 18 years ago has implemented that highlighted bit.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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?
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
Why? This could be pretty easy.
Just load up a small version of gpg that only encrypts.
Load in your public certificate, and have it encrypt every picture using that.
When you get home you decrypt them.
Except, how will this work if you want to see the photo you just took? Encrypt upon capture with encrypt-only software would prevent the camera user from being able to review the photo they just took until they get to a device that can decrypt them. if you implement encryption such that it is a process the photographer chooses to apply after taking the photo (think of it as a process similar to deleting a photo - you highlight it and select "encrypt", rendering it invisible on the camera), that will leave the photos vulnerable immediately after being taken - you know, like when the soldier grabs your camera right after you snap the photo of the soldier beating up a protester...
Ken
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.
Who could do photography under those conditions!? ;)
Encrypt-only isn't the solution to everything, but it actually might be a better solution to the problem stated in the summary. If you leave the decryption key at home then you can't decrypt it, even under coercion. Plus, if it's in the card, you just swap cards between regular shots and things you think might be sensitive. Provides some plausible deniability too: yeah, here are the pictures I've taken; oh, haven't used that other card yet.
As for looking at the pictures, you couldn't do that in the field with film either. And documentary photographers might look at quiet times for interest sake, but they don't shoot, check the photo, ask the subjects to stand differently, shoot, rearrange.... At least they're not supposed to.
> 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...
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.