In consumer goods, one way a buyer can access a product's quality is by looking at who made the product. Of course, the term quality has a lot of different features when applied to different types of goods. Goods, such as Hewlett Packard laser printers, Sony TVs, or Panasonic telephones and answering machines, are bought by people for their reliability, for the support received in case something goes wrong, and for their utility values.
The code signing technology from Microsoft, called Authenticode, is the electronic equivalent of labeling. Microsoft positions the Authenticode as "digital shrink-wrap for the Internet software."
The software authentication is similar to the labeling in concept. The software makers label their software components with a digital signature that has the developer's digital ID or digital certificate. This digital signature is tamper-proof and very difficult to duplicate. (It is believed that a 1,024-bit key will take a lot of effort to break.) The electronic label not only identifies the component maker but also verifies that the software is not tampered with after it has left the "docks."
The Microsoft Authenticode works with the Internet Explorer 3.0 and later versions. The technology can apply to ActiveX controls, plug-in components, dynamic-link libraries (DLLs), or Java applets.
Now, a legitimate question to ask is: why do you need this designer or brand name software? Why can't you use generic software? More importantly, what do these schemes give us?
The short answer is authenticity, accountability, integrity, and a tamper-proof seal.
The long answer is that it offers a level of protection to your
system from viruses, Trojan horses, and other malicious pieces
of software.
| NOTE |
Trojan horses are malicious codes that lie masqueraded in a normal program. For example, a cracker can add code to delete all your files when you press a Next Page command button in an ActiveX control. |
If you start downloading software with reckless abandon and running it as if there were no tomorrow, you will end up with components that delete files in your hard disk or render your data files useless. Anyone who has a lot of work stored in a computer is vulnerable to destruction. Another threat to your data is the publication of personal data, such as credit card numbers that can lead directly to monetary loss.
On a corporate level, an efficient virus can bring down an entire business and damage can be in the millions of dollars. Another area is espionage, where the software could start sending company secrets to its competitors.
Going back to the previous question, the authentication scheme and code signing do not guarantee protection from any of the above. It is a foolproof system of identifying the software or component maker. After you download a component, the browser will call Windows CryptoAPI to verify the signature.
If the code is not signed, it will tell you so.
If the signature is invalid or is revoked, it will let you know.
If it finds a valid signature, it will give you the component developer's name and the certifying authority.
Whether you want to run the component or not is up to you. Note the phrase, "a level of protection." The Authenticode schemes take the anonymity out of the security equation. You will know for sure who created the component if it is digitally signed. If not, you will know that the component is unsigned. Considering your experience with the certifying authority and the component maker, you can decide either to reject the component or download and run it.
The identity provides trust and accountability. Also, as the signing
process keeps a digital fingerprint of the component, digitally
signed software is tamper-proof. If somebody modifies the software,
by including a Trojan horse code for example, the fingerprint
will be different. This will alert the user that the software,
even if signed by Microsoft, does not pass the fingerprint test.
The user will be better off either downloading the software again
or abandoning the Web page. It is also a good practice to report
this kind of error to the company who signed the code.
| CAUTION |
The Authenticode is not a full security solution. The Authenticode technology does not assure a bug-free product. The Authenticode technology is not a replacement for anti-virus software or a copy-protection scheme. It only provides the identity of the component developer and assures the component's integrity across the network. |
Now you can see how this is achieved from a user perspective. The Microsoft Internet Explorer (version 3.0 and above) has configurable security settings. Figure 5.1 shows the Security Property Page for the Internet Explorer 3.0 with the various options. You can get to the Options property pages from the View-Options-Security choice in the Internet Explorer 3.0. The emphasis here is the Active Content frame.
The browser can keep a list of trusted certificates-personal, Web site, or publishers-which can be given security clearance to be downloaded and run as shown in Figure 5.2. Once an entity is in this list, the browser will not query you as to whether to download or run components signed by these entities.
To activate, choose the View-Options-Security choice in the Internet Explorer 3.0. Then press the Publishers button in the Certificates frame (refer to Figure 5.1) from the Options property pages.
In the Security property page, you can allow or disallow the downloading of ActiveX controls, enable or disable the controls, or run or do not run ActiveX and Javascripts as shown previously in Figure 5.1.
As a lot of the Web functionality comes from ActiveX controls and scripts, it is a good idea to enable all the preceding settings. You can control how these are downloaded and executed by the safety level page, as shown in Figure 5.3. You can get to this list by pressing the Safety Level button in the Active content frame (refer to Figure 5.1) from the Options property pages, from the View-Options-Security choice in Internet Explorer 3.0.
The three Safety Level Options settings for handling the active content to be downloaded from the Web are None, Medium, and High. As you can see in Figure 5.3, High is suitable for normal users. With the High setting, when the browser encounters an unsigned control or if the entity who signed the control is not in the list, the browser will notify you that an unsafe control has been encountered. It will not give you a chance to download or execute that control or component. See Figure 5.4 for the message.
In case of Medium security, the system will notify you (as shown in Figure 5.5) if an unsigned component or a component that is signed by an entity is not in the list. Unlike the high option, you can choose to download and run the component.
If the safety level is None, the browser will download and run
the component. This option should be used with care and is recommended
only for developers.
| For Corporate Administrators |
Using the Microsoft Internet Explorer Administrator's Kit (IEAK), administrators can configure the security level to control the code download across the enterprise. The administrator can also prevent a user from changing this setting. With the current level of security across the Internet, a good setting is to not allow any unsigned component to download. In the case of signed components, a default list of trusted vendors should be used for automatic download, and if the component maker is not on the list, the user can choose on a case-by-case basis. In the future, IEAK will have the capability to block any download from distrusted or unsigned sources. |
When the browser encounters a new component signed by an entity not in the list, and the safety level option is Medium, the browser will display the certificate as shown in Figure 5.6. You can see the link for details of the component as well as the Certifying Authority's Web site.
The certificate has the component name with a link to an URL, which contains more details about the control. Also shown is the name of the developer, commercial or individual, and finally, the certifying authority and a link to the CA Web site.
The Internet Explorer also gives you choices (via check boxes) to add the publisher or the certifying authority to the trusted list.
The Exploder Control is an ActiveX control developed by Fred McLain and is available at http://www.halcyon.com/mclain/ActiveX/. It is labeled as a nonviolent demonstration of the Authenticode security limitations-just because software is signed, that doesn't mean it is safe. This control, when activated, will shut down Windows 95 and turn the power off on computers that have the power conservation or green BIOS capability. Fred McLain has signed the Exploder Control using his individual software publisher certificate.
The Exploder control could have easily done a dozen things, from deleting all files in the hard disk to corrupting files. This is a control that is properly signed and will pass the Windows trust verification services. On the other hand, it could be a malicious control.
Actually, Fred McLain did a service to all the users by developing this control. The Authenticode technology does not protect the system from malicious programs-it just makes developer anonymity impossible. You will only know from whom the code came. You have the ultimate responsibility to decide whether or not to run the component.
The major pieces of the Authenticode are:
Conceptually, the certifying authorities are the electronic equivalent
of the notary public. A certifying authority (CA) is an organization
that specializes in providing security services, such as issuing
and managing certificates, authenticating identities, checking
registrations, handling legal and liability issues for broken
security, and so on. The two major CA companies are Verisign and
GTE.
| NOTE |
What happens if the certificate is stolen or a company or individual uses the Authenticode to sign malicious code? The CA will maintain a list of revoked keys. If a certificate or key is stolen, the developer will immediately notify the CA, who will issue another certificate and revoke the original certificate. A user can periodically refresh a revoked key list to get the current list of revoked keys. As the digital certificate has a site link to get more information, the developer can also display alert messages at their site in case of revoked certificates. |
X.509 Certificate The X.509v3 is data structure and standard for the binary representation of a digital certificate. It is an OSI/ITU-T standard. The X.509 certificate includes information, such as the public key of the developer's name, issuer, the serial number, the lifetime (start and end date) of the certificate, the algorithm, parameters for the signature and keys, and so on. This standard is officially called CCITT, Re-commendation X.509, Directory-Authentication Framework.
PKCS#7-Cryptographic Message Syntax Standard This standard contains the representation of a signature block to data. This standard is officially called PKCS #7-Cryptographic Message Syntax Standard.
PKCS#10-Certification Request Syntax Standard This
standard details an "electronic form" to request a certificate
from a certifying authority. The request includes infor-mation,
such as the requester's public key, signature algorithm ID, version,
requester's distinguished name, and so on. The data packet is
signed using the requester's private key. The CA will transform
the request to a X.509 certificate after proper verifications
and will send the certificate to the requester.
| Aren't There Export Controls on Encrypted Software? |
Yes. The United States government is very strict about the key lengths and algorithms when it comes to exporting secure software products. In the case of Authenticode, this is not a problem, as you are only encrypting the hash or digest of the software. The U.S. government allows the export of software that contains encrypted signatures. there are no export controls for encrypted message digests. |
RSA Encryption Standard The RSA standard MD5 algorithm generates a one-way hash or message digest for a binary stream. The hash is also called a message authentication code, or MAC. The digest has the property to be unique for a binary stream, so a gen-erated digest is a signature for the component. If the signature does not match with the component, it is sure that the component byte stream is not the same.
The WinVerifyTrust() API is the Windows call to ascertain
the subject's trustworthiness. In this case, the call will first
check for the PKCS #7 data structure in the signature block. If
it finds the data structure, it will extract the X.509 certificate
block and verify the certificate and then the software digest,
for any tampering. This is contained in the wintrust.dll file.
| NOTE |
The Windows system now has more support for cryptography. The Microsoft CryptoAPI is a set of routines to handle cryptographic functions, such as encoding, certificate authentication, encryption, and the like. It contains a rich set of functions and allows a Cryptographic Service Provider to add cryptographic services. The current version is 2.0. You can find more information on the CryptoAPI at http://www.microsoft.com/intdev/security/misf6-f.htm. |
Now that you know the pieces, you can see how it all works. First the CA, after verifying the credentials, issues a software publishing certificate (in the X.509v3 format) to the developer. When the component is developed, debugged, and ready for shipping, the developer will produce a fingerprint using the one-way hashing algorithm. The hash is then encrypted using the private key of the developer-effectively signing the software. The signature and the certificate are then appended to the software component in the PKCS #7 signed data object format. When a user wants to verify the authenticity, the WinVerifyTrust() call is made. This call first checks the certificate and then recreates the hash. When the hash is verified, the user is assured that the software is developed by the developer and has not been changed after the developer has signed the component.
Figure 5.7 shows the steps in the signing process. The first step is to apply for a software publishing certificate from a CA. Currently, only Verisign is acting as a CA. GTE and other companies are slowly getting into the arena. The CA requires a few pieces of information, including the Dunn & Bradstreet rating for a class 3 certificate. During this process, you will have to generate a pair of keys and send the CA a copy of your public key. You should safekeep the private key. For a Class 3 certificate, the hardware safekeeping is required.
The CA will do credential checking, including a financial verification. After the verification process, and if you meet policy criteria, the CA will issue a software publisher certificate. The certificate will conform to the X.509v3 format.
As a software publisher, you will have to take a pledge that you
will take all precautions required to make sure that your code
is not malicious.
| Commercial and Individual Certificates |
There are two classes of certificates issued by a certifying authority-Class 3 commercial certificates and Class 2 individual certificates. Class 3 Commercial certificates are for companies that develop a lot of controls and involve rigorous identity and financial stability checking by the certifying authority. The commercial certificate holder should have a Dunn & Bradstreet rating, and should maintain their private keys in some hardware form, a PCMCIA device, a BBN SafeKeyper, or a Spyrus EES LYNX Privacy Card, for example. Class 2 Individual certificates do not require the hardware key storage and the DUNN & BRADSTREET rating. Therefore, the Class 2 certificate has a lesser degree of identity verification and is aimed at individual software publishers. Verisign charges $400 per year for a Class 3 certificate and $20 per year for a Class 2 certificate. |
Once you get the certificate, you can start signing your code using the certificate. The tools for signing the code are available with the ActiveX SDK, which can be downloaded from the Microsoft Web site http://www.microsoft.com/msdownload/activex.htm. The ActiveX SDK contains the program SignCode. This program takes the program name, credentials, the privatekeyfile, and so on as input parameters and generates the signed component as output.
As you may have guessed by now, the Authenticode is a trademark. As with all trademarks, there are guidelines to properly use the trademark. Microsoft has the guidelines at the Web link http://www.microsoft.com/intdev/security/authcode/tmguidline.htm.
For easy reference, I am including these major points:
DO use Microsoft trademarks in a proper referential manner.
For example, phrases such as "works with," "compatible with," or "for" Microsoft® Authenticode™ technologies are proper.
DO use proper trademark symbols: When you use the Authenticode trademark, be sure to include the following references:
Authenticode™ is a trademark of Microsoft Corporation.
DO use Microsoft trademarks or product names as proper adjectives.
Don't use Microsoft trademarks or product names as part of your product name.
Don't use any language that implies Authenticode "certifies" or "verifies" your company, product, or the way in which your product is distributed. Do not use the mark in a manner that suggests that Microsoft is warranting or has tested your product.
Don't use Microsoft trademarks or product names as possessives or in plural forms.
Don't abbreviate.
Don't use Microsoft trademarks or product names with your company name.
Don't create a graphic or design out of the Authenticode trademark and do not include this trademark in any logos.