Back on September 18th, UEFI Forum posted a press release (found here) talking about how the number of adopting companies had topped 250, including Huawei, the Linux Foundation and Novell. They also mentioned their new white paper "UEFI Secure Boot in Modern Computer Solutions" by Brian Richardson and my former colleague, Dick Wilkins which gives an excellent overview of the state of the industry on this sometimes controversial topic.
The Linux Foundation news plays well with the fact that the UEFI Plug Fest was co-located with LinuxCon in New Orleans this past week. Linux-as-business has generally come to terms with UEFI and its secure boot strategy. Linux-as-religion may never come to terms with it. Every major Linux distribution supports UEFI secure boot, including SUSU Labs, who spoke at the Intel Developer's Forum two weeks ago, describing their infrastructure for extending secure boot from the UEFI hand-off up through loading the kernel.
What does this really mean? UEFI continues to expand the range of platforms and operating systems on which it can create a powerful pre-OS boot environment. And the UEFI specification is making orderly progress in addressing the needs of the people who ship systems and those who produce code that runs on those systems.
Showing posts with label Secure Boot. Show all posts
Showing posts with label Secure Boot. Show all posts
Monday, September 23, 2013
Saturday, September 21, 2013
UEFI 2.4 Review, Part 13: Hash of Certificates Used for Secure Boot Revocation
This article is the thirteenth in a series describing the changes introduced in the UEFI 2.4 specification. This time we focus on improvements to the secure boot technology. Specifically, the updates make it easier for UEFI firmware to be notified about malware UEFI drivers and applications.
In the UEFI 2.2 specification, the idea of a white list and a black list was created. Drivers whose signatures were found in the white list would be allowed to load and those found in the black list were not loaded. The white list signatures were recorded in the EFI variable "db" and the black list signatures were recorded in the EFI variable "dbx".
In the UEFI 2.3 specification, the list of signature types was expanded to allow X.509 certificates, which allowed UEFI drivers and applications to be signed by trusted certificate authorities so that anyone who was signed by that certificate authority could be loaded by UEFI firmware. There were other enhancements to allow new, authenticated EFI variable contents to be appended to an existing EFI variable without having to resign the entire EFI variable. This made distributing updates from, say, an OS or driver vendor, easier once they were already trusted.
But one of the problems with adopting the X.509 certificate was size. Each certificate required 1-2KB. This might not seem a lot in the age of terabyte drives and gigabyte DRAMs, but for UEFI firmware it is a lot to set aside just for security. In particular, as malware becomes more and more real, the need to add more UEFI drivers or UEFI driver-signing certificates to the black list started creating concerns about how much space would need to be set aside and, in some cases, when the space was full, UEFI firmware would be in the unfortunate situation of having to reject new black list entries.
Now, in the UEFI 2.4 specification, three new types of signatures for the black list were added. Specifically, the various recommended forms of the To-Be-Signed hash value (160, 256 and 512-bits) which are created during the creation of a certificate could be added to the black list instead of the certificate itself. Since it is very hard to create another certificate which corresponds to the same hash value, it is nearly identical, security-wise to use the hash value instead of the certificate itself. The bonus of this approach is that hash values for certificates range in size from 20- to 64-bytes, a big improvement over the 1-2KB needed for the certificate itself.
As an added bonus, these new certificate types also have a timestamp field, which allows the UEFI firmware to determine whether the UEFI driver or application was signed before the revocation date of the certificate. The revocation date is the time at which the certificate was identified as having been compromised. By checking the time stamps of the certificates in the UEFI drivers or applications against the time stamp of the certificate's revocation. If a UEFI driver or application was signed before that date and time, then it can still be loaded by the UEFI firmware since the certificate had not yet been compromised. If the UEFI driver or application was signed after that date and time, it might be malware and should be rejected. This generates less thrash for the IT department or OEM in having to update every single executable image ever signed by that certificate.
The timestamps used in these certificates are created and compared by procedures described in RFC3161. With this information, the time stamps can be compared with an integer compare.
Then the question arises: who gets to generate the time stamps? Well, it turns out that there are time stamp authorities, similar to certificate authorities, that issue signed time stamp certificates. When checking the time stamps, their authority must have its signature registered with the UEFI firmware, in a new authetnicated EFI variable called "dbt".
UEFI OS' must be able to get the updates to the UEFI firmware in the field so that, as more malware comes along, and more certificates are compromised in some fashion, the UEFI firmware will be up to date and able to handle these threats, well after the systems are shipped and used in production environments. UEFI 2.4 keeps the industry ready for the ever-evolving challenges of securing the boot, from reset through OS runtime.
In the UEFI 2.2 specification, the idea of a white list and a black list was created. Drivers whose signatures were found in the white list would be allowed to load and those found in the black list were not loaded. The white list signatures were recorded in the EFI variable "db" and the black list signatures were recorded in the EFI variable "dbx".
In the UEFI 2.3 specification, the list of signature types was expanded to allow X.509 certificates, which allowed UEFI drivers and applications to be signed by trusted certificate authorities so that anyone who was signed by that certificate authority could be loaded by UEFI firmware. There were other enhancements to allow new, authenticated EFI variable contents to be appended to an existing EFI variable without having to resign the entire EFI variable. This made distributing updates from, say, an OS or driver vendor, easier once they were already trusted.
But one of the problems with adopting the X.509 certificate was size. Each certificate required 1-2KB. This might not seem a lot in the age of terabyte drives and gigabyte DRAMs, but for UEFI firmware it is a lot to set aside just for security. In particular, as malware becomes more and more real, the need to add more UEFI drivers or UEFI driver-signing certificates to the black list started creating concerns about how much space would need to be set aside and, in some cases, when the space was full, UEFI firmware would be in the unfortunate situation of having to reject new black list entries.
Now, in the UEFI 2.4 specification, three new types of signatures for the black list were added. Specifically, the various recommended forms of the To-Be-Signed hash value (160, 256 and 512-bits) which are created during the creation of a certificate could be added to the black list instead of the certificate itself. Since it is very hard to create another certificate which corresponds to the same hash value, it is nearly identical, security-wise to use the hash value instead of the certificate itself. The bonus of this approach is that hash values for certificates range in size from 20- to 64-bytes, a big improvement over the 1-2KB needed for the certificate itself.
As an added bonus, these new certificate types also have a timestamp field, which allows the UEFI firmware to determine whether the UEFI driver or application was signed before the revocation date of the certificate. The revocation date is the time at which the certificate was identified as having been compromised. By checking the time stamps of the certificates in the UEFI drivers or applications against the time stamp of the certificate's revocation. If a UEFI driver or application was signed before that date and time, then it can still be loaded by the UEFI firmware since the certificate had not yet been compromised. If the UEFI driver or application was signed after that date and time, it might be malware and should be rejected. This generates less thrash for the IT department or OEM in having to update every single executable image ever signed by that certificate.
The timestamps used in these certificates are created and compared by procedures described in RFC3161. With this information, the time stamps can be compared with an integer compare.
Then the question arises: who gets to generate the time stamps? Well, it turns out that there are time stamp authorities, similar to certificate authorities, that issue signed time stamp certificates. When checking the time stamps, their authority must have its signature registered with the UEFI firmware, in a new authetnicated EFI variable called "dbt".
UEFI OS' must be able to get the updates to the UEFI firmware in the field so that, as more malware comes along, and more certificates are compromised in some fashion, the UEFI firmware will be up to date and able to handle these threats, well after the systems are shipped and used in production environments. UEFI 2.4 keeps the industry ready for the ever-evolving challenges of securing the boot, from reset through OS runtime.
Friday, September 13, 2013
UEFI At IDF13, Part 2: UEFI Secure Boot in Linux
The second session about UEFI at IDF Fall 2013 in San Francisco concerned how UEFI secure boot applies to Linux. This was presented by Vincent Zimmer, my long-time co-conspirator in the UEFI and PI specifications, and Gary Lin and Philip Oswald from SUSE Labs.
From a UEFI perspective, they took the basic secure boot story and showed how this was extended into the kernel, taking into account the roll-your-own philosophy of Linux and the GPL license. Like many other distros of Linux they have adopted the "shim" approach, which is a small signed executable that has been signed by Microsoft's Certificate Authority (or CA, to their chagrin) that, in turn, loads GRUB2. This shim OS loader contains a certificate signed by SUSE Labs, but it also can read another UEFI variable (MOKList), that contains a list of signatures that can be used to verify GRUB2. This UEFI variable is marked both non-volatile (that is, it persists across resets) and boot-service (that is, it can't be used once the full kernel takes control). Attempts to modify this variable directly from under the OS will be rejected by UEFI firmware.
Instead, SUSE's management tools to manage the MOKList contents using another variable (MOKNew) which is encrypted. During the next boot, the presence of this variable will be detected, its contents verified, and then MOKList will be updated. This tool can be run by any Linux sysadmin.
The SUSE kernel then uses either the SUSE key or the MOKList contents to verify all kernel drivers. This allows the chain of trust to extend from the firmware, all the way up into the Linux kernel. The MOKList insures that the administrator of the Linux system can control which drivers can and cannot be launched on the system, or even which version of GRUB2 can and cannot be loaded by altering the MOKList contents.
UEFI secure boot isn't about locking other operating system's out. It is about making sure we know who they are and, knowing that, whether we trust them. MOKList extends this feature on SUSE Linux (also used on RedHat) allowing the administrator to know which kernel drivers are executing and whether they should be trusted.
From a UEFI perspective, they took the basic secure boot story and showed how this was extended into the kernel, taking into account the roll-your-own philosophy of Linux and the GPL license. Like many other distros of Linux they have adopted the "shim" approach, which is a small signed executable that has been signed by Microsoft's Certificate Authority (or CA, to their chagrin) that, in turn, loads GRUB2. This shim OS loader contains a certificate signed by SUSE Labs, but it also can read another UEFI variable (MOKList), that contains a list of signatures that can be used to verify GRUB2. This UEFI variable is marked both non-volatile (that is, it persists across resets) and boot-service (that is, it can't be used once the full kernel takes control). Attempts to modify this variable directly from under the OS will be rejected by UEFI firmware.
Instead, SUSE's management tools to manage the MOKList contents using another variable (MOKNew) which is encrypted. During the next boot, the presence of this variable will be detected, its contents verified, and then MOKList will be updated. This tool can be run by any Linux sysadmin.
The SUSE kernel then uses either the SUSE key or the MOKList contents to verify all kernel drivers. This allows the chain of trust to extend from the firmware, all the way up into the Linux kernel. The MOKList insures that the administrator of the Linux system can control which drivers can and cannot be launched on the system, or even which version of GRUB2 can and cannot be loaded by altering the MOKList contents.
UEFI secure boot isn't about locking other operating system's out. It is about making sure we know who they are and, knowing that, whether we trust them. MOKList extends this feature on SUSE Linux (also used on RedHat) allowing the administrator to know which kernel drivers are executing and whether they should be trusted.
Sunday, August 25, 2013
UEFI 2.4 Review, Part 2: VendorKeys UEFI Variable
Is the system secure? That's a critical question for the IT department. When UEFI added the secure boot capabilities and Microsoft started using them, it raised quite a stir. It quickly raised the question: who can say who can boot. Well, for most platforms, OEMs (and their BIOS vendors) provide the means for users to change the secure boot policy using the firmware's built-in configuration utility.
That raises another question: did the users do anything? Did they change the secure boot policy? Now that's something my IT department would be interested in. With this new UEFI variable VendorKeys, a simple utility could verify whether something related to secure boot had been verified. If it is 0, it has been modified. If it is 1, it is unmodified.
This variable is not stored in the platform's non-volatile storage, like flash. This may seem insignificant. But variables written by OS applications must be placed in non-volatile storage. If it is not in non-volatile storage, it must have been written by the firmware. That means it cannot be easily spoofed. If it could be spoofed, then an attacker could make it look like nothing had changed. If the attacker could do that, it could prevent an IT application from looking deeper.
Keeping the system secure, and proving it, the UEFI way.
That raises another question: did the users do anything? Did they change the secure boot policy? Now that's something my IT department would be interested in. With this new UEFI variable VendorKeys, a simple utility could verify whether something related to secure boot had been verified. If it is 0, it has been modified. If it is 1, it is unmodified.
This variable is not stored in the platform's non-volatile storage, like flash. This may seem insignificant. But variables written by OS applications must be placed in non-volatile storage. If it is not in non-volatile storage, it must have been written by the firmware. That means it cannot be easily spoofed. If it could be spoofed, then an attacker could make it look like nothing had changed. If the attacker could do that, it could prevent an IT application from looking deeper.
Keeping the system secure, and proving it, the UEFI way.
Friday, September 21, 2012
UEFI/Win8 Security Vulnerability (Yawn...)
Put "UEFI" or "Win8" next to rootkit in an article, as was done by The Register, and you are sure to generate some buzz. Based on a technical report by ITSEC (found here), it talks about how you can install a root kit, if you can get your code loaded so that it can modify the Windows 8 boot loader. As taken apart by Matthew Garrett (analysis here), Linux developer, the rootkit is neither new nor unexpected.
Basically, to quote the rootkit author (Marco Giuliani) in the Register article: "Our research attempts to show the industry that the new UEFI platform is still as insecure as the old BIOS technology, it's still vulnerable to the old attacks if the SecureBoot technology is not turned on by default," [emphasis mine] Which, by the way, Microsoft is requiring every OEM to do as part of its partner program.
So the, how did The Register come up with the tag line, "Arr, 'tis typical: Redmond swabs lag behind OS X, again" Really? I am not sure how Secure Boot lags behind the OS X validation scheme, but this ITSEC report sure doesn't show it. In fact, it seems to me that OS X is pretty much in the same camp as Win 8 when it comes to multi-OS booting.
Basically, to quote the rootkit author (Marco Giuliani) in the Register article: "Our research attempts to show the industry that the new UEFI platform is still as insecure as the old BIOS technology, it's still vulnerable to the old attacks if the SecureBoot technology is not turned on by default," [emphasis mine] Which, by the way, Microsoft is requiring every OEM to do as part of its partner program.
So the, how did The Register come up with the tag line, "Arr, 'tis typical: Redmond swabs lag behind OS X, again" Really? I am not sure how Secure Boot lags behind the OS X validation scheme, but this ITSEC report sure doesn't show it. In fact, it seems to me that OS X is pretty much in the same camp as Win 8 when it comes to multi-OS booting.
Subscribe to:
Posts (Atom)
