Browse Prior Art Database

A Practical Code Signing Server for the Enterprise Disclosure Number: IPCOM000236621D
Publication Date: 2014-May-06

Publishing Venue

The Prior Art Database


A Practical Code Signing Server for the Enterprise

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% of the total text.

Page 01 of 10

A Practical Code Signing Server for the Enterprise


Digitally signed code is increasingly a requirement for patches and code updates. As is usually the case with public key applications, the math is the easy part. This paper offers a solution to the hard parts - private key security, administration, conformance to corporate standards, availability, and ease of use.

We discuss the evolution from a system that was nearly too secure to a new architecture that meets that needs of a practical enterprise application. It is based on digitally signed email for authentication and a signing server with a hardware security module to protect the signing keys.

As code patches and updates are increasingly distributed through the Internet, using web sites or automated processes built into the code, there is a basic need to authenticate the code. Is the source trusted Has the code been modified in transit

Examples are BIOS code [1] and the otherwise immutable CRTM code block [2], and UEFI capsules [3]. Others include signed Java applets, Windows drivers through the Microsoft WHQL program, and Linux software packaged as an rpm and distributed over the Red Hat Network (RHN). As hardware updates such as FPGA microcode become distributed over the Internet, we expect authentication through code signing to become a requirement.

We do not address the complementary issues surrounding key change, compromise, and expiration. See [8]. Previous Solution

Our previous solution, in production for several years, places the signing server off the network, in a locked room with controlled access. The signing keys are generated by a hardware security module (HSM), which exports them for backup wrapped (encrypted) by a master key.

In use, a trusted project member brings the code to the server on a USB stick. After logging in to both the Linux server and the hardware security module (HSM), the user supplies the encrypted private key to a signing application customized for the project, which uses the HSM to sign. The signed code is transported back via the USB stick. There are several drawbacks to this approach. Although in theory each project should have a trusted member doing the code signing, in practice there are a few people signing for everyone. Partly this was a training issue. More important, project members from Alaska or Hawaii just weren't going to fly in with USB sticks.

Once signing became limited to a few people, the social engineering issue arose. When Joe got a call at 3 in the morning to immediately sign code for someone in Alaska that he didn't know, he had a hard choice, and neither decision was the right one.

Outline of the Paper

It became obvious that we had to put the signing server on the network. The question was not whether to do it but how to do it securely.

We describe the architecture and flow of the solution in this section.

In the next section, we explain the security features. The section after that explains how...