[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250306053416.GA6682@openwall.com>
Date: Thu, 6 Mar 2025 06:34:16 +0100
From: Solar Designer <solar@...nwall.com>
To: Jacob Bachmeyer <jcb62281@...il.com>
Cc: oss-security@...ts.openwall.com, Tavis Ormandy <taviso@...il.com>
Subject: Re: AMD Microcode Signature Verification Vulnerability
On Wed, Mar 05, 2025 at 11:03:49PM -0600, Jacob Bachmeyer wrote:
> On 3/5/25 21:30, Solar Designer wrote:
> >[...] I'll focus on what the vulnerability and its fix are:
> >
> >>[...]
> >>
> >>Forging On
> >>We noticed that the key from an old Zen 1 CPU was the example key of the
> >>NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588
> >>09cf4f3c) and was reused until at least Zen 4 CPUs. [...]
>
> They... used... the... example... key... in... a... real...
> production... system...
>
> [I have no words.]
It appears they didn't realize the key's secrecy would matter for their
use case (or else they probably wouldn't use CMAC in the first place),
so it "made sense" to stick with a "standard" tested key. Given that
misunderstanding, I wouldn't blame them for choosing an example key.
Whatever key, it sounds like the Google folks already had it before they
realized it's an example key from NIST, so the rest of the story would
have been the same with any other fixed key.
The real issue is the use of CMAC without understanding its properties,
not the key choice.
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.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
