BMC update via TFTP

[Alexander Tereschenko]

On 05-Dec-19 23:37, Vernon Mauery wrote:
> 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?

We may be talking about slightly different contexts indeed. I meant to 
suggest something that doesn't require

1) any "out-of-band" channel for each file being sent (signature can be 
appended to the file itself, one-time/infrequent public key updates at 
the BMC side are discounted as arguably negligible). I use the 
"out-of-band" here as "channel different than the one where the file 
itself is being sent";
2) any symmetric secret generation/storage/distribution upon sending 
files (which is an additional burden and risk);

plus

1) provides replay protection;
2) doesn't require major infrastructure modifications (here I'm assuming 
that signing and checking the signature in this flow is less change than 
generating key, MAC and sending them over "out-of-band" channel);

I read your proposal as that the key will be a longer-term one + that 
the MAC will be sent along with the file (as it's not a secret and 
typically it's sent together with the data in such schemes). If you 
meant that both the key and MAC are generated on the fly, are one-time 
and are sent via that "out-of-band" TLS-protected channel, then I'd say 
you don't even need a keyed MAC at all and a plain cryptographic hash 
would suffice. You're sending the key along with the MAC and file 
channel itself is unprotected - so if the adversary can break the TLS, 
they can compute the MAC as easily as a plain hash and if they can't, 
they anyway can't substitute the hash value, so IMHO keyed MAC is 
surplus here.

Maybe outlining a flow (maybe as a sequence/flow diagram) in more detail 
and defining which specific adversaries (and their capabilities) we're 
talking about here would help? I agree we surely don't need a more 
complex scheme if a simpler one suffices, it's just that we may be 
talking about slightly different flows and adversaries right now :)

regards,
Alexander