| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

Authenticode-We saw in the section on authentication that a sender can encrypt a message using its private key, which the receiver then decrypts using the sender’s public key, as a means of checking the authentication of the sender. Authenticode is a specialized application of this approach used to authenticate that executable code sent from a sender to a recipient does indeed come from that sender.

The approach used is identical to the approach we described in the earlier section. The sender encrypts the executable code using its private key and then sends it to the recipient. The recipient may already have the public key of the sender. If it doesn’t, it requests the key from the Digital Certificate Authority (perhaps running under Microsoft Certificate Server), which then sends the key.

If the public key successfully decrypts the executable code in the message, the user knows the code came from the sender. If it doesn’t, the down loaded component should be discarded—as it is a rogue component or a component from an unrecognized third party (and, as such, potentially harmful).

Authenticode can be used internally by companies needing to distribute software to their end users. But this approach has particular importance in the application of Microsoft’s Web technology.

We saw in the introduction that Microsoft can support the downloading of ActiveX components to its own Internet Explorer Web Browser. The downloading of ActiveX components over the Internet, however, does raise the potential of security problems.

As we saw in an earlier chapter, the approach taken by Sun’s JavaSoft division with Java applets is simply to restrict the applet. They call the approach the Java Sandbox (where it can play!), and the sandbox defines the set of disk files, network addresses, and system properties that applets are permitted to access from a browser. The restrictions imposed at the moment are fairly severe. Java applets are restricted by the JVM from modifying any sort of file by any means and can only access the network address from which they came.

Microsoft’s strategy, as we saw earlier, revolves around the idea that down-loaded ActiveX controls can do far more than simply communicate with the original Web server. In their strategy, the controls can:

  • communicate with other ActiveX controls on the same machine
  • access data on that machine
  • and, if the client happens to be part of an internal network with a DCOM registered client, communicate via DCOM to gain access to a whole host of other ActiveX components on servers elsewhere in the network

A user could inadvertently download a page from a browser with an ActiveX control embedded within it, which subsequently wreaked havoc with their machine. The potential for destruction is appalling.

Thousands, hundreds of thousands of users—computer developers and end users—browse the Web. They often innocently access sites out of sheer curiosity—interesting name, or something which looks interesting. With ActiveX technology, the user could download a page with an ActiveX control in it, and he or she would be completely unaware that he had even down-loaded it. The ActiveX component could be a virus, malicious bug, or “spy” component—it could roam about the machine unhindered; it could use the client’s machine to gain access all over the network.

It is a prime cause of one of our risks—unauthorized addition of an application on a machine.

Does Authenticode help? Even if Authenticode is used, the approach is not without its limitations.

  • First, the user’s machine has to be enabled so that checking of the digital signature is actually performed automatically (preferably via the Web browser), as it is unlikely any user would build these capabilities.
  • Second, to work well, the user will have to have cached the public keys of all the senders of ActiveX components in which he or she is interested and no others.
  • Third, the Web Browser or other software doing the checking will need to automatically reject all other ActiveX components, deleting them from the machine.

In fact, Microsoft’s Internet Explorer Web Browser has been enabled so that it can be made to perform these checks. Furthermore, the checks can also be applied to Java applets and Navigator plug-ins. Microsoft provides a software development kit called the Internet Explorer Administration Kit, which can be used to set the options for acceptance or rejection of components. The settings are:

  • download everything/accept anything
  • download nothing/reject everything
  • download only trusted controls—this is the default setting

The last setting can be further refined, for example, to accept only trusted components from a specific distribution list. Code signing tools are provided in the ActiveX SDK and are used with the WinVerifyTrustAPI.

Previous | Table of Contents | Next