←back to thread

253 points pabs3 | 1 comments | | HN request time: 0.001s | source
Show context
londons_explore ◴[] No.44616185[source]
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).
replies(2): >>44616291 #>>44616303 #
amluto ◴[] No.44616303[source]
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.
replies(3): >>44616417 #>>44616458 #>>44618501 #
AnotherGoodName ◴[] No.44616417[source]
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?".

replies(2): >>44616606 #>>44616617 #
1. Tuna-Fish ◴[] No.44616606[source]
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.