4

I am curious, through Google research I have been learning about digital signatures and strongly named assemblies. It appears possible to use a digital signature to sign a strongly named assembly if you really try hard.

I speculate that with this practice it is possible to circumvent the purpose of a digital signature by using it this way.

Microsoft says:

"strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate."
-- http://msdn.microsoft.com/en-us/library/wd40t7ad%28v=vs.110%29.aspx

Am I correct in guessing that using a digital signature in this way is actually a bad practice, that may create a security hole and definitely serves no purpose? Or is it even possible? Is using a digital signature as the strong name possible or better then then doing nothing? Does it provide some extra security beyond using a digital signature properly.

amalgamate
  • 2,200
  • 5
  • 22
  • 44
  • The Microsoft .NET Framework assemblies are strong named and digitally signed by Microsoft. – Michael Liu Mar 06 '14 at 20:40
  • @MichaelLiu Umm What are you trying to say? details? – amalgamate Mar 06 '14 at 20:45
  • If Microsoft does it, then surely it can't be all *that* bad a practice to digitally sign a strong-named assembly. – Michael Liu Mar 06 '14 at 20:52
  • @MichaelLiu Now that sounds like a clear and good answer to me. Except to be clear: you are saying that the strong names that Microsoft use the same signatures for their Strong Named Assembly signature as their digital signatures? There can be a separate signature of each, right? – amalgamate Mar 06 '14 at 20:58
  • possible duplicate of [Signing of .NET Assemblies](http://stackoverflow.com/questions/1334631/signing-of-net-assemblies) – Alexei Levenkov Mar 06 '14 at 20:59
  • @AlexeiLevenkov I think you are missing a subtle point. I want to know about an imagined (al be it my own imagination) hole in security from the linking of these two concepts. Not precisely to know how it works in a general but to understand one focused detail of the same subject mater. I actually read that post in my research. – amalgamate Mar 06 '14 at 21:07
  • @amalgamate: Strong names and digital signatures are separate and use different keys. – Michael Liu Mar 06 '14 at 21:20
  • @MichaelLiu another excellent point, but does that mean it is impossible to mix and match them? That would answer my question soundly, especially if it was in the form of an answer. – amalgamate Mar 06 '14 at 21:23
  • You should read my article on this subject. http://blogs.msdn.com/b/ericlippert/archive/2009/09/03/what-s-the-difference-part-five-certificate-signing-vs-strong-naming.aspx – Eric Lippert Mar 06 '14 at 22:19
  • @EricLippert Thanks, I did before my post, but it is a fine article that is clear. Just to be sure, I take it that strong naming is mostly intended for the GAC to use for the prevention of DLL hell, and I suppose my secret point and or question in the form of an answer is that using Strong Naming for something else (security) is not as productive when we have another tool available which is at least slightly better. – amalgamate Mar 07 '14 at 15:28
  • Note I have removed the vague references I had to other posts as I think they are not helpful to the question, and seem to be distracting as well. – amalgamate Mar 07 '14 at 15:45
  • 1
    **No.** Strong naming is not to prevent DLL hell. The *version* in the name prevents DLL hell, but that's not what makes the name *strong*. What makes the name *strong* is the public key token, and *that* is there for a security purpose: to provide *evidence* that is the input to *security policy*. – Eric Lippert Mar 07 '14 at 15:49
  • @EricLippert I see, says the blind man. Except, if you are explicitly linking using the GAC I think you are using more than just the version because I thought I read that you can use this to delineate between two libraries with the same name. Am I wrong? – amalgamate Mar 07 '14 at 15:58
  • 1
    An assembly in the GAC is required to have a strong name; you shouldn't be putting code in the GAC if you don't have evidence of where it came from. Again: the DLL Hell solving part of the name is the *version*. The I-want-to-run-code-actually-written-by-Microsoft solving problem is the *key token*. – Eric Lippert Mar 07 '14 at 16:08
  • @EricLippert So the central key to my misunderstanding is that strong naming **is** A security feature and not something exclusively intended to the GAC as I may have misunderstood. Further confusing me was that Digital signing is a similar but different feature. (no need to elaborate as their differences are clear in your article.) – amalgamate Mar 07 '14 at 16:37
  • 3
    It is unfortunate that two very similar things exist because it leads to confusing conversations like this one! :-) Were I made king of .NET and given the chance to do it all over again I would have made strong naming and signing with a certificate the same thing, and made the strong name key generation tool produce a self-signed certificate. – Eric Lippert Mar 07 '14 at 16:45

3 Answers3

10

Is it a bad practice to use a digital signature to sign a strongly named assembly?

No. That's a perfectly good practice.

It appears possible to use a digital signature to sign a strongly named assembly if you really try hard.

It's a bit tricky, because both strong naming and digital signing modify the assembly. The assembly must be first strong named and then signed.

I speculate that with this practice it is possible to circumvent the purpose of a digital signature by using it this way, as the strongly named assembly can be hacked

OK, so you're speculating that there's an attack. I'm speculating that there isn't. State the vulnerability and the proposed attack.

(at least some post said so).

Are you going to make us guess which post said so?

"strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate."

That's correct. Strong names and digital certificates are similar but they solve different problems. Strong names solve the identification of assemblies problem. Signatures solve the chain of trust problem.

I have seen examples of Internet posters trying to do exactly that thinking that they are protecting their software.

Neither strong naming nor certificate signing protects software at all! The purpose of a security system isn't to protect the software, it's to protect the users. We don't have driver's licences to keep the Department of Motor Vehicles safe from attack by ninjas. We have drivers licenses to establish that the bearer of the license really is who they say they are and is permitted to drive. Anyone who thinks that strong naming is there to protect the software is very, very confused.

Am I correct in guessing that using a digital signature in this way is actually a bad practice, that may create a security hole and definitely serves no purpose?

No, you are wrong on every count.

it a good or bad thing to cross the streams (please excuse the humor.)?

Why would it be a bad thing? All we have is your claim that there is an attack, and no evidence whatsoever that there actually is one.

Or is it even possible?

Sure it's possible.

are the posts I have seen with references to using the two in concert (using a digital signature to sign an assembly specifically as strongly named (not digitally signed)) possible or better then then doing nothing?

You're asking us to comment on the accuracy of posts that we haven't read and you haven't provided links to. How should we know whether they're accurate or not?

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • No need to hunt down other posts, I am sure that some were inaccurate and some were not. I bring them up as motivation for my question, they are not important to the question's meat. I will consider removing that portion. The point of the question is simple (at least in my own mind), but I will see if I can make it match the accepted answer better. – amalgamate Mar 07 '14 at 15:02
  • In out product we started with strong names and digital signature for every assembly. We run into problems on machins that are not connected to the internet or corporate networks. In healthcare buisness it's normal. There is a long delay before the process of a digital signed EXE started. This is caused by an outdated ceritificate revocation list, which the system try to update. But no internet access or a DNS server are exists, so a DNS timout of +/- 30 sec. must occur before the process is started. This is a situation where the digital signature generates problem and additional work. – embee Mar 18 '14 at 10:59
4

There is no trust chain exists for keys used to strongly sign assemblies. You can't use the same type of keys for strong name signing and "code signing": so there is no problem "mixing and matching". These two types of signing server two different purposes and you need to pick ones that you need in your particular case (most likely just strong name signing and .Net does not have built in verification for the other one).

With signing for strong name you can't say if particular key belongs to particular entity, unlike other types of signing where you know source of the signing certificate (i.e. authenticode signing or SSL certificates for HTTPS) and can be reasonably sure about origin.

Strongly signing tells you that assemblies signed by the same key created by the same "entity", but there is no indication of what/who this "entity" is. You can't really say "this new version of assembly is built by FooBar company", you can only say "it build by the same company/group as previous one".

Note: Indeed there are some "well known" public keys (i.e. Framework assemblies signed by Microsoft), but you can't get any assembly and say "signed by X" just by looking at the public key.

Note that this covered in details in Eric Lippert answer - Signing of .NET Assemblies .

Community
  • 1
  • 1
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • OK, so far so good, confirming much of what I have read. Is it worse than doing nothing though? are you risking your certificate by using it improperly to strongly name an assembly. (although I take it you are saying that is a difficult and prohibitive thing to do.) – amalgamate Mar 06 '14 at 20:53
  • Found correct duplicate answer by Eic Lippert - http://stackoverflow.com/questions/1334631/signing-of-net-assemblies . I believe you can't provide you custom cert for strongly signing, so you can't "risking anything" that way. – Alexei Levenkov Mar 06 '14 at 21:01
  • I think your comment, like @Michael Liu, answers the question... at least almost, except that they are comments. – amalgamate Mar 06 '14 at 21:10
  • @amalgamate - I've inlined comment, also I think Eric's answer covers you main point too - two types of singing are just different and unrelated. – Alexei Levenkov Mar 06 '14 at 21:43
  • BTW, +1, you have gone a long way to help me understand this. – amalgamate Mar 07 '14 at 15:05
3

Just splitting this up into clear bits, because I'm not quite sure what you're asking.

Is it possible to use the private key of a digital signature (e.g. Authenticode) to strongly name an assembly?

Yes, at least in theory - since all a key is is a sequence of bytes.

Would there be any point in doing so?

Since you don't need to pay for a private key for strong naming, using a paid-for digital signature to do it wouldn't make much sense, no. What you pay for is the trust associated with the digital signature. Strong naming, as Eric Lippert, Alexei, and others explained, doesn't assert trust.

Would it be a security hole if you did so anyway?

No. Whether you're digitally signing or strong naming, and no matter what private key you may use for it, all you're giving out with the assembly is the public key. A public key is meant to be public knowledge - that's the whole point of asymmetric cryptography. As long as your private key remains private, there's no hole.

ETA: I would like to see the post(s) mentioned in the question, about strong naming using an Authenticode signature (as opposed to combining the two), though.

JimmiTh
  • 7,389
  • 3
  • 34
  • 50
  • +1: I think "giving out with the assembly is the public key" is the answer to main concern of this question. – Alexei Levenkov Mar 06 '14 at 21:46
  • I think you understood very well what I was asking actually. – amalgamate Mar 06 '14 at 21:50
  • I'm glad. :-) Please see the edited answer (bottom) - if you could link to any of those posts, I'd like to see them out of interest. – JimmiTh Mar 06 '14 at 21:52
  • this is one post of many, that seemed to have the idea in their head, yet I know it was a part of a question where op was not clear on the point either. Most were like that. http://stackoverflow.com/questions/8300865/strong-naming-or-authenticode-signing-a-new-assembly?rq=1, I think I remember some posts regarding cell phone apps that seemed more vaguely sure of themselves, however I could not find them when I looked briefly through my browser history. the point is that I found some way to be confused in my own understanding after seeing others confused. – amalgamate Mar 06 '14 at 22:10
  • 1
    Yeah, I think the main point there isn't to *use* Authenticode for strong naming, but rather that the client wants SN - and the OP is already Authenticode signing his code and wonders if that alone serves the purpose of strong naming - which it doesn't. As @AlexeiLevenkov said, the two concepts serve different purposes. – JimmiTh Mar 06 '14 at 22:21