BMC update via TFTP

[Alexander Tereschenko]

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'd be happy to help out with elaborating details of the scheme, if 
that's deemed interesting enough for wider audience.

regards,
Alexander