Read more than 3,000 books online FREE! More than 900 PDFs now available for sale HOME ABOUT NAP CONTACT NAP HELP NEW RELEASES ORDERING INFO Items in cart [0] TRY OUR SPECIAL DISCOVERY ENGINE: Questions? Call 888-624-8373

Cryptography's Role in Securing the Information Society (1996) Computer Science and Telecommunications Board (CSTB)

Find More Like This Book Research Dashboard NEW! BUY This Book

CHAPTER SELECTOR: Openbook Linked Table of Contents Front Matter, pp. i-xxxii Executive Summary, pp. 1-14 A Road Map Through This Report, pp. 15-16 Part I - Framing the Policy Issues, pp. 17-18 Growing Vulnerability in the Information Age, pp. 19-50 Cryptography: Roles, Market, and Infrastructure, pp. 51-78 Needs for Access to Encrypted Information, pp. 79-110 Part II - Policy Instruments, pp. 111-112 Export Controls, pp. 113-166 Escrowed Encryption and Related Issues, pp. 167-215 Other Dimensions of National Cryptography Policy, pp. 216-246 Part III - Policy Options, Findings, and Recommendations, pp. 247-248 Policy Options for the Future, pp. 249-292 Syntehsis, Findings, and Recommendations, pp. 293-340 A - Contributors to the NRC Project on National Cryptographi..., pp. 341-352 B - Glossary, pp. 353-363 C - A Brief Primer on Cryptography, pp. 364-395 D - An Overview of Electronic Surveillance: History and Curr..., pp. 396-413 E - A Brief History of Cryptography Policy, pp. 414-420 F - A Brief Primer on Intelligence, pp. 421-429 G - The International Scope of Cryptography Policy, pp. 430-449 H - Summary of Important Requirements for a Public-Key Infra..., pp. 450-454 I - Industry-Specific Dimensions of Security, pp. 455-468 J - Examples of Risks Posed by Unprotected Information, pp. 469-473 K - Cryptographic Applications Programming Interfaces, pp. 474-476 L - Other Looming Issues Related to Cryptography Policy, pp. 477-484 M - Federal Information Processing Standards, pp. 485-488 N - Laws, Regulations, and Documents Relevant to Cryptograph..., pp. 489-676 Index, pp. 677-688
GO TO PAGE:	TABLE OF CONTENTS PAGE 474 PRINTABLE PDF PAGE CHAPTER   PAGE	SEARCH THIS BOOK:

CHAPTER SELECTOR: Openbook Linked Table of Contents Front Matter, pp. i-xxxii Executive Summary, pp. 1-14 A Road Map Through This Report, pp. 15-16 Part I - Framing the Policy Issues, pp. 17-18 Growing Vulnerability in the Information Age, pp. 19-50 Cryptography: Roles, Market, and Infrastructure, pp. 51-78 Needs for Access to Encrypted Information, pp. 79-110 Part II - Policy Instruments, pp. 111-112 Export Controls, pp. 113-166 Escrowed Encryption and Related Issues, pp. 167-215 Other Dimensions of National Cryptography Policy, pp. 216-246 Part III - Policy Options, Findings, and Recommendations, pp. 247-248 Policy Options for the Future, pp. 249-292 Syntehsis, Findings, and Recommendations, pp. 293-340 A - Contributors to the NRC Project on National Cryptographi..., pp. 341-352 B - Glossary, pp. 353-363 C - A Brief Primer on Cryptography, pp. 364-395 D - An Overview of Electronic Surveillance: History and Curr..., pp. 396-413 E - A Brief History of Cryptography Policy, pp. 414-420 F - A Brief Primer on Intelligence, pp. 421-429 G - The International Scope of Cryptography Policy, pp. 430-449 H - Summary of Important Requirements for a Public-Key Infra..., pp. 450-454 I - Industry-Specific Dimensions of Security, pp. 455-468 J - Examples of Risks Posed by Unprotected Information, pp. 469-473 K - Cryptographic Applications Programming Interfaces, pp. 474-476 L - Other Looming Issues Related to Cryptography Policy, pp. 477-484 M - Federal Information Processing Standards, pp. 485-488 N - Laws, Regulations, and Documents Relevant to Cryptograph..., pp. 489-676 Index, pp. 677-688 GO TO PAGE: TABLE OF CONTENTS PAGE 474 PRINTABLE PDF PAGE CHAPTER   PAGE   SEARCH THIS BOOK:

The Open Book page image presentation framework is not designed to replace printed books. Rather, it is a free, browsable, nonproprietary, fully and deeply searchable version of the publication which we can inexpensively and quickly produce to make the material available worldwide.

For most effective printing, use the "printable PDF page" link available on each OpenBook page's tool block. The 300 x 150 dpi PDF linked to it is printable on your local printer.

More information on the Open Book is available.

[ Top of Page ] [ Home ] [ Contact Us ] [ Help ] [ The National Academies Home ]

Copyright © 2005. National Academy of Sciences. All rights reserved. 500 Fifth St. N.W., Washington, D.C. 20001. Terms of Use and Privacy Statement

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:

cryptographic applications programming, applications programming interface, applications programming interfaces, applications programming, built using various, programming interfaces modern, using various techniques, cryptographic applications, cryptographic functionality, programming interface, cryptographic functions, programming interfaces, interoperable products, using various, api allows, built using, various techniques, linked libraries, specifically designed, interfaces modern, provide flexibility, default cryptographic, strong cryptographic, cryptographic modules, cryptographic capabilities, technology applications, exported applications, enable applications, applications supporting, applications developers