BMC update via TFTP

Vernon Mauery vernon.mauery at linux.intel.com
Fri Dec 6 09:37:08 AEDT 2019


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.




More information about the openbmc mailing list