Axiom Cryptocamera
Open, WishlistPublic


Many of my filmaking friends come from nations where they could get arrested if they get cought at the wrong time with the wrong material on their cameras memory. In the magiclantern forum there have also been discussions about encryption (including one draft for on the fly encryption of footage). This is a serious topic because a mistake here can seriously harm people's lifes.

I will propose an idea I had a while ago:

OTP encryption
OTP is short for One time pad. This is a form of encryption used in the cold war by both sides. It works like this: you convert your message to binary, then you count the number of digits and for each digit you throw a dice. You note down the outcome of those dice throws (this is your one time pad). You give your friend a copy of your One time pad. Now you XOR the bits of your message with the bits stored in the OTP. You destroy the OTP. The only person able to decypt your data is your friend now (by doing another XOR).

The OTP is mathematically the most secure encyption there is, because you would have to do a brute force as big as the message which makes no sense, because even if you get a decrypted message which would make sense, you had no way to proof that this was what the original message stated (like the infinite number of typing monkeys who will by chance write all works of Shakespeare).

The OTP has two preconditions for reaching that level of safety:

  • it needs the best random numbers one can get. In the cold war they had whole halls filled with women dicing and noting down random numbers. Today one could use a cryptographically safe enough PRNG or a TRNG if paranoid enough.
  • the OTP may never be reused (each OTP needs to be a new patch of random generated numbers)
  • the OTP needs to be stored safely

A camera implementation would work like this:

  1. At home we generate sufficient quality random bits to fill our memory cards with the OTP. We store a copy of the OTP at home and leave it there.
  2. When we record video the camera reads a chunk of the OTP exactly the size of what it would save, XORs the recorded image with the chunk and saves the XORed version on the memorycard in place of where the OTP chunk once was (for this we obviously need some kind of reference where in the memory our last read and write was)
  3. Now we end up with a encrypted data stream, that looks completely random and can only be decrypted when we are at home. Even if someone would force us, we couldn't decrypt it, before going home (which might be a different nation). If this is implemented cleverly it could make the cards look like they are just empty.
  4. At home we XOR our Memory Cards with the OTP and get back a video.

This technique has the upside of beeing as safe as the key storage is. It obviously has the downside that one cannot review the footage while on the trip. Also one needs to have a bigger memory capacity with themselves as they wan't to record in total.

Additional ideas

  • The noise of the Axiom sensor could be used as a source for a TRNG, generating the bits on a trustworthy camera and not on a system with a potentially compromised or weak PRNG.
  • Ways to only encypt and hide certain clips (plausible denyability)?
  • I had trouble multiple times on various borders of the world with cameras. Why? Because customs people wanna fuck with you. Especially if they see a shiny looking camera which has a even more shiny "4K" written on it. "4K is new, you can't fool us, you have money". Maybe one should investigate making a really old and shitty looking DV-camera enclosure for the Axiom?


  • How to produce potentially a Terabyte of quality random numbers without statistical skew and error?
  • How to protect data integrity? One-time pads don’t assure integrity. It’s easy to flip bits: preventing this requires a MAC function. Or some kind of periodic hash against which the OTPs integrity can be compared
  • How to store the current position of the OTP pointer? Is there some on camera memory which could be used?
d0 created this task.Feb 27 2017, 12:06 PM
d0 updated the task description. (Show Details)
d0 raised the priority of this task from to Wishlist.
d0 added a project: Brainstorming.
d0 moved this task to Backlog on the Brainstorming board.
d0 added a subscriber: d0.
d0 updated the task description. (Show Details)Feb 27 2017, 12:09 PM
d0 updated the task description. (Show Details)Feb 27 2017, 12:39 PM
d0 updated the task description. (Show Details)Feb 27 2017, 12:47 PM
d0 updated the task description. (Show Details)Feb 27 2017, 1:17 PM
d0 added a comment.Feb 27 2017, 1:33 PM

The generation of true random numbers may actually stop this idea from beeing practical. A (open) hardware TRNG like the infnoise is capable of producing 259000 bits per second. To fill a Terabyte (8*10^12 bits) this would take roughly a year Maybe one should seriously consider a different approach. Edit: with something faster like the Bitbabbler one comes down to two weeks per Terabyte. If one had multiple TRNGs time would go further down. This however means: People need to get one or multiple TRNGs. People need to plan ahead (which film people usually do). The thing has to be working and save.

Maybe a more classical symmetrical encryption technique would be better here? Or something like full drive encryption, Veracrypt style?

RexOr added a subscriber: RexOr.Feb 28 2017, 3:56 AM
d0 added a comment.Feb 28 2017, 12:16 PM

Given that the Camera has a linux running on it, the easy mode on this would probably be to use something like cryptsetup. No need to invent the wheel new.

jatha added a subscriber: jatha.EditedFeb 19 2018, 2:31 PM

i think aes256 would be much more practical to use. with otp one would need to store twice the data, which is not very practical in terms of bandwidth and storage price.
Moreover, when crossing borders with footage, one would most likely carry both storage mediums (the footage and the key), which would make the encryption useless. when using aes, we could encrypt the key with a password and therefore keep the footage secure, even if all the storage mediums are confiscated.

I think aes256 with high bandwidth would be quite doable on the fpga, the axiom contains. there are even some hardware open source implementations available on opencores :).