Re: AMD Microcode Signature Verification Vulnerability

[Solar Designer <solar () openwall com>]

On Wed, Mar 05, 2025 at 11:50:45PM -0600, Jacob Bachmeyer wrote:
> On 3/5/25 23:34, Solar Designer wrote:
> > The real issue is the use of CMAC without understanding its properties,
> > not the key choice.
>
> The fact that it is called a "key" (and not a "public key") should be 
> the hint that it must be kept secret, which means do not use an example 
> value, just like you do not set your password to "password" or your PIN 
> to 1-2-3-4-5 unless you really mean to have no security on that system.

... or you mean not to use this specific authentication factor, relying
on some other(s) - like the console being protected physically.  A risky
thing to do ("what can possibly go wrong?"), but the analogy is there.

> > Indeed, HMAC wouldn't be any weaker than its underlying hash on its own
> > even when used with a publicly known example key.  So I can see how they
> > could have (wrongly) expected the same from CMAC.
>
> If the system is no weaker if the HMAC key is known, then you should not 
> be using HMAC and you should be using a plain digest instead.  (Or am I 
> missing something?  What would HMAC with a known key give you that a 
> plain digest does not?)

My point is that sometimes a building block you readily have or can
create most cheaply provides excessive functionality, or so they
thought.  Perhaps they could implement CMAC-AES easier than implement
SHA-256 (if they already had AES, but not yet SHA-256), and thought it's
as good as an HMAC.

Alexander