Re: ipmi password storage

[Vernon Mauery <vernon.mauery@linux.intel.com>]

On 14-Apr-2020 05:18 PM, Joseph Reynolds wrote:
>On 4/14/20 2:11 PM, Vernon Mauery wrote:
>>On 14-Apr-2020 06:27 PM, Alexander Tereschenko wrote:
>>>To be more specific, I'm considering two attack scenarios in the 
>>>below comments:
>>>1) The attacker gets into BMC and is able to copy off the data 
>>>files, including ipmi_pass. This IMHO is a more realistic scenario 
>>>in this case.
>>>2) The attacker gets ipmi_pass file/contents only, without being 
>>>able to retrieve anything else.
>>>
>>>Which ones do *you* have in mind? For the sake of discussion, it 
>>>would be helpful to specify them all and see how potential 
>>>solutions address them.
>>
>>Attack one is the most likely, since if you can read one file, you 
>>can probably get any/all of them.
>
>An alternate solution is to make those file readable only by root, 
>restricting root logins, and restricting SSH access in general.  See 
>https://github.com/ibm-openbmc/dev/issues/1528

Changes have been made already to restrict permissions to 0600. The 
problem is that currently that is not much of protection at all because 
all the processes run as root right now anyway.

--Vernon

>In this way, only an admin can get the files by enabling the SSH 
>interface, logging in via SSH, and using su or sudo to access the 
>files.  All of these events should be audit-able.
>
>- Joseph
>
>>
>>>On 14-Apr-20 01:00, Vernon Mauery wrote:
>>>>Possible Solution
>>>>=================
>>>>Migrate to a solution that uses a key that is longer that does 
>>>>not get written directly to the flash
>>>>1) S is now computed instead of hard-coded. S=HMAC(MachineId, AppID)
>>>
>>>I like the direction and the guiding principle, however from 
>>>"proper" cryptography standpoint, for producing keys, this is not 
>>>noticeably better than the previous solution. The key material is 
>>>still readily available on the filesystem (making points #3 and #4 
>>>irrelevant for attack scenario #1), so chances are that the 
>>>adversary who can pull /etc/ipmi_pass file, can also pull 
>>>/etc/machine-id one. In addition (but that's really a nitpick in 
>>>this case with all these much bigger problems + easy to fix), 
>>>plain HMAC is not a proper and recommended key derivation 
>>>function, an HKDF or one of the NIST constructs from SP800-108 
>>>should be used instead.
>>
>>Cool. I did not know about HKDF. I will look into that.
>>
>>>>2) S is longer (32 bytes instead of 8)
>>>This (and #4) only helps the attack scenario #2, where attacker 
>>>has to brute-force all possible values for S - and I believe that 
>>>scenario is less realictic. But yes, case #2 gets a bit better 
>>>than before, if we disregard the fact that HMAC is not a proper 
>>>KDF and that MachineID is not a proper cryptographic key material 
>>>[1, last paragraph in Description suggests that], which may 
>>>provide additional advantage to the attacker. BTW, machine-id has 
>>>at most 128 bits of entropy (if produced by a proper CSRNG, which 
>>>I'm not sure about - e.g. I see they do some formatting), so 
>>>practically it's not 32 bytes, but 16 [at most].
>>
>>Yes, this was mostly a minor point. And yes, the entropy in S is 
>>limited by machine-id, but either one is better than a hard-coded 
>>8-byte ASCII string :)
>>
>>>So while this new approach does provide some advantage for 
>>>scenario #2, it doesn't address a more important case of #1 and to 
>>>me it still looks like low security. The proper way here is indeed 
>>>to get some capability for storing the keys securely, but I see 
>>>how this is hard to impossible on AST2500 (if that's what we're 
>>>talking about here), without TrustZone or anything similar, or 
>>>some sort of ROM/bootloader-accessible-only part-unique secret, so 
>>>OTMH I can't propose any viable alternatives for a given context 
>>>(brownfield deployment, backward compatibility), but I'll think 
>>>more about that.
>>>
>>>[1] https://www.freedesktop.org/software/systemd/man/machine-id.html
>>
>>Really, I don't see a real solution without some kind of secure 
>>storage, which we don't have at this time on the ast2500. While that 
>>is not the only machine running OpenBMC, ideally the solution would 
>>be platform independent so that any machine could do it. Maybe that 
>>requirement would be that it supported some minimal cryptographic 
>>features or something (like trustzone support). But in the meantime, 
>>some sort of solution that security researchers will not rake us 
>>over the coals for would be nice. Maybe there isn't one. Some 
>>minimal configuration that is better than writing the passwords in 
>>plain text.
>>
>>--Vernon
>>
>>
>