Preventing a recurrence of the Realtek/JMicron fiasco

[Peter Gutmann]

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 [0]), 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.

  [0] "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?

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com