Projects and observations

Automatic Encrypting Camera Proof-of-Concept

A collage including people icons in the upper right, a camera icon with a compute chip and key icon included, and an old-style photograph with the image replaced by random text representing an encrypted photo.A few months ago, I ran across a post at Boing Boing by Cory Doctorow in which he relayed the desire of journalists to have cameras that would encrypt images on the fly. The uses for this are many and can protect journalists and also, crucially, those the journalist has documented. Siezed images can be used against people by governments and other agencies. It seemed a pretty sound idea to me.
The post imagines the requirement for new user interfaces on cameras to allow the entering of passphrases and the like. While certainly I don’t think that would be a bad idea, the format of dedicated digital cameras does make it a challenge. Small screens are prone to typing errors when using touch-screen keyboards and the small form factor of most dedicated cameras limit hardware input options. However, what immediately struck me was that no changes really need to be made at all, as long as one crucial trade-off is accepted: not being able to review images on-camera.
Since public key cryptography feels well-suited to the task of encrypting images on the fly, I imagined an interfaceless update to existing cameras that would provide strong encryption but without the need to enter a passphrase or any other information. It is, effectively, transparent.

Here is the system I imagined:

  1. Use a well-known (and thoroughtly vetted) public key crypto package on a computer to generate a keypair
  2. Copy the public key to the removable media used by the camera
  3. Insert the media in the camera, which imports the public key included thereon
  4. All images taken by the camera and written to the media will be encypted by the key included on that media
  5. The key is purged from the camera when the media is removed

In this system, the camera never writes an image to storage without first encrypting it. There is nothing for other parties to recover from the media apart from the strongly encrypted images and the public key – which cannot be used to decrypt the images stored. This does bring up the one tradeoff I mentioned previously – there is no way to view any of the images taken on camera. In practice this should not be too difficult to live with as taking lots of shots to be sure a good one is captured has become standard practice, but certainly this could be an unacceptable tradeoff in some situations.

 

Theory is all well and good, but I wanted to see if this system could be realized in the flesh. Since affordable prototyping platforms abound these days, I decided to build a proof of concept encrypting digital camera.

First, I chose a platform – this was a very easy decision. I went with the Raspberry Pi as it is readily available, has substantial online resources available for it, it very cost effective, and supports a native camera device. It ended up being particularly wonderful that Adafruit (an online retailer of electronics) also had a tutorial and software available to turn the Pi into a ready-to-use point-and-shoot camera — that made this a relatively straightforward project.

A clear plastic box containing a circuit board and camera. A power cable is attached to the top and a removable USB drive to the side.

The Raspberry Pi 3 with camera mounted in a case from Adafruit

Step one was getting the hardware. As I live in the Boston area, I’m lucky enough to have a Micro Center local to me which carried everything I needed. (I used the BOM from Adafruit’s camera build.)

  • Raspberry Pi 3 (the faster processor is good for prototyping and encryption, but a Zero might work)
  • Adafruit touch screen
  • Nifty case for the screen+Pi
  • Pi camera w/cable
  • 64GB USB flash drive (I used one with an A and micro-B connector so it could be tested with a Zero in the future – one could also use an SD card reader with card.)
A black plastic case with an opening for a 2.3" touch screen displaying a "gear" and "play" icon. Four hardware buttons are on the right of the case, a USB drive is attached on the left and a power cable is attached on the top.

The back of the Adafruit case with their touch screen installed displaying the camera UI developed for the linked tutorial.

From there, I simply followed Adafruit’s tutorial until I had a working digital camera. If you’d like to build one of these for yourself, follow Adafruit’s build and then come back for the rest.

Please note that this is intentionally not a detailed tutorial. This is a proof-of-concept project and it is not audited or secured in any way. If you need the protection of an encrypting camera, you’ll need to understand it deeper than following a recipe allows. However, below is a discussion of the steps I followed to implement the camera along with snippets of my custom code. With work and understanding, you’ll be able to re-create my project.

Once I had the camera working, I needed to identify how I would have the system perform the encryption. I chose GPG (Gnu Privacy Guard) because it is well-vetted, available for every platform, includes a Python library (conveniently, the camera software is Python) and already familiar to many. I installed GPG on my laptop and on the Pi and performed a few excercies to familiarize myself with the tool, such as generating, exporting, and importing keys, and encrypting/decrypting files between systems. Once I was comfortable, it was time to automate things on the Pi.

I installed the usbmount library on the pi and created a mount script for my USB device in /etc/usbmount/mount.d. Usbmount allows the system to automatically run a script when a specific USB device or class of device is inserted or removed. An included script ensures that the flash drive is always mounted at /etc/usb0 so I can make sure to put images in the right place. My custom script then automatically imports a GPG key from the “key.asc” file found on the drive into a known GPG homedir. That way the camera script has the key available in a known location later. In addition, I created an unmount script that removes the key from the system once the drive is removed.

Mount Script
#!/bin/sh
mkdir /tmp/gnupg
export GNUPGHOME=/tmp/gnupg
gpg --import /media/usb0/key.asc
gpg --list-keys --with-colons 2>/dev/null| awk -F: /^pub/{print\$5} > /tmp/gnupg/keyid
exit 0
Unmount Script
#!/bin/sh
rm /tmp/gnupg/*
exit 0

After a few rounds of testing, I was ultimately happy that this solution was reasonably robust. To get the key onto the camera, one only has to export it from GPG into “key.asc” and place it in the root of the media. Every drive/card could have a different key if needed, and all could be prepared ahead of time. (In fact, the system containing the private key need not even be in the same country as the camera or even available to the camera user!)

Next, I needed to modify the camera script that was installed as part of the Adafruit tutorial. This turned out to be pretty straightforward. (Though there was a bit of trial-and-error getting the python gnupg package to properly encrypt.) Ultimately, I simply needed to intercept the saving of the image to camera, run the in-memory image through the encryption package instead, and redirect the output to the configured USB drive. Just a few lines of code (mostly to import and configure python-gpg) were needed. Note that I did not take the time to disable alternate saving methods like Dropbox, and I did not test what happens should one try to use them with my script modifications.

#At the top of the file with the other imports:
import gnupg

#I modified the array (~line 260) used to direct where images are stored this way:
pathData = [
 '/media/usb0/DCIM', # Path for storeMode = 0 (Removable Media)
 '/boot/DCIM/CANON999', # Path for storeMode = 1 (Boot partition)
 '/home/pi/Photos'] # Path for storeMode = 2 (Dropbox)
]

#In the takePicture() routine (about line 450) I added these GPG-related lines to
# read the key ID that the usbmount script helpfully stored for us:
gpg = gnupg.GPG(gnupghome = '/tmp/gnupg')
 infile = open('/tmp/gnupg/keyid', 'r')
 gpgTempKey = infile.read()
 gpgKeyID2 = gpgTempKey.rstrip('\n')

#A little further down in takePicture() I intercepted the camera capture
# and writing commands and replaced with this:
camera.capture(camera_image, 'jpeg')
#I found gpg.encrypt didn't play well with the BytesIO() object
temp_image = camera_image.getvalue() 
#encrypts and automatically writes the output to filename
encrypted_image = gpg.encrypt(temp_image,gpgKeyID2,always_trust=True, output=filename) 

A photo inside a building including part of a table-top in the foreground with a wood door and glass door in the background a few feet away.

This haphazard photo of the inside of the Democracy Center in Cambridge, MA was the first encrypted photo to be taken with my camera.

Finally, I had a working Encrypting Digital Camera! Whenever I insert media in the camera that contains a valid GPG key in a file called “key.asc” the camera then begins to encrypt every image taken until the media is removed. On my computer, I can then use the private key (protected by a passphrase) to decrypt the images on the command line and I’m left with pristine* jpgs! (*Well, 8MP noisy JPGs but that’s a function of the mediocre Pi camera, not the encryption!) It’s not exactly fast, though. It took approximately 6-10 seconds to encrypt and write the JPG to disk. Of course, this is a low-powered processor and a single-threaded encryption engine. It is, however, a very successful proof that this system can work.

I have shown that with minimal software changes, cameras can support robust encryption with no changes to user interface at all. I would hope that we see commercial camera producers consider integrating a system like this in the near future. Additionally, I have to wonder if third-party firmware updates (like CHKDSK for Canon cameras) could add such support. At worst, with some effort, platforms like the Raspberry Pi could offer a decent starting point. Of course speed may be an issue until dedicated encryption hardware is added to cameras. I am unclear as to how well-suited the DSP custom processors found in digital cameras could be adapted for encryption tasks (possibly very well!) but in the near future, retrofit software would probably preclude the super-fast capture rates that professional photographers have come to expect.

Now, for the BIG HUGE DISCLAIMER: This is a PROOF OF CONCEPT. While I’m providing some code snippits here so that others can recreate my work, it’s super important that everyone understand that this project has not be audited or vetted by security professionals, nor was it created with the intention of being used in the field. It’s possible that this project could give some level of protection as-is, but it’s also possible that there are glaring errors that would erase any gains or even exacerbate the situation you may be trying to avoid. Please don’t use this in production! (As a note, I have made no attempt to harden the Pi against access, for instance via wifi, ethernet, or USB. It could be trivial to circumvent the entire encryption system via these vectors.)

Powered by WordPress | Designed by Elegant Themes

Pin It on Pinterest

Share This