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

Previous Table of Contents Next


The Mechanisms of Protection

We have seen that there are six main services that can be provided to help protect distributed applications from the risks I’ve described. Each of these services can be implemented by more than one mechanism of support; in other words, a service such as authorization can be achieved using a number of alternative mechanisms, for example, user/password combinations, Digital certificates, and Smart cards. In the next few paragraphs I will explain some of the more important mechanisms—especially the ones Microsoft is supporting or is aiming to support.

Authentication

One of the most frequently used and better known mechanisms of authentication is the user/group and password approach to checking the identity of someone, but this is not the only mechanism available. Authentication can be based on what you know (for example, a password), what you have (for example, a smart card or other physical device), or who you are (for example, biometric authentication using voice recognition, fingerprint readers, retinal scanners, etc.).

User names and passwords-Despite their widespread use, user names and passwords, as a means of establishing identity, are open to abuse. They can be forgotten, passwords, can be easy to guess, users often leave passwords accessible (on Post-it notes stuck on their machine, for example), and they are not necessarily unique across the organization or across companies. Despite this, the user/password approach is one of the most commonly used within most organizations.

Checking is usually only performed when a user requests a service from a server. The server is not generally asked for its name and password.

A secure file (it must be a secure file as there is no point in having it) containing the user names, groups, and passwords is set up manually by the administrator. This file can be a:

  Globally relevant file containing all the users, groups, and passwords—this file may occur just once on the network but be accessible to all in the network, or a better option for performance reasons is an automatically replicated file, which is stored on each machine.
  File which just has the users, groups, and passwords of the users connected to that server machine.

The first option, especially if it uses replication, is probably the best solution, as it saves the administrator effort and is more easy to keep secure.

Digital certificates-Provide electronic proof of identity using cryptographic keys, which are then used to “sign” or “seal” the message. They have the advantage that both sender (client) and recipient (server) can be asked to prove their identity, thus providing some assurance to the client that the server is also who/what it says it is.

Digital certificates in this case are issued by a third party—often called a Trusted Third Party (TTP) or Digital Certificate Authority.

TTPs have the responsibility of revoking certificates when they are no longer valid, publishing a list of revoked certificates in the Directory, and revalidating and reissuing certificates that have expired. There is no reason why a company cannot be its own TTP if it wants to set up a network of registered authenticated users (internal and external). In fact, this may be the best way, as each company then has a vested interest in ensuring its users are properly authenticated physically before being given certificates, can issue Smart Cards to people in person, and are more likely to keep certificate information up-to-date. So how are certificates issued?

The TTP first generates a key pair—one public and one private key for the person requesting the certificate. The public key is placed in a Directory. This Directory must be accessible by any process or user the person needs to communicate with. The private key is given to the person.

When the person wants to request a service from a remote server, the message is encrypted with the private key. This acts like a signature—as only the person knows the private key, it can only be that person who sent the message. At the other end, the recipient “unlocks” the message—in reality decrypts it—using the public key that it obtains from the Directory.

A standard exists—the X509 Authentication Framework—which covers Digital Certificates and PKCS (Public Key Certificate Standard) to cover the various formats for the requests for certificates. Under this standard, the Digital Certificate Authority receives an initial request from a user and then assigns a unique name to each user, together with the keys. This standard also covers subsequent requests for the public keys of third-party recipients from a sender.

Smart Cards-Care must obviously be taken that the private key does not fall into the wrong hands, and as such as a general rule it should not be stored on a machine accessible by others. One way of ensuring the key is safely stored is to keep the private key routine on a floppy disk, for example, or some other storage mechanism that can be safely kept with the person.

One of the major new ways in which private keys are being stored, however, is via the Smart Card. These have the added advantage that to use them, the person must also have the PIN number of the card, so even if the card is lost or stolen, the data—the private key of the individual—should be protected.

A Personal Computer/SmartCard Workgroup (PC/SC Workgroup) was founded in 1996, of which Microsoft is a founding member, along with Groupe Bull, Hewlett Packard, Schlumberger, and Siemens Nixdorf, to address smart card interoperability issues and to create specifications in the areas of interfacing smart card readers and cards with PCs. It is also looking at ways of providing device-independent APIs to encourage the development of smart card aware applications. Some more details of the public and private key mechanism are provided in the paragraph below on encryption.


Previous Table of Contents Next