[Feature]: Set EFI_TIME in the DBX's EFI_VARIABLE_AUTHENTICATION_2 to the time when the DBX was updated

[pbatard]

Feature Overview

Per specs, the signed DBXs are of type EFI_VARIABLE_AUTHENTICATION_2 as defined in the EDK2.

This means that, like all EFI_VARIABLE_AUTHENTICATION_2 structures, the signed DBX files start with an EFI_TIME structure that can (should?) be set to the time at which the EFI_VARIABLE_AUTHENTICATION_2 is built.

Looking at the DBX files released in the past few years as well as the secure_boot_default_keys.py in this repository, we see however that the EFI_TIME used in DBXs is always fixed to 2010-03-06 19:17:21 (This is easy to validate by looking at very first bytes of any DBX).

We find this to be problematic because it prevents automated tools dealing with DBXs to validate whether a specific DBX is more recent than another one, or provide feedback to the user with regards to when the DBX was released by simply looking at the file itself. We don't see a valid reason to have the EFI_TIME construct not reflect the time of creation, especially when this seemed the intent of the UEFI specs (or else it wouldn't make sense to add an EFI_TIME struct to EFI_VARIABLE_AUTHENTICATION_2).

Solution Overview

We propose that the following section in scripts/secure_boot_default_keys.py (currently line 288):

    # Microsoft uses "2010-03-06T19:17:21Z" for all secure boot UEFI authenticated variables
    efi_time = EfiTime(time=datetime.datetime(2010, 3, 6, 19, 17, 21))

is changed to:

   efi_time = EfiTime(time=datetime.now())

This way, utilities and people looking at DBXs can immediately determine when exactly they were created, which might also avoid issues with old DBXs being inadvertently used in lieu of newer ones on account that it is not currently possible to validate if a DBX is more recent than another, or matches the release date, by simply looking at the file.

Alternatives Considered

Since we don't really see what prompts the need to use a fixed 15 years old static date, and the request seems easy to implement, we have not considered any alternatives.

Urgency

Low

Are you going to implement the feature request?

I will implement the feature

Do you need maintainer feedback?

No maintainer feedback needed

Anything else?

I am willing to submit a PR for this feature, unless someone can justify the need to set the variable authentication of DBXs to the year 2010.

[kerneis-anssi]

This would prevent rollback: if the date is older, the UEFI should deny the update per the spec:

Unless the EFI_VARIABLE_APPEND_WRITE attribute is set, verify that the TimeStamp value is later than the current timestamp value associated with the variable

https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#using-the-efi-variable-authentication-2-descriptor

Preventing rollbacks may be a desirable feature, but I guess this is the reason why fixed timestamps are used at the moment. It should arguably be explained in the comment you quoted.

[pbatard]

Thanks for clarifying the use of the variable. And indeed I guess we might need to make the case of whether we want rollback DBX capability or not.

I would argue that, since this is a security feature, and DBX updates are ultimately aimed at the general public, we should enable anti-rollback by default, and let people who do need rollback (and who should have Secure Boot Setup capability on the target they plan to install previous DBXs anyway) install their own PK and thus set up their own Secure Boot databases as they see fit. In other words, I don't think allowing rollback to any DBX that was ever released is a desirable feature, when this of course leaves an attacker, who finds a way to issue DBX updates from within the OS environment, with the capability to install and run revoked UEFI bootloaders. Better to be restrictive by default, and then let the subset that needs to be more permissive use other means of enabling rollback, than be permissive by default just for that small subset.

But then again, I am not sure I can envision the scenario that prompted Microsoft to want to enable rollback by default, so I'm open to counter arguments.

[Flickdm]

@kerneis-anssi is correct with his understanding of the spec. Firmware that has the default edk2 implementation actually doesn't check the timestamp if the "APPEND" attribute is set because the idea is that there could be multiple servicers of the DBX (Every KEK) and they wouldn't know what each others timestamp was.

 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;
    }
  }

The timestamp is really only useful in a "SET" operation and then that would protect against rollback attacks.

Now in my experience a change like this has more downsides than upsides. The ecosystem has expected this datetime to be consistent for the last 15 years. Things like doing a DB 'APPEND' in some cases have broken (Bricked) some internal systems in more ways than one because an OEM never expected us to change anything. We're currently working with OEMs to get them updated with a 2023 KEK so we can continue servicing the ecosystem but we're having to be very cautious because the quality of firmware code can vary widely.

I think this could be a great idea for a property of "SecureBoot v.Next". But with the current ecosystem I think this would cause more harm than good.

[Flickdm]

I added a discussion because I think this is a fair question that other people would be likely to ask about #158