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?
There go your photos... but then the powers that be can't prove you were taking pictures of the super-secret-government-coverup and hopefully would be less likely to send journalists to a dark hole.
Think about it... If you were searched by border patrol in a fscked up country and you were taking pictures of things that "no one is supposed to know about". What would you prefer: a smashed camera, or blatant evidence of actions which would definitely put your life in danger.
The goal of computer science is to build something that will last at least until we've finished building it.
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
> 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.