BMC update via TFTP

[Joseph Reynolds]

On 12/6/19 8:03 AM, Alexander Tereschenko wrote:
> 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.
...snip...
>> 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
>
...snip...

I was thinking along the lines of adding [SFTP][] (or SCP) support and 
then migrating existing TFTP users to the new secure solution.

That is, the BMC admin performing [code update][] can currently get a 
firmware image via POST DownloadViaTFTP to URI 
/xyz/openbmc_project/software.
My idea is to offer a DownloadViaSFTP method (or preferably a Redfish 
API) for this.  Note that the TFTP download is disabled by default per 
[bmcweb config][].

Once OpenBMC supports downloading firmware via SFTP, we can encourage 
our users to set up their SFTP servers and take down their TFTP 
servers.  I realize that sounds easy, but I don't have a feeling how 
difficult that would be in practice.

Does that sound feasible?

- Joseph

[SFTP]: https://man.openbsd.org/sftp-server
[code update]: 
https://github.com/openbmc/docs/blob/master/code-update/code-update.md
[bmcweb config]: 
https://github.com/openbmc/bmcweb/blob/41d1d1833f476766f88cfb624e66eef7906bdf8c/CMakeLists.txt#L98

> regards,
> Alexander
>
>