Re: [RFC 2/4] Add rsa support

["Jan Lübbe" <jlu@pengutronix.de>]

On Fr, 2015-03-13 at 11:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:10 Fri 13 Mar     , Jan Lübbe wrote:
> > On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > Having an ASN1 parser for DER/x509 is a huge amount of complexity I
> > > > would not want in a bootloader. Just take a look at the problems the
> > > > SSL-CAs and browsers had with different interpretations of the same
> > > > cert.
> > > 
> > > der is nothing few under lines
> > 
> > Sorry, I can't parse this.
> > 
> > > x509 a few more as it's based on DER
> > 
> > Could you show me that code?
> let me finish to clean it
> and rebase it

Sure.

> > > > The FIT format (and corresponding public key in the bootloader's DT) has
> > > > been adopted by depthcharge and u-boot, because it handles the
> > > > requirements and nothing more.
> > > 
> > > if you want to add this format you can but via the keychain loader not in the
> > > code as today you do have soc such as imx that store the key in OTP as DER
> > 
> > The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over
> > a table of "super root keys". This is irrelevant for barebox, as this is
> > already handled by the ROM code.
> it's does as you can use it as hw IP to check the kernel

RSA checking in HABv4 (i.e. MX6) is done in software by the ROM code.
For the first step we should only support RSA in software to keep the
complexity down.

> yes you store a hash but you do can use it in barebox.

Yes, you could use it in barebox. What is the use case where you would
do this instead of having the key compiled-in (and verified together
with the code by the ROM)?

> other SoC (i can mention the name NDA) does store the key in the OTP of the
> SoC programmed at production time of the SoC itself.
> with HW RSA accelerator

OK, please leave HW RSA as a future step.

> > > and u-boot is not the best reference EVER.
> > 
> > Depthcharge is much more relevant here, as it's used as a coreboot
> > payload on chromebooks.
> 
> does not make it more relevant is the term of key format
> 
> the Standard are x509, PGP and der/pem for ages
> 
> and as said we can support it but make it the only one NO WAY

I'd prefer PGP to x509 anyway. ;)

If we can have x509 and FIT (with key in DT) without too much additional
complexity and have each optional at compile time, I'm not against it.
I'll wait for your code.

> > > > What is your use-case for which you need to add keys at runtime?
> > > 
> > > simple you want to allow user to put their own key
> > > or use a CA to handle allowed key
> > >
> > > if you want to replace grub this is critical
> > 
> > We have customers which require that do not allow runtime loading of
> > keys. So it should be possible to disable runtime loading at compile
> > time. 
> yeah of cource but the feature need to be here IMHO

OK.

> and honestly to respect the opensource if you allow this you MIGHT be
> compliant with GPLv3

s/compliant/non-compliant/ ?

How you need to handle that in practice depends on the context of the
whole system.

> it's more user friendly
> For my own customer I always recommand to have a board uniq key that you
> can provide to each end customer upon request to it can install it's own
> linux. Even if the key is not replaceble.

Yes, that's nice if the production work flow in the factory can do this,
but it's not always possible.

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 |


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