Where is the private key stored?

[Sathyaish]

Where is the private key to an assembly stored?

The public key is stored in the manifest. All clients that reference
the shared assembly, when compiled, store the public key _token_ into
their manifests along with a hash value for the referenced assemblies.

However, the private key is not distributed. From what I've read, it
still remains with the author on his machine in the .snk file generated
by the sn utility.

If the private key never leaves the development PC, how does the
production server where the shared assembly is deployed sign itself so
that its clients may be assured of its authenticity?

 

[Nicholas Paldino [.NET/C# MVP]]

Sathyaish,

It doesn't. The assembly is signed before the assembly is distributed
to the production server.

 

[Sathyaish]

The assembly is signed before the assembly is distributed
to the production server.



Nicholas,

Here's my understanding and let's see if we can reconcile it with the
facts.

The assembly is signed by running the sn utility on it. This generates
a file that carries the public and private key pair. The pair is not
yet linked to the assembly until you specify the
Assembly:AssemblyKeyFile attribute in the assemblyinfo.cs file, and
then build the project (to install the key pair into the CSP).

After this, I am lost. The assembly is installed in the GAC on the
production server using gacutil -i or an msi installer.

How does the private key move from the .snk file on the development PC
to the production server? Do you mean that when the project is built
after giving the assembly a strong name, the private key is also munged
into some part of the assembly? Just like the public key is written to
the manifest, is the private key also written to some other portion
(may be the IL itself or the metadata section)?

 

[Nicholas Paldino [.NET/C# MVP]]

Sathyaish,

No, the private key is not located anywhere in the assembly. The idea
here is that an assembly with a public key can only be created by the person
who has the private key.

If the private key was in the assembly, then someone could extract it,
and compile their own assemblies with your identity.

 

[Sathyaish]

Nicholas,


I know what you're saying and it makes a lot of sense. However, I am
still confused. I am not able to reconcile a few ideas.

If the assembly on the target/production server does not carry with it
any signatures in the form of a private key, then how does it know when
a new version wants to overwrite it, that the new version comes from an
authentic source?

 

[Lloyd Dupont]

Your problem is about understanding the more general problem private/public
key concept in cryptography.

I will let it up to you to find relevant reading, just explain this
particulare case.

Basically there is a 'secure signature' in the assembly however it's called.
It's a hash of the assembly encrypted with the private key.
Because the public key is public, every one could use the public key to
decrypt the signature and verify it corresponds to the assembly's hash.

But only the private key could produce this signature. And private & public
key for a pair.
So you know it's valid.

 

[William Stacey [MVP]]

At compile a hash is made of the assembly bytes, then signed by the private
key. The signature is stored as well as the public key inside the assembly.
After this the private key is never again (unless you keep recompiling.)
When the code loads the hash is computed again and verified against the
signature. The public key is used to decrypt the signature and the two
clear hashes are compared for equality. If someone changes the code, the
hashes will not compare. If someone changes the public key in the assembly,
the hashes will not equal. However, it is still possible for a third party
to fully resign the assembly with their own key pair which would allow them
to change the assembly and have it still load as normal. This signing was
not developed to protect your assembly (as some still think), the primary
goal was to uniquely (and unambiguously) identify assemblies.