Of all the gin joints in all the towns in all the world, Blibbet had to walk into mine at 11:14:29 on Wednesday 09 September 2015 and say:
> I have some questions about UEFI and the below excerpts from NIST > SP-147, from sections 3.1.1 and 3.2. > > Is this "gold master image" possible with UEFI? Are any enterprises > practicing this? What tools are they using? I can't any information on > any enterprise who does this today. > > I currently doubt it is possible with UEFI, given how little information > -- by UEFI Forum, IBVs, OEMs or IHVs -- is provided to system owners on > how to backup/restore their BIOS. At least I can't find any info so far. > > Can anyone point me to a case where an organization can "assert greater > control" or "actively participate in the update process", like below? > > Most of the security in these guidelines are based on crypto, yet I've > yet to find a CRL or OSCP URL by an IBV/OEM/IHV for any of their UEFI > signed code. > > Can anyone point to a case where someone is able to test the security of > this signed code? > > How can "multi-party control" with below PKI if the enterprise can't > even access the original keys? > > I could see the below with UEFI in a fully-open source firmware > scenerio. But all UEFI IBVs are closed-source, and Intel's FSP is > closed-source, so I don't see how mainstream UEFI-based systems can be > used with 147 enterprise guidelines. > > If anyone can point to any more info on this, please speak up. > > I'm giving a talk to some sysadmins on integrating SP-147 with UEFI > along with traditional hardware lifecycle models on Thursday... :-) Oh sure, no pressure. As you say, the closed source nature of most BIOSes makes complying with these requirements nearly impossible for most organizations. The only exceptions I can think of are big companies with connections to the IBVs (e.g. Intel, Microsoft) or the government/military. Something tells me none of them will in any rush to talk to you though. :) -Bill > Thanks, > Lee > RSS: http://firmwaresecurity.com > > ----snip---- > > Some organizations may wish to assert greater control over BIOS updates > in high-security environments. The authenticated update mechanism may be > designed to permit organizational control over the update process, where > updates to the BIOS or rollbacks of the BIOS to an earlier version are > permitted only if the update or rollback has been authorized by the > organization. For example, specific BIOS images could be authorized by > an organization by countersigning them with an organization-controlled > key, which would be verified during the update process. > > Provisioning Phase: > It is crucial that the organization institute a mechanism for > identifying, inventorying, and tracking the different computer systems > across the enterprise throughout their life cycle. Identifying and > monitoring the BIOS image characteristics such as manufacturer name, > version, or time stamp allows the organization to perform update, > rollback, and recovery. The organization should maintain a “golden > master image” for each approved system BIOS, including superseded > versions, in secure offline storage. > If the platform has a configurable Root of Trust for Update (RTU), the > organization needs to maintain a copy of the key store and signature > verification algorithm. If the RTU is integrated into the system BIOS > then this guideline is satisfied by maintaining the golden BIOS image. > If the RTU is not integrated into the system BIOS, the security afforded > the RTU should be at least as strong as that for the golden BIOS image. > Most organizations will rely upon the manufacturer as the source for the > authenticated BIOS. In this case, the organization does not maintain any > private keys, and the RTU contains only public keys provided by the > manufacturer. Where the organization prefers to participate actively in > the BIOS authentication process by countersigning some or all approved > system BIOS updates, the RTU may contain one or more public keys > associated with the organization. In this case, the organization must > securely maintain the corresponding private key so that the next BIOS > update can be signed. Private keys should be maintained under > multi-party control to protect against insider attacks. For > organizational keys, the corresponding public keys must also be > maintained securely (to ensure authentication of origin). > > Operation and Maintenance Phase: > Where the organization participates actively in the update process, the > multi-party control process must be executed to retrieve the private key > from secure storage and generate the digital signature. The BIOS > installation package should also be signed, and the digital signature > should be verified before execution. Once the update has executed > successfully, the configuration baseline should be validated to confirm > that the computer system is still in compliance with the organization’s > defined policy. > > Disposition Phase: > Before the computer system is disposed and leaves the organization, the > organization should remove or destroy any sensitive data from the system > BIOS. The configuration baseline should be reset to the manufacturer’s > default profile; in particular, sensitive settings such as passwords > should be deleted from the system and keys should also be removed from > the key store. If the system BIOS includes any organization-specific > customizations then a vendor-provided BIOS image should be installed. > This phase of the platform life cycle reduces chances for accidental > data leakage. > > ----snip---- > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, [email protected] | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
