3 ms·

Ideally, a chain of ongoing trust signs that a validation occurred before the cert expired. For example, the owner of a laptop could sign an initial validation

by yayana 8y ago

Ideally, a chain of ongoing trust signs that a validation occurred before the cert expired. For example, the owner of a laptop could sign an initial validation and continue to trust the firmware was authentic and not backdated after perhaps the original certificate expired and then its key length gradually became factorable. It is rather hard to handle code signing and backdating problems purely in software without either removing the benefit of expiration or requiring someone to go sign for the legitimacy of a lot of things they only sort of trust. This has been comming up a lot with git signing and key lifetimes too.

hyperman1 8y ago
I don't understand that. If the owner of the laptop approve by an initial validation, then he could as well approve by accepting unsigned binaries? Having a cert which cannot be validated seems more or less the same to me as having no cert. All the usual caveats apply: vendor loses signing key after expiration, etc... Vetting which firmware is safe is exactly the responsibility the end user didn't want to have to begin with. And if the owner doesn't get that power from whoever designs the OS, it makes a reinstall of the device impossible. The only way out I see apart from never expiring the certs is having a central third party vet the signature ('Yes, this binary with this signature was in our storage before the expiry.') A microsoft update or debian firmware repository could assume that role. But then you are depending on a third party for hardware you own yourself, and if they would rather have you upgrade, you're toast.
- deleted 8y ago
  [deleted]
- tialaramex 8y ago
  Where the certificate is just bogus, like it says "Test" or "Do not use" on it, and that's not a joke (TPPI which stands for "Test Pack Please Ignore" genuinely is one of the more famous Minecraft modpacks so, you know...) then you're correct that all bets are off. But, where certificates expire the whole _point_ of a code signing or document signing system that makes it different from the Web PKI (certificates for stuff that speaks TLS) is that it makes use of Time Stamping, ala RFC 3161. The Time Stamping services don't know anything about anything, except they promise to make signed documents saying they saw a particular bit-string (a hash) at a specific moment in time. Timestamps. And it turns out that this (if you trust any Time Stamping service to know what the time is and not be corrupt) is enough to bootstrap a completely acceptable code signing system where even though the certificate expired in say, January 2017 you can trust that it was valid in March 2015 when its keys were used to sign some code, so therefore the code is still good. The Certificate Transparency system does a lot MORE than this, but that only makes sense when we want transparency, proprietary vendors mostly do NOT want transparency.
  - Osiris 8y ago
    This is how Microsoft code signing working. Your certificate just needs to be said valid at the time it was signed by using a timestamp service.
  - hyperman1 8y ago
    I start to see how this works. There is a third party, but they intervene at signing time and not at validation time. In detail: You create a hash of your executable and send it to the third party, the TSS. They sign the hash, and never even need to see the actual executable. As long as the end user trusts the third party's cert, the TSS can guarantee the executable existed in its current shape on the date you claim it existed. A kind of notary service. For who wants to know more: Here is a Java article detailling how this works for Java, and what happens if the TSS cert itself expires https://blogs.oracle.com/java-platform-group/signed-code-needs-to-be-re-signed?source=:em:nw:mt::RC_WWMK180514P00061:SEV100743665&elq_mid=122882&sh=19261382112291426131527042&cmid=WWMK180514P00061 https://blogs.oracle.com/java-platform-group/signed-code-nee... And wikipedia is interesting too: https://en.wikipedia.org/wiki/Trusted_timestamping https://en.wikipedia.org/wiki/Trusted_timestamping
throwaway2048 8y ago
[removing noise due to misunderstanding]
- detaro 8y ago
  How does a TLS method translate to firmware signatures?
- deleted 8y ago
  [deleted]

by yayana 8y ago

hyperman1 8y ago

I don't understand that. If the owner of the laptop approve by an initial validation, then he could as well approve by accepting unsigned binaries? Having a cert which cannot be validated seems more or less the same to me as having no cert. All the usual caveats apply: vendor loses signing key after expiration, etc... Vetting which firmware is safe is exactly the responsibility the end user didn't want to have to begin with. And if the owner doesn't get that power from whoever designs the OS, it makes a reinstall of the device impossible. The only way out I see apart from never expiring the certs is having a central third party vet the signature ('Yes, this binary with this signature was in our storage before the expiry.') A microsoft update or debian firmware repository could assume that role. But then you are depending on a third party for hardware you own yourself, and if they would rather have you upgrade, you're toast.

deleted 8y ago
[deleted]
tialaramex 8y ago
Where the certificate is just bogus, like it says "Test" or "Do not use" on it, and that's not a joke (TPPI which stands for "Test Pack Please Ignore" genuinely is one of the more famous Minecraft modpacks so, you know...) then you're correct that all bets are off. But, where certificates expire the whole _point_ of a code signing or document signing system that makes it different from the Web PKI (certificates for stuff that speaks TLS) is that it makes use of Time Stamping, ala RFC 3161. The Time Stamping services don't know anything about anything, except they promise to make signed documents saying they saw a particular bit-string (a hash) at a specific moment in time. Timestamps. And it turns out that this (if you trust any Time Stamping service to know what the time is and not be corrupt) is enough to bootstrap a completely acceptable code signing system where even though the certificate expired in say, January 2017 you can trust that it was valid in March 2015 when its keys were used to sign some code, so therefore the code is still good. The Certificate Transparency system does a lot MORE than this, but that only makes sense when we want transparency, proprietary vendors mostly do NOT want transparency.
- Osiris 8y ago
  This is how Microsoft code signing working. Your certificate just needs to be said valid at the time it was signed by using a timestamp service.
- hyperman1 8y ago
  I start to see how this works. There is a third party, but they intervene at signing time and not at validation time. In detail: You create a hash of your executable and send it to the third party, the TSS. They sign the hash, and never even need to see the actual executable. As long as the end user trusts the third party's cert, the TSS can guarantee the executable existed in its current shape on the date you claim it existed. A kind of notary service. For who wants to know more: Here is a Java article detailling how this works for Java, and what happens if the TSS cert itself expires https://blogs.oracle.com/java-platform-group/signed-code-needs-to-be-re-signed?source=:em:nw:mt::RC_WWMK180514P00061:SEV100743665&elq_mid=122882&sh=19261382112291426131527042&cmid=WWMK180514P00061 https://blogs.oracle.com/java-platform-group/signed-code-nee... And wikipedia is interesting too: https://en.wikipedia.org/wiki/Trusted_timestamping https://en.wikipedia.org/wiki/Trusted_timestamping

throwaway2048 8y ago

[removing noise due to misunderstanding]

detaro 8y ago
How does a TLS method translate to firmware signatures?
deleted 8y ago
[deleted]