SPARTA ISSO

Finished Projects

Cryptographic Technologies

Summary of the Fourth International (ICE)

Summary of the Fourth International ICE/CAPI Workshop

Held at the Holiday Inn Gaithersburg, Maryland, USA
December 3-4, 1996

Dennis Branstad and David Balenson
Trusted Information Systems, Inc.

Contents

Introduction

The Fourth International Cryptography Experiment (ICE) / Cryptographic API (CAPI) Workshop was held December 3-4, 1996 at the Holiday Inn in Gaithersburg, Maryland, USA. The workshop was sponsored by Trusted Information Systems (TIS). Participation in the workshop included over 60 representatives from many international industrial and government organizations.

ICE is an international program to promote the use of logical interfaces between computer applications needing cryptographic-based security and the underlying cryptographic algorithms and related functions implemented either in hardware or software form. The overall aim is to demonstrate cryptographic-based security APIs (CAPIs) in international secure applications which are independent of particular cryptographic implementations and algorithms. The TIS ICE project is sponsored by the U.S. Defense Advanced Research Projects Agency (DARPA).

The specific aims of this workshop were to identify progress in the development of security service APIs and cryptographic APIs; identify progress in the area of security support service APIs, including certificate management, key management, and authentication APIs; demonstrate the use of CAPI-related technology and products; and identify next steps in additional experiments and demonstrations.

The workshop included a technical presentation on the background and current status of ICE; numerous technical presentations on Government and industry efforts to develop and promote the use of cryptographic-based security solutions utilizing security APIs; presentations on efforts to develop security support APIs for certificate management and authentication; and several technical demonstrations of CAPI-related technology and products.

DECEMBER 3 (DAY 1)

Welcome
Stephen Walker, President of Trusted Information Systems welcomed the participants to the fourth ICE/CAPI workshop, noting that the first ICE workshop was held at NIST two years earlier in December 1994. He recalled that the foundation of the ICE project was laid by Keith Klemba (HP) in 1993 when Keith described the use of a set of cryptographic algorithms, any one of which could be implemented in a security token that could be used in one or more countries. A few weeks later, Steve flew to London where he met with Dr. Brian Gladman and Dr. John Laws and began to outline the concept of cryptographic interfaces that could allow and support the use of multiple algorithms. Dr. Gladman subsequently moved to the NATO SHAPE Technical Centre where the second ICE workshop was held in September 1995.

The third ICE Workshop was held at the NIST North in March 1996. Walker stated that a major part of the second and third ICE workshops had been to give European and U.S. perspectives on post-Clipper cryptographic technology and policy but that this meetings agenda was intended to minimize political positions and maximize technical discussions of CAPIs. He specifically noted emphasis on policy was no longer needed because the new policies on export of cryptography have alleviated or clarified these issues.

Walker outlined the TIS experiences in implementing strong cryptography in secure products such as its encrypting firewall and exporting the products to organizations such as Shell in the Netherlands. He finished with a strong statement on the importance of the technical aspects planned for the meeting, especially the demonstrations planned for the second day of the workshop.

ICE Layered Security Architecture and Experimental Framework
David Balenson, the ICE project leader at TIS, previewed the agenda of the workshop and set the technical tone for the rest of the workshop. Balenson reiterated the goal of ICE as developing modular, removable, replaceable crypto-based security components. He presented the ICE project, including the new ICE layered security architecture and experimental framework, and he outlined the current ICE demonstration activities including the development, demonstration, experimental use, reporting, and technology transfer phases.

NSA's CAPI Initiative Update
Amy Reiss, with the INFOSEC Research and Technology Office at NSA, presented an update on NSA's CAPI initiative. An NSA cross-organization team led by Reiss examined a number of CAPIs and produced a set of recommendations. The original NSA CAPI Recommendation included the Internet Generic Security Service API (GSS-API) with the Independent Data Unit Protection extensions (IDUP-GSS-API), the X/Open Generic Cryptographic Services API (GCS-API), and RSA Labs Cryptoki. A second edition of the NSA CAPI Recommendation was release in July 96, with updates to the GSS/IDUP and GCS-API specifications and the inclusion of Microsoft CryptoAPI. NSA is currently validating its recommendations by developing prototype implementations. A copy of the second edition of the NSA CAPI Recommendation is available on the Web at http://www.tis.com/crypto/ice/nsacapi/capi19.htm.

NSA FORTEZZA and CAPIs
John Centafont, with the Network Security Group at NSA, presented FORTEZZA and CAPIs, giving the evolution of the current low-level Cryptologic Interface (CI) Library into common operating environments. He discussed many applications that now make use of FORTEZZA. Centafont stressed the need to allow developers to use a standardized CAPI. Limited Cryptoki functionality is available today for Windows 3.1. Fortezza support is being integrated into Cryptoki Version 1.1. Support for full Cryptoki functionality will be available in early 1997, and support for Microsoft CryptoAPI will be available in Fall 1997.

UK MOD SOS TDP Update
Lt. Col. Collin Whittaker, U.K. Ministry of Defense (MoD) gave an update of their Security in Open Systems (SOS) Technology Demonstration Program (TDP). He noted that they are in the implementation phase of Demo 1 now but that Demo 2 has not started yet. He said that Demo 2 is presently in the bidding process and that two consortia have made bids with the results anticipated shortly. Collin stated that security is provided by telecommunication companies in general, that the U.K. MoD owns and secures its own communications now but that they may use security in commercial communications in the future that meets their needs.

A Pilot Programme for Confidentiality Services in Europe
Dr. Brian Gladman, Technical Director of TIS Europe, was with the U.K. MoD when he created the SOS-TDP and helped create the ICE project. He was also the Deputy Director of the NATO Shape Technical Center (STC) during the third ICE/CAPI workshop. Dr. Gladman presented a proposal for a Pilot Programme for Confidentiality Services in Europe. He said he has made the proposal to the Information Security Programme of the European Commission as part of a larger study in confidentiality services in Europe. He stressed the focus on commercial needs and not government access, although this was considered in his comments and proposal. He noted that such EC sponsored activities were 50% funded by companies performing the study with the aim of migrating to commercial confidentiality services. He addressed the requirement of a solution in a multinational environment (not just a national need) and stated that conclusions must be drawn by end within Europe without external constraints . His proposal called for 5 key recovery centres to be located in France, Germany, Netherlands, Switzerland and in the U.K.

Robert Rosenthal, DARPA, asked if there was a need for governments to approve the cryptographic algorithms to be used and if there would be industry acceptance. He also asked if there is a metric of a good algorithm that could be used to evaluate and compare public algorithms. Brent Holden, NATO STC, asked if a change of legislation was needed to deploy the pilot. Dr. Gladman responded that no change is expected nor needed.

Cryptographic Token Interface (Cryptoki) Update and Platform-Independent Crypto API (PICA) Alliance
Dr. Ray Sidney, RSA Laboratories, presented an update on the Cryptographic Token Interface (Cryptoki) and a short description of the activities of the recently formed Platform-Independent Crypto API (PICA) Alliance. Dr. Sidney explained that the primary goal of Cryptoki was to enable applications to interface with various cryptographic tokens easily. He said that Cryptoki Version 1.1 is planned to be released in early 1997. This new version will include support for a number of new mechanisms, including RC5, CAST, Fortezza, SET, key wrapping with checksums, keyed hashing MACs such as HMAC, and IEEE P1363. There are also future plans for Cryptoki Version 2.0, which will include major enhancements such as multi-user support and certificate-chain checking.

Sidney briefly discussed the newly formed Platform-Independent Cryptography API (PICA) industry alliance. PICA is gathering requirements and investigating existing APIs for possible use by the alliance.

Intel Common Data Security Architecture (CDSA)
David Aucsmith, Intel, described the Common Data Security Architecture (CDSA) that he has helped develop and that several companies have adopted. Aucsmith emphasized that the primary goals of his activities was to remove security/safety as a barrier to new business at Intel and to remove obstacles to growth of the PC market. He said that CDSA was freely licensable (i.e., anyone can get a license without cost) but that a license is required in order to control its specifications and implementations. Licensees must adhere to a set of test suites in order to prevent chaos and will be part of a standards process leading to uniformity.

Aucsmith explained that CDSA is not about cryptography; it is about trust provided through layered security services such as cryptography management and certificate management. CDSA uses a trust policy processor and a security policy is semantically checked via a parser. Key exchange mechanisms are part of the architecture. He stated his belief that, over time, trust will migrate to the hardware components of the platform. He noted that the information technology market requires trust of both a company and its products and that Intel will provide features such as trust assurance if the market wants it.

During the questions, Aucsmith stated that a CDSA license requester must be U.S. citizen in order to get code; and that CDSA follows a Web of Trust model rather than hierarchical model, because the former was not available, but that they can support both.

HP International Cryptography Framework (ICF)
Keith Klemba, Hewlett-Packard Corporation, presented the HP International Cryptography Framework (ICF). The goal of the ICF was to solve three categories of problems for three groups which he summarized as: export problems for HP; national problems because laws are constantly changing; and cryptographic utilization problems by enterprise developers. The basis of ICF is a cryptographic unit (token) in which different algorithms can be implemented depending on national requirements. They are colloquially called policy activation tokens and intended to work within an application domain authority. Each nation is able to approve (i.e., digitally sign) the policy provided by the national token. Klemba noted that TIS RecoverKey technology is supported as an option but that other options without key recovery are supported also.

Klemba explained that a major part of ICF is support for a binding capability between an application and an approved token via signature verification of components signed by a security domain authority. The principle ICF pillars include having cryptographic functions disabled using Touch Point Logic which allows export and can only be activated by an approved Policy Activation Token (PAT) by the policy authority of the local domain. Other governments can put classified algorithms in their national flag cards and provide the desired class of service activated in the cryptographic unit. These cards contain tamper resistance features and firmware providing all the glue needed between an application and the token.

Entrust Use of Security APIs
Tim Moses, Nortel, presented the use of security APIs in Nortel's ENTRUST product, including provisions for MISSI and ENTRUST interoperability. He discussed the Architecture for a Public Key Infrastructure (APKI). Moses noted that most users want to provide their own cryptographic services and simply use the certificate management capability of ENTRUST . He mentioned that the NIST specifications for U.S. government public key infrastructure (PKI) services are available on the NIST Web site.

NIST Proposed Authentication Module Interface (AMI)
Jim Dray, NIST, presented his work on a NIST Proposed Authentication Module Interface (AMI). The proposed AMI is based on the Common Authentication Architecture (CAA) specified by the NIST Advanced Authentication Technology Program. The AMI provides a generic interface to authentication functions by providing a number of functions that support the consistent communication and processing of authentication data among various system components and authentication modules. NIST hopes that the availability of a standard AMI will encourage system developers to create and employ authentication modules with well-defined boundaries, functionality, and entry points.

Dray also stated that NIST has contracted Cygnacom to build a reference implementation of the Generic Cryptographic Services API (GCS-API) on top of the Federal suite of algorithms including DES, X9.42, SHA-1 and DSA. The implementation is due for delivery in third quarter 1997.

DECEMBER 4 (DAY 2)

Overview of Certificate Management APIs
Neal Ziring, NSA, presented an overview of existing and emerging Certificate Management APIs (CMAPIs). Ziring explained the important role of CMAPIs for acquiring, validating, manipulating, and issuing public-key certificates. He reviewed the work of the Open Group Security Task Group to define operational requirements for CMAPIs. Ziring surveyed a number of existing or emerging CMAPIs, including dedicated CMAPIs such as Nortels CMS-API and NSAs CMAPI, as well as a number of security APIs with certificate management functions, such as Intels CDSA, Sun Microsystems SKI, Sesames PKM-API, and Microsofts CryptoAPI 2.0.

One participant asked if there is there a consensus on identification field (ID) of an individual in their X.509 format? The distinguished name is used but there are no firm and final formats was the response.

TIS ICE Demonstration
Michael Elkins and Chris Thorpe, TIS, described the ICE/CAPI demonstration they had developed and would be giving during the technical demonstrations. Elkins described his part of TIS ICE Demo One consisting of the TIS MIME Object Security Services (TIS/MOSS) secure e-mail toolkit integrated into Qualcomms Eudora Pro e-mail package on the Windows/NT platform. Eudora Pro 3.0 includes a new Extended Messaging Services API (EMS-API) which conveniently supports MIME security multiparts and allows other applications like TIS/MOSS to plug-in to Eudora Pro.

The TIS/MOSS toolkit has been modified to invoke low-level cryptographic services via Microsofts CryptoAPI 1.0. Thorpe described his work on TIS ICE Demo One to develop a number of Cryptographic Service Providers (CSPs) for CryptoAPI 1.0. The current demo includes the Microsoft Base Provider (which implements the RC2-CBC/40, MD2/MD5, and RSA cryptographic algorithms) and a TIS-developed software CSP (which incorporates RSADSIs BSAFE toolkit and implements the DES-CBC, MD5 and RSA cryptographic algorithms). Development is continuing on additional CSPs for Fischer Internationals Crypto SmartDisk, NSAs FORTEZZA card, and TISs RecoverKey technology. All of these CSPs utilize RSA Labs Cryptoki as an internal interface.

NSA's CAPI Demo: GSS-API Over CryptoAPI
Amy Reiss, NSA, presented the NSA CAPI demonstration, a simple Network Chat application providing secure on-line communications among a set of workstations using the Internet Simple Public Key Mechanism (SPKM). Reiss explained that SPKM security services are invoked via the Internet Generic Security Service API (GSS-API) and that cryptographic functions are invoked via the Microsoft CryptoAPI 1.0. She outlined the GSS-API function calls used by their application, and the mapping of those functions to CryptoAPI function calls.

The Real World Implementation of CAPI
Thi Nguyen, Secured Communications Inc. (SCI), Canada, presented SCIs work on CAPIs for their Session Key PCMCIA crypto card. Nguyen explained how they implemented a CSP for Microsoft CryptoAPI 1.0 with RSADSIs BSAFE as an application-mode process, and a low-level device driver with RSA Labs Cryptoki interface for their PCMCIA card as a kernel-mode process. He noted that there is usually a tradeoff in the use of layered CAPIs between fast development and slow execution. Nguyen described some decisions and experiences concerning their implementation for demonstration including what he called mutex (mutual exclusive) protection. He said that software-based solutions were more difficult than hardware solutions for providing high assurance and performance.

Technical Demonstrations of CAPI Technology and Products
TIS, NSA, and SCI conducted the technical demonstrations they had described. The participants were divided into groups and each group had twenty minutes to observe each of the demonstrations.

Novell's Controlled Modular Cryptography
Dr. Roger Schell, Novell, presented Novells approach to Controlled Modular Cryptography (CMC). Schell noted that this is now the foundation for future NetWare cryptography-based solutions and the targeted security infrastructure for applications. He said that in order to comply with international laws and to obtain approval for export from the U.S. as well as approval for import world-wide, they had to develop products that had no crypto-with-a-hole; that provided the strongest crypto possible in the end- customer environment; that supported key escrow as a new requirements; that supported extensible crypto services; and that controlled access to and use of crypto in accordance with the laws and regulations of many countries. In satisfying these, Novell decided they could not have crypto-in-a-red-box which is their terminology for a commercial shipping product. They are designing all their applications to work only with properly signed crypto modules, including: a null crypto-engine; approved exportable algorithms; and U.S. only algorithms. They are using a crypto loader that verifies module signatures and enforces layering independent of specific algorithms because they cannot ship applications that call crypto without a null, signed engine (prevents supplying crypto at a foreign site that is not approved for use). They require that a unique key identity be bound to every key recovery location for use in key backup and recovery.

Schell said that cryptographic policies are very important and must be associated with modules. He emphasized that they have designed CMC to provide the best crypto legally available to produce the most secure network possible. He noted that CMC specifications for potential partners are available under a license agreement if approved by various governments involved. The U.S. and G7 countries are probably easy with other countries being more difficult.

Update on Microsoft CryptoAPI & Security Service Providers Interface (SSPI)
Curt Kolcun, Microsoft, presented an update on the Microsoft CryptoAPI and Security Service Providers Interface (SSPI), which are components of the Microsoft Internet Security Framework. Kolcun described the digital signature system that Microsoft uses to sign Cryptographic Service Provider (CSP) software modules and verify them when loaded into Windows NT and Windows 95. The goal is to have only approved cryptographic modules operate easily with these operating system. This was done to obtain approval for export in compliance with government regulations. The validity and integrity of a CSP is checked at loading and during run time. The details of the checking process are not public. Kolcun said there is a big cost involved in setting up signing services but they have been looking at various countries having CSP approving and signing services. Having the European Community do it is one possibility. In response to a question regarding a bottleneck in the approval process, he answered there are many discussions going on right now but there is no bottleneck per se.

Kolcun noted there are already 5 million copies of CryptoAPI 1.0 in existence now. New services are being defined for new releases/versions. These could include: security services for mutual authentication; connection oriented transport independent security; services modeled after GSS-API; credentials and context support; distributed personal authentication (DPA); Kerberos in one or more flavors; certificate server support. He said that Microsoft has not exported software development kits (SDKs) for CryptoAPI 1.0 or 2.0 although the specifications are available. He stated that there has been some confusion over the Microsoft policy in SDK export and use overseas, including in the U.K. and other NATO countries.

RecoverKey: Emergency Secret Key Recovery
David Carman, TIS, presented the current perspectives on export of cryptographic products and the TIS RecoverKey and RecoverKey International approaches for recovering keys for users and for national emergencies, respectively. Carman described acceptable encryption algorithm key lengths going from 40 bits in 1992 to 64 bits with key recovery to proposed unlimited key length with approved key recovery. TIS RecoverKey products are following, and adhering to the evolving policy. U.S. vendors can export 56-bit key length encryption (e.g., DES) if they commit to build key recovery in their future products. He mentioned the Key Recovery Alliance which started with 11 members and is now up to 40 organizations.

WRAP-UP
Dave Balenson summarized the results of this workshop and did a wrap-up of the meeting. Balenson suggested that there was a seemingly confusing array of APIs two years ago but they have started to sort themselves out now. He noted there are a number of emerging cryptographic-based security architectures that make use of APIs, and there are a number of leading APIs. He said there appears to be great interest in cryptography with a lot of industry posturing with different consortia coming up with different solutions to the same set of problems. He asked rhetorically, Does there even need to be one CAPI? Do we need heterogeneity? He noted that a CAPI is intended to provide portability, but asked what does one do about interoperability?

Dr. John McHugh, Portland State University, noted that a CAPI gives a high level applications flavor of portability but what about an IPSEC view? In particular, one can encrypt at various levels in the communications stack of protocols. He wondered, if one needs to break the layered architecture in order to do functions such as key management, what are clean ways to communicate up and down stacks to negotiate the needed services at different layers?

Next ICE/CAPI meeting
The next ICE/CAPI workshop will likely be held in late summer / early fall 1997 in the Washington, D.C. metropolitan area. A notice of the meeting will be sent to the ICE interest e-mail list and posted on the TIS ICE Web page.