Re: Designing a Code Signining System

[mike () sharecube com]

You are right to be concerned about controlling access to code signing. There are exploitable flaws with the proposed 
solutions.

The web based ("Hi-Tech") solution can be exploited by a Trojan within your organization. It can pretend to be a valid 
request from inside the organization and acquire a key. The Trojan can then use this key anywhere it wants.

The "Low-Tech" approach, as described in the post, has no accountability except for physical access. This is subject to 
a mischievous user who may sign any code.

An alternative doesn't have to be much more technical and can be high-tech. You will need two sets of keys. I would ask 
the following:

a) User produces a binary from a sanctioned build system based on checked-in sources. The build system signs the binary 
using its private key. (key set 1).

b) As part of the release, the build system asks an authentication system to officially sign the binary and submits the 
binary from step 1. The authentication system unsigns the submitted binary (using the build system's public key), then 
signs it using a private key. (key set 2).

This is stronger but not bullet proof. The authentication system is connected to an intranet that is open to attacks in 
a number of ways. Therefore it can be exploited by common viruses and Trojans unless it is highly secured and patched. 
It is also subject to attack by a determined attacker.

The right mix of solution depends on what you are trying to protect.

Mike Podanoffsky
mike /at/ sharecube /dot/ com