ipmi password storage

[Alexander Tereschenko]

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.

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.

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

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