Beginning with Windows Vista, Microsoft slowly began increasing the requirements of code running in Windows to be digitally signed. Here is their definition of code signing:
A signed driver is a device driver that includes a digital signature. A digital signature is an electronic security mark that can indicate the publisher of the software, as well as whether someone has changed the original contents of the driver package. If a driver has been signed by a publisher that has verified its identity with a certification authority, you can be confident that the driver actually comes from that publisher and hasn't been altered.
Their kernel-mode code signing policy is an important step in securing the operating system and making the lives of users easier. Being able to verify the integrity of a file every time the image of the file is loaded into memory reduces the odds of the OS loading modified or malicious code into ring 0. Giving users easy ways to load malicious code into the kernel is a great way of giving malicious people an easy way to do bad things to systems.
This is a bit of a tangent, but what good is a signed driver if the OS can be modified to ignore it? Please ignore that fact that if someone can modify the OS, you already have big enough problems. Focus instead on the fact that many of the better hackers and security researchers chain together a handful of small things to make big things happen. It's similar to finding a simple buffer overrun or getting a system to crash with a fuzzer. The system isn't necessarily vulnerable YET. It's often only a matter of time before it is. SHA-1 isn't actually vulnerable yet, but all of the major browsers are removing support for a reason. You don't want weakened security when you don't have to have it.
Beginning with Windows 10 (the standard OS delivered with most new PCs) "all new Windows 10 kernel mode drivers must be submitted to and digitally signed by the Windows Hardware Developer Center Dashboard portal. Windows 10 will not load new kernel mode drivers which are not signed by the portal."
Attacks on computer firmware have been around since at least the 90's, with fun code such as CIH & later Mebromi. In the last few years that type of attack has been making the news more often. Firmware vulnerabilities such as those for BIOS, or those for UEFI have increased the awareness for the need to actually do something about it. A fairly new security feature named UEFI Secure Boot is on the market. It's been required for Windows 8 machines to be part of the Windows Hardware Certification Program and be “Designed for Windows” certified. That rule also specified that PC manufacturers had to provide a way to turn it off. Microsoft no longer requires (as far as I dug) that PC manufacturers give the option to turn off secure boot.
Secure boot begins in hardware with a Trusted Platform Module (TPM) on the motherboard. A TPM is hardware that securely stores cryptographic information such as security certificates and encrypion keys. A TPM is designed to never release this sensitive data. They allow for remote attestation to determine if the initial stage firmware has been modified. This chain of cryptographic verification continues up the stack. Windows will only boot if every layer is certified to be unmodified. A properly implemented system like this makes it mathematically impossible or at least intractable to run sofware that has been modified by someone malicious. Sure you can disable this security feature, but I don't believe you should without a good reason. I don't believe installing a driver for microcontroller is a valid reason.
I recently finished up a project that required a new driver. A customer or two mentioned that it didn't work on Windows 8. That's not okay with me; at least not if I had the support to fix it. I use OS X, Linux, and Windows 7, probably in that order. I'd never really run into the issue. The drivers build in to the OS for the POSIX systems just work. In Windows 7 you get an error saying that the driver isn't signed. I know the driver came from a trusted source and why I was installing it. That's not a big deal to ignore. Around 10 steps with multiple reboots to make my system less secure before that last 'uncomfortable' step is a bigger deal to me.
Unsigned driver warning
The process of signing a driver is somewhat expensive and time consuming. It's a real barrier to tiny companies. We have to sell a lot of RedBoards to cover the cost. Thankfully management here agreed with me that the customer experience was worth the investment. The issue was relatively new. People had only been seeing it for around 3 years, or like myself, never. The issue also had a workaround. It had grown to be an issue with over 20 poducts at least for a period of time. Partners and collaborators had started signing their drivers. It appears that Arduino waited a year and a half to sign their Windows 8 drivers and they (LLC) are arguably a software company.
SparkFun Electronics now owns an Extended Validation (EV) code signing certificate. That cert along with a Microsoft cross-signing ceritificate, the Windows Driver Kit, and a few custom batch scripts now allows us to create and sign security catalog files (.cat).
The missing component in the previous paragraph is an .inf file. These are text files containing all of the information that the device installation components need to install a driver. Basically it tells Windows all of the settings and files required for a driver. Once the inf file has been processed and a signed cat file has been generated, Windows will trust and use the driver. You can right click on the inf and select install, or you can have the OS find the driver information in the device manager. Any of the tools or methods that you may use to install drivers should work.
Right click on the inf to install the driver
Much more tempting to click 'Install' near the words 'trust software' than to click 'Install this driver software anyway', right??
Driver signed by Spark Fun Electronics Inc
A few drivers I wrote basically from scratch. Others were simply signed by certificates that don't meet the requirements of the last 3 releases of Windows. Those I simply resigned with a valid certificate. They should behave exactly the same other than be trusted by Windows. As with any software release by any company, the general public is likely to be able to find bugs or break things the engineering team never imagined possible. If you have any issues, please let us know so we can fix them.
There is nothing more frustrating to using MS Windows than driver signing. Even in Windows 7. I use a utility called com0com to create virtual serial ports for industrial equipment. To use it practically I have to get a version some guy signed out of the goodness of his heart and the fact he had the resources at his company to do so. This barrier to using the OS has caused me to reevaluate my usage of the platform in an industrial setting. For instance, if I need to write a custom driver for a specific purpose then I have to get that signed? So I lose all the benefit of the com0com project being open source. In the future we plan on moving all of our control consoles to Linux as it affords us much more control and freedom on our platforms. Not to mention way better security tools. I do appreciate Sparkfun making the effort to ease the usage of their hardware. It makes testing and deployment a lot less frustrating and time consuming.
It is sad that Windows 7 was a giant leap forward in MS OS lineup. Now they are regressing so quickly with Win8 and WinX that I have to wonder what is really going on in Redmond.
Security is always a security/usability trade off. That's why all of my bank passwords are on this post-it note on my monitor; I want them hard to guess. ;-) They have to hit the average user, or the biggest part of the market. Large corporations can install their own self-signed root certificate authority certificates on the machines they own and then sign all of the internal drivers they want w/o further inconveniencing their employees. That might be a workaround a more advanced user such as yourself could use for your own customized drivers. I did that to one of my machines to practice before we spent the money on the real deal.
You sure that signed driver image at the end is legit? Isn't it called "SparkFun" without the space? ;)
Funny you call us out on that. I thought the same thing. Legally our company name is "Spark Fun Electronics Inc". SparkFun is a registered trade name that we use. I assume Spark Fun was registered before it was cool to make new words by smashing together 'real' words. http://tinyurl.com/ovsoaza
Kudos to you guys for making this decision/investment. As an IT manager, I cringe any time I see someone that has been trained (by usually well-meaning folks) to ignore security warnings when they usually don't have the skill to tell if there is really a problem or not. Self-signed SSL certs are just as bad a problem as unsigned drivers.
hi
Is the link at the end of the TL;DR section at the top of the page correct? It leads to a Bluetooth tutorial, and has nothing about disabling driver security. Whereas it seems this one is more approriate:
https://learn.sparkfun.com/tutorials/disabling-driver-signature-on-windows-8
The link should be good, but it looks like there is a bug somewhere. I've notified IT to look into it. You are correct though.
P.S. So where exactly are those signed drivers downloadable? I can't find a link to them. The Redboard product page still links to the FDTI download site.
The signed drivers are available on GitHub (https://github.com/sparkfun/SF32u4_boards & https://github.com/sparkfun/Arduino_Boards) or through the Arduino IDE board manager. In the case of the Redboard, it still uses the FDTI drivers. Boards such as the Redboard that use an FTDI enumerate to the OS as an FTDI device and work well with their drivers. I've signed the drivers that have a SparkFun USB vendor ID only.
These Securities are good but it makes sometime system too slow . Processing really becomes difficult sometime.
What makes you say this? My understanding is the OS roughly does a hash to verify the driver hasn't changed before loading it, and then it's the same. Doesn't take long at all to hash a file and compare it to the signed signature.
Great article and agree with chriscrowder's post. On Safari my screen keeps shifting and is freaking my eyes out.
You guys got something weird going on with your post (at least for me in Chrome). It appears the spacing between lines is shifting every so often when the main page is loaded. Really annoying when you towards the bottom and everything shifts a line or 2. Only seeing it on your main page. Not on any of the other post pages.
What @chriscrowder said and it's driving me nuts. Using Firefox/Win7... please make it stop!!!
Sorry guys. I made it stop.