Do You Code Sign? 259
Saqib Ali asks: "I am a regular reader of Bruce Schneier's Blog, Articles, and Books, and I really like what he writes. However I recently read his book titled 'Secret and Lies' and I think he has done some in-justice to the security provided by the 'Code Signing.' On page 163 of his books, he (Bruce Schneier) basically states that: 'Code signing, as it is currently done, sucks.' Even though I think that Code Signing has its flaws, it does provide a fairly good mechanism for increasing security in an organization." What are your thoughts on the current methods of code signing in existence, today? If you feel like Bruce Schneier, how would you fix it? If you feel like Saqib Ali, what have you signed and how well has it worked?
"The following are the reasons that he (Bruce Schneier) gives:
Bruce's Argument #1) Users have no idea how to decide if a particular signer is trusted or not.
My comments: True. However in an organization it is the job of the IT/security dept to make that determination. It shouldn't be left up to users. The IT dept should know not to trust "Snake Oil Corp.", however anything from "Citrix Corp" should be fairly safe. Moreover Windows XP SP2 provides provides a mechanism to create a Whitelist of certain trusted signers, and reject everything else. This is a very powerful security mechanism, and greatly increase the security in a corporate environment, if the workstations are properly configured. Having said that, this feature may not be that useful for home user, who can not tell the difference between Snake Oil and Citrix Corp.
Bruce's Argument #2) Just because a component is signed doesn't mean that it is safe.
My Comments: I fully agree with this. However Code Signing was never intended for this purpose. Code signing was design to prove the authenticity and integrity of the code. It was never designed to certify that the piece is also securely written.
Bruce's Argument #3) Just because two component are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited.
My comment: Again Code Signing was was never designed to accomplish this.
Bruce's Argument #4) "safe" is not all-or-nothing thing; there are degrees of safety.
My comment: I agree with this statement.
Bruce's Argument #5) The fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attack could delete or modify the signature during the attack, or simple reformat the drive where the signature is stored.
My comments: I am not sure what this statement means. I think this type of attack is outside the realm of Code Signing. 'It is like saying host based IDs or anti-virus are useless, because if you can compromise the system you can turn them off.'
I would really appreciate any comments / thoughts / feedback on the above mentioned Bruce's arguments and my commentary. I am planning to give a short talk about benefits of code signing, so any feedback will really help me."
Good comments (Score:3, Informative)
I would add that "always trust X" is not appropriate for home users, and it is good that MS makes the unchecked state the default. I don't recall MS telling me to always trust MS, and if they do, I would want to give them feedback about that wording.
The "always truxt X" feature is best used by domain admins who can pre-approve stuff for their users. It's even better if they can resign the code themselves with a cert on the approved list.
--Jaborandy
Do you code write? (Score:3, Informative)
2 things... (Score:2, Informative)
Maybe Bruce himself reads /. and will post. I read his blog daily and I know he often posts comments in his own blog.
Re:Why code signing sucks. (Score:4, Informative)
Re:"Always trust code from Microsoft" (Score:5, Informative)
In firefox you will have to remove 3 ticks instead of one button, but those ticks are way easier to find. Not that anyone knows, but it is possible.
I do. (Score:2, Informative)
About Bruce's Argument #1, that is true. However, the idea is that whomever they got their certificate from (Comodo, Thawte, Verisign, etc) will revoke the certificate as soon as they do something against the rules. It will show as revoked if the user is on-line when the screen comes up.
I previously heard about someone's certificate being revoked for wrongdoing. I can't remember any of the details.
If the certificate issuers acted fast on reasonable complaints, it could be a great security enhancer.
As it is, the group that gets the most of it is MS (who gets fees from issuers for being in their OS's root certificate) and the certificate issuers.
Re:"Always trust code from Microsoft" (Score:5, Informative)
In addition to the two points on what you are trusting Microsoft to do, there is a third, even more important, thing that you are trusting. By "trusting" the signed code, you also trusting the chain of certificates involved.
"Huh?" you say? "WTF does that mean?" Most of the time, the certificate that was used to sign the code was also signed by another certificate. This is supposed to establish a chain of trust. In Microsoft's example, their root certificate may be signed by Verisign. The theory is that Verisign is trusted by everybody, and therefore if Verisign signs someone's key, the signed key can also be trusted.
Unfortunately, the theory breaks down. There was a well-publicized instance where Verisign issued a code-signing certificate to someone claiming to be from Microsoft but actually wasn't. When Verisign screws up, or otherwise proves themselves to be not trustworthy, then the end user is left with trying to figure out which "Microsoft" keys are good and which ones aren't. Above and beyond the fact that many users aren't equiped to make those decisions, the vast majority simply don't care.
In a closed-form environment (i.e. inside a company with a PKI in place, physical security on the PKI servers and root key, documented procedures for establishing the identities of the cert requestors, where the apps being signed are for internal use only), code signing, and even chain of trust, mostly works. Once you get out of that tight model, the signature on the code only says "This code was signed by someone claiming to be Microsoft".
Argument #5 (Score:3, Informative)
Sometimes "code-signing" is said that even though it does not garantee the safety of a downloaded component, at least you know who to blame if it crash your computer. But, a bad-guy can sign his component, you accept the signature, and then the component can delete all traces of the signature from your computer. So even if you later realize that it was a "bad-component", you have no mean to review the signature.
Who are you anyway? (Score:3, Informative)
Re:Yes, I sign everything (Score:3, Informative)
You joke about that, but that's exactly what the authors of "Who wrote Sobig" did. They published anonymously, but put a public key in their text so no other "anonymous coward" could pretend to be them (or he, she or otherwise).
Re:Bruce is right (Score:2, Informative)
You've got some typos there. The word "if" falsely implies that Debian doesn't already do this. [debian-adm...ration.org] Replace it with "because". Several other words should be changed to past tense.