ipmi password storage

[Joseph Reynolds]

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

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
>
>