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...@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 majord...@metzdowd.com