Chapter 7: How Vista Secures Services

New Code Signing Rules

Vista includes new stricter code signing rules that will most likely impact you. Before we move on to the specifics of the Vista code signing requirements, let's look at why code signing is even required in the first place.

What Is Code Signing and Why Does It Matter?

So, why is it so bad to run an unsigned driver or application? The concept of code signing is based on authenticating the software's publisher. If a publisher signs an application, we can know that the application really came from that specified publisher. We also know that the software has not been tampered with since it was code-signed.

However, a code-signed application is not necessarily a "good" application. For example, GoodApp.exe could be signed by EvilCorp and be designed to bundle a seemingly innocuous media player with a keylogger. It's really up to you as the admin to determine what a "good" or "bad" application is, and to then control which applications can be installed by implementing an installation policy or by using installation services. While Vista includes some built-in tools to prevent some bad things from happening to your system, there's no guarantee that your system will be impenetrable if you choose to install a bad application. Once you grant an unknown or malicious application the right to use your administrator access token, all bets are off. The following sections detail which types of drivers and applications must be signed on Windows Vista.

ActiveX Controls

If you download an ActiveX control in Internet Explorer, Vista won't run the control if it is not Authenticode signed. To change this behavior, you can edit the options in Internet Explorer. Figure 6.1 shows the location of the setting.

Figure 6.1: Internet Explorer ActiveX controls options

Enabling the "Allow software to run or install even if the signature is invalid" setting will enable both signed and unsigned software to run and install in Internet Explorer. This setting is also controlled by modifying the Security Zone in the Internet Explorer options. The default Internet security setting in Vista is Medium-High, which blocks unsigned ActiveX control installations. Figure 6.2 is a screen shot of the security level.

Figure 6.2: Internet Explorer default security level

If you have a managed infrastructure with Active Directory, you can use the ActiveX Installer Service to delegate which ActiveX controls that standard users (nonadministrators) can install and update on Vista. The ActiveX Installer Service uses Host URLs to define permitted ActiveX controls and is an optional component and must be installed on a client computer to be available. A really great feature of this service is that it allows administrators to track ActiveX controls not explicitly allowed in Group Policy that users are attempting to install. When a user attempts to install such a control, like the Flash player, Vista throws event ID 4097. This event lists the ActiveX control, and an administrator can choose to either enable the installation in Group Policy or to not adjust the Group Policy setting.

Protected Media Path Requirements

In addition, all software that runs in Vista's Protected Media Path (PMP) must be signed. PMP is Vista's enhanced support for digital rights management (DRM) for next-generation media formats, such as HD-DVDs. In short, this signing requirement means that the content on HD-DVDs will be successfully run and rendered on Vista if content is code-signed. This PMP requirement also impacts display drivers, which will have to include an embedded certificate in order to run on Vista.

x64 Requirements

All kernel-mode drivers and applications and boot-start drivers must be signed in order to run. Kernel-mode drivers and applications run in kernel mode, close to the operating system. Because they run in a protected area, it makes sense that they're required to be signed. A boot-start driver is a driver that the Vista system loader loads at boot-up. Boot-start drivers either have an INF that specifies the start type as "Start=0" or the driver is marked as a "kernel driver" or "file system driver" with a StartMode of "boot."

The kernel-mode software signing requirement is mandatory for 64-bit kernel-mode applications, and you cannot configure Vista to allow unsigned kernel-mode applications to run. Let's say that again: you can't make 64-bit Vista accept an unsigned driver. There's no way around it, short of setting up a certificate server of your own and signing whatever currently unsigned third-party drivers you want to use. We'll talk a bit about that soon. A boot-start driver must have the signature embedded within the driver, and is also not an optional component. If your boot-start driver does not have embedded signature, it won't run. Nor need you stop at drivers and operating system components for ensuring code integrity. You may also recall from Chapter 2 that User Account Control lets you crank up the requirement for signed executables with its User Account Control: Only elevate executables that are signed and validated setting.

Getting Down to Business: Code Signing an Application or Driver

So, now you know that you'll have to code-sign many (or all) of the applications that you will run on your Vista computers. There are really two ways to code-sign an application or driver:

1. Software publishers can code-sign the application or driver with the company's certificate.

2. System administrators can code-sign a released application that was not previously signed by the software publisher.

Note 

Kernel-mode drivers and applications must be signed by the software publisher. The publisher must also embed a signature in boot-start drivers before their release. There are no available methods for systems administrators to sign released kernel-mode software or to embed certificates with boot-start drivers.

If you're looking at option 2, chances are the software publisher never signed the original application. Make sure to check with the vendor directly to get updated drivers and applications. If the vendor has not yet provided a signed version, choose between the following two code signing options:

1. Use an internal certification authority (CA).

2. Use a commercial CA.

Make sure that you only sign applications for trusted vendors. This is really a judgment call on you and your company's part. You can also use third-party reputation services to gather information about the vendor, as well.

Using an Internal CA

One reason why you might use an internal CA instead of a commercial CA is to code-sign line-of-business, internally developed applications. If you do use an internal CA, the CA must be trusted. This is a given. To trust a CA in your network, use Group Policy or auto-enrollment to add the root certificate of the internal CA to the Trusted Root Certification Authorities store. You might also want to use an internal CA to have more control over the applications that are trusted in your network. For example, if you choose to allow a developer's certificate, all applications signed with that certificate will automatically be trusted in your network. This situation might not be ideal for some environments. If you want to have more control over what installs, consider using an internal CA to sign a specified subset of the developer's applications. Be careful here, though-re-signing an application developed by a third party and then redistributing that application outside of your network can violate some license agreements and have some litigious results.

Using a Commercial CA

You can also use a third-party certificate from a commercial CA to sign your applications for internal distribution. A big bonus to using this method is that you don't have to spend the time and resources to deploy and maintain an internal CA. Applications signed with this type of certificate will also be able to be trusted outside of your organization or network. You might want to use this method of signing if you need to share your internally developed applications with people outside of your company.

However, there are some downsides to using a commercial CA. You're pretty much dependent on the commercial CA to provide new certificates and certificate updates. Obtaining a certificate from a commercial CA can also be difficult, expensive, and time consuming. You will have to provide information to the third party so that it can verify your organization's identity.

The signing method that you eventually choose will depend on what you want your end result to be. If you need to share your applications externally, use a commercial CA. However, if you already have an internal CA, it can save you time and money to use the internal CA instead of applying to a third-party certificate vendor.

Note 

For more information on the actual nuts and bolts of setting up digital signing, you can download a fairly extensive Microsoft white paper on it at http://www.download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fded599bac8184a/64bitDriverSigning.doc. If that link doesn't work, then just Google "64bitdriversigning.doc" to find the white paper.

Getting Down to Business: Deploying an Application or Driver Signed by a Publisher

In order for Vista to know that a publisher is truly trusted in your network:

• The third-party publisher's code signing certificate was issued by a commercial CA.

• The third-party publisher's code signing certificate is trusted in the Trusted Root Certification Authorities certificate store.

• The third-party publisher's certificates are configured in either the user or computer Trusted Publishers certificate stores of your managed computers.

Note 

Keep in mind that your network's security will depend on the security of the third-party publisher's private keys if you choose to add a third party's certificate to your trusted store.