[cryptography] How are expired code-signing certs revoked?

Jon Callas jon at callas.org
Sat Dec 10 12:44:16 EST 2011

On 9 Dec, 2011, at 2:08 PM, Steven Bellovin wrote:

> On Dec 9, 2011, at 3:46 18PM, Jon Callas wrote:
>> On 8 Dec, 2011, at 8:27 PM, Peter Gutmann wrote:
>>> In any case getting signing certs really isn't hard at all.  I once managed it 
>>> in under a minute (knowing which Google search term to enter to find caches of 
>>> Zeus stolen keys helps :-).  That's as an outsider, if you're working inside 
>>> the malware ecosystem you'd probably get them in bulk from whoever's dealing 
>>> in them (single botnets have been reported with thousands of stolen keys and 
>>> certs in their data stores, so it's not like the bad guys are going to run out 
>>> of them in a hurry).
>>> Unlike credit cards and bank accounts and whatnot we don't have price figures 
>>> for stolen certs, but I suspect it's not that much.
>> If it were hard to get signing certs, then we as a community of developers would demonize the practice as having to get a license to code.
> Peter is talking about stolen certs, which for most parts of the development
> community aren't a prerequisite...  But there's an interesting dilemma here
> if we insist on all code being signed.
> Assume that a code-signing cert costs {$,€,£,zorkmid}10000/year.  Everyone but
> large companies would scream.  Now assume the cost is {$,€,£,zorkmid}.01/year
> or even free.  At that price, it's a nuisance factor, and would be issued via
> a simple web interface.  Simple web interfaces are scriptable (and we all know
> the limits of captchas), which means that malware could include a "get a cert"
> routine for the next, mutated generation of itself.  In fact, they're largely
> price-insensitive, since they'd be programmed with a stash of stolen credit
> cards....

Well said, Steve, and that's largely my point. Any code signing system that wants to survive the scrutiny of people like us has to essentially hand out certs for free. (And there are regimes that in fact do that, and work well.)

Therefore, you must assume that any given cert might have been stolen or simply issued to a bad person. The sketch I gave previously about how code-signing is useful even with zero trust on the signing certs. You detect malware by signatures, hashes, and keys, and *then* by content scanning, and build up whitelists and blacklists. It isn't perfect, but it works better than mere content scanning alone.

Any code-signing system that assigns worth to the developers based upon certificate issuance is effectively agreeing with those who think that evil-doing can be stopped by ID cards and an attendant ban on anonymity/pseudonymity.

There is, however, a way to surpass the loosie-goosy signature system. If the software marketplace itself were to issue signatures, then you'd have a way to get an improvement. You'd really want to back up the mere digital signature with an assurance system. If the marketplace enforced code reviews, and backed up the code reviews with a capability-based OS so that they could enforce some practices (for example, you could keep a Disgruntled Birds game from turning on the microphone and camera with capabilities and a code review), then you would expect such a software marketplace to have a dramatically lower rate of malware. 

They'd have that lower malware rate because in that system, the digital signature is an assurance mark on top of an actual assurance system. The debate that we're having boils down to wringing our hands over how to make an assurance mark that assures quality with no underlying assurance evaluation and enforcement.

If someone actually built such combination of OS and marketplace, it would work for the users very well, but developers would squawk about it. Properly done, it could drop malware rates to close to nil.

But anyway, you're absolutely right, and that's really my point. A code signing system that operates on its own has to assume that certs get lost, stolen, or handed out to bad (or misguided) people, and have that as part of its threat model.


More information about the cryptography mailing list