How Windows Determines Which Software to Trust According To Code Signing Ecosystem
Here’s How Code Signing Ecosystem Helps Windows Determining Which Software to Trust
Have you ever come across an “Unknown Publisher” popup message when you tried installing software? For instance, when you’re installing a piece of software and your Windows computer shows a popup like this stating the software publisher is unknown:
Without Code Signing Certificate
With Code Signing Certificate
Code Signing Certificate – What Is It and How Does It Works?
Technically similar to other digital certificates such as SSL certificates, a code signing certificate has a specific use case: digital signatures for signing software packages, executable files, scripts, and other software files to verify the identity of the author. A digital signature ensures that the software file is from a trustworthy source, and that it hasn’t been tampered with since it was signed, so users can install it without worrying.
In other words, code signing is similar to an old-time wax seal—but instead of verifying a proclamation from the king, it helps the recipient confirm that the software is valid and wasn’t tampered with. As mentioned above, a code signing certificate is provided by a respected certificate authority (like DigiCert or Sectigo) that validates the organization before issuing the certificate. This confirms that if you’re able to trust an organization, then you can trust their code or software package you’re installing.
Benefits of Code Signing Certificate
Code signing is used for signing program files, executable, software packages, scripts, and software updates using a digital signature from a trusted certificate authority like Sectigo or DigiCert. Signed files can then be authenticated during installation and execution. Similar to a wax seal, it guarantees to a recipient that the software is from the trusted author and it hasn’t been tampered with.
The most common use case is seen with software developers using a code signing certificate for proving the authenticity of their software in Windows. For example, you would want to know that the Windows 10 update you receive is from Microsoft, and not from a malicious hacker who’s trying to impersonate and trying to compromise your computer.
Code signing certificates help you to be sure that you’re downloading a software file from the genuine author or publisher and not an attacker who’s looking to take your information or data. In other words, a code signing lets you know that the code has not been altered by any bad guy, and you can safely install and run that software on your computer.
Code Signing Ecosystem: How Digital Signatures Work Behind The Scenes
How does code signing work? How does the user’s computer know whether to trust the signature or not?
Many users and even software developers might not know all the things that are going on behind the scenes. In fact, code signing requires many roles that combine to create the code signing ecosystem.
Let’s dig into details and take a look at the various parts of the code signing ecosystem and how they fit into together.
Code Signing Ecosystem: 4 Separate Roles
The main roles within a code signing ecosystem are:
- Certificate Authorities (CAs)
- Software Publisher
- Software Distributor
- Software Consumer
Let’s take a look at each one, in turn…
Certificate Authorities (CAs)
If you’ve purchased a code signing certificate, then you already know that CAs like Sectigo and DigiCert are responsible for issuing the certificate. But, you might not know that their responsibility doesn’t end there. CAs are more like trust brokers, when they issue code signing certificate, they’re also required to bind the publisher’s public code signing key with information about the publisher’s identity so that software consumers can verify it. The policies and procedures differ from one CA to another, but, some of the common things found among them are:
- They have to verify the software publisher’s identity who has requested the certificate.
- The certificate must be issued to the verified software publisher.
- A certificate will be revoked if the private key of a software publisher is compromised or the publisher violates the usage practices of the CA. CAs revoke the certificate via online certificate status protocol (OCSP) or certificate revocation lists (CRLs).
- Protecting their own (CA’s) private keys is critical in order to remain trusted.
- The CA’s root certificate needs to be included in popular operating systems so consumers can verify the identity of the software publishers to whom CAs have issued their certificate. CAs deploy a certificate chain for signing applications, in which all issued certificates are digitally signed by an intermediate certificate. This forms a certificate chain that traces back to the CA’s root certificate, making a hierarchy of trust.
A software publisher registers with the CA (Certificate Authority), requests a code signing certificate, and agrees to follow the CAs policies. Once the certificate is issued, the publisher can create and digitally sign software packages with their code signing certificate.
The software publisher’s responsibility doesn’t end here. They’re responsible for protecting the private key of their code signing certificate and setting up internal policies and procedures for ensuring that only approved code gets signed. Also, the publisher is responsible for requesting revocation of the certificate if a code signing certificate gets compromised or it’s used to sign a malicious program.
Note: Software publisher is a broad term which includes a diverse range of software development companies and individuals. For example:
- IT administrators who sign third-party applications and drivers which are used in a network.
- Independent software vendors (ISV) who produce Windows applications.
- Independent hardware vendors (IHV) who produce Windows drivers.
- Web developers who create ActiveX controls for public or internal applications.
Software distributors are responsible for publishing software to users. And, digital signatures ensure the software’s integrity regardless of the method chosen by these software distributors (distribution mechanism varies from one software distributor to another). From a security point of view, it doesn’t matter how the file is distributed, whether it’s through a website, FTP, file sharing, email, or optical media like a CD or DVD.
Software consumers are the users of an application. It’s the user and/or their computer that verifies the digital signature on software. Software consumers ultimately make the decision whether to trust the software or not based upon the identity and integrity of the digital signature. Software consumers may not decide to install or run the software if the digital signature is missing. Because a valid signature assures software consumers that the application is from a trusted source and the software they’re about to install hasn’t been tampered with.
Having a valid signature doesn’t always mean that the users or administrators should trust the software publisher blindly. It’s the user’s responsibility to decide whether to install or run an application based on their knowledge or reputation of the application and the software publisher.
Does a Code Signing Certificate Differ From an SSL/TLS Certificate?
If you’re asking if there’s any difference between a code signing certificate and an SSL/TLS certificate, then the answer is YES, they do differ. Though both of them are X.509 certificates, both are used for protecting users from becoming victims of cyber threats, and both with show a warning message to users if the certificate is missing, but function wise they are different.
A code signing certificate is used for signing software using a digital signature, and it assures users that the software is coming from a trusted source and hasn’t been tampered with since signing. On the other hand, an SSL/TLS certificate is used for providing a secure encrypted tunnel between a client and the server. Whatever information is sent between, for instance a credit card number submitted by the user to the website, remains secure and unreadable until it reaches the intended party.