All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vernon Mauery <vernon.mauery@linux.intel.com>
To: Alexander Tereschenko <aleksandr.v.tereschenko@linux.intel.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: BMC update via TFTP
Date: Thu, 5 Dec 2019 14:37:08 -0800	[thread overview]
Message-ID: <20191205223708.GC9613@mauery.jf.intel.com> (raw)
In-Reply-To: <94b297b5-81d1-1e07-498f-155a9160cb1d@linux.intel.com>

On 05-Dec-2019 12:05 PM, Alexander Tereschenko wrote:
>On 04-Dec-19 22:36, Vernon Mauery wrote:
>>Even if the BMC only accepts signed images, we want to make sure 
>>that the signed image the BMC fetches is the one that the 
>>administrator *wants* to be fetched. With tftp or http (or any 
>>insecure transport), one possible MiTM attack would be to substitute 
>>an alternate valid image. Let's say the admin wants to go from 1.18 
>>to 1.20, bu the attacker wants to go to 1.16, which has a known 
>>vulnerability. The image would be authenticated by the signature, 
>>and will be accepted.
>
>Thanks Vernon for raising this one - I think this is indeed a valid concern.
>
>So there are essentially two things that we are talking about here, if 
>we peel it a little bit:
>
>1) an additional authorization by the BMC admin of specific images 
>they want to run
>2) plain integrity protection of the file being sent over insecure channel
>
>The first one is a bit different from the second one (and frequently 
>solved by co-signing these days), but in thise specific use case I'd 
>say these two indeed overlap.
>
>In this case, I'd rather suggest us to look into asymmetric crypto, so 
>that no secret sharing/storage (with accompanying additional risk of 
>compromise) is necessary. An admin would sign the image being sent + 
>some context information (like time, to provide replay protection - 
>also applicable to MAC case, otherwise the attacker can trivially 
>replay the file/MAC) and the BMC would check the admin's signature 
>using pre-provisioned public key (send over HTTPS, same as MAC key in 
>your proposal - but only for integrity protection, con confidentiality 
>is necessary) + verify that the context is "fresh" and then use the 
>file.

I am not convinced that it needs to be this elaborate. I don't see what 
it adds over the simple case of sending the key/hmac/uri encrypted with 
TLS to the BMC. There will be no replay attacks because TLS prevents it. 

Maybe I am missing something?

--Vernon

>I'd be happy to help out with elaborating details of the scheme, if 
>that's deemed interesting enough for wider audience.

  reply	other threads:[~2019-12-05 22:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 12:02 BMC update via TFTP rgrs
2019-12-03 16:12 ` Gunnar Mills
2019-12-03 17:08   ` Gunnar Mills
2019-12-03 19:55     ` Adriana Kobylak
2019-12-04 15:47       ` Joseph Reynolds
2019-12-04 21:36         ` Vernon Mauery
2019-12-05 11:05           ` Alexander Tereschenko
2019-12-05 22:37             ` Vernon Mauery [this message]
2019-12-06 14:03               ` Alexander Tereschenko
2019-12-06 22:52                 ` Joseph Reynolds
2019-12-09 16:06                   ` Alexander Tereschenko
2019-12-10  1:25                     ` Joseph Reynolds
2019-12-10 18:58                       ` [EXTERNAL] " Neeraj Ladkani
2019-12-10 21:10                         ` Joseph Reynolds
2019-12-11  4:56                           ` Bonnie Lo/WYHQ/Wiwynn
2019-12-11  5:59                             ` Lei YU
2019-12-11 21:51                           ` Milton Miller II
2019-12-11 11:02                       ` Alexander Tereschenko
2019-12-11 20:17                         ` Joseph Reynolds

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=20191205223708.GC9613@mauery.jf.intel.com \
    --to=vernon.mauery@linux.intel.com \
    --cc=aleksandr.v.tereschenko@linux.intel.com \
    --cc=openbmc@lists.ozlabs.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.