Do You Code Sign?

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."

Comments

"Always trust code from Microsoft"

[DeadSea]

The best example of why code signing as it is currently implemented is broken is Windows Update. During the windows update process you are asked to accept signed code and you may "Always trust code from Microsoft". In the context of Windows update, that sounds perfectly legit to most users. They want to update their computers. They don't want to be bothered by the dialog again to do so in the future.

By agreeing to always trust Microsoft you are agreeing to several things you may not realize:

1. You are trusting all code by Microsoft, not just Windows update (obvious to most people)
2. You are trusing Microsoft code that folks other that Microsoft give you to run.

The second one is the kicker. If there is a bug in some signed code by microsoft that allows JavaScript to call it and write to any file, then anybody can give you that signed code and some JavaScript and take over your computer. This will be done without any further notification at all to you as the end user.

You are trusting microsoft to:

1. Write perfect code
2. Envision every possible use of code they write

Even if you believe that code can be bug free, there is no way anybody who write code really locks it down so it can't be used for anything other than what it was intended. There was a security vulnerability that took advantage of just this. I bug in some signed Microsoft code. I'm not sure how it was fixed.

Currency conversion with understands "convert 23 dollars to pounds"

Re:"Always trust code from Microsoft"

[bitslinger_42]

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".

Yes, I sign everything

[Anonymous Coward]

FIRST POST

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
MessageID: 5NWrD3M0/1xt+ynMPHbCYX+e3KSK9qhU

iQCVAwUBOFV2W1FO4fmE3w/VAQHgrgP9GlNAaTdNR7DI/Mh62H aZj49496wbM1Nh
YKlmtJIse2vcLF4LFVLJ47zQi4dK21vPlQ9XXAk4n4cype4gDn p6nWR+Rrz+3DPC
gpTUtsdlxZyMh0PvbAmssEX8z3In+cWgs43sjw6Tf0G4ENx68K 8yCEK0oe/aX0vv
mktgUuXP6A4=
=3mUU
-----END PGP SIGNATURE-----

Re:Bruce is right

[Anonymous Coward]

This isn't "insightful".

You need both a sandbox and authentication of the provider. I can give you code for your sandbox that purports to be a login client for your bank, you enter your creds and I can send them to another URL or do other nasty things.

Code signing is designed to handle the problem of types "is this software from my bank really from my bank". It's the same problem an SSL certificate solves. You can have a perfectly valid SSL certificate, but if it claims to be from your bank and really isn't your data could go anywhere.

In other news, seatbelts proven not to prevent auto-accidents!

Re:Bruce is right

[vadim_t]

It has its value. It's just not a panacea.

You can apply code signing for several things. For instance, you might use it while working from home. This way whoever receives your source can be quite sure it comes from you. This also assures that the source was not changed since you signed it, for instance, by a virus. The later relies on that it couldn't have been infected before it was signed, though.

It could be also useful for distributions. Let's say, somebody breaks into a Debian mirror and replaces sshd with a version with a backdoor. If code signing was in place, you could notice it quite easily. Now, probably you don't trust every developer individually, but trust them because their key was signed by the general Debian key. But still, something can be arranged. For instance:

Debian would have a master key that signs developers' keys. Debian would also have a list of developers, and a list of their projects, also signed with a key. And then there are packages signed by each developer.

To check trust, you check the signature, then make sure the developer who signed it belongs to that project. This way merely being a Debian developer is not enough to put a backdoor in some random package.

Of course, none of this assures complete security. It could be a bug, the developer's key could be stolen, etc. But this gives you interesting mechanisms, such as revoking a developer's key, and it makes life much harder for random script kiddies.

Now, I completely agree that this is not a panacea. But let's be realistic, while a web browser could run in a VM, I doubt very much this approach would work so well with sudo. Being able to make sure that the update to sudo you're about to install comes from the usual developer has some value.