> That's not how it works. You need the private key to sign the drivers. This is not a file that developers of those companies have access too.
No, you could unfortunately get around that very easily (or rather, ignore recommendations) at least a few years ago. So I bet there are a lot of certificates and private keys lying around on disks, build servers, version control systems and probably even on developer USB sticks.
The cert and key just needs to be something signtool can access. Signtool doesn't care whether it's relatively unprotected key in system software based key store or on a HSM.
Windows 10 1607+ enforces a much stricter standard, especially if you want your driver to work in Secure Boot mode. There are also stricter requirements for driver testing and static analysis, although those depend on the driver type. Microsoft requires and checks testing tool output as a part of the driver submission before finally signing it with their cert.
Tip: If you run Windows 10 and value security (and system stability), use Secure Boot.
No, you could unfortunately get around that very easily (or rather, ignore recommendations) at least a few years ago. So I bet there are a lot of certificates and private keys lying around on disks, build servers, version control systems and probably even on developer USB sticks.
The cert and key just needs to be something signtool can access. Signtool doesn't care whether it's relatively unprotected key in system software based key store or on a HSM.
Windows 10 1607+ enforces a much stricter standard, especially if you want your driver to work in Secure Boot mode. There are also stricter requirements for driver testing and static analysis, although those depend on the driver type. Microsoft requires and checks testing tool output as a part of the driver submission before finally signing it with their cert.
Tip: If you run Windows 10 and value security (and system stability), use Secure Boot.
(I've developed Windows kernel drivers.)