Custom Component Security

This chapter implicitly assumes that any custom controls or components that you build are safe and trustworthy. It assumes that you don’t need to worry about a control installing a virus on your computer or deleting a bunch of files. That’s certainly true when you use a control that you write yourself (unless for some reason you want to destroy your operating system).

It’s also true when you build a custom component inside an executable application. If a project’s files include a custom control that the program uses, you know that the control is as safe as you write it.

In contrast, suppose you download a control library DLL from the Internet. If you use the controls in the DLL in your application, you cannot tell if the controls are safe. You can’t even always tell if the DLL you download is the one that the original authors posted. It is possible that some scofflaw replaced the original with a virus-infested version. In fact, it’s possible that prankster has replaced a DLL that you built yourself with another version that looks similar but that has malicious side effects.

Visual Studio provides two approaches for combating these problems: making a strongly named assembly and using a signature authority.

Strongly Named Assemblies

A strongly named assembly includes a manifest identifying the files that the assembly contains and a digital signature. Another program can verify the digital signature to verify that the assembly has not been tampered with since it was created.

Unfortunately, that doesn’t guarantee that the assembly is actually what you think it is. An attacker could make a new assembly and then strongly sign it. If you verify the signature, you can tell that the attacker’s version of the assembly hasn’t been tampered with and the viruses it contains are the original ones. The Microsoft web page Code Security and Signing in Components at http://msdn2.microsoft.com/en-us/library/txzh776x(vs.71).aspx says:

Tip 

Although providing a strong name for your assembly guarantees its identity, it is by no means a guarantee that the code can be trusted. Put another way, the strong name uniquely identifies and guarantees the identity of the assembly, but does not guarantee that you wrote it. Nevertheless, a trust decision can reasonably be made based on strong-name identity alone, provided that the assembly is a well-known assembly.

Although this is a pretty big loophole, it’s still better than nothing.

To sign an assembly, start a new Visual Basic project as usual. The SignedAssembly project (available for download on the book’s web site at www.vb-helper.com/vb_prog_ref.htm) is a DLL project.

In Project Explorer, double-click My Project to open the project’s Property pages and select the Signing tab, as shown in Figure 12-8.

Figure 12-8: Use the Signing tab to sign an assembly.

Select the Sign the assembly check box. Then, open the key file drop-down list and select <New...>. On the resulting dialog box, enter the name that you want to give the file and optionally enter a password to protect the file. Then click OK.

At this point, Visual Studio builds the key file. It looks like gibberish, but contains all the ingredients needed to sign the assembly. When you build the assembly, Visual Studio uses the key file to sign the result. Build a main program, reference the assembly, and use its methods as you normally would.

Later, you can use the strong name tool sn.exe to verify that the assembly has been properly signed. The VerifyAssembly.bat batch file shown in the following text verifies the signed assembly SignedAssembly.dll. The first call to sn.exe, with the –T flag, displays the public key token that was used to sign the assembly. The second call, with the –v flag, makes sn.exe verify that the assembly is properly signed.

  PATH=C:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Bin sn.exe -T .\bin\Debug\SignedAssembly.dll sn.exe -v .\bin\Debug\SignedAssembly.dll PAUSE 

Using a Signature Authority

Signing an assembly ensures that some villain hasn’t meddled with the assembly since it was signed. If you built the assembly yourself, that gives you some assurance that the code is safe.

However, if someone else built the assembly and posted it on the Web, all the signature guarantees is that the assembly contains whatever the original author put in it. It doesn’t guarantee that that author didn’t insert a virus. In fact, it doesn’t guarantee that a hacker didn’t replace the original author’s assembly with a spoofed version.

So, suppose you write an assembly that you want to share with others. You can make using your assembly safer by using a certificate authority.

A certificate authority is a company that sells digital certificates that guarantee the authenticity of a piece of signed code. The company verifies your identity, so they are certain that you are who you claim you are. It then gives you a certificate that you can use to sign assemblies. Later, when someone uses your assembly, they cannot only verify that it has been signed and that it has not been corrupted since you wrote it, but they can also verify that you wrote it.

Hackers won’t use certificate authorities to spread viruses because they would have to identify themselves to the authority, and that would give you a way to track them down and sue them. The certificate still doesn’t guarantee that the code is completely safe, but it does establish accountability if the code turns out to be unsafe.

For information on signing assemblies and using certificate authorities, see the Microsoft web pages Signing an Assembly with a Strong Name at msdn2.microsoft.com/library/aa719592(VS.71).aspx and Code Security and Signing in Components at msdn2.microsoft.com/library/txzh776x(VS.71).aspx.