SPARTA ISSO

Finished Projects

Cryptographic Technologies

International Cryptography Experiment (ICE)

Summary of the Third International Cryptography Experiment (ICE) / Crypto API (CAPI) Workshop

Dennis Branstad and David Balenson
Trusted Information Systems, Inc.

Held at the National Institute of Standards and Technology
Gaithersburg, Maryland, USA
March 11-12, 1996

The Fourth International ICE Workshop has been scheduled for September 17-18, 1996, in Europe, probably in the United Kingdom. Workshop details will be posted, as they become available here.

Contents

Introduction
The International Cryptography Experiment (ICE) calls for a series of experiments to demonstrate the international use of cryptography in computer software applications in a manner that balances the needs of users, vendors, and national governments. ICE is intended to explore the use of logical interfaces between computer application software needing security and the underlying cryptographic algorithms and related support services. The overall aim is to provide and demonstrate the use of a Cryptographic Application Program Interface (CAPI) within international information processing applications so they can be independent of particular cryptographic algorithms.

The Third ICE/CAPI Workshop was held at the headquarters of the Information Systems Laboratory of the National Institute of Standards and Technology (NIST North). Miles Smid, Project Leader for Cryptographic Technology at NIST; Stephen Walker, President of Trusted Information Systems, Inc.; and Dr. Brian Gladman, Deputy Director of the Shape Technical Centre, The Hague, The Netherlands, were the cosponsors of the workshop. The workshop participants included ninety-one representatives from seven countries.

The workshop consisted of introductory comments by David Balenson, the TIS ICE Project Leader and Workshop Coordinator; welcomes by the cosponsors listed above; keynote presentations by Dr. Mike Nelson, Office of Science and Technology Policy, Executive Office of the President of the United States and by Mr. Andrew Saunders, Director of the Communications Electronics Security Group in the United Kingdom; and technical presentations by individuals interested in the international use of cryptography. The primary activities of the workshop included discussing the policies regarding the use of cryptography in several countries, identifying the constraints to widespread use of strong cryptography in widely supported commercial information processing systems, addressing the concerns of users, vendors, and sovereign governments, and outlining potentially workable solutions of political and technical problems in his area.

MARCH 11 (DAY 1)

Welcome
The meeting was called to order by David Balenson, leader of the International Cryptography Experiment project at Trusted Information Systems. This project is sponsored by the Defense Advanced Research Projects Agency (DARPA). David announced the logistics for the meeting.

Dr. Stuart Katzke, Chief of the NIST Computer Security Division, gave the welcoming address. He said that the first ICE workshop was held at NIST a little over a year ago [Note: December 1, 1994] with 50 participants. He reaffirmed his interest in the results of the ICE program.

Overview of Current Issues
Miles Smid, the NIST host and workshop cosponsor, gave an introduction to the NIST CAPI efforts. He said that nearly everyone who gave a presentation at the first workshop said they would have a CAPI available for use in six months; however, many of the predictions have since been proven to have been overly optimistic. He reviewed the goals of CAPI standards and reiterated his continued interested in their development.

Steve Walker, the second cosponsors, discussed the background of the ICE project. He talked about a Hewlett Packard proposed approach to having a "flag card" containing the cryptography of the country and having the application simply use the algorithm (s) approved by the country. He said a genesis of ICE was to investigate the export control of cryptography from the United States while relaxing the export control of the applications.

Steve reviewed his initiation of the ICE project and his interactions with several people around the world regarding the project. He said he had talked with Mr. Ed Hart, then INFOSEC Director at the U.S. National Security Agency (NSA), about the goals of the project and with Steve Squires and Barry Leiner of ARPA about funding it. He stressed the goals of balancing the goals of users needing security, vendors needing to export their products, and law enforcement and national security officials needing to do their jobs. He said that he, and most other American citizens, wants these groups to do their jobs efficiently and effectively while still meeting the needs of users and vendors.

Steve overviewed the NSA CAPI Recommendation and the Microsoft Crypto API architecture. He stressed the importance of providing flexibility for the user while still preserving the interests of governments. He outlined the three-layer, four-column framework that Dr. Brian Gladman had proposed as an experiment at the Second ICE Workshop last September. He observed that successful adoption of such a framework would allow vendors, such as National Semiconductor, to build several types of crypto modules (e.g., FORTEZZA, DES) for use with the same applications. He stressed that this architecture is not intended to make the U.S. dominate the world market for information processing but to allow all international industry to compete effectively. Steve concluded by stating that U.S. "centric" solutions will not work internationally and that every country must feel like they control their own sovereignty.

Dr. Gladman, the third cosponsor, stated that his goal was to work out a balance among international political interests. He has been working towards a global information infrastructure for many years and hoped it would be available by the turn of the next century. He stated that this is truly an international meeting with many people from Europe, Canada, and South Africa in attendance. He stressed the need to protect and balance all the national and commercial interests.

Crypto Policy in the U.S.
Steve Walker introduced Dr. Mike Nelson, Special Assistant to the Science Advisor in the Office of Science and Technology Policy (OSTP), Executive Office of the President. Dr. Nelson stated that he had been a telecommunications specialist with Senator Al Gore before the last election.

Dr. Nelson said that he spends most of his time in the area of National Information Infrastructure (NII) policy. He outlined the major goals of the NII, including bringing good teleprocessing to the schools and good, safe encryption technology to users in order to protect their valuable information. He said that establishing encryption policy was not an easy job. The Clipper Chip (Escrowed Encryption) initiative had been inherited from the previous administration and the present administration is still trying to establish the right policy in this area. He jested that his background in geology, especially his experience in seismology, was useful in working on the encryption issue since in both areas, nothing happens for a long time and then all hell breaks loose.

He presented the goals of the administration's encryption policy, specifically to provide users with global encryption solutions they can trust to protect the confidentiality of their information and that do not unnecessarily hinder the ability of law enforcement and intelligence agencies to do their jobs. He stated that billions of dollars and thousands of lives are at stake if the wrong encryption policy is adopted. He also stressed that the United States would like to maintain a good market share in this global industry.

Dr. Nelson answered the self-imposed question, "Who's involved in establishing the government's encryption policy in the administration?" He named eleven federal agencies that are participating in the Interagency Working Group on Encryption and Telecommunications, including representatives from the Department of Commerce (NIST, BXA), Department of Defense (NSA), Department of Justice, Department of State, FBI, National Security Council, and OSTP as major players. He stated the fundamentals of current encryption policy, including that there are no controls in the U.S. on the domestic use or import of cryptography and there have been no changes in existing privacy laws affecting the internal use of cryptography.

He then outlined the recent history of U.S. encryption-related export policy, stating that all cryptographic products required a State Department export license prior to 1983 when the Commerce Department was given authority to issue licenses for certain cryptographic products. In 1992, products using certain encryption algorithms with effective key lengths of 40 bits or less were approved for mass-market software export. The next highlights were the Clipper chip announcement in 1993, the Escrowed Encryption Standard publication in 1994, and the key escrow encryption initiative in 1995.

Dr. Nelson then walked through the policy problem that the administration is still addressing -- find an encryption policy that makes everyone happy (or equally unhappy). He listed nine constraints to the "solution space" for this problem (seethe slides for his presentation). He noted that encryption is a very touchy issue, stating that he had gotten "some heat" for jokingly calling it the "Bosnia of Telecommunications policy." He concluded the list with the two problems: (1) no one knows if the encryption they are buying is any good, and (2) "no one trusts anyone."

"The U.S. is talking with other countries, as in the OECD meeting held in Paris last December," Dr. Nelson said. He listed several reasons why finding an acceptable international solution is so tough, including intelligence gathering requirements, national sovereignty, and trade competitiveness. He listed several issues that still remain unresolved, including: Who can hold keys? Will there be international cooperation on decryption? Will anyone buy it?

He noted that there had been some progress in resolving cryptography issues, the most important being moving beyond the "one-dimensional debate in export control" (i.e., encryption algorithm key length). He said we are now in a "two-dimensional debate" and another axis for solutions (i.e., escrowing all or part of the key) has been added. He said he wished that the encryption issue was a simple linear programming problem for which he could use a computer program to look for a solution. He said that the U.S. policy is not to slow down encryption but to work with other countries in finding an acceptable approach. All countries want solutions that do not slow down the use of the information highway and want the availability of strong encryption but only while protecting national security and law enforcement interests.

Dr. Nelson then invited questions. During the discussion, he stated that:

  • encryption products still must be evaluated one by one;
  • the administration doesn't want to export a DES-based general communication product;
  • he expects no legislation that removes all export controls;
  • there may be legislation that legitimizes and solidifies key escrow rule;
  • criminals will not be stopped from developing their own uncontrolled cryptography;
  • criminals, however, like others, need to communicate with a wide range of people.
  • the draft key escrow agent criteria are not as flexible as desired;
  • the draft key escrow agent criteria are undergoing an evolving process;
  • the U.S. must work with their allies in developing an international encryption policy; and
  • the Clinton administration will oppose any relaxation of export controls.

He admitted that there is unbreakable encryption available commercially and that no country can prevent two terrorists from getting homegrown cryptography. However, their goal is to have standards that meet (at a 90% level) the needs of users, law enforcement, and national security. He stressed that users do not know how good their encryption is, that other countries control the use of cryptography (some more than the U.S.), and that in spite of the Department of Commerce report on the availability of cryptography, most of the cryptographic products available worldwide are not as good as users may desire.

A question was asked concerning an international framework for authorized escrow agents and if the U.S. has a position regarding escrow agents being outside the U.S. Dr. Nelson stated that there is no such policy because the U.K., France, Germany, and others in the European Union also have problems with cryptographic policy, and many details for interoperability have not been worked out. The U.S. "centric" view of his presentation was questioned but he answered that even though the current cryptographic policy change was initiated within the U.S., no final position will be established without coordination with appropriate allies and counterparts.

Steve Walker thanked Dr. Nelson for his participation and said that recommendations from the workshop would be passed on to Dr. Nelson.

Crypto Policy in Europe
Dr. Gladman introduced Mr. Andrew Saunders, Director of the Communications Electronic Security Group (CESG) in the U.K. for the past five years. Mr Saunders presented a talk ( see full transcript) and answered questions on the status of security policy in Europe.

The central topic of his speech was the pressing need for measures including the use of cryptography which will facilitate and promote transatlantic and world commerce while respecting and protecting national sovereignty. In the course of his speech, which was entitled "Crypto policy in Europe", he compared the situation in Europe with that in the U.S.

He began by outlining his responsibilities in the U.K., which include the electronic security of classified and sensitive information held by U.K. Government Departments, but do not extend to the commercial world. The duties include working with the Ministry of Defense to provide INFOSEC assistance to NATO and other alliances in the interest of secure interoperability. CESG's responsibilities in the U.K. were therefore broadly equivalent to those of the ISSO and part of NIST in the U.S.. CESG also made an input to the discussion of national cryptographic policy. He noted the growing importance of authentication, integrity and availability, particularly in the unclassified but sensitive domain.

Noting that his participation in the Workshop followed the precedent of Ed Hart (previously Director of Information Security in the U.S. National Security Agency) in the Hague last year, he turned to the main subject of his address. Europe did not have a single, shared crypto policy. Any policy had to take account of the many national security interests. A debate was taking place which recognized the rights of individuals, the potential use of cryptography for both good and bad ends, and the need for decision and action on its use and control.

CESG has taken an active interest in CAPIs as part of the general desire to take advantage of commercial developments and are about to change their funding basis by moving to a regime under which costs would be directly recovered from customers of their services.

The Trusted Third Party (TTP) approach to key escrow encryption was finding increasing favor within Europe, where a security system whose keys were all held in one place was never likely to be attractive to sovereign nations, and where there was resistance to a nation using a security product whose keys were escrowed in another country.

Mr. Saunders dealt with the requirements which a TTP system or infrastructure must satisfy: it must provide appropriate security, facilitate national and international transactions, be suitable for use by different communities of interest, be based on established technical standards and provide the means whereby Governments, under strict legal conditions, may gain timely access to encryption keys. He envisaged an international network of commercially-run licensed TTPs offering a value-added service on public networks, primarily supporting electronic commerce. Associated legal and technical issues were under consideration.

European nations considered the arrangements associated with legal interception to be a matter of national sovereignty. While the European Commission proposed to fund and encourage the development of TTPs, access to cryptographic keys and a European network would have to be under the control of member status. Nations needed to consider their own legal positions though any legislation might be harmonized. He acknowledged that these ideas had not yet in Europe been converted into policy and believed Europe had learnt from the U.S. CLIPPER experience. He gave credit to the U.S. for having faced the issue and stimulated the debate.

Mr. Saunders closed by stating that the issues cannot sensibly be addressed on a single national, or even a single continental basis and that users, vendors, and Governments all have a stake. They must cooperate to take matters forward; they must seek arrangements which will facilitate transatlantic and world commerce while respecting and protecting national sovereignty. CESG remained eager to work closely with customers, counterparts and industry in this spirit.

Following a break, Mr. Saunders responded to numerous questions from other workshop participants. The commonality (or differences) of the key escrow encryption approach of the U.S. and the TTP approach of the U.K. and Europe was discussed. The travelling electronic commerce customer using cryptography to protect business interests was discussed with respect to national laws, policies, approved technologies, and governing authorities as the customer moved from country to country. Interoperability among various approaches and technologies was discussed. Incentives for using various technologies was discussed. Mr. Saunders responded that a wide range of issues, from policy to the technical details of some of the questions, were being addressed within his organization and others.

One statement of a workshop participant was that export control is a lever for key escrow. Mr. Saunders response was that the European position is to provide value added security services in the information processing area, that TTP key escrow may be one of the services provided as the integrated security system grows, and that public and government endorsements key escrow will achieve its increased usage throughout Europe.

Steve Walker stated that commercial key escrow used to provide a spare copy of the key during an emergency is good for user and claimed that it should be acceptable for governments' needs. He said that "special plugs for cryptography" in applications do make the application programs nonexportable now in many instances. One participant stated that if an item is export-controlled, any item designed to be used with that controlled item is also controlled. It was stated that there is a gray area on what is controlled. A rhetorical question was raised, "If all software eventually has "cryptographic plugs" for export, will all software be controlled"? A discussion ensued over export controls without resolution.

U.K. MOD SOS TDP Update
After lunch, Lt. Col. Colin J. Whittaker of the United Kingdom Ministry of Defence (MOD) introduced the Security in Open Systems Technology Demonstrator Programme (SOS-TDP). The objective of this programme, he said, was to help reduce system lifecycle costs by encouraging industry to incorporate appropriate security in COTS products to enable organizations to use them for secure system interoperability. He then introduced Mr. Robert A. J. Hill of the U.K. MOD who gave the technical presentation on the Demonstrator Programme. Mr. Hill said that interoperability was predicated on a common set of protocols and mechanisms; portability on a common set of API's; and modifiability on a common security service API and "layering" technology. "Demonstrator 1" participants include Microsoft, Digital, and Novell utilizing PEM and MSP as applications. He stated that the design is evolving and Chrysalis and Lynks tokens are to be used. "Demonstrator 1" achievements include getting several competing companies to work together, changing a number of commercial products, producing a specification for the first demonstrator, and changing how business will be conducted.

"Demonstrator 2" focusses on session-based security of typical client/servers and accessing information within a business enterprise. The overhead slides of the presentations are included in this report.

A question was raised, "What happens if you become wildly successful?" Mr. Hill responded that the TDP process is a demonstration to users and vendors that security is needed and can work well among various products. Success, he said, would be measured by the number of vendors putting security in their products that can be procured and effectively used by HMG. He said that all results of the programme and the demonstrators will be in the public domain.

In response to, " Do you have multiple CAs in your architecture?" Mr. Hill responded that cross certification is supported using a version of X.509 certificate and that interoperability is supported among different domains using the NORTEL ENTRUST PKI system. He stated that a 40-bit DES is used, that vendors are building products now, and that export of applications using various crytographic methods will be sought.

Canadian Public Key Infrastructure
Lawrence G. Dobranski, Manager of the ITS Industrial Programs, Standards and Initiatives Section of the Canadian Communications Security Establishment (CSE) (http://www.cse.dnd.ca) gave a briefing on the Government of Canada's Public Key Infrastructure (PKI). CSE is a lead agency with responsibilities in information technology security for the Canadian Government. These responsibilities include providing endorsed or rated ITS products for protecting information regarding the national interest (i.e. classified), designated (sensitive but unclassified), and for Electronic Authorization and Authentication (EEA).

He outlined the report from the Information Highway Advisory Council of the Canadian government and their desire to balance the basic level of security needed to protect privacy and commercial interests with those of law enforcement and national security. The council recommended to provide encryption algorithms and standards open to public scrutiny and create a uniform PKI to support all needed security services.

The overhead slides of the presentation are contained in the report. The Canadian specifications were clear, precise, and dictated what was being supported within the Canadian government (With cooperation and support of Nortel). These included GSS-API, IDUP, PKCS 11 (CRYPTOKI), RSA, DSA, DES, Diffie-Hellman, and other approved algorithms for specific applications.

Mr Dobranski emphasized that they have unbundled the security services of nonrepudiation, integrity, and confidentiality. The Government of Canada has no official policy on law enforcement access, however, as outlined in the Information Highway Advisory Council report its requirements must be part of the Balance. Law enforcement access or data recovery is only an issue for the confidentiality service. Their is no requirement for such a recovery capability within digital signature process in their case since they do not use confidentiality to achieve data integrity. He said that while they were relying on the ENTRUST product line for baseline security architecture, they would support other end cryptographic units or applications that use the open CAPI interfaces.

Their goal is to establish a level of trust across the system, binding users to keys in accordance with a realistic security policy. He felt that unbundling of digital signatures from encryption makes some problems less difficult to address such as data recovery and export control.

Within the Canadian Government PKI, the root of the certification tree is the CSE. The PKI vouches for identities and the trust in binding is a value added service as is cross certification. He said that PKI security policy must be harmonized with other PKIs to achieve cross certification. The Policy Management Authority determines the security policy for the Government of Canada PKI, and arbitrates policy issues with other PKIs.

Their initial PKI would have a cadre of 175,000 users, with operation scheduled for the fourth quarter 1997. Further roll out to all of government would be based on demand and business case analysis. The PKI infrastructure components used by the Canadian government will be endorsed by CSE.

NSA CAPI Activities Update
Amy Reiss, NSA, gave an update on NSA's CAPI initiative. NSA's first CAPI recommendation is available at http://www.omg.org/. A second CAPI recommendation, incorporating Microsoft's CryptoAPI, is targeted for release on June 12, 1996. The NSA technical staff are implementing several CAPIs and experimenting with them, including a CSP within the Microsoft CryptoAPI architecture. They are also investigating and developing Security Service APIs and a Certificate Management API. Their plans include an authentication API, a key management API, and an audit API. Ms. Reiss proposed a specific ICE experiment consisting of three platforms:

  • one running GSS + CryptoAPI + FORTEZZA CSP within Windows;
  • one running GSS + Cryptoki + FORTEZZA PCMCIA token within Windows; and
  • one running GSS + CRYPTOKI + FORTEZZA PCMCIA token on a SUN Workstation.

Overview of NIST Cryptographic API and Authentication Program
Jim Dray, leader of the NIST Advanced Authentication Technology Program presented the NIST Cryptographic API Project. Voting on the General Cryptographic Service (GCS) API Draft 7 standard closed, he said, on March 8, 1996. The next X/OPEN Cryptographic Working Group meeting is scheduled for March 20-22, 1996. The NIST FIPS based on GCS-API is still scheduled for the third quarter of 1996 but its adoption has been affected by the Microsoft CryptoAPI. No resolution has been reached.

Mr. Dray also described the Authentication Module Interface and its related Authentication Program milestones. FIPS JJJ, a draft Public Key Authentication Standard, is still on track and is nearing completion. In the security model that he described, authentication is another security service one level above cryptography.

Microsoft CryptoAPI
Douglas Barlow of the Cryptographic Services group of Microsoft gave an overview of their cryptographic API and a status report on cryptographic service provider (CSP) development. Their API is presently available on Windows NT version 4.0 running on 32-bit platforms and will be available soon in Windows 95. Developers Kits are available now for CSP developers who are targeting Windows 95 markets.

The CryptoAPI presently includes service calls supporting key generation, key exchange, data encryption/decryption, hashing functions, and digital signatures. Their model is to have applications without embedded cryptography calling security services through the operating system to encapsulated cryptographic functions in CSPs. New CSPs can be added as needed. Their cryptographic-enabled Windows system presently ships with a Microsoft-provided CSP that supports an exportable 40-bit encryption algorithm. For communication with a user, a path is provided between an encapsulated CSP and the user through the Microsoft operating system.

In order to load and use a CSP, Mr. Barlow explained, the CSP software module must be signed by a 1024-bit RSA key held by Microsoft. The signature is to assure (to some level) the integrity of the software CSP and to demonstrate that Microsoft and the CSP vendor have taken steps to comply with local (U.S.) export laws. This process is intended to remove the burden of export control from the application developer and the operating system vendor and put it on the CSP developer. Microsoft is supporting only exportable operating systems and is not responsible for export approval of cryptographic modules.

Mr. Barlow further explained that if a foreign company wants to build strong cryptography in U.S. and comply with U.S. export controls, Microsoft will provide the same tools for them as for domestic developers. However, the CSP development kit must be licensed for export at present. Currently, CSPs to be used outside the U.S. must meet U.S. export restrictions (because they must be brought into the U.S. in order to be signed), even if they originated outside the U.S. for use exclusively outside the U.S. He said that Microsoft is actively lobbying to change this policy and would prefer to see CSP signing done by their subsidiaries within countries in which the CSP would be used.

Only one RSA key is currently used to sign CSPs, said Mr. Barlow. However, provision has been made for creating and using a master key which could become the root of a tree structure for later improved configuration control.

Barlow believes that there is a good market for CSP products and said that several organizations are working on software and hardware CSPs. The Microsoft model is to assume that CSP providers are "honest" and that Microsoft signing a CSP does not guarantee quality or validity of a CSP. He stated that a signed CSP module can load additional code which may not be signed.

Discussion ensued as to whether a signed CSP approach was a "way around" the "crypto with a hole" export issue (it remained unresolved).

A question was raised about availability of Windows with this API on a MacIntosh and the answer was deferred. Certificate management and key management questions were raised with a response that an API for them is being studied.

Dr. Brian Gladman presented his "level playing field" argument (i.e., he wants a security system in the U.K. equivalent to those existing with in the U.S). He noted the lack of domestic controls over the use of good cryptography in both the U.S. and the U.K. He doesn't think Microsoft (or any other company) should discriminate between users in the two countries. He would like to see an approved process for signing CSPs in each country, in accordance with local usage rules, by an authorized Microsoft signer (i.e., subsidiary). He said he will work in Europe to prevent widespread use of this "market discriminatory" mechanism.

One participant observed that the problem results from the control on export, as opposed to the use, of cryptography. Another remarked that this brings the validity of export law into question. Yet another observed that allowing the signing of strong, cryptography-providing CSPs outside of U.S. will increase the use of strong cryptography outside the U.S. which is against U.S. policy. It was observed that the agreement to control the signing of CSPs is a "done deal" between Microsoft and U.S. government.

Workshop participants were encouraged to propose experiments leading to a better understanding of U.S. export controls over CSPs and other implementations of cryptography. Some felt that a test case for CSP "approval via digital signatures" should span multiple countries.

Several participants felt that we must be able to "solve this problem." Some favored making a recommendation that the governments of the world control their domestic use of cryptography and provide CSP signatures locally. A recommendation was not finalized.

X/Open GCS-API
Piers McMahon, Chair of the X/Open Security Working Group, presented the status of their Generic Security Services API (GCS-API). He outlined the next steps of the working group in processing the GCS-API. Only minor modifications, he stated, were needed to be made to their document before it was published. He also compared this CAPI with the Microsoft CryptoAPI. He said the general philosophies of the two CAPIs were different. GCS-API supports a wider range of crypto primitives and targets more "crypto-aware" programmers. GCS-API supports symmetric key management as well as public key management, key storage, other key life-cycle services (registration, archive, etc.), integrity protection only (i.e., without data encryption), and is UNIX-oriented vice Windows-oriented, as i the MS CryptoAPI. He said there was no provision for "approval or control" of cryptographic algorithms or implementations as there is for the MS signature process. If possible, he said, he would like to see the two CAPIs converge.

Certificate Management Services API
Brian O'Higgins, Director of NORTEL Secure Networks in Canada, described the Certificate Management Services API (CMS-API) and the Public Key Infrastructure (PKI) available in their ENTRUST product line. He said the security API has 3 levels: applications using a high level security API (e.g., GSS-API, CMS-API); a mid-level cryptographic library API (e.g., BSAFE); and an API to support hardware modules (e.g., PKCS 11). He stressed that a CMS API provides easy access to a public key infrastructure and is not a CAPI for user data protection services, but is needed to support those secure applications. Entrust is a PKI product, he stated, and security applications developers are their intended customers. His slides are contained in this report. The URL for additional information is http://www.entrust.com/resources/whitepapers.htm. During the discussion period, Mr. O'Higgins said that applications have to process certain fields of certificates in order to make use of the CMS services. The CMS functions include creating new certificates, replacing old ones, and recovering old encryption keys. It should be noted that key escrow is called key recovery in Canada. Brian stated that NORTEL does not offer service directly to end customers but does provide technology to end-product developers and end-service providers. NORTEL makes the parts to connect to the PKI. Responding to a question, he said that they use Certificate Revocation Lists ( CRLs) instead of providing real-time verification of certificates (i.e., no instantaneous revocation of certificates). Certificates need replacement only within a 24-hour period, he stated.

NORTEL ENTRUST products have been endorsed under the joint U.S. and Canada FIPS 140-1 conformance program and they have received endorsement of their PKI in Canada also. NORTEL designs its products to protect against self modification of the software, he said, and users simply want to "sign and seal" their information. Developers don't care about crypto details, he continued; they just want a good security product on which to build their applications.

TIS ICE Program Status
Mr. David Balenson, ICE Project Leader at TIS, discussed "What is ICE all about?" and gave a program status update. A complete set of his ICE overhead slides are in these proceedings.

David explained that applications with embedded strong cryptography are not exportable but applications that contain no cryptography are exportable. A gray area exists if they use, but do not contain, cryptography. The goal, he said, was to support mass-market software vendors in building applications that rely on, but do not include, cryptography for certain security services. The cryptographic modules (hardware or software) containing the specific algorithms and supporting functions would still be controlled by their country of origin or of use. A slide illustrating a software application using Crypto API Service Calls through an operating system to loadable, changeable CSPs hypothesized that export is allowed for the application. David reviewed the benefits if this approach succeeds.

After the presentation, one participant asked, " If we accept the architecture as you depicted, with applications using a high-level CAPI to call services of a mid-level CAPI to call easily replaceable cryptographic algorithm services, isn't the problem regarding export just pushed down one level?" David responded that the CAPI specification is exportable and implementations (that exist) have been approved for export. "However," he rhetorically inquired, " can this be generalized?" He then led the discussion addressing this question.

Open Discussion
"Everyone wants to know the limits of export control and then push them for their own purposes" seemed to be the theme of the open discussion period. Many questions of the following nature were asked but no definite answers were given. "Why is a cryptographic service provider's implementor kit export controlled?" "How can we use the Microsoft experience in obtaining export approval for an application or operating system as an experiment in ICE? "Why isn't the emphasis on making strong cryptography available worldwide?" "Isn't it obvious that export of an encryption-enabled application will not be allowed unless it will only work with "approved algorithms and implementations?" "What makes it approved?" "Does making it exportable make it unacceptable to foreign customers (ala the 40-bit encryption algorithm effective key length mass market software agreement) given the publicity on how easy it is to break export approved algorithms?"

One question was raised about the issue of "easing" or facilitating parts of export control when authentication, confidentiality, integrity algorithms, and services are separated. The primary export controls focus on data encryption (i.e., confidentiality protecting) algorithms that provide security beyond an "acceptable" level. The next level focuses on key establishment algorithms beyond an "acceptable" level. Algorithms and implementations that can only be used for user authentication and/or data integrity usually fall into a different category and can be exported easier. However, if they can be easily replaced or modified, it takes longer to get a license for export.

The new U.S. policy on exporting 64-bit ( maximum) key length, escrowed encryption systems was raised. Various experiments regarding this policy were discussed but none were selected for performance. Uncertainty on the policy of exporting various CAPIs caused several participants concern. These felt that the Microsoft agreement with the government allowing export of their applications and operating system operating with "approved" CSPs should be available to others so that "a level playing field" could be found. Key issues should be identified and articulated, they thought. Written statements regarding these key issues were solicited from participants by the workshop sponsors for consideration during the second day of the workshop.

Formulators of experiments were encouraged not to predetermine acceptable solutions. Scientific experimental methods should be used. There was a discussion on whether ICE constituted primarily experiments in national export policy or in technical aspects of interoperability and replaceability. ICE was said to be primarily the latter but finding acceptable solutions within various export and use policies of different countries is also needed.

One participant stated that 21 nations coordinated their export rules on various areas, including cryptography, and that COCOM (the Coordinating Committee) no longer existed although the coordinated list still exists and contains rules on export of cryptography from the participating countries. However, some countries interpret the rules differently; some more strictly than others.

Steve Walker asked the participants to submit questions they would like to have answered for discussion the next day.

MARCH 12 (DAY 2)

David Balenson announced an agenda change adding comments by Doug Barlow and additional presentations by John Hughes and Richard Dowell.

New Encryption Legislation in the 104th Congress
Joan Winston, government policy coordinator for Trusted Information Systems, presented the proposed Encrypted Communications Privacy Act of 1996 and the proposed Security and Freedom through Encryption (SAFE) Act, introduced on March 5, 1996, in the U.S. Senate and House, respectively. She stated that the bills (proposed Acts) have similar, but not identical, provisions; have bipartisan support; and that hearings will probably take place in 6 weeks to 2 months on the two bills. She discussed the provisions of the bills, as shown on her overhead slides in these proceedings. Following her presentation, a number of questions were asked. One participant asked about Dr. Mike Nelson's position on the bill, the chances that the President would veto the bill if it passes, and the chances a veto would be overridden. Ms. Winston responded that some, but not all, the major areas probably will be changed. No one can predict what will happen on any bill and this will be harder than normal. Ms. Winston was asked if the International Traffic in Arms Regulations (ITAR) have precedence over legislation. She responded that legislation overrides administrative regulations. Another participant asked if the Congressman Grassly bill that prohibits use of encryption without key escrow on Internet has precedence over this bill. She responded that the last passed bill has precedence. Another participant asked if the ICE participants could use the personal use exemption for exporting cryptographic products for one's personal use. The response from a participant was that export of a controlled cryptographic item for demonstration was specifically prohibited by the personal use exemption.

Exportability of DCE Multi-Crypto Feature
Dr. Walter Tuvell of the Open Systems Foundation (OSF) presented his experiences attempting to get approval to export software for their Distributed Computing Environment (DCE) software that supports a multi-cryptographic algorithm/service feature. He described OSF DCE as a full-featured distributed application development environment containing APIs and online network services for doing distributed computing. The security services include authentication (based on Kerberos), authorization (based on Privilege Attribute Certificates), protected remote procedure calls (using GSS-API) having integrity and confidentiality protection, and audit. He said everything was considered "exportable" except for the confidentiality feature, which caused his problem. He claimed that the DCE Remote Procedure Call (RPC) specification is a very high-level CAPI and that applications can only specify high-level services and do not explicitly contain any cryptography. He also differentiated between their current product and their proposed future product regarding export approval. They currently only support DES, but the proposed multi-crypto feature would permit multiple key exchange and confidentiality protecting algorithms.

He said that, mindful of export concerns, they asked NSA (Z03) if such a multi-crypto feature would itself be exportable (noting that individual crypto mechanisms would require an export license). He also noted that current systems contain source code to do confidentiality using DES and that a Commodity Jurisdiction had been received in 1991 if the DES code was replaced by a trivial copy function (i.e., supports DES but does not contain DES). The response, he said, was that an implementation of multi-crypto supporting DCE would not be exportable in source-code form because it was an instance of "crypto with a hole" that would be too easy for someone overseas to fill in with strong cryptography. To be exportable, the CALLS to the cryptography would also have to be removed.

He concluded that it appeared that electronic copies of the source code of any program that calls a CAPI would be non-exportable even though their listings would be exportable. He called this policy absurd.

During the question period, several issues were raised: Why is electronic software export controlled while listings of software are not? Is intent involved in breaking export laws? Is "publicly available" the same as published? He concluded that the intent is to control the widespread use of strong cryptography, but the methods of controlling often don't make sense.

Novell's Defense Messaging System Program
Steve Beus, representing Novell's Defense Messaging System (DMS) Program from the Novell sales organization, gave a briefing on their approach to providing security in software systems, especially the DMS. Their goal is to work with customers worldwide and to satisfy all the requirements of customers, including those for security and exportability. He stressed that international markets are a large part of their work and that they are participating in numerous ongoing worldwide security projects in the "Pacific Rim" countries, Australia, Canada, and the U.K. MOD TDP. Export issues are very important to them, he said, since they want to help build smart global networks whereby 60 million people use their systems, moving around the world, connecting to any telephone line, and talking securely everywhere. They are anticipating 1 billion users in the future for teleprocessing services using different communications with many devices via their Net 2000 system. A major announcement would be forthcoming in this area shortly, he noted. He asked interested participants to watch the Novell Web page at http://www.novell.com for new announcements.

As the program manager for the Novell DMS program, Mr. Beus said that the U.S. DoD is the primary customer now, but they expect the system to go beyond the 2 million users of DMS in the DoD and be adopted by U.S. government civilian agencies looking for secure e-mail and then to users throughout the U.S. and then the world.

He summarized that DMS supports organizational messaging, uses an X.400 backbone, an X.500 directory, a modified commercial e-mail, and the FORTEZZA token for cryptographic based security services. Commercial standards plus military standards (P42 is a new security message type) such as the Message Security Protocol (MSP) are used. Novell, E-systems, and Firefox are working together in this area. Their goal is to provide Groupwise Desktop, allowing the user to click on "send DMS mail" or "get directory information" from the Desktop.

Beus said that the exportability of their product (minus the FORTEZZA cards) is an issue right now. When they get a resolution, they will provide it to the ICE group. He said they can support "content encrypted messages" right now and that the CAPI used in their MOD TDP demonstrator may not be the same as in DMS. He also noted that they could provide other encryption capabilities if FORTEZZA is not "the answer" for their customer.

An Architectural View of the Federal Security Infrastructure
Phil Mellinger, Chief Engineer of the Federal Security Infrastructure (FSI) Program, headquartered at the U.S. General Services Administration (GSA), presented an architectural view of the security infrastructure being developed for federal use. While GSA is the operator of the FORTEZZA program for civilian agencies, his group is looking at multiple security infrastructures and how they fit together.

Their mission is to support the government's vision of "paperless Federal transactions" being processed electronically, assuring that each electronic transaction is valid and secure. Their view includes applications interfacing to several service providers: basic cryptography service providers; supporting security service providers (e.g., certificate access); and secure repository services (date-time stamped and sealed and signed document storage). They are working with several federal agencies in developing pilot programs to use security services offered by the USPS and others. They are also coordinating with the federal secure messaging activities ongoing in DoD and elsewhere. They plan to use an information collection (I9) form to obtain the information from a user to go into a certificate which is then electronically put into a user-held token, such as a SmartDisk. A certificate for the USPS will also be on the token for verifying other certificates received from message-sending parties.

The Federal Security Infrastructure plans to support on-line revocation of certificates once the USPS Certificate Authority (CA) is on-line. There also will be an on-line directory service offered. The repositories for certificates include both trusted and untrusted facilities. FORTEZZA is a trusted repository; non-trusted repositories may also be used then the certificate must be validated each time it is used. He said that applications will need standard interfaces to make use of their services. He would like to see key exchange services use commercial standards.

Lawrence Dobransky noted that there is a difference between "Orange Book" trust (no crypto) and the Canadian/Common Criteria approach, which recognizes that cryptography can be used to provide trust. He stated that trust can be provided in vastly different ways. A plaintext key can be protected in a physically secure repository or in an encrypted form in a physically insecure repository. The latter is being more widely used now via certificates.

Microsoft Export Update
Doug Barlow addressed the question of the exportability of applications written to the MS CryptoAPI. Mr. Barlow read from the MS CryptoAPI Q&A, which addresses a number of questions, including U.S. export controls on CryptoAPI components. Under the heading "What elements of CryptoAPI are subject to Commerce Department (Commerce) licensing?" the answer includes "Applications that call CryptoAPI and do not otherwise implement cryptographic security" and further states "We expect U.S. export authorities will waive the commodity jurisdiction (CJ) requirement for CryptoAPI-enabled applications that do not otherwise implement secure functions, as soon as their regulations have been amended to allow them to do so."

Trusted Third Party (TTP) Key Escrow Proposal within the U.K.
John Hughes, Trusted Information Systems U.K./European office, gave an overview of the TTP key escrow approach that had been described by staff members of the Royal Holloway College in the U.K. He said that the technically detailed paper uses a modified Diffie Hellman key establishment protocol for government authorized key recovery. He described the protocol that two TTPs (Ta, Tb) must perform to establish enough information so that when User-"a" sends encrypted mail to User-"b", that the key needed to decrypt the message can be obtained from either Ta or Tb. He said that this TTP proposal is a mathematical framework requiring detailed engineering to make it practical.

Following the presentation, TIS was asked to put the technical paper containing this proposal on the TIS ICE home page. Dr. David Herson of the European Commission was noted to have said that the TTP approach is the way key escrow will be done in Europe. Steve Walker encouraged the workshop participants to comment on the proposals. [Note: TIS will provide the proposal and make the comments available on the ICE page.] Mr. Walker said that a list of "hypothetical criteria" were created in the U.K. about a year before the Royal Holloway paper was published and that these appear to have been used in developing a system that meets the EC desires.

Other comments on this proposal included that a secret key system (see X9.17 for reference to a Key Distribution Center) would satisfy similar requirements; that a parallel infrastructure for digital signature certificates could be operated by a TTP; and that linkage could be established between them since one infrastructure could be used to distribute signature certificates once a user's private encryption master key has been escrowed.

CESG's Architecture for Secure Messaging
Dr. Richard Dowell, CESG, gave an overview of the CESG's Architecture for Secure Messaging (CASM). He said the system is based on the message transfer agent model that is currently popular in the U.K. It is also a U.K. variant of the U.S. DOD Message Security Protocol (MSP). It uses a cryptographic engine that is developed for and available in the U.K. He said both modules are being provided by the CESG.

The security model is based on having one U.K. top-level certification authority and adding other policy certification authorities as needed. All certification authorities are housed in TTPs based on the ideas in the Royal Holloway College publication. Engineering requirements will change the details in the implementation, said Dr. Dowell. The CASM provides a security label in the clear - signed but not encrypted - and an additional encrypted label when needed. Their protocol is largely based on MSP 4, but the key management is different. He said there is a national extension field - beyond the MSP protocol (version 4)- for internal U.K. purposes. He responded to a question about the encryption algorithm but said it was independent of those in MSP.

Dr. Dowell stated he was interested in both the RSA and DSA for signature but that the CESG has not made a final decision as to which to use. When asked, "Where does the security label come from?" he responded that the user establishes the classification of the message and selects the appropriate label in the User Agent (UA). He also said CASM is designed to an ITSEC "E3" security rating level but that the prototypes had not been evaluated. CASM is not addressing traffic flow security. He said CASM will work inside a protected domain with a Guard to check the security label and to check if the information is encrypted properly. Binding between User Agent programs (UAs) gives peer entity authentication, he noted, but not non-repudiation of submission. He concluded by saying that there is a goal of having a common MSP with other countries.

Proposed 64-bit CKE Experiment
Dr. Brian Gladman described the "64-bit CKE Experiment" that he had proposed at the Second ICE Workshop and later refined. He described a 4-column, 3-tier model wherein the 4 columns represent decreasing levels of risk (and crypto strength). The 3 tiers described risk, crypto strength, and key recovery approach, he said, and he wanted to focus on the two middle columns. He noted that the third-tier name was changed from key escrow to key recovery intentionally.

He proposed an ICE experiment (see his slide) as: two applications (electronic mail and a word processor) with a certificate manager and a crypto key manager running on a platform. He proposed GSS-API over the GCS-API over Cryptoki (PKCS 11) using PCMCIA interfaces to high-grade government algorithms (e.g., SKIPJACK in FORTEZZA) and high-grade commercial algorithms. Commercial Key Recovery meeting draft U.S. export criteria would be used. He stated that: Commercial Key Recovery was a good match with commercial needs; it fits with current search-warrant legislation in many countries; it is capable of supporting European TTP concepts; and, it is likely to attract much wider support than government-sponsored key escrow. He felt that it is a means to an end (proving CAPI concepts) and not an end it itself.

Dr. Gladman stated his opinion that the Microsoft approach to export was a major technical advance. However, he wants Microsoft subsidiaries in each country to be able to sign CSPs "approved" for use in that country and open markets between nations with equivalent constraints on cryptography.

A lot of discussion ensued. One question was raised about controlling the export of strong encryption from the U.S. which may not be controlled overseas. The Microsoft process was questioned, i.e., why is it that a CSP built outside the U.S. that is imported into the U.S. only to be signed should be subject to U.S. export control now? Brian said he has made a request to Microsoft for a CSP developer kit but has received only one (neutral) response in 8 weeks. He felt that the U.K. should control export from the U.K. and that other countries should be able to export U.K. approved products back to the U.K. He reiterated his desire for a level playing field, i.e., what is available in the U.S. should be available in the U.K. He felt this was now a GAT trade issue that could result in trade embargoes. Others said this could be a method to restrict trade and be a non-tariffed barrier to trade.

One U.K. participant stated that the problem may be a failure of the U.K. to have a dominant software industry to compete with the U.S. Another participant questioned if crypto export laws had outlived their usefulness to the western alliance. Another asked if Americans are willing to participate in electronic commerce with rest of world using only 40-bit security.

Additional ICE Experiments
Following Dr. Gladman's presentation, David Balenson led the discussion on establishing additional ICE experiments focussing on technical matters. However, the participants preferred to focus on the export issues. One proposed experiment was to export a Microsoft Software Development Kit (SDK) to Europe so that a CSP could be developed in Europe for signing (perhaps in Europe) by Microsoft.

Dr. Gladman summarized the two groups of participants in the Second Ice Workshop that had 1) agreed to participate in ICE Experiment 1, and 2) agreed to consider participating in that Experiment. The first group included: U.K. MOD, SPYRUS, TIS, Microsoft-U.K., and NSA.

One participant felt that ICE should not be an experiment in key escrow but rather a broader experiment in export understanding. Others said ICE is both a technical and political experiment answering questions about what works and is exportable.

A participant called for a set of controlled experiments conducted in accordance with scientific methods whereby a null hypothesis is stated, independent variables established, and dependent variables identified. The experiments then would change just one variable at a time in order to see what effects were caused by what changes.

A general set of questions to be explored could include:

  • Are applications with CAPI calls exportable?
  • Are CAPI (source, binary) implementing software themselves exportable?
  • Are Cryptographic Development Kits exportable?
  • Are CSP's exportable and what are the constraints?

Specific sets of experiments would be conducted to answer these questions.

Dr. Brian O'Higgins of NORTEL offered to provide the CAST symmetric encryption/decryption algorithm to experiment participants for free. CAST is a DES-like algorithm with a 64-bit key length.

A participant stated that there would be a RSAREF implementation available from MIT and that PGP 3.0 will have a .dll for windows. Another attendee stated the desire to find something Acceptable to governments and to the users, saying that the U.S. CERT uses PGP to sign emergency responses for integrity and source assurance before distribution.

It was observed that a crypt- aware application does not need a high-level CAPI, and the goal of low-level CAPIs is "plug and play" crypto modules. One person claimed that GSS is a security API, not a crypto API. Another claimed that the level of the CAPI may affect the (export) experiment and the products used in the experiment. Another argued that the level of the CAPI may or may not change the results of export request.

Dr. Walt Tuvell responded to Steve Walker's call for written proposals by proposing a letter to NSA Z03 asking for policy clarification on "export of CAPI" issues. The group was unable to concur on the contents of the letter.

Questions arose such as : Who is the "user" in the planned export experiment? military? financial? e-mail user? David Balenson said that we can't target any particular group of users. This was countered with the assertion that export controls are group-dependent, e.g., financial transactions versus general communications.

Steve Walker said that the workshop participants had been focussing on U.S. export controls and that someone should build a cryptographic product in another country and trying to export it. For example, one or more applications and CSPs should built outside the U.S.

Miles asked that if someone has a CAPI or an application different than those being discussed, how can they get it to become part of an ICE experiment? The proposer should present a concrete proposal to TIS, the ICE coordinator, he was told.

It was noted that:

  • Those who already own a specific application using cryptography are being encouraged to join an ICE experiment;
  • Participants should understand what is available (a goal of the ICE workshops);
  • Participants should consider which CAPIs are relevant to them and to the experiment;

The participant from South Africa strongly suggested that the workshop coordinators and participants should choose parameters; set deadlines; completely specify a project plan; and get it done before next meeting.

A final note was made that any experiment should include both FORTEZZA tokens and non-FORTEZZA tokens.

Next ICE/CAPI meeting
The next semi-annual meeting will be held September 17-18 (Tuesday-Wed), 1996. Dr. Brian Gladman will find an appropriate location. David Balenson will send a notice of the meeting to the ICE interest list and will also post these proceedings on the TIS ICE Web page. David thanked the NIST hosts, the cosponsors, and the participants.