Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 474
Page 474 K Cryptographic Applications Programming Interfaces Modern software systems are built using various techniques that provide flexibility and reliability. One of the most important techniques centers on the use of an applications programming interface. An applications programming interface (API) is a well-defined boundary between two system components that isolates a specific process or set of services. For example, it is quite common now for an application to interact with an electronic mail (e-mail) server through an e-mail API, such as MAPI (Microsoft), VIM (Lotus), or AOCE (Apple), to name a few. In such cases, the API defines a set of services that allow an application to retrieve or submit mail messages from or to the mail server. APIs can be implemented by using hardware, software, or some combination. Furthermore, software APIs can be implemented by using dynamically linked libraries, statically linked libraries, remote procedure calls, or any combination. APIs have evolved as the result of both technical and business pressures. Technically, software developers have moved increasingly to "open," client-server systems. An open system is one in which interoperable products from different vendors are used to provide the functionality required by the users. Such systems depend heavily on commercial standards and APIs are often used to support those standards. For example, e-mail exchange using the X.400 standard is now supported by the CMC API. An API allows multiple vendors to develop interoperable products, even though individual product versions are continually changing. Although APIs are used to support open standards, a large number of
OCR for page 475
Page 475 proprietary APIs are also used by vendors to safeguard their technical investments. Even within these closed environments, APIs provide a major technical and business benefit for those vendors licensed to develop products using that API. For example, Novell was one of the first network operating system vendors to make extensive use of an API to support a wide range of add-on products. Under its approach, a "netware" loadable module (NLM) can be developed by a third-party developer and incorporated into an operational system by the user. The use of a proprietary API allows vendors to maintain the quality of third party products, to provide a basis for the development of niche products, and to maintain a competitive advantage. In Novell's case, the development of NLMs for major database products has boosted its sales in that competitive server market. Perhaps the most common API today is Microsoft's object linking and embedding (OLE) software technology, which provides general-purpose sockets for modules that can undertake many different functions. For example, an OLE socket can provide the user with the capability to insert a module for file encryption or for file compression. Thus, although it might be possible to use government regulations to prevent the widespread use of sockets for encryption, it would be difficult to dampen the spread of a general-purpose socket that has many uses. OLE interfaces could plausibly support some level of encryption capability; however, since OLE interfaces are not specifically designed for security, they may have weaknesses that render them unsuitable for security-specific applications. A cryptographic applications programming interface (CAPI) is an API specifically designed to support the introduction of cryptographic functions into products. It is not necessary to actually provide the cryptographic functions when the system is initially sold. Users would then be able to incorporate the cryptographic add-ons of their choice. Technically, a CAPI would provide an interface to a set of cryptographic services; it would usually include authentication, digital signature generation, random number generation, and stream or block mode encryption. Although there are some technical problems specific to CAPIs, most notably those associated with ensuring the integrity of the security processing, they exhibit, for the most part, the same advantages as any other API. That is, there are strong technical and business reasons for incorporating a CAPI into open systems. CAPIs would enable applications developers to take for granted the existence of cryptographic functionality and not have to provide for such functionality themselves. Moreover, by separating the cryptography from the baseline product, major system vendors will be able to make changes
OCR for page 476
Page 476 to the baseline product driven by market considerations without waiting for an export license review that would be necessary for a product with built-in cryptographic functionality. Cryptographic APIs are likely to have a profound effect on the rapidity with which cryptography will diffuse into various information technology applications. If implemented properly (not a trivial task), they can enhance the security of stored data and communications. When effective CAPI technologies are embedded into the operating systems upon which IT applications build, the result will likely be encrypted files and communications galore. Operating systems will be shipped with default cryptographic modules that are active "out of the box," and users will have the option of replacing default modules with more capable modules procured from other vendors. The notion of a CAPI is not new. However, in general, export licenses for products incorporating CAPIs have been denied, even though such products, with no cryptographic capabilities built into them, have no cryptographic functionality and are therefore not specifically included in Category XIII of the International Traffic in Arms Regulations (see Appendix N). The reason for such denial has been that strong cryptographic capabilities could be deployed on a vast scale if U.S. vendors exported applications supporting a common CAPI and a foreign vendor marketed (or some party made available over the Internet) an add-on module with strong cryptography, which foreign users could then plug into the baseline U.S. product.
Representative terms from entire chapter: