io_crypt - encrypt your photos while you shoot them

[Levas]

Just wondering.

What happens if I open one of these encrypted files in Lightroom or Canon DPP.
Is Lightroom or Canon DPP asking for a password or encryption key file ?

[msw]

Hi g3gg0,
great to see such a function coming up. However, when it comes to implementing crypto there are a few pitfalls and it seems you didn't manage to stay clear of all of them. I had a quick glance at the code (which is easy to read, good work on that) and with the current state of affairs I'd issue a warning that io_crypt should not be considered as safe unless you just want to hide photos of upcoming christmas presents from your spouse.

The biggest issue I have with your implementation is the selfmade-streamcypher based on the 64-bit LFSR. It just too easy to break. Also using it in the hash function to derive a key from the password (where the password is alphanumeric only and no salt is added) reduces the strength further. Also, you have to add some fresh randomness for every picture or you get the same keystream for different pictures. XORing two encrypted pictures the removes the keystream and returns the difference of the pictures to you.
The next issue is using deterministic RSA. As the symmetric key is only 64 bits (and not 128 as stated in https://bitbucket.org/hudson/magic-lantern/src/703ee626326d7cb310b087a337b9dad2b2d642c4/modules/io_crypt/hash_password.c?at=unified#cl-45) given a series of encrypted pictures an somewhat powerful adversary has a non-negligible chance of guessing a key.
Finally there is no protection against malicious modification of pictures. An attacker may alter some parts of the picture at will. This will likely show up as random noise (instead of some person or object that the attacker wanted removed). But with some sort of message authentication you could at least prove that the manipulation happened after writing the file to the SD-Card.

The great thing is: You showed that it is possible to do on-the-fly encryption on the camera. That is the important part. The next step is putting in good crypto in the right way. Have a look at http://tweetnacl.cr.yp.to/software.html This should compile without much fiddling and can replace your RSA code. (It might be even faster.) For password-based encryption you still will have to find an appropriate function for key derivation. The most common is PBKDF2 and it should not be to hard to adopt e.g. the Code from OpenBSD (http://bxr.su/OpenBSD/lib/libutil/pkcs5_pbkdf2.c).

If you have questions or need any assistance, just drop me a pm. I'd love to see io_crypt mature.

[g3gg0]

hey msw,

thanks for that constructive feedback!

indeed, some of these issues, especially the obviously weak XOR cipher, i already discussed with alex.
i am confident that this encryption is too weak to save lifes but good enough - as you say - to hide things.
especially as this module is experimental and described that the algorithm has weak points, i hoped to clarify its non-mature state.

main concern is still making the encryption more performant.

PBKDF2:
thanks a lot for pointing me to this algorithm. the (true) reason why i didnt implement it yet is,
that i didnt even look for the "state of the art"-algorithm for this task

128 bit:
right, this is a wrong comment. not sure why i left it there.

XOR encryption:
i am totally unstatisfied with the XOR based encryption.
problem is that at the moment i have to encrypt the file content in some random-access file IO routines.
my first approach was building a 64 bit XOR key depending on the key and file offset.
but that CPU is so slow and has to process ~30MiB images with up to 120MiB/s, so i had to play with larger block sizes.
this way i could get from 1MiB/s processing speed to ~20 MiB/s IIRC.
as this is a compromise, i am totally unhappy with it, because compromises are the worst thing when it comes to data security

the best thing (as proposed by alex) would be to decouple the random access code from the encryption code.
so that any file IO is buffered plaintext into RAM and on file close, it will get encrypted and written to the card.
same for opening - the file is read in a whole and decrypted into RAM.
so we could use e.g. CBC to get rid of all the possible attacks possible with ECB.


do you want to jump in? which camera model do you have?
the current problem is lack of time (main job consumes more and more time...) and that i tend to focus things that seem to be of interest.
this encryption experiment didnt bring up many voices that shared their experience in terms of stability and workflow from the userbase.

BR,
g3gg0

[g3gg0]

@Levas:
no, but a LR plugin is possible. just like with dual_iso files.

[msw]

@g3gg0

Have a 60D, but not running ML and don't want to risk (soft)bricking it. I'm low on time too, but I'll keep it on my agenda.

[g3gg0]

yeah, the 60D is a bit sensible. seems some canon issue

[stoopkid]

I would still love to see this in the unified build some day. Are you still working on this at all?

[g3gg0]

its a bit too experimental for mainline, sorry

[stoopkid]

Yeah of course, I'm just wondering if you're still pursuing it or if it's fallen by the wayside.

[g3gg0]

i think its in state "well, it seems to work".
any help is appreciated, as i personally am very busy with work, house and family.

[Sapporo]

I tried to compile this module, io_crypt, but I get errors whatever I do. I already has the io_crypt.mo because I found it online. What I need is the io_decrypt for decrypting the RSA-files.

I followed the tutorial from mk11174 http://www.magiclantern.fm/forum/index.php?topic=6425.0 and did everything as he did, but when I wrote Make I got this instead:

Code: [Select]

magiclantern@magiclantern-VirtualBox:~/magic-lantern/modules/io_crypt$ make
Updated HGVERSION
[ README   ]   module_strings.h
Traceback (most recent call last):
  File "../readme2modulestrings.py", line 113, in <module>
    txt = run('cat README.rst | grep -v -E "^:([^:])+:.+$" | ' + rst2htmlCommand + ' | python ../html2text.py -b 700 | sed "s/\r$//"')
TypeError: cannot concatenate 'str' and 'NoneType' objects
make: *** [module_strings.h] Error 1
Please explain to me as if you would explain to your grand mother or to a child.

[g3gg0]

hm, tried a make clean already?
this error doesnt tell me anything

[Sapporo]

Tried make clean.

During the days I have tried different tutorials on Ubuntu, Windows Msys2, Cygwin. One nice thing is that I fail with different things every time and not always the same thing.

Anyway, today I tried http://www.magiclantern.fm/forum/index.php?topic=7579.0 and failed at nr 27. At 27 I got the same error message as I posted above.

I will try http://www.magiclantern.fm/forum/index.php?topic=7579.msg134989#msg134989 later today or tomorrow.

[nkls]

Seems like the script can't find rst2html, are you sure that it's installed?

[dmilligan]

Those errors come from trying to compile the ML module (you need lots of stuff setup correctly for that, such as the ARM toolchain, python, and various utilities like rst2html). If you don't need the module, and you just want the decrypt utility, try:

Code: [Select]

make io_decrypt


[Sapporo]

Those errors come from trying to compile the ML module (you need lots of stuff setup correctly for that, such as the ARM toolchain, python, and various utilities like rst2html). If you don't need the module, and you just want the decrypt utility, try:

Code: [Select]

make io_decrypt


That made it. It works in the prepacked Oracle thingy on my Windows but I can't get it to work on my Ubuntu 16.04 (64). What is it that my Ubuntu system is missing? Do I need arm-none-eabi-gcc-4.8.3 even on my Ubuntu machine to run io_decrypt?

Code: [Select]

bash: ./io_decrypt: The file or folder doesn't exist
Edit: Maybe because of 64 bit. I will check it.

Edit2: It was because of 64 bit. Fixed. Thank you guys. 

Is there an easier way converting 20 raw files? For example:

Code: [Select]

./io_decrypt {_MG_8457.CR2,_MG_8458.CR2} home/krypterat/a/{_MG_8457.CR2,_MG_8458.CR2}
or

Code: [Select]

./io_decrypt *.CR2 home/krypterat/a/*CR2



[Sapporo]

Fixed it with

Code: [Select]

#!/bin/bash

for i in *.CR2
do
  ./io_decrypt $i /decrypt/$i
done

[dmk]

I'd take a look at stream ciphers which allow random access... Salsa20 might work, I believe you can set the key from any position of 8-byte blocks (and so you can just seek anywhere, get previous block, and ignore the overflow)

[chris_overseas]

Relevant article: https://www.wired.com/2016/12/200-filmmakers-ask-nikon-canon-sell-encrypted-cameras/

Edit: Hacker News discussion here: https://news.ycombinator.com/item?id=13175810

[g3gg0]

very interesting. probably should polish that feature

[DeafEyeJedi]

Absolutely @g3gg0 I'm all for this feature as well and Thanks for sharing the article @chris_overseas!

[crypt()]

Absolutely! This is really good stuff, thx for building this. Chacha20 would be really nice ...

So far this is afaik the most promising implementation in the direction of secure picture storage on cameras.

[g3gg0]

yeah already started with chacha20 (rfc7539) but didn't get far due to lack of time.
if you want to help, please jump in

[g3gg0]

btw the file format is also just experimental.

i tend to do this:
 - only encrypt CR2
 - keep the original file format (more or less)
 - (RSA-mode)embed RSA ciphered keys into comment fields of the file format
 - add dummy image as content
 - append original, encrypted image at the end/comment field

reasons:
 - deniability as all tools see a valid image with uncritical content
 - forensics will for sure find the real image though
 - no jpeg to simplify development effort

modes:
  RSA-mode: random key for every image, asymmetrically embedded into image. no image review. no chance to "hand out" or "expose" the key
  password mode: enter symmetric key on startup. image review possible.  has to get entered every startup

[g3gg0]

with ChaCha20 i get ~4.5 - 4.8 MiB/s
with XTEA its ~0.8 MiB/s
with LFSR it was ~20MiB/s (iirc)