Re: [RFC 2/4] Add rsa support

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

On 11:43 Fri 13 Mar     , Jan Lübbe wrote:
> 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)?

yes let the rom code handle it if you want, it will be a HW implementation
specific to IMX with HABv4

The framework must not be limited to FIT only but FIT is just one of secure
boot supported
> 
> > 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.

The current framework is already ready for this mostly
> 
> > > > 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. ;)
I do prefer PGP too but unfortunately it's not a flexibal format
> 
> 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/ ?
compliant we had layer checking it for one of my client in the pase, I'll ask
for the result
> 
> 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.

if you use x509 you can

you just need to have a unique ID on the HW and then use a x509 object to
store it. then signed it with you CA. As only validated keys can be used,
you can easly give a generated key for a specific HW.
And this key will be valid only for this HW.

Already did it in the past

on u-boot and barebox

Best Regards,
J.

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