locked
use of snk file RRS feed

  • Question

  • Hello everybody,

    This is somewhat layman's query.

    i have read about snk files to be included in the assembly to sign it and protect it from unknown people for which it is not meant for.

    I don't understand that how can we protect an assembly from an snk when we pack that in the assembly itself.

    Can somebody please t ake out some time and explain what exactly is the purpose of snk file and how exactly it serves that purpose.

    Also why do we need a Assemblydelaysign property in assemblyinfo.cs file.

    Thanks for your help

    rajiv

    Monday, August 21, 2006 11:52 AM

Answers

  • Rajiv,

    my explanation will be far apart from a scientific explanation of the case, but my intention is to explain, with simple words, the idea behind cryptography of public and private keys

    This mechanism is usually used to guarantee that the emisor of something is really who is supposed to be. In our .NET context, I sign my assemblies to give you the security that nobody can replace them with his/her own logic

    To do that, I generate in advance a pair of keys. The private key will remain with me forever and neither you nor the hacker will have access to it never. For every assembly, both you and me will calculate a digest through some hash function (Secure Hash Algorithm 1, SHA-1 or similar). But...

    I will sign that digest with my private key, attaching it into the assembly together with the public key. You are able to calculate the digest from the received assembly using the same hash function. But you alse need to decrypt the attached digest and compare it with what you calculated. To decrypt it, you'll need the enclosed public key. That key can just decrypt values, not encrypt them

    So let's consider that someone else try to replace my assembly without having the private key. He has to encrypt the digest but... without the right private key, he just will produce a digest that won't match the digest you calculate, once you receive the encrypted digest and try to decrypt with the public key

    Yes, I guess what you are thinking: the hacker can generate his own pair of keys, enclosing his own public key, spoofing thus my identity. But here is where the .NET framework shows its power:

    I, as a provider, give you from the very beginning the public key you'll need to decrypt my digests. So what you have to do with that is enter in the .NET Framework Configuration Console (Control Panel, Administrative Tools) and there you have to select "Configure Code Access Security Policy / Increase Assembly Trust". There is a wizard that will permit you trust in all assemblies with a specific public key. There you have to put my public key, and any other public key of the rest of providers you trust -probably that includes yourself: your own organization as a provider of in-house code, right?-

    So, in the case the hacker provide his/her own public key, .NET's Code-Access Security (CAS) won't trust in this not enlisted public key, causing a SecurityException

    I won't extend in the rest of set up details but that's the overall approach about how Strong-named Assemblies work, and what role have private and public keys

     

     

    I hope my explanation was clear and helpful. More about Security best practices: http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag2/html/PAGGuidelines0003.asp

    Saturday, August 26, 2006 7:50 AM

All replies

  • The SNK file is not embedded in the assembly. It's only used when you sign it. The public key is written to the assembly so the signing can be verified, but the private key is kept private.

     

    Monday, August 21, 2006 12:13 PM
  • Hi Mattis,

    Thanks for your reply.

    Continuing on what you responded, where do that private key remains.

    as per your suggestions,if i make a msi file of a windows appplication, we will pack both assembly and exe file .but where will be  the private key.if we pack it inside, that will no longer be private.

    and taking the other case that we keep the private key with us, then how do all software companies allow there softwares to be downloaded.do they give private key seperately. i think they don't

    so in what case and how exactly we use this private key.

    regards

    Monday, August 21, 2006 1:06 PM
  • Rajiv,

    my explanation will be far apart from a scientific explanation of the case, but my intention is to explain, with simple words, the idea behind cryptography of public and private keys

    This mechanism is usually used to guarantee that the emisor of something is really who is supposed to be. In our .NET context, I sign my assemblies to give you the security that nobody can replace them with his/her own logic

    To do that, I generate in advance a pair of keys. The private key will remain with me forever and neither you nor the hacker will have access to it never. For every assembly, both you and me will calculate a digest through some hash function (Secure Hash Algorithm 1, SHA-1 or similar). But...

    I will sign that digest with my private key, attaching it into the assembly together with the public key. You are able to calculate the digest from the received assembly using the same hash function. But you alse need to decrypt the attached digest and compare it with what you calculated. To decrypt it, you'll need the enclosed public key. That key can just decrypt values, not encrypt them

    So let's consider that someone else try to replace my assembly without having the private key. He has to encrypt the digest but... without the right private key, he just will produce a digest that won't match the digest you calculate, once you receive the encrypted digest and try to decrypt with the public key

    Yes, I guess what you are thinking: the hacker can generate his own pair of keys, enclosing his own public key, spoofing thus my identity. But here is where the .NET framework shows its power:

    I, as a provider, give you from the very beginning the public key you'll need to decrypt my digests. So what you have to do with that is enter in the .NET Framework Configuration Console (Control Panel, Administrative Tools) and there you have to select "Configure Code Access Security Policy / Increase Assembly Trust". There is a wizard that will permit you trust in all assemblies with a specific public key. There you have to put my public key, and any other public key of the rest of providers you trust -probably that includes yourself: your own organization as a provider of in-house code, right?-

    So, in the case the hacker provide his/her own public key, .NET's Code-Access Security (CAS) won't trust in this not enlisted public key, causing a SecurityException

    I won't extend in the rest of set up details but that's the overall approach about how Strong-named Assemblies work, and what role have private and public keys

     

     

    I hope my explanation was clear and helpful. More about Security best practices: http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag2/html/PAGGuidelines0003.asp

    Saturday, August 26, 2006 7:50 AM
  • Hi Diego,

    You have given the best possible elaboration on why to use snk files.

    Thanks a lot

    regards

    rajiv

    Monday, August 28, 2006 9:28 AM
  •  

    1. After I use "sn -k MyKey1.snk" the snk file is created.
    2. I then goto my solution and add an existing item.
    3. Select the key file I just created
    4. It is added to my solution
    5. when I click it to edit the assembly data the file opens as a garbage
    text file within .Net

    I'm I missing something here? The key file when created also does not have
    the "key/lock" icon in explorer.
    Wednesday, September 19, 2007 6:35 AM
  • You don't have to add the file to the project (unless you want to include it in source control for example). But you should go into the project properties (the Signing tab if using VS2005) and point to the file from there.

    Wednesday, September 19, 2007 6:55 AM
  • I'm wondering how other people deal with keys/source code control in their suite of applications.

     

    I generated private and public keys and stuck 'em at the root of version control.

     

    With any new projects I go into the properties signing tab and reference the key file. Of course, this pulls down a local copy of the key. When I go to add the project into SCC, I have to make a decision whether to add the copied snk file.

     

    My instinct is to NOT add it. I certainly don't want dozens of copies of the same file, plus this would preclude me from changing the file and recompiling everything.

     

    But... any time I pull down a new copy of such a project, it won't compile until I reestablish the key link.

     

    So how do you handle this?

     

    One idea I had: create a LINK in VSS to the root snk file instead of adding the copy.

    Thursday, January 24, 2008 3:37 PM
  • Are the SNK and private key the same thing in this context?
    Friday, January 11, 2019 3:21 PM