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

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:08 Mon 16 Mar     , Jan Lübbe wrote:
> On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:19 Mon 16 Mar     , Jan Lübbe wrote:
> > > 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.
> 
> Not necessarily. For example on the MX6 you can trigger a security
> violation in the CAAM from software. That will clear the OTPMK in its
> Key-RAM. From that point on you can run any software but you will not be
> able to decrypt any secret data which was encrypted with the OTPMK.
> 
> On hardware which supports something like this, debugging hardware
> problems is easy and there is no danger of leaking any secret
> information. If something is useful/possible in any specific project
> obviously depends on the threat model and hardware capabilities.

I knonw about the imx6 but that does not mean all the SoC
unfortunatly.

The other pb I see is this one where and do you plan to store the RO x509
the trusted one.

if you use on OTP this means this is enough to ensure secured boot as if you
can not modify the primary cert of key. No one can brake it. But as you load
it in ram you need to be sure no one modify it. Even in unlock mode to do only
allow to boot secure images by expected key.

So you may not have secured place to store the cert or key in ram but only
RAM. so we do need to forbidden this memory acces to everyone except the
crypto API. if we want ot allow dev mode.
> 
> > > > 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
> 
> For environment or state storage?
envfs
> 
> > 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
> 
> Another possibility is to use the HW AES key and a compiled in value to
> derive a per-device HMAC secret. The same approach can also be used in
> Linux for deriving the IMA/EVM HMAC secret.
this for me need to be integrated in the keystore to be transparent for the
rest of the API

Best Regards,
J.