[DONE] Optional Image Encryption

Started by Se7eN, January 13, 2014, 09:25:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Se7eN

Quote from: g3gg0 on January 15, 2014, 11:03:00 PM
this

i bet when you get a gun pointed right onto your head, you will give out the key.
well, this is a drastic example. but there are coutries where you have to be afraid of some kind of punishment.

if you ever find yourself with images on your card that someone is willing to shoot you over, it's then somewhat likely that if they see the photos they'll still shoot you, or perhaps just imprison you forever.

1%

Yea its not likely they would know. If you're up against serious people maybe. NSA/MI5/FBI might know but Thuggee McThug in Egypt won't know and neither would random policeman.

Password prompts, large numbers of unreadable files and suspiciously similar preview images might arouse suspicion from less tech savy tho. All in all its a good idea in general.

g3gg0

ok the first EXPERIMENTAL version is here
beware that this will destroy any footage you shoot and could even kill your camera etc.
business as usual.... dont cry :)

supported models:
- 600D [not tested]
- 7D [tested]
- 5D3 [CR2 tested]

how it works:
- enable modules ime_base, ime_rot, trace and io_crypt
- on startup you get an IME dialog that asks for your password
- enter it using the wheel/SET and press Q to jump to OK and press SET
- any file created (JPG, CR2, MOV) will get encrypted (BUT MOV PLAYBACK WILL CRASH!!)
- any of these files being read, will get decrypted using your password

hints:
- if the password doesnt match, you get an error message that the image could not be shown
- if decoding was successful, a few files usually get cached - even changing the pass will still show you a decoded image
- you can set another password from the debug menu -> "Enter crypt password"
- image reading/writing will be noticeable slower
- currently uploading a youtube video



currently there is no PC-decrypter, its just an in-camera experiment, so dont complain please.
also the encryption method is not final and will change, so you can not decrypt these images some time later...
so only use it for tests!
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Michael Zöller

neoluxx.de
EOS 5D Mark II | EOS 600D | EF 24-70mm f/2.8 | Tascam DR-40

Se7eN

Quote from: g3gg0 on January 16, 2014, 02:04:48 AM
ok the first EXPERIMENTAL version is here
beware that this will destroy any footage you shoot and could even kill your camera etc.
business as usual.... dont cry :)

supported models:
- 600D [not tested]
- 7D [not tested]
- 5D3 [CR2 tested]

how it works:
- enable modules ime_base, ime_rot, trace and io_crypt
- on startup you get an IME dialog that asks for your password
- enter it using the wheel/SET and press Q to jump to OK and press SET
- any file created (JPG, CR2, MOV) will get encrypted (BUT MOV PLAYBACK WILL CRASH!!)
- any of these files being read, will get decrypted using your password

hints:
- if the password doesnt match, you get an error message that the image could not be shown
- if decoding was successful, a few files usually get cached - even changing the pass will still show you a decoded image
- you can set another password from the debug menu -> "Enter crypt password"
- image reading/writing will be noticeable slower
- currently uploading a youtube video



currently there is no PC-decrypter, its just an in-camera experiment, so dont complain please.
also the encryption method is not final and will change, so you can not decrypt these images some time later...
so only use it for tests!

This is amazing! thanks for all your hard work g3gg0!

-Se7eN

Alex135

While I am not an active participant on the forums most of the time, I am a regular reader and follower of the development of ML and use ML regularly. (Almost religiously ;-) )
G3gg0, you have done an outstanding job on this. I have not tested it myself but from the video it already shows a lot of practical application uses. I never thought about on-camera encryption and locking out of images, but this is fantastic. A secondary partition or saving the files somewhere in a hidden directory in the ML folder or similar that looks like misc files from the camera's OS would do even better if the card was taken out of the camera to be searched. Sure there would be some large files in weird places, but nobody would be able to open them and likely as not nobody would care. Just a thought on if it is practical or not.

A standard format of encrypted CR2 files or JPEG would be good to have documented in a format other than what is easily recognized by most. I am thinking similar to the ML DNG format that is being implemented for RAW recording.  (Conceptually ofcourse. A documented standard "encrypted.*ML crypt file extension here*" type of file. )

As a photographer/videographer that currently works for an organization that works in restricted access countries I can safely say this would be of huge use to myself. Much easier than using a live linux USB distros to move data onto hidden encrypted hard disk partitions... still would be done but makes on-camera files much safer.

Keep up the good work guys.

g3gg0

thanks :)

but i need testing and feedback.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

blade

This may be a big thing for a lot of people. I myself do some ubex, and hiding some foto's may be usefull.  However this would be a killer option for e.g. journalists etc. I attempted a test, however, as stated it does not work a 650D.

I will keep up to date  on this tread and test a version if it is available for my camera.

eos400D :: eos650D  :: Sigma 18-200 :: Canon 100mm macro

fbaux

EOS 100D.101 (2018-02-27) + Canon EF-S 18-135mm f/4-5.6 IS + Canon EF-S 55-250 f/4.0-5.6 IS II + Eye-fi card

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

1%

On 7D.

Module on, enter password -> can see pics taken, can't see unencrypted pics
module off -> can't see encrypted pics, can see normal ones

Also get an underflow error from the memory back end.

g3gg0

Quote from: 1% on January 19, 2014, 08:23:15 AM
Module on, enter password -> can see pics taken, can't see unencrypted pics
module off -> can't see encrypted pics, can see normal ones

thanks for testing. thats how it works currently.
no autodetection if a file is encrypted or not.
if a file is crypted, it just contains some garbage with a (repeating) 64 bit xor crypt key that changes every 4k.

i am currently experimenting with RSA and plan to generate the key not from a passphrase, but from random numbers.
then i have to save that key into a RSA encrypted block.

this means:
- no password to be entered
- every picture taken is encrypted using a random cipher key (still the symmetric cipher as before, based on 64 bit, 4 tap LFSR and XOR)
- every file has a sidecar file that gets encrypted using the "public" RSA key
- this sidecar file contains the file's symmetric, random cipher key
- to reveal the symmetric cipher key, you have to use the "private" RSA key which should be on your computer at home only

as this means you can not decrypt the file in camera (you cannot review the files anymore) i plan to also add modes that allow you both being used in parallel.
maybe caching the key until camera gets restarted, or a function to save the keys protected with a password if you want to review it later.

mode a) "paranoid": all gets encrypted using RSA+LFSR-XOR in realtime. if you take a shot, you cannot view them in the camera anymore.
mode b) "relaxed": like paranoid, but the decryption keys stay cached until you poweroff the camera
mode c) "normal": all gets encrypted using LFSR-XOR in realtime. you have to enter a password on startup.
mode d) "casual": files are not encrypted. with a menu entry called "encrypt all files", you can encrypt the files


Quote from: 1% on January 19, 2014, 08:23:15 AM
Also get an underflow error from the memory back end.

uhm any idea where it comes from?
whats the message?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Quote from: g3gg0 on January 17, 2014, 04:36:07 PM
thanks :)

but i need testing and feedback.

It seems as if nightlies are now being updated again for the 60D so I will test it out after work today and post the results.

g3gg0

it will only work for 600D, 7D and 5D3
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Ah ok. Is that due to system specs or just not enough development done yet for the 60D?

g3gg0

i did not dig into the 60D binary yet, where to add the hook poins.
will tonight look into it if its the same and then add the addresses.
(per model we need 3 values. two memory addresses and one size)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

Alex135

Quote from: g3gg0 on January 20, 2014, 03:04:52 PM
i did not dig into the 60D binary yet, where to add the hook poins.
will tonight look into it if its the same and then add the addresses.
(per model we need 3 values. two memory addresses and one size)

Ah, alright, that makes sense. I don't know much about the specifics of the ML coding so forgive my ignorance. Either way I will await your update and be sure to test it out once it is up.

One of these days I will find the time to dig around in the ML code.

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

larrycafe

glad to see progress in this thread, I just don't know why I am not getting any positive comment in my previous post. thanks g3gg0, looking forward to see it going to 60D.

rubixcom

This is such a great feature. Can't wait to try it.  ;D

My 2 cents with regards to deniable encryption; storing sensitive/secret images inside least significant bits of raw sensor data part of a CR2 file seems like the best option to me.

So the scenario might be:
1) Photographer fills his card with CR2 images.
2) He/she enables "stealth mode" and provides a password.
3) Any photos taken from that point are shot as JPEGs only but are not actually saved as new files, instead they are stored within least significant bits of sensor data inside existing CR2 files. Which CR2 files are modified could be determined by the encryption algorithm or selected by the photographer. Image data would also have to be encrypted (or at last stripped of common headers/identifiers) before being stored so that the noise would appear random.
4) If the camera or memory card is taken away and inspected, all CR2 images simply appear to contain an amount of random noise as you would expect in a CR2 file.
5) Photographer gets home and copies the files to his PC where he uses a separate application to extract the images.

Since CR2 files are huge, it might even be possible to store a few different low res JPEGs inside to allow the photographer to reveal 1 or 2 sacrificial passwords if the interrogators become suspicious that stenography is used.

Also, if not possible to do this in real time, perhaps a script to hide secret images could be developed and run adhock from the ML menu.

And while on the subject of security; how about another script to fill unused space on the card with random noise so that deleted pictures cannot be extracted later with photo recovery software.

Thanks to all hard working devs,
Alfred

g3gg0

Quote from: rubixcom on January 23, 2014, 08:26:58 AM
My 2 cents with regards to deniable encryption; storing sensitive/secret images inside least significant bits of raw sensor data part of a CR2 file seems like the best option to me.

okay this is then cryptography + steganography.
quite advanced, but anyone is invited to help with the development to make it happen ;)
its not *my* project - its an open source project and i try to give all the chance to help with improving/adding such features.

so anyone - provide me a "uint32_t cr2_inject(char *cr2_filename, char *jpg_name)" and i will embed it ;)

Quote from: rubixcom on January 23, 2014, 08:26:58 AM
And while on the subject of security; how about another script to fill unused space on the card with random noise so that deleted pictures cannot be extracted later with photo recovery software.

already considered that - this is especially important for the mode c) "casual" which alows you to call "encrypt all files now" mode that will run for an hour or so.
in this case all images already were written plain to the memory card and could potentionally be restorable using simple tools. (photorec)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

rubixcom

Quote from: g3gg0 on January 23, 2014, 11:50:35 AM
so anyone - provide me a "uint32_t cr2_inject(char *cr2_filename, char *jpg_name)" and i will embed it ;)

Happy to give it a go :). But, being quite unfamiliar with CR2 file structure, ML source code and having not touched C++ in 13 years, it might take me some time.

I am guessing that to implement this properly, you'd need to:
1) Extract only the Huffman compressed DCT data from the source JPEG. The reason for this is to reduce the chance of anyone brute forcing the password until they detect any common JPEG structures or image sizes within the decrypted data. The obvious downside of stripping these headers would be that image parameters such as image size, colour format and etc would not be stored. The user would have to supply those while extracting the images. Also, a non-easily identifiable method of storing the Huffman tables would also have be devised.
2) Encrypt this data using the password supplied.
3) Extract raw sensor data from target CR2 as a bitmap (I image that there should be code for this at dcraw)
4) Store encrypted data inside the least significant bits of the pixels from the bitmap image decoded from the CR2 raw sensor data. The pixels that are modified would have to be dispersed throughout the image in a random fashion based on a part of the password. If sequential pixels are modified instead, an attacker may notice an increased amount of noise in the certain areas of the image.
5) Re-compress and save the CR2 file (I imagine ML would have some utilities for this) ensuring that the created/last updated timestamps are not updated.

The user must also be forced to give at least a 10 character password otherwise the whole thing is still quite vulnerable to brute force attacks.

This would need to be done properly as people tend to (perhaps foolishly) put a great deal of faith in encryption.

Thanks,
Alfred

g3gg0

i would not use C++ for that.
could be possible with modules, but never tried. ;)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!

g3gg0

Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!