#code-signing #ev-certificates #token #hardware-security-module #hsm #exe-dll-msi #device-driver #smartscreen-filter
In the last month the code-signing demand for organisation rises, as all Windows device drivers must be protected using strongest EV certificates. Otherwise, these drivers are not accepted by the operating system. Furthermore, Windows SmartScreen-filter in Windows 10 warns for software packages and executables not signed by an EV code signing certificate. But what exactly are EV code signing certificates and what is the difference to standard code signing certificates? Why does it also make sense for companies to protect their software with EV certificates? We are going to answer these questions in this article and video.
Code Signing – the Basics
Before we start to discuss EV-certificates, we need to go through some basics. A Code Signing certificate is issued by an authority who ensures who you are and that you are allowed to digitally sign your software. This safeguards that every change or manipulation of your executable after the code signing process will invalidate the digital signature immediately. Therefore, code signing will help to determine the origin and integrity of software. It can be seen as an software insurance for your customers enforced by the Windows operating system.
The source code itself is usually not signed but signed once compiled to a binary file, e.g an EXE file, a DLL library or MSI installation file. Technically seen, the binary will be hashed, and a digital signature will be embedded. The signature includes all relevant certificates when it is attached to the binary. Once the operating system opens the file, the binary (without the code signing signature) is hashed again and checked against the hash in the signer’s certificate. If the file remains unchanged, the hashes are equal and therefore the signature is assessed valid. If there is only one bit different, the signature becomes invalid.
Different types of certificates
We must differentiate between two strengths of code signing certificates: The Organisation Validation or standard code signing certificate and the Extended Validation code signing certificate also called EV-certificate. Both certificates have in common that they are usually issued by a trusted CA-Authority. The standard certificate only checks some minimum details required to prove the requesters’ identity whereas the EV-certificate carries out many more identity checks. This procedure mostly results in much higher costs for the EV-certificate. For this reason, many companies decided to go with standard certificates, as they were enough in the last years. In today’s operating systems and IT-environments, however, the situation has changed significantly as result of the ever-increasing threat of malware and malicious infected standard software.
EV Code Signature and Timestamps
Windows users can check in the file properties if a file is signed. The tab “Digital Signatures” only appears when there is a signature attached. Otherwise, this tab is not visible.
You can select the signature to check out its details. So, you easily can obtain the information on the issuer and the used timestamp server, if applicable. A timestamp server in the lower part of the details dialog is applied to externally prove the time the signature has been attached. Although it is not required to use a timestamp-server, it is strongly recommended to use, as many CAs provides their timestamp servers for free. There are two standards for time stamping: the older Microsoft Authenticode and the newer RFC3161 timestamp-servers, which utilise the TSP-Protocol (Time Stamp Protocol).
Timestamp servers feature a reference clock and indicate when a signature has been issued. This is important as certificates have a limited validity and a timestamp server proves that the signature has been issued during the validity date of the certificate. To include a timestamp is a requirement for valid EV-signatures.
A file can have one or multiple signatures. To issue an additional signature is common when you are signing device drivers. Starting with Windows 10 Release 1607, it is required to have two independent signatures for drivers. One is issued by you with your EV-certificate and the second– by the Microsoft Hardware Labs.
EV Code Signing for Windows Device Drivers
Device drivers are a special kind of software. There are two types of device drivers: so-called user mode drivers and kernel mode drivers. User mode drivers are drivers which can use abstraction layer or API (usually provided by the OS vendor) to talk indirectly with a hardware. Kernel mode drivers are directly talking to the OS kernel and are therefore characterised by featuring extended rights and permissions. On the one hand that comes with great responsibility, but on the other hand kernel mode drivers can be really dangerous and were misused in the past years by several malware developers as an entry to windows kernel resources.
Due to this reason, Microsoft added a second layer of security, which means that modern versions of Windows the OS require two independent signatures. First, you must sign the driver with your own certificate, which must be an EV-certificate. Secondly, you must send the driver to Microsoft to be signed by the Windows Hardware Labs. Based on the type of driver, you must carry out some predefined tests declared in the “Windows Hardware Compatibility Programme”. To get an account for the Windows-Hardware-Dashboard, you must have an EV-certificate for the account creation.
The only way to go around this is to start windows in “test signing” mode. In this developer mode you can sign the driver with an own certificate for testing and debugging. In this mode, Windows will accept, and load drivers signed with your own certificate.
The “test signing” mode can be initiated by a local PC administrator using the command line. The first command will enable test signing and the second will disable test signing. You need a reboot to complete the operation.
BCDEDIT -set testsigning ON BCDEDIT -set testsigning OFF
CAUTION: This mode is only recommended for testing and debugging and may be a security risk during day-to-day work.
In earlier versions of Windows, you were able to use your own certificates or install the driver anyway. Windows was triggering a warning message that the software may be dangerous, however. Don’t let this happen to your customers!
See the comparison of EV code signing requirements rising from Windows Vista to Windows 10 and 11:
If you are developing hardware, you must have an EV-certificate to sign your drivers. EV is recommended for older operating systems as well to avoid any kind of warnings.
Application Software
For application software there is no requirement to use EV-certificates to sign. It is not even necessary to sign at all. Nonetheless, it is strongly recommended to do so because code signing is the only way to distribute your software though the Internet and avoid any warning from the Windows smart screen filter.
Windows Defender SmartScreen is represented by the blue warning that “Windows Protected your PC”. According to Microsoft, you have two ways to get rid of this uncomfortable Windows Defender SmartScreen filter message:
- Sign your software with an EV-certificate
- Wait until enough users download and install your files. A Smart Screen warning may occur until enough software proves sufficiently popular with Windows users for Smart Screen to view it as “well known.” This might take some months.
More Information can be found in the following article from Microsoft and in the Microsoft Smart Screen FAQ.
All in all, it is advisable to always sign your application with an EV-certificate.
How to get an EV-certificate
EV-certificates can only be issued by an external CA also called Trust Center or Trust Service Provider (TSP). There is no way to install an own Root-CA in the Windows “Trusted Certificate Store”. Only Microsoft can manage the trusted store for EV-certificates.
EV-certificates are only available for registered and verifiable organisations, not for individuals, nor for open source working groups. Applicants for EV code signing certificates go through a more secure application process than standard code signing certificates. In addition to verifying the name of the issuer’s organisation, other company information, such as physical address and jurisdiction, is checked. This thorough vetting process makes it much more difficult for sneaky malware developers to impersonate and obtain a code-signing credential to use to sign malware under the guise of a legitimate development company.
The hassle with hardware based key storage
Typically Trust Service Providers supports hardware key storages like the Thales Gemalto eToken 5110 FIPS or the Thales Gemalto eToken 5110 CC, both USB based cryptographic token. Those USB crypto-token are not easy to be handled, as storing a costly EV certificate on a USB based cryptographic token has a lot of disadvantages like
- PIN management
- sharing the USB token across build servers and
- the worst thing, those tokens become defective or may be lost.
To store such a certificate on a network attached hardware security module (HSM) is not affordable for many customers as most certificate authorities have exclusive partnerships with well-known and expensive HSM vendors. This makes it difficult for cost-conscious or smaller companies to purchase EV code signing certificates for their build systems and developers across their network.
Another issue is that most hardware token can become unusable once the PIN is entered incorrectly too often. This happens from time to time during configuration of build servers with an attached USB device.
How to use EV code signing cost-effectively on multiple build servers?
This is where se.SAM™ N-Series network HSM comes into play. The se.SAM™ N200 Crypto Appliance (see datasheet) is built as an affordable solution, which will help you to use code signing certificates across your enterprise networks. The solution supports a migration strategy, to move from a USB key media to a fully network-based solution.
This is how we protect your EV-certificate from abuse:
- PIN and certificate authorisation: Protects the PIN and certificate with an additional layer of security. When the HSM is switched on you can define that a key usage must be authorised by a security administrator before it can be used.
- PIN and PIN-less usage based on IP or credentials: Granular rules define how users and systems are authenticated. As an example, you can specify that build servers from defined IP addresses can access certificates without a PIN but users still need to authenticate via their LDAP credentials. There are dozens of options available to simplify your build and binary management.
- No CALs or client restrictions: You do not have to pay per server, per application, per user, or per signing process to sign your binaries. The appliance services any authorised system or developer with its maximum available code signing performance.
- Key usage monitoring: With our integrated audit log you can identify how often a key was used to sign.
Migrating existing USB-token
In addition to EV-code signing, se.SAM™ N-Series is capable of handling standard code signing USB-token which can easily be integrated into your network environment. This will protect the issued token from being misused or lost and the pin can be managed centrally.
Code Signing – what else?
The se.SAM™ N-Series appliance is capable of much more than just serving code signing certificates. Have a look to the datasheet to explore the full cryptographic power of se.SAM™. It is not just a brand but a philosophy to work against the complexity of cryptography in today’s workflows for industry, IoT and IT. Once obtained se.SAM™ N-Series is a framework that simplifies the complex use of cryptographic processes and thus, enables even unexperienced users and developers without prior knowledge to work with state-of-the-art cryptography.
The se.SAM™ N-Series device consists of a hardware-based crypto processor and a secure and hardware-based key storage. This ensures full protection of your key data. At the same time, it is guaranteed that cryptographic operations are performed entirely within the secure hardware.
se.SAM™ solutions generally avoid complex interfaces and convert processes and commands into human readable form – the so-called sematicon “Human Command Interface” or HCI in short.
Every appliance features two or more independently configurable crypto processors, which work with a variety of keys. Therefore, test and production can be operated separately on only one platform.
The operation of multiple devices in a high available cluster guarantees system stability and reliability for critical environments. There are no limits in cluster configuration and number of cluster nodes.
The keys and their usage are subject to authorisations. Users can be authenticated from a local service or existing directory services (i.e. Active Directory). Reliable processes require an easy-to-handle back-up concept. Back-ups are created automatically or can be stored as backup-files according to your configuration and data carrier of choice.
