EFI_TIME in DBX's EFI_VARIABLE_AUTHENTICATION_2

[Flickdm]

This is a follow on discussion / documentation for #157.

As a quick recap!

Microsoft uses a timestamp of 2010-03-06T19:17:21Z in the EFI_VARIABLE_AUTHENTICATION_2 for UEFI DBX Payloads.

The format of EFI_VARIABLE_AUTHENTICATION_2 can be broken down like so:

[EFI_TIME][WIN_CERTIFICATE][SIGNATURE][DATA]
    |            |             |        |
    |            |             |         `---- Variable Size
    |            |              `------------- Variable Size
    |             `--------------------------- Fixed Size
     `---------------------------------------- Fixed Size

 Where SIGNATURE = Asn.1 `SignedData` object or `ContentInfo` object
 And DATA = EFI_SIGNATURE_LIST

For more information see:

• UEFI Spec
• Signature

The edk2 code performing the validation for the authenticated variable can be found in the function: VerifyTimeBasedPayload (..)

In the case of an APPEND operation the timestamp is not verified and is checked in the case of a SET

if ((OrgTimeStamp != NULL) && ((Attributes & EFI_VARIABLE_APPEND_WRITE) == 0)) {
    if (AuthServiceInternalCompareTimeStamp (&CertData->TimeStamp, OrgTimeStamp)) {
      //
      // TimeStamp check fail, suspicious replay attack, return EFI_SECURITY_VIOLATION.
      //
      return EFI_SECURITY_VIOLATION;
    }
  }

Because the DBX may have multiple servicers via the KEK the timestamp during a APPEND operation is not checked thus enabling multiple servicers.

Some python tooling to create signed payloads can be found in edk2toollib

One thing to note is that the attributes are used to create the signature.

        # This is the digest being signed that all signer's must sign
        self.digest_without_payload = (
            name.encode("utf_16_le")
            + guid.bytes_le
            + efi_attributes.encode()
            + self.authenticated_variable.time.encode()
        )

Since the attributes are in the signature the firmware should disallow any attempt at using an APPEND payload as a SET payload.

Many OEMs attempt to create security features that would differentiate themselves from their competitors. These security features often take dependencies on consistent behavior that we would be likely to break. Thus we're unlikely to change this date until we start signing with the new certificate.