Improvements to FIT ciphering

[Philippe REYNES <philippe.reynes@softathome.com>]

Hi Patrick,

Sorry for the late answer, I was very busy in the beginning of september

>> 
>> I agree that IV should be set in the FIT.
>> 
>> So in the dts, we may have:
>> cipher {
>> algo = "aes256";
>> key-name-hint = "aeskey";
>> iv = "aesiv";
>> };
>> or (I propose) :
>> cipher {
>> algo = "aes256";
>> key-name-hint = "aeskey";
>> iv-name-hint = "aesiv";
>> iv-in-fit;
>> };
>> 
>> I think that both solution should work ...
>> 
>> Have you planned to implement this change/feature ?
>> (otherwise I will try to found some time for it,
>> it is a really nice improvement).
> 
> Hi Philippe,
> 
> here is what I had in mind, in the .its we would put:
> 
> cipher {
> algo = "aes256";
> key-name-hint = "aeskey";
> };
> 
> when mkimage processes this it opens /dev/urandom to generate a unique
> IV. It then uses this IV to perform the encryption and writes it IV to
> the .fit image like so:
> 
> cipher {
> algo = "aes256";
> key-name-hint = "aeskey";
> iv = <0xa16e090c 0x7e116bf8 0x75c44329 0x3278c74d>;
> }
> 
> I don't think there is a need for a "iv-in-fit" property and
> "iv-name-hint" can be deprecated.

I think that we should keep the compatibility with previous code.
If a company/project has started to used iv in the u-boot device tree,
may be they want to continue without changing the format.

Idea 1:
if there is a property "iv-name-hint" in the FIT image, mkimage uses
the old format, and put the iv in the u-boot device tree. Otherwise,
mkimage generate a random iv an put it in the FIT image (recommanded solution).

Idea 2:
We manage four cases according to the properties in the its file:
- property "iv-name-hint" and no flag "iv-in-fit" :
  => the iv is static and added in the u-boot device tree (actual scheme)
- property "iv-name-hint" and flag "iv-in-fit" : 
  => the iv is static and added in the FIT image
- no property "iv-name-hint" and no flag "iv-in-fit" :
  => the iv is generated and added to the u-boot device tree
- no property "iv-name-hint" and flag "iv-in-fit" :
  => the iv is generated and added in the FIT image (recomanded scheme)


>> > However, if adding "hashed-nodes" and "hashed-strings" properties to
>> > the image signature is acceptable we can still support signing
>> > ciphered images with no problems.
>> 
>> I think that everything should be added to the signature. I think it's
>> simpler and more safe.
>> 
>> Have you planned to implement this/propose a patch please ?
>> (of course, if not, I will try to found some time)
> 
> Unfortunately right now it is crunch time at $DAYJOB to meet a
> deadline by the end of September, so I don't have much (if any) time
> to dedicate to working on U-Boot right now.
> 
> There are actually five issues on my list to address in U-Boot/mkimage:
> 
> * mkimage needs to generate encryption IV using /dev/urandom
> * FIT image signatures need to include cipher node
> * AES-GCM cipher support
> * mkimage -B option doesn't zero padding bytes
> * mkimage -B option unnecessarily pads the end of the image

I've got a lot of work too,  so I can't do all those features.
But I'll try to work on the (random) IV generation and set it in
the FIT image.


> I was planning on working through these when I get time, but I have
> not started on any of them yet. So, if you have time (and energy),
> please, go ahead :)

I'll do my best to start this work.

 
> Best regards,
> 
> Patrick

Best regards,
Philippe