Dual Control in Code Signing Using Standard Crypto Interfaces

Introduction to Dual Control in Code Signing

Code signing is the process of digitally signing executables or scripts to ensure integrity and authenticity of the code. This way the software vendor can guarantee that the code has not been tampered with. For signing the code, the software vendor uses a private key that needs to be protected from stealing and from misuse.

Unfortunately, the applied protection mechanisms are often not sufficient as the history shows. An infamous breach of a code signing key happened to Solarwinds, which affected the IT of about 18,000 customers [source].

Just imagine, if software for airliner cockpits or nuclear power plants are hacked by attackers. The possible damage would be disastrous. So understandably, code signing should be done with due diligence.

For more information on the need for signing code, please read the blog on introduction to code signing

But before we go into the protection of the code signing key, let’s take a step back and have a look at how code signing is done on a high-level. Depending on the code type that is supposed to be signed, like JARs, Windows files or Docker containers, different signing tools are used. Very common ones are depicted in Figure 1.

Figure 1: Typical Code Signing Tools Using Standard Cryptographic Libraries

As this diagram shows, these code signing tools, use standard cryptographic interfaces, such as JCE, CNG or PKCS#11, which are the predominant interfaces for signature processes. These cryptographic interfaces provide access to the signing keys, which are stored within a key store.

Unfortunately, these cryptographic interfaces were designed decades ago and do not feature any support for dual control. However, there is a solution providing dual control, which is detailed in this blog.

Requirements for Code Signing

But before we go into the solution, we need to have a look at the requirements for code signing. What needs to be in place to prevent misuse of code signing keys?

Let’s check official standards and recommendations. Highly relevant are:

• NIST - Zero Trust Architecture
• CASC (CA Security Council) - Code Signing Whitepaper
• CA/Browser Forum – EV Code Signing Guidelines
• NIST – Security Considerations for Code Signing

Also, it should be taken into account that code signing is a major step for achieving compliance with the Cyber Resilience Act, which is an upcoming European regulation.

In short, these documents, inter alia, define the following main requirements for code signing:

• Provide a Role Based Access Control (RBAC) to follow the principle of need to know.
• Setup custom roles to conform to the principle of least privilege.
• Introduce strong authentication to prevent account compromise.
• Perform continuous monitoring and maintain a tamper-protected audit log to prove what happened on the system
• Usage of extended validation (EV) certificates.
• Store code signing keys in tamper-evident crypto modules, ideally a FIPS 140-2 Level 3 compliant HSM.
• Use a Key Management System (KMS) to manage your code signing keys.
• Set up dual control to protect your code signing keys from rogue single persons.

For all the points above, several solutions are already available on the market, except the last point in the list about dual control. As mentioned in the beginning, standard crypto interfaces just do not cover the concept of dual control. Fortunately, Fortanix has invented an excellent system to combine dual control with standard crypto interfaces, as explained in the next section.

Dual Control for Code Signing

Dual control, also called multi control or 4-eye principle, describes the process to only permit a task after at least two different individuals have separately approved this task. In case of code signing, the signature operation itself shall be protected by dual control.

Figure 2 depicts such a signing process including dual control. A developer intends to sign a code with his code signing tool. The code is hashed by the code signing tool and then forwarded inside an approval request to the KMS.

The KMS has an approval policy set on the code signing key and therefore informs (e.g. via email) the possible approvers about the signing process. Hereby, the KMS can follow an n out of m quorum.

Typical quorums are e.g. 2/3, which means that 2 persons of a group of 3 people must approve a request. Only after the required number of persons have approved the request, the signature is calculated and returned to the code signing tool, which embeds the signature into the code.

Figure 2: Code Signing Procedure Using Dual Control

This quorum approval process on standard crypto libraries as JCE, PKCS#11 and CNG is implemented in Fortanix Data Security Manager (DSM), along with all the other requirements as mentioned in the chapter above.

DSM features a user-friendly user interface allowing the approvers to review the approval request and to decline or approve it, as depicted in Figure 3. Hereby, the important information displayed for approving signing of code are:

• Who or what has requested the approval process?
• What is the approval process about?
• Which digital key is involved?
• When has the approval process started?
• Who are the allowed approvers?
• Who has approved the request already?

Figure 3: DSM Task Approval Pane

DSM features also a more detailed pane, showing this further information:

• Which data or hash is to be signed?
• Which hashing algorithm is applied?
• Which signing method is selected?
• What is the ID of the request for later references?

Though this information is rather technical, it is crucial to make sure that the correct data/hash is signed. Figure 4 shows how this further information is displayed in DSM.

Figure 4: DSM Task Detail Approval Pane

Further Recommendations for Managing Code Signing Keys

Besides the requirements for code signing as mentioned above, there are other KMS features that will make the life of a software company easier. Though they are not strictly necessary, it is good practice to follow them. These recommendations are:

• Define a cryptographic policy within KMS to ensure no weak keys are ever generated or used.
• Establish a key undo policy in KMS, to prevent the accidental loss of vital keys, in case all participants in this process delete the key mistakenly.
• Create a key metadata policy so no keys are generated without important custom attributes, e.g., the project ID or the requestor name, which will easy the management of the key.

Conclusion on Dual Control for Code Signing

Code signing is a critical task in the software development process. Therefore, a couple of safeguards have to be put in place, like utilizing a FIPS 140-2 Level 3 HSM, monitoring the system, and following a zero-trust concept. However, the critical part of dual control for the signature process should not be missed. Hereby, Fortanix DSM provides a neat solution to apply a quorum approval on the typical standard crypto interfaces.

For more information, please contact Fortanix.