encryption - Feature Requests - CHDK Forum

encryption

  • 15 Replies
  • 7228 Views
*

Offline hk

  • *
  • 5
encryption
« on: 25 / June / 2009, 10:26:22 »
Advertisements
I'm completely new to CHDK. Before I spend more time I would like to know if it is possible
at all to encrypt a taken image after the jpg compression and before it is written to the SD
card.  The following steps would be needed:

1. After power on a password must be read from a password file on the SD card.
   Using some sort of hash function a new password is generated from the old one and
   stored in the password file (if possible the old one should be physically overwritten).
   This way it is not possible to calculate the old password from the new one, but
   the user who has  the original password can decrypt all pictures encrypted with the
   child passwords.

2. After the jpg compression is done by the camera software a provided symetric
    encryption routine must be called with pointer/size to the jpg data. Then the camera
    software should continue with writing the data to the SD.

*

Offline reyalp

  • ******
  • 13826
Re: encryption
« Reply #1 on: 25 / June / 2009, 20:32:03 »
You should really define the goals before you worry about the implementation at all. Are you worried about people casually viewing your pictures ? People stealing your camera/card and spreading the pictures on the internet or using them for blackmail ? Law enforcement ? Intelligence agencies ?

In some cases, simple obfuscation would be sufficient. Others will be impractical regardless of the encryption, because they will always be subject to rubber hose cryptanalysis.

There has been discussion and even some work on code (discussed in IRC, I forget who was doing it though) of this but it's difficult for a number of reasons.
There are also some related bugs in the tracker:
http://chdk.kernreaktor.org/mantis/view.php?id=79
http://chdk.kernreaktor.org/mantis/view.php?id=81
http://chdk.kernreaktor.org/mantis/view.php?id=78

We don't currently hook into jpeg processing / saving. I assume that the actual jpeg encoding is not done on the ARM side of DIGIC, because the CPU isn't fast enough. Just iterating over the the raw buffer takes significant time. So significant reverse engineering would be required to even know if what you want to do could be done.

The slowness of the main CPU is a big problem, encrypting a jpeg would take a long time.

In theory, you might be able do block level encryption pretty easily, at least under vxworks which has documented interfaces for the device drivers. However, it's not clear that the canon firmware would survive the additional CPU load. Things might start to time out or break in other ways.

As far as passwords and key management go, I'd strongly suggest you start with some existing, proven system, or at least a good book on the subject. Most people who try to roll their own get it wrong.

The simplest approach would be to encrypt the raw buffer. This would render the jpegs unreadable even with the key (since the jpeg compression is lossy) but you could save the encrypted raw. However, this means you couldn't review your images (rolling your own raw viewer would be possible, but a lot of work), and you'd have the slow speed of raw saving in addition to the encryption overhead.

Don't forget what the H stands for.

*

Offline mx3

  • ****
  • 372
Re: encryption
« Reply #2 on: 26 / June / 2009, 03:17:34 »
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline hk

  • *
  • 5
Re: encryption
« Reply #3 on: 26 / June / 2009, 04:32:53 »
> You should really define the goals before you worry about the implementation at all.
> Are you worried about people casually viewing your pictures ? People stealing your
> camera/card and spreading the pictures on the internet or using them for blackmail ?
> Law enforcement ? Intelligence agencies ?

There was a discussion about it in a photos news group. And because I just got a A590
(which is cheap enough to risk a damage by doing firmware experiments) I
wanted to check whether it is possible. I think encryption would be a nice
feature for many purposes. Because it costs not more than a few lines of code,
I suppose in the near future some manufacturer will include it in their consumer
products for marketing reason and then all the others have to follow. So maybe it's
not worth to do it by a hack if it is very complicated because it will be available
in the future anyhow.

 
> In some cases, simple obfuscation would be sufficient. Others will be impractical

Don't think this would make any sense because a strong symmetrical encryption like
IDEA or AES doesn't need much computing power.

> regardless of the encryption, because they will always be subject to rubber hose
> cryptanalysis.

This wouldn't work if the symmetrical key is encrypted with a public key technique
and the photographer doesn't know the private key (only his agency knows it).


> We don't currently hook into jpeg processing / saving. I assume that the actual jpeg
> encoding is not done on the ARM side of DIGIC, because the CPU isn't fast enough.

If it's not possible to hook between jpg compression and writing to the flash, then it
doesn't make any sense. Once the picture is stored on the flash, it will be practical
impossible to remove it without completely overwriting the free space on the flash.


> Just iterating over the the raw buffer takes significant time. So significant reverse

But encryption of the jpg should be faster. I suppose, most time will take the
memory access and because the jpg is much smaller it should be much faster.
The encryption routine is hold in the cache and should be pretty fast.
 
> The slowness of the main CPU is a big problem, encrypting a jpeg would take a long time.

 
> In theory, you might be able do block level encryption pretty easily, at least under
> vxworks which has documented interfaces for the device drivers. However, it's not

That's not really an option because then you can't read the card with a standard
PC. Only the files must be encrypted, not the file system.

 
> As far as passwords and key management go, I'd strongly suggest you start with some
> existing, proven system, or at least a good book on the subject. Most people who try
> to roll their own get it wrong.

The encryption part isn't the problem. The problem is to be able to modify the data
after jpg compression but before writing to the flash.

 
> The simplest approach would be to encrypt the raw buffer. This would render the jpegs

Is it possible to modify the raw buffer before the jpg compression starts?
 
> unreadable even with the key (since the jpeg compression is lossy) but you could save
> the encrypted raw. However, this means you couldn't review your images (rolling your
> own raw viewer would be possible, but a lot of work), and you'd have the slow speed
> of raw saving in addition to the encryption overhead.

Encrypted raw files aren't an option for a normal user.


Re: encryption
« Reply #4 on: 26 / June / 2009, 05:38:11 »
saving a key on the sdcard is not neccessary, we just have to finally implement the keyboard. or if that isnt done, we could use a sequence of key presses.
anyhows, it IS possible, but somebody gotta do it ;)

Re: encryption
« Reply #5 on: 26 / June / 2009, 05:47:45 »
btw: http://www.canon.co.jp/imaging/osk/osk-e3/index.html
it should be possible doing something like this. information about this osk-e3 is very rare in the internet. i wonder why ;)

*

Offline hk

  • *
  • 5
Re: encryption
« Reply #6 on: 26 / June / 2009, 07:28:33 »
Ailurus fulgens wrote:

> saving a key on the sdcard is not neccessary, we just have to finally
> implement the keyboard. or if that isnt done, we could use a sequence
> of key presses.

No, that wouldn't be an option. If you first have to enter a password
before you can take pictures, then the camera becomes unusable. The best
way would be, to generate a random password after power on for a symmetric
encryption algorithm like AES, encrypt this password with a public key algorithm
(the public key can be stored on the SD card) and then add the public
key together with the encrypted AES key as comment in the jpg header.
Also the encrypted jpg data is stored as comment only in the jpg file.
As actual jpg data a small picture is added, which only displays:
"This picture is encrypted". This way the SD card can be read on any
PC, but all you see is a picture with "This picture is encrypted". A play back
in the camera is only possible for pictures taken since the last power on
(because this AES key is still available in the camera), for any older
pictures you also get just a picture with "This picture is encrypted".
 

But for a start it would be sufficient to do it without the pubic key
encryption by generating new passwords by applying a hash function to the
old password.

> anyhows, it IS possible, but somebody gotta do it

That's easy to do for the camera manufacturer, but I don't know whether
it can be done within the CHDK project.



   
> btw: http://www.canon.co.jp/imaging/osk/osk-e3/index.html
> it should be possible doing something like this. information about
> this osk-e3 is very rare in the internet. i wonder why Wink

There is no information on this Canon web page which encryption they
use so you shouldn't trust it too much.

*

Offline reyalp

  • ******
  • 13826
Re: encryption
« Reply #7 on: 26 / June / 2009, 17:08:38 »
You are going about this completely backwards. Define what you need, then worry about the implementation.

If you can't define what you need, then you probably don't really need it.
Don't forget what the H stands for.


*

Offline RaduP

  • *****
  • 908
Re: encryption
« Reply #8 on: 28 / June / 2009, 03:21:23 »
AFAIK, you also need a PRIVATE key, not just a public key to do the encryption. So the private key must be stored somewhere in plain text, either on the SD or in the camera itself (but then you'd need to flash some new firmware).

*

Offline hk

  • *
  • 5
Re: encryption
« Reply #9 on: 29 / June / 2009, 05:53:43 »
reyalp wrote:

> You are going about this completely backwards. Define what you
> need, then worry about the implementation.
>
> If you can't define what you need, then you probably don't really need it.

I have clearly defined what I need:

1. On power up I need to read the content (16 byte) of a file stored on the
   SD card (the encryption key) and replace it by a new one.

2. When a picture is taken, I must be able to access the already jpg compressed
   picture data before it is written to the SD card. I must have write access
   to this data, but (in a first step) it is not necessary to change the size
   of the data.


That's all I need. I don't need any help in the encryption part, neither
why to do it nor how to do it.

 

Related Topics