ClickOnce Security

ClickOnce, as you've seen, uses the manifests of the application it's about to download to analyze the application. If there are issues in one or more of four categoriespublisher, machine access, installation, and locationthose issues are flagged by ClickOnce, before displaying the Security Warning dialog. From this dialog, users can open the More Information dialog (shown earlier in Figure 19.10) to view precisely which of the security issues are flagged.

Of the four categories, there isn't much you can do about ensuring that location isn't flagged. Installation is dependent on how you configured the install mode for your application: If online/offline, this category is flagged. Ensuring that the publisher and machine access categories are not flagged requires you to dip your toes into code signing and .NET's code access security (CAS).

Code Signing

Because downloading code and executing it locally is akin to erecting a large neon sign saying, "Please destroy my computer!" users may feel uncomfortable about doing so. However, users also need to be able to do so. That's where Authenticode code signing technology comes into play.^[20]Authenticode allows users to verify the publisher of the code they want to download, as well as hold the publisher accountable if something goes wrong, whether maliciously or accidentally.

^[20] See Microsoft's Authenticode FAQ for more information: http://msdn.microsoft.com/library/dcefault.asp?url=/library/en-us/dnauth/html/signfaq.asp (http://tinysells.com/46).

The foundation of Authenticode is the digital certificate, which application publishers use to sign their code. In exactly the same way that Secure Sockets Layer (SSL) certificates are issued for secure web sites, digital certificates are issued to application publishers by trusted certification authorities (CAs), such as VeriSign and thawte. CAs have the power to accept or deny requests from application publishers for trust certificates. If a request is accepted, it means that a CA vouches for the application publisher, guaranteeing that the publisher is who it says it is. Additionally, the CA certifies that the application publisher is trusted to create and make claims about other keys. Either way, the resulting certificate lets downloaders know who it was that digitally signed published code. This allows users to find out exactly whom they might be downloading code from, as well as provides a mechanism by which users can deny or allow code to be downloaded.

ClickOnce relies heavily on the Authenticode code signing model to ensure that absolutely no application code is downloaded, let alone installed and executed, without the express permission of the user.

Digital Certificates

ClickOnce applications cannot be published unless they are digitally signed by an Authenticode certificate. You should absolutely acquire a digital certificate from a CA for your publicly published applications, but if you want users to trust and use them, you can temporarily get away without a CA-provided certificate for your development environment.

VS05 allows you to manually create a certificate from the Signing tab of a project's property pages by clicking the Create Test Certificate button, as shown in Figure 19.33.

Figure 19.33. Viewing and Selecting Code Signing Certificates from VS05

When you create a test certificate, you are asked to password-protect it, which is obviously recommended. The resulting certificate is a .pfx file whose name conforms to the following format:

ProjectName_TemporaryKey.pfx

A .pfx file is a Personal Information Exchange certificate file (PKCS #12), which is a container for a digital certificate.^[21] VS05 also adds this certificate to your computer's personal certificate store, as shown in Figure 19.34.^[22]

^[21] PKCS Standard #12 is described at http://www.rsasecurity.com/rsalabs/node.asp?id=2308 (http://tinysells.com/47).

^[22] You can open the certificate store either by running certmgr.exe from the command line or by opening Internet Explorer and selecting Tools | Options | Content | Publishers.

Figure 19.34. Managing Certificates on a Client Machine

As you can see, there are several certificate stores, although the Personal store is the library of certificates installed on your machine that are typically either for you or created by you. You gain two advantages by retaining personal certificates in the certificate store: Certificate sharing is simplified, and Windows take care of the complexities of key management. For example, applications like VS05 can ask Windows to sign code on their behalf, without their ever having to touch the private key. The advantage is that applications you may not trust with your key can still sign code for you.

You can proactively select a certificate from the Personal certificate store by clicking the Select from Store button shown in Figure 19.33.^[23] Additionally, you can choose a certificate that's deployed with a personal certificate file outside your project. This action imports the .pfx file into your project and loads the certificate into the certificate store. Finally, if you haven't created a test certificate when you publish your application for the first time, VS05 creates one for you.

^[23] When you click the desired certificate in the list, you should also click the Advanced button to open the Advanced Options dialog and check that it is configured for code signing purposes.

By default, a test certificate is untrusted, which is something you can determine by viewing detailed certificate information for the selected certificate in VS05. To do this, you click the More Details button in VS05 (see Figure 19.10 earlier) or the View button in the certificate manager (Figure 19.34), which opens the dialog shown in Figure 19.35.

Figure 19.35. Certificate for Untrusted Publisher as Created by VS05

You need to trust a certificate if you want to trust code signed by that certificate. Code signed by a certificate can become trusted only if the CA is listed in the certificate manager as a trust root certification authority; CAs like VeriSign and thawte already are listed there. Alternatively, you can manually add your test certificate to the Trust Root Certification Authorities list for the same effect. After you do, your certificate's details are updated to match, as shown in Figure 19.36.

Figure 19.36. Certificate for Trusted Publisher

Notice that the certificate is valid for only one year. Although VS05 arbitrarily chooses one year as the life span for test certificates, CAs like VeriSign and thawte always issue certificates with one-year life spans.^[24] The reason? With mathematical certainty, digital certificates can be cracked. Additionally, private keys can be stolen or leaked, and certificate authorities have revocation lists for this purpose. Having certificates expire after one year prevents anyone with access to a few supercomputers from cracking them and, more importantly, protects someone who doesn't have an up-to-date revocation list.

^[24] .NET SDK tools like MakeCert and Mage create certificates that expire on the December 31, 2039, at 11:59:59 GMT (just in case you were wondering).

However, it would be painful for users to have to download new versions of your application every year after a digital certificate is re-signed.

Time-Stamping

To avoid forcing users to re-download your application in the face of certificate expiration, a published application's digital signature can be time-stamped. This requires providing a hash of the code to a CA. Then, when the digital certificate expires, applications like Internet Explorer and ClickOnce can query a time-stamp server (typically operated by a CA) to confirm that the digital signature was created before the digital certificate expired.

VS05 allows you to specify a time-stamp server for your certificate by using the Signing tab, as shown in Figure 19.37.

Figure 19.37. Configure a Digital Certificate's Time-Stamp Server

You should check with your CA to determine the most appropriate time-stamp server to use.

Publishing Signed Code

The certificate you choose for digitally signing your application is not used by VS05 to sign the application files themselves. Instead, VS05 signs the application manifests, which control whether any actual application files are downloaded.^[25] In other words, these files act as a barrier between users and actual application code; if users don't trust them, no application is downloaded.^[26]

^[25] The ClickOnce-generated setup application is also digitally signed and checked for tampering.

^[26] Conceivably, particularly savvy users can discover the URL for and download actual application files. If they do, they are effectively shunning the protection provided by Authenticode.

Tamperproofing

Before the application manifest and setup files are even processed, a red flag is raised if they were tampered with after being published, in the form of the Application dialog that's shown in Figure 19.38.

Figure 19.38. Cannot Start Application Dialog

Clicking the Details button provides a summary of the reason. For tampering of a deployment manifest that looks like the following:

PLATFORM VERSION INFO ... ERROR SUMMARY   Below is a summary of the errors, details of these errors are listed   later in the log. *  Activation of http://.../wahoo2/wahoo_1_0_0_16.application   resulted in exception. Following failure messages were detected:     + Exception reading manifest from      http://.../wahoo2/wahoo_1_0_0_16.application:      the manifest may not be valid or the file could not be opened.     + Manifest XML signature is not valid.     + The digital signature of the object did not verify.     ...

When an application is published, each file listed in a manifest file is hashed, and then the entire manifest file itself is hashed. The hash of the manifest file is then signed with the private key contained in the certificate. On the client side, the hash is recomputed by ClickOnce, and, if there is a mismatch, the XML signature in the downloaded manifest or setup files is considered invalid and the tampering exception is displayed.

Trusting a Signed Application

If the manifests are valid, users will see the dialog shown in Figure 19.39.

Figure 19.39. Downloading an Application from an Untrusted Publisher with ClickOnce

At this point, the application is confirmed to be untampered, although the publisher is still unknown. Clicking on the More Information link shows that the publisher as unverified, as with Figure 19.10 (presented earlier). If a user ignores this warning and clicks Install, the application is automatically trusted and is added to the list of Trusted Applications known to CAS.^[27]

^[27] You can view the Trusted Applications list by opening the .NET Framework 2.0 Configuration application (Administrative Tools | .NET Framework 2.0 Configuration) and choosing .NET Framework 2.0 Configuration | My Computer | Runtime Security Policy | User | Trusted Applications.

Subsequent downloads of the same application, via manifests signed with the same digital certificate, execute in true ClickOnce fashion, without the Security Warning dialog being shown. If you reuse the same .pfx file (and certificate) in a different application, users will need to trust the publisher again, because the application is different. To cause a client machine to trust a client certificate you have issued, you install it into the Trust Root Certification Authorities certificate store. If no other security warning categories are flagged, the Security Warning dialog is skipped during the launch process. If other security warnings are flagged, the Security Warning dialog is shown as in Figure 19.40.

Figure 19.40. Trusted Publisher with Other Security Warnings Flagged

This time around, the Publisher option in the More Information dialog is OK'd (as shown in Figure 19.41), because we've designated it as a Trust Root Certification Authority.

Figure 19.41. Configuring ClickOnce Application File Dependencies

So, the publisher is now known, but the client machine should know about a real publisher rather than the developer who built the application.

Code Signing with a Real Certificate

A real publisher is associated with a real certificate, which, as we've discussed, you need to purchase from a CA or obtain from your IT department. You then import this certificate into VS05, which requires a slightly different process from the one you use with a VS05 temporary certificate. Follow these steps (based on my thawte-issued certificate):

Install the certificate into the personal certificate store by right-clicking the certificate file and choosing Install to start the Certificate Import Wizard.
Click Next to specify the certificate file to import, which is automatically selected.
Click Next to enter the password for the certificate and to ensure that strong private key protection is enabled. This implies that the certificate password is asked for whenever the private key is used (I wasn't asked for the password during signing because VS05 didn't ask Windows for the private key).
Click Next to choose the certificate store in which to install the certificate, which should be the Personal certificate store because that's the only store VS05 looks at.
Click Next and then Finish to complete the wizard and install the certificate.
From VS05, open the Signing tab from the project's property pages.
Click the Select from Store button, which allows you to choose a certificate from the Personal certificate store.
Select the newly imported certificate.

When the certificate is imported into your project, you can publish as usual, although VS05 asks for permission to sign your application with the chosen certificate via the dialog shown in Figure 19.42.

Figure 19.42. Allowing VS05 to Sign an Application with a CA-Issued Digital Certificate

After you click OK, ClickOnce and VS05 publish the application as usual. Then, when the application is launched, the Security Warning dialog contains useful publisher information, as shown in Figure 19.43.

Figure 19.43. Certified Publisher Information in the Security Warning Dialog

Clicking the Publisher link opens the Certificate dialog shown in Figure 19.44.

Figure 19.44. Certified Publisher's Certificate Details

This allows users to discover more information about the publisher and helps them decide whether to continue downloading. The Publisher section of the More Information dialog, shown in Figure 19.45, also shows the updated publisher information.

Figure 19.45. Certified Publisher Information in the More Information Dialog

With all this information in hand, users should feel much more comfortable about the origin of their application. But as you can see in Figure 19.45, users might not feel comfortable about what the application wants to do on their machine, as described by the Machine Access security warning. Understanding how an application should be configured to avoid this warning depends on code access security.

Code Access Security

All .NET assemblies execute within a security sandbox provided by the .NET Framework's code access security (CAS) technology. This sandbox controls the degree of access an assembly has to a computer's resources, which can include local disks, network connections, and the Registry. CAS provides different permissions based on evidence, which is most often a matter of where the application is launched fromthe local machine, an intranet, or the Internet. Ensuring that your applications conform to these defaults is a key consideration for ClickOnce-deployed applications, because it enables you to advertise your applications as being safe, secure, and benign.

To access a computer's resources, an assembly needs an appropriate set of permissions that CAS grants based on where an application has come from. To view the current permission settings on your machine, use the Microsoft .NET Framework Configuration tool (available in your Administrative Tools menu). Drilling down into the Permission Sets for the machine's Runtime Security Policy reveals a number of entries, including FullTrust, LocalIntranet, and Internet. Figure 19.46 shows the set of default Internet permissions.

Figure 19.46. Drilling into a Machine's Permission Sets

Permission sets apply to every assembly that is loaded by the Common Language Runtime, whether they are user-run EXEs or DLLs loaded from other assemblies. Table 19.1 compares the LocalIntranet permission set to the Internet permission set.

Table 19.1. LocalIntranet Versus Internet Permission Sets
Permission	Level	LocalIntranet	Internet
Environment Variables	Read=USERNAME	Yes	No
File Dialog	Unrestricted	Yes	No
File Dialog	Access=Open	Yes	Yes
Isolated Storage File	Allow=AssemblyIsolationByUser	Yes	No
Reflection	Flags=ReflectionEmit	Yes	No
Security	Flags=Assertion	Yes	No
Security	Flags=Execution	Yes	Yes
UI	Unrestricted	Yes	No
UI	Clipboard=OwnClipboard	Yes	Yes
UI	Window=SafeTopLevelWindows	Yes	Yes
DNS	Permission=DNS	Yes	No
Web	Connect=http to Originating Site	Yes	Yes
Web	Connect=https to Originating Site	Yes	Yes
Printing	Level=DefaultPrinting	Yes	No
Printing	Level=SafePrinting	Yes	Yes

Assemblies are associated with a permission set in a number of ways, including the publisher, the site, the strong name, or the security zone. Most of the default code groups associate code with a zone. For example, the My_Computer_Zone is associated with the FullTrust permission set, the Local_Intranet_Zone with the LocalIntranet permission set, and the Internet_Zone with the Internet permission set.

The zone an assembly comes from is determined by that assembly's path, as configured in Internet Explorer via Tools | Options | Security (see Table 19.2).

Table 19.2. Determining the Zone an Assembly Is Deployed From
Path	Examples	Zone
Local file	c:\ foo\foo.exe	MyComputer
UNC Name or Nondotted Site URL	\\server\foo\foo.exe http://server/foo/foo.exe http://localhost/foo/foo.exe z:\foo\foo.exe (if z is mapped to a network share)	LocalIntranet
All-Numeric IP Address or Dotted site URL	http://1115768663/foo/foo.exe http://www.sellsbrothers.com/foo/foo.exe http:// 64.85.21.138/foo/foo.exe http://127.0.0.1/foo/foo.exe	Internet

On the one hand, you've seen how CAS provides a default set of permissions to an assembly based on where it comes from. On the other hand, an assembly might require fewer, more, or different permissions from those provided by CAS. ClickOnce conveniently gives you a mechanism for requesting a custom set of permissions.

Requesting Permissions

An assembly needs a minimum set of permissions in order to execute; this set of permissions can be treated as unrelated to the set of permissions CAS grants to assemblies based on deployment location.

By default, a Windows Forms application is configured to support full trust, which is a way of saying that it needs all permissions awarded to users running the application as determined by their Windows user accounts. However, even though users can elevate permissions for such an application, it's your duty to ratchet down the required set of permissions by asking only for what you need to run. In this case, you need to consider configuring your assembly to support partially trusted execution.

You configure an assembly's trust level from the Security tab of the project's property pages, as shown in Figure 19.47.

Figure 19.47. Managing the Security Settings of a ClickOnce-Deployed Application

By default, an assembly doesn't enable ClickOnce security settings until the first time you publish it, in which case VS05 automatically enables them for full trust; or you enable it manually yourself. The resulting selection is recorded in your published application's manifest:

// Wahoo.exe.manifest <?xml version="1.0" encoding="utf-8"?> <asmv1:assembly ... > ...  <trustInfo>    <security>      <applicationRequestMinimum>        <PermissionSet           version="1"          Unrestricted="true"                    SameSite="none" />        <defaultAssemblyRequest permissionSetReference="Custom" />      </applicationRequestMinimum>    </security>  </trustInfo>  ... </asmv1:assembly>

The applicationRequestMinimum tag contains all the information that ClickOnce needs on the client machine to determine which permissions are required by the application. For full trust applications, this means that the Unrestricted attribute of the PermissionSet tag is set to true.

When you elect to go with partial trust, VS05 provides the means to specify the subset of permissions that you need. It supports two preconfigured permission setsLocalIntranet and Internetor it lets you create your own, as shown in Figure 19.48.

Figure 19.48. Configuring ClickOnce-Required Permissions

LocalIntranet and Internet correspond to the permissions provided by the LocalIntranet_Zone and Internet_Zone code groups you saw earlier. Wahoo, for example, will be deployed over the Internet, and hence the Internet zone selection. This has the effect of automatically including a request for the permissions from the Internet zone:

// Wahoo.exe.manifest <?xml version="1.0" encoding="utf-8" ?> <asmv1:assembly ...>   ...    <trustInfo>      <security>        <applicationRequestMinimum>          <PermissionSet                             SameSite="site">               <IPermission                 docEmphStrong">Access="Open" ... />                <IPermission                                  Allowed="ApplicationIsolationByUser"                 UserQuota="512000" ... />               <IPermission                                  Flags="Execution" ... />               <IPermission                  Window="SafeTopLevelWindows"                 Clipboard="OwnClipboard" ... />               <IPermission                                  Level="SafePrinting" ... />               </PermissionSet>               <defaultAssemblyRequest permissionSetReference="Custom" />           </applicationRequestMinimum>       </security>    </trustInfo>    ... </asmv1:assembly>

As you can see, Wahoo is now configured to request the specified permissions, and only those permissions, for the security sandbox it runs in. But this also means that you must ensure that your application code doesn't require permissions beyond those specified to avoid run-time issues.

Permission Elevation

When the set of permissions required by your application exceeds those permitted by CAS for the zone, the Machine Access security warning category is flagged (see Figure 19.49), whether or not the client's machine has been configured to trust the publisher.

Figure 19.49. Trusted Publisher but Potentially Harmful Machine Access

At this point, the user can either cancel application launch or elect to grant the application the additional permissions it needs, a process known as permission elevation. When permission is granted, the permission set and application signature are added to the list of trusted applications managed by CAS. The application is then downloaded, installed, and executed within a CAS security sandbox that's configured to the permissions stored by CAS for the application. Partial trust applications don't appear under their own name in the Task Manager; the CLR uses applaunch.exe to launch partial trust applications, and it's applaunch.exe that you see in Task Manager.

After a publisher is trusted, permissions are granted as required and the application is executed. Users can subsequently execute and upgrade the same application as many times as they like. If users download a different application from the same publisher, however, they must go through the permission elevation process again if Machine Access is flagged. If the permissions required by an application are less than or equal to those allowed for a particular security zone, the Security Warning dialog gives the green light, provided that the publisher is trusted and the application is launched from a trusted location.

If subsequent versions of an application are deployed with increased permission requirements, users are prompted to elevate permissions again. Users are not prompted if subsequent versions either maintain or reduce the required permissions.^[28]

^[28] Brian Noyes has written an article at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickoncetrustpub.asp (http://tinysells.com/48) that provides detailed insight into when prompting occurs, as well as the ability to alter it.