verifying the authentity of an assembly producer with strong naming?

  • Thread starter Thread starter Reinhold Schalk
  • Start date Start date
R

Reinhold Schalk

Hello,
somewhere i've read that using strong names does assure two things:
1. Assure that the content of the assembly is not modified (that's ok in my
opinion)
2. Assure that the assembly is really from the "fabricator" (?)

If these two point are correct (i'm not sure), i have a problem with point
2.
To assure the authentity of the fabricator, the public key (which is a part
of the manifest) has to be checked against a certificate.
Is this really done? If yes, who does this? And what about the SN.EXE
Tool - it's possible to generate a lot of keypairs (for testing).
Certainly in a PKI a company would have a public - private key pair an would
probably use delayed signing.
But how can a client computer really check, whether the installed assembly
is really from this company (checking the public key).
I'm a little bit confused.

Perhaps someone can help me.
Thank in advance.
Reinhold
 
Reinhold Schalk said:
Hello,
somewhere i've read that using strong names does assure two things:
1. Assure that the content of the assembly is not modified (that's ok in my
opinion)
2. Assure that the assembly is really from the "fabricator" (?)

If these two point are correct (i'm not sure), i have a problem with point
2.
To assure the authentity of the fabricator, the public key (which is a part
of the manifest) has to be checked against a certificate.
Is this really done? If yes, who does this? And what about the SN.EXE
Tool - it's possible to generate a lot of keypairs (for testing).
Certainly in a PKI a company would have a public - private key pair an would
probably use delayed signing.
But how can a client computer really check, whether the installed assembly
is really from this company (checking the public key).
I'm a little bit confused.
Click to expand...

Well, basically, an assembly that is linked against a signed assembly has a
reference to the public key token of the signed assembly(its part of the
full type name), so it can verify that that assembly is, indeed, the
assembly that it is supposed to link to. It also wouldn't be impossible for
a tool\class to be written that can check against a published key on the
producers server. You could, for example, have a loader class that will only
load assemblies signed with a set of keys that are under administrative
control, or you can apply permissions based on public key.

The verification can be circumvented, of course, completly removing all
signing from all assemblies is one way, possibly resigning them. Signed code
basically allows untampered with code to verify that the called assembly
hasn't been tampered with as well as allowing endusers a way to verify that
they have an assembly that was signed with a specific companys private key.
There isn't much more of a benifit than that, that I can think of anyway.

I don't understand what the questino about SN is, could you clarify it a
bit?
 
Hello Daniel,
thanks for your reply.
Yes, indeed i do also think, that the primary benefit of strong named
assembly from the endusers point of view is, to know exactly that the
assembly is untampered (not modified).
And if i have understood everthing right, there is no way of "automatically"
checking the public key against a certificate, that means really verifying
that the assembly is really from a specific company (Company X delivers a
strong named assembly and says it's from them (does contain their public
key)).
You are right - perhaps one could write a custom loader class who does this
verification, but that's not the way one would like to go...

Concerning SN-Tool i do not have a question. I have justed mentioned it, if
there would have been a way to verifiy the public key, how would this be
accomplished using the public key generated from SN.EXE.

Again thanks for your reply
Reinhold
 
Reinhold Schalk said:
Hello Daniel,
thanks for your reply.
Yes, indeed i do also think, that the primary benefit of strong named
assembly from the endusers point of view is, to know exactly that the
assembly is untampered (not modified).
And if i have understood everthing right, there is no way of "automatically"
checking the public key against a certificate, that means really verifying
that the assembly is really from a specific company (Company X delivers a
strong named assembly and says it's from them (does contain their public
key)).
You are right - perhaps one could write a custom loader class who does this
verification, but that's not the way one would like to go...

Concerning SN-Tool i do not have a question. I have justed mentioned it, if
there would have been a way to verifiy the public key, how would this be
accomplished using the public key generated from SN.EXE.
Click to expand...

Well, you could publish the public key and write a tool that does the
verification, I'm kind of surprised that sn doesn't have a parameter
(atleast that I can find) that will verify an assembly against a given
public key, asit stands you'd basically need to dump the signed key and the
public key from a keypair\public key file and manually compare them...that
is kind of strange.

basically, use sn -p myKey.snk mypublicKey.snk or whatever file names you'd
use, then distribute mypublicKey.snk in a manner that end users could get at
it to verify that the assembly is properly signed.

But, this is pretty much the end of my knowledge. Hopefully someone who is
more knowledgable about the inner workings of signing will reply with more
information.
 
The public key is enough to indicate that the assembly is really from the
"fabricator", but it does not at all indicate who the fabricator is.
Basically it is imply there the assist in generating a unique name for each
assembly, and to prevent impersonation. If you want to establish identity
or trust relationships with the fabricator, you would have to rely on
classic signing methods like Authenticode.

As far as validating the public key, it is quite easy. "sn.exe -vf
assembly.dll" Will validate the signature. I'm not good with crypto stuff,
but it's using simple public-private key encryption such that anybody with
the public key can decrypt, but only those with the private key can encrypt.
Thus everybody can validate the signature, but only the fabricator can
create the signature. And just like PGP, you still need some other means of
establishing who the "fabricator" really is.
 
Back
Top