Code Signing Architecture: How the Code Signing Process Works
Code Signing Requires Four Different Components for the Code Signing Architecture
But, today, we’ll dig a little deeper to understand the architecture of a code signing certificate and the sets of components that are responsible for the code signing process. You might know the basics, but let’s explore it for the ones who don’t.
A code signing architecture has four different components
- Code Signing System (CSS)
- Certification Authorities (CA)
- Time Stamp Authority (TSA)
Let’s look at each one in order…
1. Code Signing System (CSS)
The code signing system (CSS), the first component of the process, is where the code is actually signed. Typically, code goes through a series of steps such as authentication and authorization of the one who submitted code, then finally, generation of the signature. To generate the signature, the code signing system uses a certificate and a private signing key, which is kept securely to prevent unauthorized usage.
2. Certificate Authorities (CAs)
The requirements mandated by the CA for issuing a code signing certificate, are based on guidelines from the CA/Browser Forum and the CA Security Council, who specify the required documents that are needed for the issuance of a code signing certificate.
3. Time Stamp Authority (TSA)
Code Signing process and architecture involves the use of a time stamp authority (TSA). Although this part is optional it’s recommended. A TSA is used for specifying at what time and date a piece of code are signed. This is so the signature will be valid even after the certificate has expired. Whenever a Time Stamp Authority (TSA) is used, the signature is sent to it. Then the TSA applies its signature along with the signing time to be added to the software package or other executable files.
Code Signing process and architecture involves the use of a time stamp authority (TSA). Although this part is optional it’s recommended. A TSA is used for specifying at what time and date a piece of code is signed. This is so the signature will be valid even after the certificate has expired. Whenever a Time Stamp Authority (TSA) is used, the signature is sent to it. Then the TSA applies its signature along with the signing time to be added to the software package or other executable files.
Once your software package or executable file is signed and timestamped, any client that attempts to use the file will first attempt to verify the signature. As a developer, it’s recommended that you verify the signature yourself before publishing the file.
The clients or verifiers manage trust anchors that are used for validating certificates.
Verifiers use trust anchors for validating the signature, generally by verifying issued code signing certificates.
Trust anchors are typically public keys for root certificates that are installed and securely stored on the verifying platform. For example, a self-signed root certificate using standard X.509 architecture works as a trust anchor for applications, if that certificate is included in the verifier’s trust store. A web browser like Google Chrome and Mozilla Firefox and operating systems also provide the list of their trust anchors.
These trust anchors do not verify code directly, but they’re public keys of root CAs which are used for signing code signing certificates of CAs like Sectigo or DigiCert.
We hope this article gives you a better understanding of how code signing certificates work, while making you aware about the different components involved to make the signing of an executable file or software package successful. In the end, the goal is to assure users that the signed file they’re downloading or installing is trustworthy, genuine, and coming from the original publisher without being tampered with.