. Net Assembly Signing Tool Sn.exe key pair SNK file

Source: Internet
Author: User
Tags asymmetric encryption

Tag: Represents a ref local account update algorithm information encryption generation

The. Net Assembly Signing Tool Sn.exe the most basic use of a key to the SNK file (this article is transferred from someone else, and it feels good to stay.) Thanks to the original author! The. Net Assembly Signing Tool Sn.exe the most basic usage of the key pair SNK file

Before I explain the concept of the signature tool, let me say what it is not:

1. It is not a tool used to encrypt an assembly, and it does not have a dime relationship with preventing reflector or ilspy from compiling an assembly.

2. It hates people to associate it with encryption.

I say again what it is:

1. A big name

SN is the abbreviation for strong name, as its name, the purpose of Sn.exe is to give the assembly a unique name (hash+name+version+culture), that is, the signature, guaranteed not to have two different DLLs duplicate (just as the identity card cannot be heavy)

2. Let the caller identify if the called DLL has been tampered with

This is what I want to say, let's first assume a scenario. A hacker is using a bank client program to transfer funds to an account, through the anti-compilation found that the front-end main program Bank.exe call Transfer.dll TransferMoney method to transfer operations. He naturally thought, if I modify the TransferMoney method, multiply the amount parameter by 10, then recompile to Transfer.dll and overwrite the original Transfer.dll, he can become the richest man in the universe!

From this example, it is clear that the security problem that we need to solve is to let Bank.exe have the ability to know whether the Transfer.dll of the call has been tampered with by others. Then we will naturally think, with the Information digest algorithm Bai ~ (nonsense, different content summary out of the 128-bit string is absolutely not the same)

Yes! This big name from SN is the summary information, We can save it in the citation of Bank.exe. I should call Transfer.dll's Digest value Orihash, so we can get a summary of the current Transfer.dll at the time of the call and then compare Curhash and Orihash! Process such as:

        

That seems to be the right answer, but ...

There is a problem with this, that is, your pre-saved digest value Orihash. There are two aspects:

Aspect 1. Once I have updated Transfer.dll normally, the summary has changed, which means you have to notify Bank.exe to update Orihash.

Aspect 2. Security issues raised by issue 1.

For the Aspect 1, I think the main reason is that Once Transfer.dll updated, in order to compare the summary, Bank.exe need to update orihash, update 100 Transfer.dll, you have to update 100 times Orihash, this practice is too deadly, of course, this is only a matter of trouble level, more serious is that we can imagine due to frequent Security issues that arise when updating Orihash.

For the aspect 2, because you always go to update orihash, this link once intercepted by hackers, your orihash is not necessarily guaranteed to be true, of course, I personally think this suspicion a bit too much, because the DLL reference information is usually automatically added to the tool, Unless you transfer this orihash to Bank.exe's project file (such as bank.csproj) through some kind of network mechanism, there is more black risk at this time Orihash, which is a security issue!

So based on the above two points,. NET takes out the asymmetric encryption algorithm this sword! (again, asymmetric encryption generates a pair of keys-the private key and the public key, plaintext is encrypted by the private key can only be decrypted with the public key, and vice versa, so the private key itself to be absolutely confidential, the public key can be given to anyone)

The Orihash is encrypted with the private key as Codedhash and stored in the Transfer.dll. Then in the Bank.exe in order to call Transfer.dll the public key, but must be aware that Transfer.dll inside is absolutely no private key, the private key is only contained in the Mypair.snk file, and only you hold, and with the armed guards to the protection of the people will not be taken away.

So the new verification process is as follows, please combine:

A. First Bank.exe contains the public key, Transfer.dll contains Codedhash

B.bank.exe decrypting Codedhash with public key

C1. If decryption succeeds, it proves that the Codedhash is encrypted with the private key that is paired with my public key.

C11. Summary of the Transfer.dll to get Curhash, and the decryption of the hash comparison, if the same proof Transfer.dll is safe, and is complete, loading can be. If it is different, it proves that the Transfer.dll was tampered with and refused to load Transfer.dll

C2. If decryption fails, it proves that the Codedhash is encrypted with another private key, which is what the hacker did, and also refuses to load Transfer.dll

Such as:

      

This process solves two of the previous problems, That is, when the Transfer.dll normal update, no longer the new hash to the Bank.exe, Bank.exe just use the public key to decrypt the codedhash can know this thing is who sent, and through the decryption of the hash and real-time calculation of the Transfer.dll hash comparison. Here we have a logical assumption that the public key in Bank.exe to invoke Transfer.dll is true. If you say this is black what to do, then I can only say, he can change you this Bank.exe public key information, he wants to change what, you sometime it. In addition, if you say that we are afraid to pass to Bank.exe Orihash have false, then why do you not afraid to pass to Bank.exe's public key is false? I can only say that your logic is very clear, indeed, we can not guarantee, but I would say that after all, the public key is only transmitted once, and orihash may need multiple transmission, the risk probability is different, If we assume that Transfer.dll will never change, that is to say, Orihash is only used once, then I can argue that you use no asymmetric encryption algorithm is the same, because to ensure that the first time to give the Orihash is true and ensure that the first time the public key is true, the two risk factors are the same. Do not know so, people can understand my meaning, I also around for a long time to smooth.

We can assume again the hacker's possible attack method: (note that the hacker cannot move the Bank.exe and the internal PubKey1)

Attack 1: Change and overwrite my Transfer.dll, but Codedhash is identical

In this case, the hash of the Transfer.dll Digest and PubKey1 to the Codedhash decryption results hash is not the same, successfully solved!

Attack 2: Changed and overwritten my Transfer.dll, the hacker generated the public key private key pair, and the Transfer.dll hash with the private key to encrypt into Codedhash.

In this case, when we use PubKey1 decryption Codedhash, because the public key PubKey1 and the hacker's private key is not right, decryption is not open, successfully solved!

Attack 3: Change and overwrite my Transfer.dll, and Transfer.dll is not a signature compiler at all.

In this case, the result and the previous two are the same, the success of the crime!

Attack 4: The hacker brother because can't take your private key, said there is no other attack plan, t_t.

At this point, the principle is finally clear. Now I'll show you how to use Sn.exe to do these things.

I hate that MS has packed so many important tasks in the sn.exe, first of all we have two engineering bank.csproj and Transfer.csproj, we have to do is to achieve the process.

1. Generate the public key private key to the file mypair.snk with Sn.exe. such as: (You have to defend the mypair.snk, because there is a private key, and this is the only place where the private key exists)

        

2. In the transfer project, fill in the Mypair.snk path to the AssemblyInfo.cs file, such as:

        

3. Compile the transfer project and generate the Transfer.dll. At this time The compiler instantly completes the hash of the Transfer.dll, encrypts the hash into codedhash with the private key in the mypair.snk, and stores the Codedhash in Transfer.dll, while the public key information is also stored in the Transfer.dll (note that there is absolutely no private key).

4. In the Bank project, re-referencing the Transfer.dll file, recompiling the Bank.exe, the compile-time compiler extracts the public key PubKey1 in Transfer.dll and writes it in the description of the reference DLL. When we look at Bank.exe with the Anti-compilation tool, we can look at the following information:

Transfer, version=1.0.0.0, Culture=neutral, publickeytoken=3d5e0147c186af58

PublicKeyToken is what we call the public key PubKey1.

5. At this point, no matter if someone compiles a tampered Transfer.dll with their private key or compiles without a private key signature, the following message is thrown when running Bank.exe:

        

This is the most basic application, I also refer to a lot of articles, of which the more important is http://www.windowsdevcenter.com/pub/a/dotnet/2003/04/28/ Strongnaming.html, the article also describes the mechanism of delayed signing, and interested friends can look at it.

Again, Sn.exe does not prevent the assembly from being recompiled, just letting the caller know that the calling object is not what it wants, and that's it.

In addition, HTTPS is a similar scheme to determine whether the other side is not their own, but more than a symmetric encryption algorithm to encrypt the packet this step, the other and this is the same.

. Net Assembly Signing Tool Sn.exe key pair SNK file

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.