3 ms·

Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been

Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).

AnotherGoodName 1y ago
Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol! It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
- Tuna-Fish 1y ago
  Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.
  - londons_explore 1y ago
    There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet. Sounds like a cleaner solution than any of the ones in the article too!
    - Tuna-Fish 1y ago
      That's risky, an unclean shutdown would require resetting the clock which is a bother. It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
      - homebrewer 1y ago
        You can simply avoid adjusting the hardware clock. The kernel clock is not tied to it and can be modified separately. chrony can do that, for example. https://wiki.archlinux.org/title/Chrony#Real-Time_Clock https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
  - andrewmcwatters 1y ago
    Infosec engineers hate this one trick!
- charcircuit 1y ago
  >years for the expiration of a stolen certificate Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.
amluto 1y ago
That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.
- montroser 1y ago
  And what is the purpose of expiration in this case?
- AnotherGoodName 1y ago
  There is no purpose to the expiration in this particular case. If you have an expiry of say 24hours and constantly update that makes some sense - stolen certs get a very short time window. If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!" As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
  - Tuna-Fish 1y ago
    Even more, the "current date" comes from an external source that anyone with access to get new images on the machine can probably also manipulate. Setting the hardware clock is a normal operation available to the kernel.
  - londons_explore 1y ago
    If there were no certificate expiry, I could break into your system by finding some bankrupt company last trading in 1980 and stealing their keys to mint my own certificate. With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
    - 1y ago

AnotherGoodName 1y ago

Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol! It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.

Tuna-Fish 1y ago
Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.
- londons_explore 1y ago
  There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet. Sounds like a cleaner solution than any of the ones in the article too!
  - Tuna-Fish 1y ago
    That's risky, an unclean shutdown would require resetting the clock which is a bother. It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
    - homebrewer 1y ago
      You can simply avoid adjusting the hardware clock. The kernel clock is not tied to it and can be modified separately. chrony can do that, for example. https://wiki.archlinux.org/title/Chrony#Real-Time_Clock https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
- andrewmcwatters 1y ago
  Infosec engineers hate this one trick!
charcircuit 1y ago
>years for the expiration of a stolen certificate Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.

amluto 1y ago

That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.

montroser 1y ago
And what is the purpose of expiration in this case?
AnotherGoodName 1y ago
There is no purpose to the expiration in this particular case. If you have an expiry of say 24hours and constantly update that makes some sense - stolen certs get a very short time window. If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!" As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
- Tuna-Fish 1y ago
  Even more, the "current date" comes from an external source that anyone with access to get new images on the machine can probably also manipulate. Setting the hardware clock is a normal operation available to the kernel.
- londons_explore 1y ago
  If there were no certificate expiry, I could break into your system by finding some bankrupt company last trading in 1980 and stealing their keys to mint my own certificate. With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
  - 1y ago