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 descriptionAdd 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 modelStorage 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 speedOne 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.
