|
Back in 1995 the most popular web browser company in the world, Netscape, decided to use asymmetric encryption to allow people to safely enter credit card numbers in the web browser. Mathematicians started talking about asymmetric encryption in the late 70's. There are two keys, one to encrypt and a different one to decrypt. It is very difficult to figure out one key unless one has the other. This way a website can send an encrypt key to the browser and the browser can encrypt the data to be sent. Even if someone is able to see the encrypted data and the encrypt key, the data can not be decrypted without the decrypt key. Part of the magic involves very large prime numbers and complex equations.
That is not all the browser did for SSL (Secure Socket Layer, AKA https). This also created the idea where each SSL website would have a certificate issued by a trusted authority. That certificate indicates the web site domain is encrypted by the authority. The browser can decrypt the certificate to learn the verified name of the company that is running the web site. In this case, it is the encrypt key that remains secret. The idea was to prevent a user from being spoofed into entering their credit card on a web site that appears to be a well known site, but is not.
It is that second use that caught the eye of Microsoft in the XP days. They decided to use the certificate concept to add a signature to executable files loaded by Windows. It works like this: A software publisher gets a certificate from a trusted authority, the same people doing web site certificates. Using a tool from Microsoft, a signature using the certificate with the company name and a CRC of the executable file is appended to the file. When the OS loads the file, it can decrypt the signature, verify the CRC and decide how trusted the file is. For example if a message like "This program was published by CCS, Inc; if you trust that company press continue."
The only encryption algorithm used up to 2001 was called SHA1. In 2001 a new algorithm called SHA2 (AKA SHA256) came out that was considered harder to break with the newest fast computers. XP SP3 would accept either encryption but the older XP versions would only take SHA1. One could sign a file with two signatures, SHA1 and SHA256 and it would all work, so this became the norm.
Starting with 64 bit Windows 7 Microsoft began requiring all drivers be signed with a certificate traceable to an authority they approved of. The way these certificates work is company A can issue a certificate to you and they have a certificate issued by company B and they have one issued by company C. This chain of certificates is all part of the signature. Microsoft maintains a list of the large handful of top level certificate issuers it trusts. Drivers were considered sensitive because they often operate in kernel mode where they can access any memory in the PC.
With all the websites in the world a lot of companies were issuing a lot of certificates and some of these authorities were not doing much to check for who they were issuing them to. The concept of an Extended Validation certificate (EV) was created where it requires a great deal of verification to ensure the certificate holder is who they say they are. Microsoft uses this in their SmartScreen web browser download checker. It flags any software without a EV certificate as suspicious.
This was all well and good until the release of Windows 10 that first was sent out October of 2020. Microsoft decided drivers loaded into Windows would only be accepted if they were signed by Microsoft. The way this worked is the software publisher would first sign the driver with an EV certificate, then send it to Microsoft. If approved, the publisher signature was stripped and a Microsoft signature applied. They would then send the package back to the publisher. So the whole world did not grind to a halt, they have exceptions as a part of a roll out plan. In general, right now anything signed in 2021 needs a Microsoft signature and most older files are accepted.
So here come the headaches for CCS. First I should point out even though we have a yearly developer subscription with Microsoft we did not get the memo about this new rule. In the old days Microsoft published a newspaper sent via snail mail to all developers. The last one we got was October of 2000. For a while we got news by CD and then that was replaced with a slew of online blogs.
Microsoft does not update all machines at the same time, so early this year we started getting some calls of trouble but not enough to be very concerned. There seemed to be work-arounds that got people going. Only new drivers had a problem and only on machines that did not have the driver previously installed. The error did not say "Sorry this driver must be signed by Microsoft", it did say "Invalid signature hash."
We put in a support ticket with Microsoft in May and were then told about the new rules. Our first step was getting an EV certificate. We had been using the ordinary certificates (OV) since the beginning but never bothered with the EV. It then took over two months and a pile of tickets in attempts to log into the Microsoft driver signing website. The problem turned out to be another account with the same company name was taken out 10 years ago and not used since. The error was not "Company name already used", it was "Something went wrong, try again later." The next problem was our files were not being accepted. Another dozen tickets and we found out the reason our certificate was not working was the authorities started issuing SHA3 certificates and the Microsoft website could not handle those yet. Windows is OK with SHA3 but not the website that accepts the driver submittals. After making a special request for an SHA2 certificate and another couple of weeks to figure out what the special website wanted, we started getting Microsoft signed drivers.
So far we have not been able to figure out how to append additional signatures on to the files so it seems we need to have new and old style drivers depending on the OS.
Many of our customers are using USB CDC drivers to talk to the PIC® MCU. This creates a COM port in Windows that can use the normal serial API functions. The driver for a CDC device is just a .inf file with VID, PID and company information, plus the .cat file with the signature. In Windows 10 no driver is required for CDC devices. You do need it for older versions of Windows. If you do want to use a .inf for a CDC device in Windows 10 then it does need the Microsoft signature even though the driver file is optional.
It is possible to load a driver into Windows that has a bad or wrong signature. This link details the procedure:
https://www.howtogeek.com/167723/how-to-disable-driver-signature-verification-on-64-bit-windows-8.1-so-that-you-caninstall-unsigned-drivers/
The procedure will not work if you have secure boot enabled and on some PC's you need a password to disable secure boot. This also will not work on PC's that are in S-Mode. Only software products in the Microsoft store can be installed in S-Mode. This might be a hint that new rules for normal executable are coming.
Microsoft is evolving with encrypted certificates as are web browsers. If you ever try powering up a old PC you may find it can no longer browse the web because it uses an older encryption method and most websites are now the newest https. Asymmetric encryption technology can be used to send encrypted data to anyone you have not previously made secure contact with. It is finding use in a large variety of applications. One big use, that would not otherwise be possible, is cryptocurrency.
We are sorry for the inconvenience to customers who were trying to use our products during this adventure (nightmare). Many customers were able to use the above workaround and others returned product out of fear of damaging their system. We are now back to normal and everyone should be able to install our drivers.
Like us on Facebook. Follow us on Twitter.
About CCS:
CCS is a leading worldwide supplier of embedded software development tools that enable companies to develop premium products based on Microchip PIC® MCU and dsPIC® DSC devices. Complete proven tool chains from CCS include a code optimizing C compiler, application specific hardware platforms and software development kits. CCS' products accelerate development of energy saving industrial automation, wireless and wired communication, automotive, medical device and consumer product applications. Established in 1992, CCS is a Microchip Premier 3rd Party Partner. For more information, please visit https://www.ccsinfo.com.
PIC® MCU, MPLAB® IDE, MPLAB® ICD2, MPLAB® ICD3 and dsPIC® are registered trademarks of Microchip Technology Inc. in the U.S. and other countries.
|
