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

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 14:28 Mon 16 Mar     , Jan Lübbe wrote:
> On Mo, 2015-03-16 at 13:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > 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.
> 
> Yes, every SoC is different. But we should be able to use HW features
> when the are available, as sometimes the HW is selected specifically to
> used these security features.

I agree with you we just need to ensure that it work also when we can not
use such HW feature.
> 
> > The other pb I see is this one where and do you plan to store the RO x509
> > the trusted one.
> 
> Sorry, I can't parse this.
where do we store the trusted keys/cert need to be secured or inaccessible
except crypto API
> 
> > 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.
> 
> I should have been more clear: The use case here is to ensure that the
> OTPMK-AES-HW-Key is only available when booting with a correct boot
> chain. It's OK to boot something else (only the OTPMK needs to be
> cleared).
> 
> This is a very different goal from making sure that only correctly
> signed code is executed.
> 
> Both cases need mostly the same verified boot features, only the policy
> (especially what to do on signature errors) is different.
secure boot means in 95% of the case only correctly signed file can be booted
> 
> > 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.
> 
> On MX6 this can be done by the HW. Doing this (without TrustZone) purely
> in SW seems extremely difficult.

if you do not allow console easy, if you do you need to make the memory where
you do store the trusted keys and barebox itself no accessible by any std API
or command

such as md/mw, etc...

yes this will be difficult

Best Regards,
J.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox