|
|
|
|
|
|
by Terr_
2 hours ago
|
|
|
I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are: A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised. B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com . C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy. Those are all interesting to contemplate, but they are at best "out of scope". |
|
|
1. Axiom: We trust the current daemon and OS. We must assume this, because otherwise it's an entirely separate problem and this whole discussion of an auto-update channel is irrelevant.
2. Axiom: We trust the owner. Tampering with the local auto-update process is not part of our threat-model, because a user who can do that doesn't need to.
3. The daemon is already coded to trust a replacement/successor installer if it meets certain criteria, which are:
3a. It comes from a trusted domain name it already knows should be owned by the same developer/company.
3b. The remote end is authenticated to "be" that domain via certificates from the (trusted) OS.
3c. The content is protected from tampering due, becauese we trust that TLS/SSL encrypts it.
That all already exists, it does not need to be torn down or rebooted. The proposal here is to simply to harden it with a new requirement in the next version:
3d. The next install must be signed by a trusted key-pair that was shipped with the current install.
This improves trust because it means an attacker would also need to compromise keys held in a release pipeline, which is much easier to secure than a CDN/webserver.