I had an email interview with Andrew Regenscheid of NIST, one of the authors of the SP800 BIOS security documents.

Q1: Can you clarify NIST SP80-147’s reference to ‘golden images’ during various platform lifecycle phases? Specifically, does that imply source access to firmware, or is binary-only (‘blob’) ok?

A1: Golden Images

In SP 800-147 and SP 800-155 we end up referring to “golden images” a couple different ways.  They’re related, but a bit different. 

In SP 800-147, the idea was simply to store and use BIOS update images that you trust. The term “image” is perhaps a misnomer, as we were effectively just talking about saving BIOS updates from the OEM, which tend to include both the firmware image itself and the update utility.

We certainly weren’t imagining that you’d obtain sources.  We weren’t even imagining that you’d be able to cleanly separate the firmware code from the update code.

In SP800-155, we referred to golden measurements.  The idea here was to have “known-good” measurements for your firmware.  An easy example here would be the OEM telling you what you should expect to see in PCR-0 (in the TPM) for each system/BIOS version.  If vendors don’t supply this data, you could provision a couple boxes yourself and see what’s in PCR-0.  More generally, you could use other tools to do this from the OS (or a UEFI shell).  Obviously there’s security implications of taking these measurements from an untrusted environment like the OS, but it still might be a useful check. 

Q2:  What about the need for updating the trust in the keys baked into the keys? How does a system administrator verify the keys are still valid, using CRL/OSCP or other methods?

A2:
Key management will largely be driven by the OEM.  System administrators will simply trust whatever trust anchor is baked into the BIOS.  I wouldn’t expect most implementations to make it easy to find the trust anchor.  Theoretically, you might be able to find the public key that’s embedded in the firmware by searching the contents of the system flash, but that’s not going to be easy without knowing where to look.  There’s no API for that.

The idea of blindly trusting the embedded public key might be troubling to anyone that’s followed some of the security incidents at publicly-trusted CAs on the web.  But, I’ll note this is a very different use case.

Your BIOS likely just has a single public key embedded for verifying signatures on BIOS updates.  That key pair should be held exclusively by your OEM, and only used to sign
updates for its BIOS updates.  Your browser, on the other hand, has a couple hundred CA certificates, each of which could issue other CA certificates or web server certificates for any domain online.  The odds of a CA compromise or a need to revoke keys/certificates is much, much higher in the case of Web PKI.

That’s not to say we didn’t think about revocation for BIOS signing keys.  We thought about it, but ultimately decided the best way to revoke a signing key is simply to replace the public key in the next BIOS update.  How else would the BIOS get revocation information?  Online certificate status checking using OCSP seems impractical, since you’re not necessarily going to have network access from the BIOS layer.  Something like a CRL could work, but how would you download it, where would you store it, and how would you protect it?  

To support UEFI Secure Boot (which is completely different from signed BIOS updates), UEFI has its own key store.  That key store includes what is essentially a revocation mechanism (DBX- the forbidden signatures database).  DBX is intended to be updated from the OS, so revocation makes a bit more sense in that case.

You could imagine using something like the DBX for revocation of BIOS update signing keys, but it’s probably a lot easier simply to replace the trust anchor.

Q2.5 – Question on organizational control over BIOS updates

A: OEMs, as the source of BIOS updates, were the natural choice to sign updates, but we thought some organizations would want to authorize updates for their own equipment in addition to verifying those updates came from the definitive source.  To accommodate that use case, we discussed the idea of countersigning in SP 800-147.  The idea was that the OEM would sign the update, as well as the organization.  The update process would verify the authenticity of the BIOS update by verifying the OEM signature, and verify that is authorized by verifying the organization signature.  

Support for countersigning, or other mechanisms to allow organizations to authorize BIOS updates, was never a require part of SP 800-147.  However, we included it because we thought some end users in high-assurance environments would want that level of control.  For most organizations, I suspect the need for administrative access to apply a BIOS update is sufficient.  

I’m not aware of any major OEMs shipping products that support countersigning.  If they did, they would need to provide a way to allow end-users to configure a new trust anchor, and tools for countersigning BIOS updates.  End-users would be responsible for securely managing the signing key used to countersign updates.

Q3: What does it mean to say a vendor is ‘complaint’ to NIST SP800-147?

A3: Compliance

For a vendor to say they are “compliant” with SP800-147, all they really need to be able to assert is their BIOS implementation meets all of the “SHALL” statements in Section 3.1.  The guidelines also include a number of “SHOULD” statements, which are recommended, but not required.  For example, rollback protection is included as a “SHOULD” statement. 
Note that there isn’t a formal certification or validation process for testing that BIOS implementations meet the requirements in SP 800-147.   However, there are tools that can provide some assurances, like MITRE’s Copernicus tool, or Intel’s CHIPSEC tool.

Q4: If you could re-write SP80-147 today, how would you change it?

A4:
I’ve learned a lot about firmware security since working on the original SP800-147. Some of this came when we were rolling out BIOS updates across NIST when our OEMs started offering BIOS updates that added support for BIOS protections.  If I were writing SP 800-147 today, I think my guidance on managing BIOS (Section 3.2 in the current document) would be quite different.  I think it overemphasizes certain aspects of provisioning, and doesn’t emphasize enough the importance of applying BIOS updates.

Researchers are finding problems, and vendors are patching vulnerabilities.  But, a lot of people don’t seem to bother pushing out updates.  Why?  Because it is relatively complicated, compared to pushing out OS/app updates.  It’s gotten a bit better- you ought to be able to just push out a BIOS update utility using whatever patch management tool you have deployed.  Still, it isn’t done very often.

But, at this point I consider SP 800-147 quite stable.  We submitted NIST SP 800-147 to ISO SC27 for standardization under their Fast Track process.  It’s now an international standard as ISO/IEC 19678:2015.

Q5: One of the three NIST BIOS guidance documents is “DRAFT”. When might we see a final draft of that, and/or more BIOS security advise from NIST?

A5: Soon, I hope.  I know NIST SP 800-155, BIOS Integrity Measurement Guidelines, has been stuck as a draft for several years now.  I do intend to publish a final version, but before the document goes final I intend to put out a new draft that includes updates based on public comments on the 2011 draft, as well as new material for server architectures.  That should go out sometime early next year.

In addition, I’m working on firmware security guidelines with a broader scope than what’s in SP 800-147, which only targets the “system BIOS.”  There’s a lot of other security-relevant firmware in computer systems, and I’d like to see that protected as well.  We’re still in the early stages of this work, but I hope to get a new draft document out in the first half of next year.

 

End of email-based interview with Andrew. THANKS Andrew!

Note my comments on NIST ‘golden images’ were incorrect, I was thinking they needed blob-free full source, which is not what Andrew clarifies above.

http://csrc.nist.gov/

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=65998