Preventing a recurrence of the Realtek/JMicron fiasco
pgut001 at cs.auckland.ac.nz
Thu Aug 5 05:24:07 EDT 2010
I've been having an off-list discussion with someone about how you'd prevent
the recent Realtek/JMicron certificate fiasco. My thoughts on this:
Since many development shops see the signing process as nothing more than an
annoying speed-bump that stands in the way of application deployment, not
helped by the fact that code-signing tools like Windows SignTool and Unix'
GPG are hard to use and poorly integrated into the development process,
developers have generally used the most expedient means possible to sign
their code, with signing keys left unprotected or with easy-to-guess
passwords (trivial variations of "password" are a favourite in web advice
columns that give examples of how to do code signing ), or passwords
hard-coded into the scripts that are needed in order to integrate the
signing into the build process. Combine this with the existence of entire
families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus that
integrate key-stealing functionality and it's inevitable that legitimate
code-signing keys will end up in the hands of malware authors.
 "p at ssw0rd" is the "password1" of code signing.
So my advice would be to keep the signing key on a dedicated, non-network-
connected machine that takes to-be-signed input from a USB drive with autorun
turned off (or, better, Didier Stevens' USB-protection driver installed,
http://blog.didierstevens.com/programs/ariad/) and sign that. For test
purposes during development you can always sign with test keys, and then only
sign the final release once it's passed QA. Even if you don't want to go that
far, just getting rid of the current worst practice would be a start, where
code-signing keys are just random data to be copied onto every developer's
machine with no password or a fixed password coded into batch files.
Potential issues/discussion topics:
- The signing tools should include a test key along the lines of the EICAR
test virus sig. that's included by default and recognised everywhere as
being purely a test key, to create a zero-overhead way of leaping the
signing hurdle during development.
- As an extension of the above, the development environment should have some
checkbox option to test-sign debug builds of binaries so developers don't
have to google + cut&paste obscure command-line strings and batch files into
equally obscure config dialogs in their IDE.
- Developers may need to repeatedly sign test releases and beta releases. How
do you distinguish "signature for testing purposes" from "signature for live
release"? Pretty much anything you do, e.g. throw up a warning every time a
test-signed version is run, is going to cause enough discomfort eventually
that developers will go back to using the release key.
Any other issues that anyone can think of?
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography