ipmi password storage

[Vernon Mauery]

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.

>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