SPARTA ISSO

Finished Projects

Cryptographic Technologies

International Cryptography Experiment (ICE)

International Cryptography Experiment (ICE) Status Report
Stephen T. Walker
David M. Balenson
Trusted Information Systems, Inc.
January 6, 1995

Introduction
In April 1994, Trusted Information Systems first proposed an International Cryptography Experiment (ICE) to explore and experiment with a range of solutions to the international availability of cryptography which meets the needs of both governments and industry. The response to our proposal has been very positive. We distributed our first status report on ICE in August 1994. This is the second status report on ICE, and the circumstances surrounding the program, and its progress to date.

ICE calls for a series of experiments to promote the international use of cryptography in common computer software applications (i.e., word processors, spreadsheets, electronic mail systems) in a manner that honors individual national controls on the use and export of cryptography. The general approach being advocated by numerous organizations in several countries is to separate the actual performance of the cryptographic functions from the software applications that call for encryption of specific messages or files.

The integration of Cryptographic Application Programming Interfaces (CAPIs) at various levels of software applications provides the best approach to establishing the separation needed between applications asking for cryptography and hardware or software actually performing the cryptography (see Figure 1).

ICE is an informally structured program to coordinate the many efforts underway in several countries to advance the general understanding of CAPIs and their use to promote international cryptography. ICE is not a standardization program. ICE will use whatever interfaces are available in experiments to demonstrate the effective use of cryptography. It is intended that practical standards derived from actual use will evolve from these experiments in the spirit by which Internet standards evolve.

The Overall Problem
As the world moves rapidly into the information age, there is an ever growing need by individuals, corporations, and governments for improved protection of their sensitive information, and the failure to do so will severely undermine any potential of a national or global information highway. At the same time, the very availability of cryptography solutions to protect sensitive information threatens a vital function of a modern government, and governments worldwide strive to maintain their prerogatives to control the use and export of cryptography by their own countries. The dilemma posed by these fundamental and conflicting interests is causing difficult and emotional debates within many countries today. The lack of a solution acceptable to both sides is frustrating both government and business interests and keeping much highly sensitive information at risk of compromise.

As cryptography has become available worldwide, continuation of government controls on the export, import, and in some cases internal use has been seen as increasingly futile and restrictive by information system developers and users. Nevertheless, the restrictions remain and the penalties are sufficiently severe to strongly curtail the availability of popular information system products with integrated cryptographic capabilities. Vendors of major mass market software systems with worldwide markets will not afford to build products they cannot ship to all their existing and potential markets.

In an effort to establish what it feels is a reasonable balance between the interests of privacy and those of the law enforcement community, the US government has introduced a technique it calls key escrow that makes available strong cryptography while maintaining the interests of law enforcement by allowing decryption of key-escrowed communications when legally authorized.

The Fortezza initiative introduced by the US National Security Agency (NSA) places the cryptographic functions for protection of unclassified but sensitive information in an external card (called a PCMCIA card) that interfaces to applications running on a workstation or laptop computer. This approach, which employs key escrow, has the advantage of isolating the cryptography from the computer system, thus making it difficult to modify and easier to control its distribution. While the details of key escrow bother some, the US is proceeding with Fortezza for at least government use. Other governments are said to be considering similar programs.

Meanwhile, business groups within most western countries continue to try to convince their governments that the growing worldwide availability of cryptography makes further control of cryptographic export both futile and highly restrictive to the economic interests of those countries. These efforts may eventually succeed in loosening some export control restrictions, but any coordinated worldwide relaxation of controls is highly unlikely in the near future.

An Interim Solution That Meets the Needs of Both Sides?
In the meantime, it is useful to explore alternatives that may provide at least partial solutions to this international dilemma while satisfying the interests of both sides. The seeds of one potential solution come from a number of sources within various national government and industry initiatives. The ICE program has emerged from a variety of ideas proposed by industry and governments in several countries. The success of ICE could fundamentally change the international availability of information security products.

The success of the NSA Fortezza initiative depends upon the information systems industry adopting a common set of interface standards for Cryptographic Application Programming Interfaces (CAPIs). The Fortezza program has defined an initial set of such standards, but they must be endorsed industry-wide for the program to succeed.

Various vendors such as Hewlett-Packard and National Semiconductor have proposed the development of additional PCMCIA card configurations that would make use of standard CAPIs and allow individual countries to implement their own collections of cryptographic algorithms serving their own particular needs. If common CAPIs were to be widely adopted, initiatives such as the Fortezza program in individual countries would be much more likely to succeed.

In the United Kingdom, the Ministry of Defence (MoD) has begun a Security in Open Systems (SOS) Technology Demonstration Programme (TDP) with a specific objective of defining CAPIs and attempting to get them widely adopted by industry and government throughout the world.

These proposals, sparked in part by the Fortezza program, could bring about a fundamental change in the availability of information security capabilities. With common CAPIs at sufficiently high levels of abstraction, mass market software developers could include the capability for cryptographic functions in their products without implementing any particular cryptographic algorithms. Such products, which rely on the user selecting the actual cryptography to be used at the time of actual use, should be readily exportable. The user in a particular country would choose among those available cryptographic PCMCIA cards in that country to perform the actual encryption functions.

This approach offers the dual advantages of freeing major software vendors to include some form of cryptographic function in their products while allowing governments to retain the same controls they now have over the export, import, and use of cryptography. Governments that wish to pursue techniques like key escrow can "enter the marketplace" and "prove" the advantages of their approach.

A program to define and place such CAPIs in use internationally requires no legislation (at least in most western countries) and can be adopted through industry-wide cooperation, drawing from already available CAPI standards.

An International Cryptography Experiment (ICE)
ICE calls for a consortium of interested parties in industry and government to define preliminary cryptography interface standards, incorporate these interfaces and supporting cryptography implementations into software applications, and place them in use on an experimental basis for a period of a year or two. After this test period, international standards organizations would be requested to adopt the resulting CAPIs for widespread use throughout the world.

ICE is comprised of three overlapping phases:

CAPI Definition Phase (3 to 6 months)

A rapid effort over three to six months to identify an initial set of cryptographic application programming interfaces for use in the experiment. These interfaces would be derived from existing interfaces or interfaces under development by industry and standards organizations in the US, UK, Canada, Germany and elsewhere, and from the efforts of programs such as the UK Technology Demonstration Programme. This effort should look at such interfaces in the context of multiple cryptographic algorithms.
Development Phase (3 to 6 months)

Application Software Development. Major software application developers would include cryptographic function calls to the high-level CAPIs within their products. Products containing these function calls would be tested against the PCMCIA implementations that would be developed in the next phase. These high-level products that contain no cryptography themselves should not be subject to export controls in most countries. All exports of these products will be coordinated with the country's government in which they are developed.

PCMCIA card implementations. Cryptographic functions that meet the CAPIs would be implemented in each participating country in accordance with the cryptography available in that country. These implementations may not be exportable from the country of implementation depending upon the type of cryptography used.
Experimental Use Phase (one to two years)

As soon as applications using the CAPIs are generally available and PCMCIA implementations of specific cryptography are available in specific countries, a one-to- two-year experimental period will commence. During this period, coordination of use within each participating country and among participating countries (where compatible cryptography is available) will validate the design and implementation of the CAPIs and lead to additional application development. Because the actual use of cryptography is constrained to be in accordance with the internal regulations of each participating country, there should be no export issues with this phase. Following the experimental use phase, international standards organizations will be consulted to begin adoption of the validated CAPIs as international standards.

Additional Thoughts
The approach proposed herein relies on the use of PCMCIA cards for isolating the selection of cryptographic functions to a user's decision at the time of use rather than a developer's decision at the time of implementation. This time-of-use feature is essential to allowing application developers to employ high-level cryptographic functions without encountering export controls.

However, the use of PCMCIA devices is considered a disadvantage by many because of extra hardware costs and potential performance issues. It may be possible within a particular country to implement system level cryptographic software compatible with the PCMCIA CAPIs. Such software functions would be subject to export control and if integrated directly into the general purpose application, would render that version of the application non- exportable. If a sufficient market existed within a particular country, overcoming the hardware disadvantages may be worth the export restrictions.

Some will argue that this approach does not satisfy government's concerns with the widespread availability of cryptography. In reality, though, this approach gives governments that wish to pursue techniques such as key escrow their best chance for success by providing a wide marketplace of application programs that can easily be used by their PCMCIA cards so long as they are compatible with the evolving worldwide standards.

Status of CAPI development
There are a number of examples of CAPIs that are already defined or near to being defined and in use or near to being in use at this time. In December 1994, the US National Institute of Standards and Technology held a meeting to explore and facilitate the sharing of information about various activities related to CAPI development in several countries.

The meeting was well attended by over 50 individuals representing numerous industry and government organizations. All of the current ICE participants attended the meeting. Government organizations represented at the meeting included NIST, NSA, National Aeronautics and Space Administration (NASA), Advanced Research Projects Agency (ARPA), Defense Information Systems Agency (DISA), the UK MoD and Defense Research Agency (DRA), and the Canadian Communications Security Establishment (CSE). Businesses and vendors represented included TIS, RSA Labs, Bell-Northern Research, Spyrus, IBM, Hewlett-Packard, National Semiconductor, Novell, Microsoft, Datakey, Litronic, Racal- Guardata, Uptronics, Anagram Labs, Bankers Trust, Fischer International, ICL, and PC Security Ltd. Other standards organizations represented at the meeting included X/Open, ANSI, and IEEE.

The meeting heard presentations on ICE as well as numerous CAPI efforts:

  • International Cryptography Experiment (ICE): one of the first objectives of ICE is to identify available CAPIs for integration into software applications to be placed into experimental use on an international basis.
  • UK MoD Security In Open Systems Technology Demonstration Programme: a specific objective of the SOS-TDP is to develop common cryptographic protection mechanisms and attempt to get them widely adopted by industry and government throughout the world. Supporters of the program are encouraging ICE as a potential means to establish a mass market for secure applications using strong cryptography.
  • X/Open Security Working Group: the group is developing a Cryptographic Service Model which includes the definition of APIs to enable development of secure applications using numerous security services, including data encryption. The group plans to publish its complete initial specifications in early 1995.
  • ANSI X9F1 Working Group: the group recently initiated an effort to define cryptographic interfaces for secure banking applications. The group has developed its requirements and a layered cryptographic service model, and is looking to align its work with other CAPI standards.
  • IEEE Portable Application Standards Committee (PASC) Encryption API Study Group: The recently formed study group is exploring the feasibility of defining cryptographic service extensions to the Portable Operating System Interface (POSIX), or IEEE Standard 1003.
  • Generic Security Service API (GSS-API): initially developed in the early 90's, GSS- API has been adopted and used by numerous organizations and is currently under consideration as an Internet Standard. GSS-API defines a service interface to distributed security technologies, implemented on top of multiple authentication and encryption technologies, and enabling application portability.
  • NIST Proposed Federal Information Processing Standard (FIPS) for Cryptographic Service Calls: NIST recently distributed a draft proposed CAPI standard for public comment and is planning to revise the proposed standard to incorporate feedback received during the comment period. NIST is actively participating in several CAPI standardization efforts, including the X/Open and ANSI efforts, and is exploring convergence/ coordination possibilities.
  • NSA CAPI Goals, Architecture, and Requirements: the Network Security Group at NSA supports the development of APIs to implement comprehensive security services that support Fortezza, are architecturally complete, and are commercially acceptable.
  • UK MoD SOS-TDP Cryptographic Interface Study: this recent study performed by Royal Holloway, University of London for the UK MoD analyzed existing CAPIs and identified recommended services and qualities of a cryptographic interface with a goal of determining acceptability of CAPIs to vendors for use in commercial products.
  • RSA Labs Cryptoki - A Cryptographic Token Interface: this interface is nearing completion and is designed to provide a standard device-level API to support the use of portable cryptographic devices in application programs. Cryptoki is intended to become a part of RSA Labs' series of Public-Key Cryptography Standards (PKCS).
  • IBM Generic Crypto Services API (GCS-API): this proposed interface is modeled after GSS-API and is designed to be a high-level, algorithm-independent, application independent API supporting secure applications.
  • Northern-Telecom ENTRUST APIs: NT's family of ENTRUST products provide a comprehensive set of tools and services for secure distributed applications. The ENTRUST APIs use the GSS-API, built on a simple public-key authentication mechanism, to provide session-oriented protection. The APIs also define an extension, Independent Object Protection (IOP GSS-API), to provide off-line protection for data objects.
  • Spyrus Extensions for Algorithm Agility (SPEX/aa): this low-level interface, based on the Fortezza interface, is designed to support a rich set of cryptographic functions and hardware/software implementations.

The initial stages of ICE will continue to look at these efforts and in order to identify all practical CAPIs and attempt to coordinate their use in experiments with commonly available software applications. To the extent possible, all publicly available interfaces will be included in the initial set of ICE experiments.

Status of Computer Applications
Discussions have begun with a number of software application developers with the intent of including their applications in the set of ICE experiments. Up to this point, the focus of attention has been on identifying CAPIs and software/hardware implementations of cryptographic functions. As we believe that a sufficient suite of CAPIs and supporting cryptography implementations is available, there is now a stronger need to consider application support. We are ready to aggressively pursue interactions with software applications developers. We are soliciting parties interested in developing or using software applications which provide cryptographic functions using CAPIs.

Status of Government Interactions
Of essential importance to ICE is the ability to export applications that call upon CAPIs but do not themselves contain any cryptographic functions. This is somewhat new territory for the export control process. If an application developer merely removes the cryptographic software from an application (such that it could, for example, be added back in with relative ease), export is still disallowed, in the United States at least.

But application programs that call CAPIs are not the same as programs for which the specific cryptographic code has been deleted. In this case, the actual cryptography used is bound to the application not by the software vendor but by the user at the actual time of use. The choice of which cryptography to use is made at the time a message is sent or a file saved, not at the time of manufacture of the program.

As we have reported earlier, the essential issues of this proposal have been discussed with appropriate officials in the US government. It is not clear when or if a decision will be made in favor of the export of applications that call CAPIs. But we are encouraged with the level of discourse that has taken place in the past year, and we will continue to push for a reasonable and timely outcome of this process.

So Where Do We Go From Here?
A proposal has been submitted to the US Advanced Research Projects Agency (ARPA) to support the coordination activities of ICE and to ensure that at least one publicly available application program is interfaced with the available CAPIs. We will integrate many of the available CAPIs and cryptography implementations into the TIS Privacy Enhanced Mail (TIS/PEM) software. We expect this proposal to be funded, and significant ICE activities to begin shortly. In the meantime, we will continue to pursue ICE coordination activities at a modest level of effort.

Individuals and organizations that wish to participate in ICE or to remain abreast of its activities are encouraged to contact us at Trusted Information Systems, Glenwood, MD, 21738 USA, 301-854-6889, or send e-mail to ice@tis.com. If you would like to participate in ICE, please indicate whether you are interested in application development, CAPI development, cryptographic function development, participating as a user, or something else. As our contacts in various industries and governments develop, we will be back to you with details on how to proceed.


Figure 1