From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 2/4] Add rsa support
Date: Mon, 16 Mar 2015 12:33:06 +0100 [thread overview]
Message-ID: <20150316113306.GH26127@ns203013.ovh.net> (raw)
In-Reply-To: <1426505135.3330.55.camel@pengutronix.de>
On 12:25 Mon 16 Mar , Jan Lübbe wrote:
> On Mo, 2015-03-16 at 11:27 +0100, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
> > On 11:00 Mon 16 Mar , Jan Lübbe wrote:
> > > On Fr, 2015-03-13 at 16:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > 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.
> > >
> > > Yes, this sounds useful. So you'd have a board-specific way to check the
> > > unique ID constraint in an intermediate cert against the HW ID?
> > yes more or less but but at the key itself as you will have to upload the
> > key to the board. And the key will only be accepted to be stored as it will
> > be valid and have the HW ID.
>
> OK. Sounds good to me.
>
> > And for the record remember if you want to use module in secured boot mode
> > for the kernel you will have to use x509 certificate anyway.
> >
> > So why not to use the same principal.
> >
> > u-boot way is not what is doing today on the market for authentication
> > format. Today it's x509 or PGP.
> >
> > So I do prefer to stay as standard as possible, this does not mean we can not
> > support the FTD stuff. But IMHO it's not the right way.
>
> x509 only defines the certificate format, not how it is used to sign
> kernel, initramfs and device tree.
>
> The kernel defines its own format based on ELF and store the signature
> inside. That can't be reused directly for the kernel itself, initramfs
> or DTB. UEFI has again its own format.
>
> We don't want to sign kernel, initramfs and DTB individually, as this
> would allow an attacker to mix-and-match these to trigger a
> vulnerability. So we need to have some format which supports signing a
> given configuration consisting of specific kernel, initramfs and DTB.
>
> FIT handles this requirement. It also supports having multiple
> configurations (each signed) referencing for example the same kernel
> +initramfs but different DTBs for a set of similar boards.
>
> What is the image format you intend to use with x509 certs?
I'm not talking about FIT format but the key FTD format
I do not like and do not want to use the FTD format to store the key
but x509.
Image format need to be 100% seperated from key format.
That's why I work on a framework so we do not care of both.
Multiple image format with multiple image of key format.
So internally we will store the key in our own format so we can do what we
want.
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2015-03-16 11:33 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 14:39 [RFC 0/4] FIT Support Jan Luebbe
2015-03-12 14:39 ` [RFC 1/4] digest: Make filename arguments const Jan Luebbe
2015-03-13 7:40 ` Sascha Hauer
2015-03-12 14:39 ` [RFC 2/4] Add rsa support Jan Luebbe
2015-03-12 17:47 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 9:35 ` Jan Lübbe
2015-03-13 9:56 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:06 ` Sascha Hauer
2015-03-13 10:12 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:22 ` Jan Lübbe
2015-03-13 10:26 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:10 ` Jan Lübbe
2015-03-13 10:25 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:43 ` Jan Lübbe
2015-03-13 15:49 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:00 ` Jan Lübbe
2015-03-16 10:27 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 11:25 ` Jan Lübbe
2015-03-16 11:33 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2015-03-16 15:42 ` Jan Lübbe
2015-03-17 10:48 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:09 ` Jan Lübbe
2015-03-17 12:39 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-17 12:57 ` Jan Lübbe
2015-03-12 14:39 ` [RFC 3/4] FIT: add FIT image support Jan Luebbe
2015-03-12 18:19 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 9:28 ` Jan Lübbe
2015-03-13 10:05 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 10:21 ` Jan Lübbe
2015-03-13 14:28 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 15:41 ` Jan Lübbe
2015-03-13 16:08 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:19 ` Jan Lübbe
2015-03-16 11:14 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 12:08 ` Jan Lübbe
2015-03-16 12:19 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 13:28 ` Jan Lübbe
2015-03-16 13:51 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:31 ` Jan Lübbe
2015-03-16 14:40 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 14:50 ` Jan Lübbe
2015-03-13 11:33 ` Marc Kleine-Budde
2015-03-13 15:54 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 16:06 ` Marc Kleine-Budde
2015-03-13 17:00 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-16 10:04 ` Jan Lübbe
2015-03-16 10:28 ` Jean-Christophe PLAGNIOL-VILLARD
2015-12-29 10:18 ` Yegor Yefremov
2015-03-12 14:39 ` [RFC 4/4] FIT: add test config and data [do not merge] Jan Luebbe
2015-03-12 14:51 ` [RFC] digest: Add enum Jan Luebbe
2015-03-12 17:50 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 9:54 ` Jan Lübbe
2015-03-13 10:10 ` Jean-Christophe PLAGNIOL-VILLARD
2015-03-13 18:50 ` Robert Schwebel
2015-11-11 11:39 ` [RFC 0/4] FIT Support Yegor Yefremov
2015-11-13 11:35 ` Antony Pavlov
2015-11-13 12:54 ` Sascha Hauer
2015-12-29 8:10 ` Yegor Yefremov
2016-01-05 8:11 ` Marc Kleine-Budde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150316113306.GH26127@ns203013.ovh.net \
--to=plagnioj@jcrosoft.com \
--cc=barebox@lists.infradead.org \
--cc=jlu@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox