mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: "Jan Lübbe" <jlu@pengutronix.de>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 2/4] Add rsa support
Date: Mon, 16 Mar 2015 12:25:35 +0100	[thread overview]
Message-ID: <1426505135.3330.55.camel@pengutronix.de> (raw)
In-Reply-To: <20150316102713.GB26127@ns203013.ovh.net>

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?

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

  reply	other threads:[~2015-03-16 11:25 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 [this message]
2015-03-16 11:33                       ` Jean-Christophe PLAGNIOL-VILLARD
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=1426505135.3330.55.camel@pengutronix.de \
    --to=jlu@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=plagnioj@jcrosoft.com \
    /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