[RFC 3/4] FIT: add FIT image support

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:19 Mon 16 Mar     , Jan Lübbe wrote:
> Hi Jean-Christophe,
> 
> On Fr, 2015-03-13 at 17:08 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 16:41 Fri 13 Mar     , Jan Lübbe wrote:
> > > On Fr, 2015-03-13 at 15:28 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > It's not the job of barebox to define security policies, it must fit
> > > > > well into the larger security design, which may require compromises.
> > > > 
> > > > I disagree, disable by default non secure feature is require to pass
> > > > secure boot certification
> > > 
> > > Is there a specific certification you are targeting?
> > 
> > yes but can not give details all under NDA, a book of more than 500 pages
> > for bootloader/linux/kernel & co
> 
> OK, that's unfortunate. Still I'd like to have some documentation on the
> overall design of Barebox's verified boot. That doesn't mean you have to
> write it all by yourself. ;)

I'll already pass the certification but it's a nightmare.

I wish to have a mainline version that can pass it
> 
> > > How do you intend to handle console access in verified boot mode?
> > > Allowing access to md/mw would break any security.
> > 
> > it's already mainline for month, check password support
> > 
> > as I put it in production more than 1 years ago
> > 
> > or simple disable input console all time, the code is here
> 
> So currently we have:
> 1) use password
> 2) disable console
console enable
but require a password to unlock

I've on an other hw HMAC for envfs to ensure envfs is not tempenred with.
I've on an other HW where we encrypt in in AES CBC or AES-XTS (this one not
yet in production in qualification)
> 
> Later I'd like to have optional support to switch barebox into a
> "non-secure" or "developer" mode at runtime, which would make hardware
> secrets inaccessible. That could be triggered when a prompt appears or
> when booting for a different source (such as USB fastboot).

yeah, I like the idea but for this will have to put a lot of protection so you
can not read/write some part of the memory included barebox itself (in RAM)

As in the kernel we have no memmory protection from the shell.
> 
> > the main problem is not console but env you need to drop RW env support
> > and use only RO one, except for keyring support where you will a RW env but
> > not executable and only accesable by crypto API
> > 
> > otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support
> > to sign the env at runtime and ensure the symetric key is secured
> > or encrypt it via aes (did this in the past)
> 
> For an upcoming project we'll add HMAC support to the state storage Marc
> recently submitted.
I've a patch too I need to send it

but I prefer to wait we have keystore support as this will store the key for
the HMAC otherwise we need to use HW HMAC that store the key in the soc

> 
> > ww may have to get secured malloac with part where the md/mw and any other
> > API can not touch only the crypto API
> > 
> > but this will be for later
> 
> Yes.
> 
> > I'll send a patch to use the pbkdf2 for password
> 
> Nice.

Best Regards,
J.
> 
> Regards,
> Jan
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>