I understand the basics of signing. You must have a private key and a certificate (not necessarily) from a reputable certificate authority. You must then have the public key of the signer to verify its integrity.
I can see this working online; A site is given a certificate (not necessarily) from a reputable certificate authority (such as Verisign for example), and Firefox (for example) can check the authenticity of the certificate by contacting said certificate authority.
Yes, I know you can sign things with a self-generated certificate, but Firefox will complain when this happens and so does Windows when installing a 3rd-party driver.
My question is thus; how does windows know a driver is signed by a reputable certificate authority when it is offline and can't check with said reputable certificate authority?
Does Windows keep a collection of public keys from reputable certificate authorities within Windows? Wouldn't one be able to alter this list to load a driver as if it had the certificate of a reputable certificate authority?
How does driver signing work offline?
Yes, Windows keeps a collection of trusted root certificates. Some software, such as IE and Chrome, uses that collection; some software, such as Firefox, ships with its own list. That's how certificate verification works; nobody gets root certificates from the CA over the internet, because how would you know you were really talking to the CA?
You can view the Windows root certificate store using MMC, via the Certificates plugin. Note that each user account has its own certificate store, in addition to the global ("Computer account") store.
However, Windows does not use that list of trusted certificates for driver signing. Instead, the Windows kernel has a built-in list of root certificates. Certificate verification for drivers is based on that built-in list, which, if I understand correctly, consists entirely of root certificates belonging to Microsoft.
When a driver is signed by a third-party certificate authority, a cross-signed certificate is used.
One further complication is that in most cases, device drivers are cryptographically verified in two separate ways; once during installation, and then again when the driver code is loaded into the kernel. The verification during installation uses the main root certificates list and can be overridden on a case-by-case basis by the administrator; the verification when the driver code is loaded uses the kernel's root certificates list and cannot be overridden on a case-by-case basis.