Image encryption - General Discussion and Assistance - CHDK Forum  

Image encryption

  • 2 Replies
  • 2136 Views
Image encryption
« on: 14 / February / 2011, 05:05:15 »
Advertisements
Dear disassembler overlords,

I'd like to encrypt pictures I take as detailed below, like many before me (2008,2008,2009,2010). I am willing to spend time and knowledge in ARM related C and inline ASM programming (including ECC, RSA and AES on ARM). I however don't think I'll find the time to master disassembling the missing stubs, event routines or callbacks. Therefore I am asking for help. Before asking questions let's detail what I thought ...

Feature description
Add an "encryption mode" toggleable via <alt>-menu with the current state displayed in OSD. If encryption mode is enabled unencrypted media (picture,video) must not reach persistent storage (prefer temporary failure of device over failure to encrypt). Encryption happens per file with assymetric cryptography using one or more public keys stored on the SD card, so that they can be read only by the owner of the corresponding private keys. File metadata (size, data, ...) need not to be encrypted.

Threat model
Storage medium is stolen or copied. The camera is power-cycle before being maliciously accessed. Malicious tampering with device or SD card prior to this event shall not be considered. Neither should be the loss of the private key.

Crypto protocoll (scetch)
Just for the record, the correct protocoll seems to me (choice of symmetric stream cipher and assymetric cipher intentionally left blank):

As soon as there is noise in the VRAM (at first image or earlier):
1. Generate enough strong random bits from physical noise (image)
2. Generate a symmetric cipher key (S) from these random bits; store it (expanded) in RAM as long as the device is turned on
3. Load the asymmetric key (P) from the SDcard and use it to encrypt the symmetric key; store the result in RAM
4. Init a PRNG using some random bits

For every image (N):
4. Generate a new symmetric key S_N using our PRNG
5. Encrypt S_N with S and store the result in a file accompanying the media file
6. Store the media payload using S_N (simple stream cipher or block cipher, if required by access pattern)

On encryption speed
One AES cycle (128 bits at a time) on ARM costs on the order of 1000 cpu cycles. The slowest AES throughput I have ever seen on an ARM cpu in practice was 2.7 Mbit/s. I blindly hope that the DIGIC IV in my posession is somewhat faster. In combination with small file sizes, encryption is no obstacle to a decent performance (say save a picture in a second). On the other hand using the raw pictures is simply too much data to be useful.

Key question
Is there any way to access the generated media files (e.g. jpegs) in memory before it gets written to sd?


Without looking at the Canon firmware or DIGIC architecture I assume (from similar setups I know) that the coprocessor handling the compression signals (or is polled for) completion of JPEG-encoding the image (or a part of it) and the ARM processor than issues a DMA command to transfer from RAM to SD (after some filesystem mangling). What is known already about this (presumably) short execution path? I have read about DryOS drivers in this forum .. might they offer the neccessary hooks? Block-level encryption (instead of file-level) would be fine.

I have more questions, but there is no point to bother with them until the question above is settled.

So long, thanks to all devs for letting me put my code on my camera.

*

Offline c10ud

  • ***
  • 245
Re: Image encryption
« Reply #1 on: 14 / February / 2011, 06:51:46 »
all the buffers are accessible in memory before they get written (specifically, in my camera seems like the jpg buffer is a 15mb buffer where data is appended and the camera holds a pointer to the last jpg added...while the raw buffer are, well, raw buffers :)).

in this thread ( http://chdk.setepontos.com/index.php?topic=6104.0 ) i was just trying to find a method for inhibiting the camera from saving them directly (so we could decide what to do with them -- e.g. save only DNG or modified raw or, as you say, encrypt data and then write..) but no luck so far.

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Image encryption
« Reply #2 on: 14 / February / 2011, 14:06:24 »
On encryption speed
One AES cycle (128 bits at a time) on ARM costs on the order of 1000 cpu cycles. The slowest AES throughput I have ever seen on an ARM cpu in practice was 2.7 Mbit/s. I blindly hope that the DIGIC IV in my posession is somewhat faster. In combination with small file sizes, encryption is no obstacle to a decent performance (say save a picture in a second). On the other hand using the raw pictures is simply too much data to be useful.
In case it matters, note that CHDK mostly runs in thumb mode to save RAM. Platform code that interfaces with Canon firmware is in ARM mode. If in doubt about performance, you can probably cook up some dummy code to benchmark before you put full effort in implementation. One kind of related thing you can already look at is RAW->DNG conversion. DNG write takes quite a bit longer than RAW even though there's really not that much going on there (most of the time difference comes from reversing byte order, I believe).

all the buffers are accessible in memory before they get written (specifically, in my camera seems like the jpg buffer is a 15mb buffer where data is appended and the camera holds a pointer to the last jpg added...while the raw buffer are, well, raw buffers :)).

in this thread ( http://chdk.setepontos.com/index.php?topic=6104.0 ) i was just trying to find a method for inhibiting the camera from saving them directly (so we could decide what to do with them -- e.g. save only DNG or modified raw or, as you say, encrypt data and then write..) but no luck so far.
Even if you couldn't inhibit saving, you could clear the buffer before it is saved on the SD card if a suitable hook exists or can be added. Not ideal, but at least this it wouldn't be a show stopper.

 

Related Topics