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.
Jon
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
