In many ways, enabling technologies are the most exciting part of this security story because they portend a rich, ongoing stream of trusted applications that are more economical, more secure, and easier to administrator because they take advantage of the Windows NT security infrastructure. This section about enabling technologies begins with the Microsoft cryptographic application programming interface, CryptoAPI, and a public key security protocol called Secure Channel
(S-Channel).
Cryptography is the essential component of networking security. Unfortunately, it is a difficult technology to learn and implement. Microsoft created the CryptoAPI to address this problem. The CryptoAPI is a set of software libraries with high-level cryptographic interfaces (APIs) that manage the many details of key management, formatting, and cipher algorithms, presenting applications with a single interface that serves different underlying ciphers. CryptoAPI uses Cryptographic Service Providers (CSP), plug-in cipher modules that cryptographers create and market. In short, CryptoAPI joins application developers, who know little of cryptography but need to use it, with cryptographers who develop the base technology.
Each CSP implements a specific set of cryptographic algorithms. Microsoft provides a base CSP that includes a full complement of cryptographic ciphers and hash functions licensed from RSA Data Security, Inc. Under CryptoAPI, you can replace one CSP with another of the same type without affecting any of the applications that use that type. For example, Microsoft provides an enhanced version of the RSA-based CSP that supports stronger encryption. This also allows you to upgrade your security to hardware devices such as smart cards, by simply replacing the CSP.
A second advantage of the CryptoAPI is that it fully encapsulates the storage and protection of crypto keys and the ciphers themselves. A CSP can implement its schemes either in software or on smart cards. Smart cards present significant security advantages over software because they are portable and can better physically protect a user’s secret keys.
Microsoft delivers a basic set of CSPs with Windows NT (you may need special third-party licenses if you develop and sell products using these CSPs). All BackOffice applications are moving quickly to fully utilize CryptoAPI. The recently released CryptoAPI 2.0 includes a complete set of certificate management APIs that implement the latest X.509 certificate formats.
Secure Channel (S-Channel) is a security service provider module that implements the popular public key security protocols between Web clients and servers. These include SSL, PCT, and TLS (an upcoming standard that merges SSL and PCT). S-Channel is layered on top of CryptoAPI for key and certificate management services. Independent software vendors and developers can use S-Channel to add these cryptographic protocols to any client/server application.
Traditionally, on a single-logon system such as the Windows NT operating system, users were required to remember only their logons and passwords. However, increased security in heterogeneous environments imposes additional burdens. These include private keys and certificates, trusted CA certificates, credit card and bank account numbers, other personal identification information (such as driver’s license numbers), and data that helps their applications use this information automatically and transparently. There needs to be a single place to store and protect this information that applications can share. On the Windows NT operating system, the Protected Store (P-Store) is the technology that meets this need.
P-Store is a set of software libraries that allow applications to fetch and retrieve security and other information from a personal storage location, hiding the implementation and details of the storage itself. For example, the storage location could be the user’s Windows NT profile, a preferences file, a diskette, or a smart card.
Microsoft Wallet is a generic name for a window application that serves as the user interface to the P-Store. Microsoft Site Server already uses the Wallet with Microsoft Internet Explorer.
Personal Information Exchange (PFX) is a protocol that securely transfers the contents of a P-Store from one location to another, for example, from an office computer to a home computer.
As intranets become more secure, client applications (such as Web browsers and e-mail programs) and servers (such as Web servers and e-mail hosts) become more complicated because different situations require different types of authentication and cryptography. Microsoft’s Security Support Provider Interface (SSPI) makes common network authentication and cryptographic data protection schemes available to both client and server applications through simplified software libraries. Programs that use SSPI do not need to encode the details of specific authentication or cryptographic schemes. Instead, the SSPI libraries do all the complicated work.
A Security Support Provider (SSP) is a library that manages a particular scheme. Applications interact with all SSPs through a common SSP interface (hence, the name SSPI), which further hides the details of the specific scheme. SSPs rely heavily on other enabling technologies like CryptoAPI and S-Channel whenever possible. SSPI currently includes four SSPs:
Distributed and client/server applications use SSPI in several ways, from calling its SSPs directly to selecting security options when using Distributed COM (DCOM), Remote Procedure Call (RPC), and other popular Internet APIs. DCOM and RPC are enabling technologies that make it easier for users to create distributed applications. (Distributed applications use cooperating components that run on different computers, and perhaps even different operating systems, such as Windows NT, UNIX, or Macintosh). For example, Windows NT remote administration uses RPC extensively. DCOM and RPC manage and hide the details of how the different parts communicate with each other. Both DCOM and RPC have simple options that automatically use SSPI authentication and message encryption. These options are sometimes called “Secure DCOM” or “Secure RPC.” These are among the easiest ways to use SSPI.
For example, most authentication protocols begin by exchanging a series of packets between the client and server.
SSPI also supports server impersonation, so at this point the server might impersonate the client user–that is, it might begin working under the client user’s identity. If the client and server are cryptographically protecting their data, each one passes each of its outgoing packets to the SSP for encryption or signing, and each incoming packet for decryption or signature checking. In this case the initial exchange usually negotiates the encryption keys for the session.
Certificate Management refers to the process whereby public and private encryption keys are securely and reliably managed by a Certification Authority (CA). A key component of this process is that the CA creates a user’s certificate (essentially, signs the user’s public key) after verifying that the user has presented a legitimate name (often a full name or e-mail address). Although there are several companies that provide this service, large Windows NT–based networks want and need their own certificate authorization services. This need is met by Microsoft’s Certificate Server (CS).
You can think of CS as a toolkit for CAs. It accepts certificate requests from users in a variety of popular, standard formats (such as e-mail), subjects the requests to any number of “approval modules” that the CA easily can add to the server, and then constructs and returns a certificate to the user. Each site adds its own approval modules. A module might engage in an e-mail exchange with the user’s listed e-mail address or send a request to an assistant who researches the requester. CS can also manage Certificate Revision Lists. The value of CS is that it decreases costs by creating certificates in-house and also allows you to establish the certification policies important to your organization. You can even use it to establish your own public certification service.
In the early days of the Web, when you clicked a hyperlink, your browser printed the link’s contents on your screen. But today your browser may invisibly download and locally run a number of small programs that manage the presentation of the page on your screen. These active Web page elements, including ActiveX controls, Java applets, and .exe files, pervade the Web and are the wave of the future. Their presence as local programs is automatic and transparent.
Unfortunately, you have no way of knowing whether these active elements attempt to act maliciously on your system. They run under your identity with your capabilities and can do everything you can do. This can include deleting files, e-mailing files to third parties, and installing malicious programs on your computer.
Microsoft’s Authenticode technology uses the simple cryptographic integrity features presented earlier to help ensure that your browser accepts only active elements you think are safe. Reputable software vendors join a software vendor organization and receive a certificate signed by the CA of the organization. People who browse the Web install that CA certificate on their workstation. (It usually comes preinstalled in the browser.) Vendors sign their active elements using the integrity algorithm described earlier.
Your browser can now determine two important things: first, that an active element comes from a genuine member of that organization and, second, that it has not been tampered with since the vendor signed it. You can easily instruct your browser to ignore elements that fail these tests or allow only elements from a list of vendors you specify. Microsoft Internet Explorer can check Authenticode on any active element (ActiveX, Java, and so forth).
Is this sufficient assurance? Suppose you visit your favorite computer store and buy a shrink-wrapped program from a software vendor that produces a wide selection of PC programs. You probably have no reservations about the safety of the software because you have no reason to think it is malicious. No legitimate software house risks its business by selling what it knows or suspects to be a tainted program. It is always possible, of course, that someone tampered with the package or substituted a fake CD-ROM, but that is unlikely.
Authenticode assurance is analogous but even stronger. It is more difficult to tamper with cryptographic signatures than with shrink-wrapped software, and the software vendor organization attests that the software vendor is genuine and willingly joined the organization. If shrink-wrap tampering is unlikely, then Authenticode tampering is as unlikely.
Java offers some additional security possibilities. Java applets do not necessarily gain full access to your system. Your browser (more properly, the local software that runs the Java applets) can limit these applets, for example, preventing them from writing onto your file systems. The scope of a Java applet is often called its sandbox. With the proper Java security model this can be an effective security restraint, but it involves an inevitable trade-off against the capabilities of the applet. For example, when you prevent an applet from writing to your hard drive you may be removing its ability to give you the services it is designed to provide. Internet Explorer 3.0 fully enforces the standard Java “sandbox,” and Microsoft is working with industry groups to make the sandbox walls more flexible.
There is no question that for some applets, the sandbox is an effective protection. But there is also no question that in general, it is not enough. Authenticode does not have this trade-off and need not make these concessions to usability.