SPARTA ISSO

Finished Projects

Cryptographic Technologies

International Cryptography Experiment (ICE)

An International Cryptography Experiment 'Plug and Play' Cryptography
by Dr. Brian Gladman
December 8 1995

  1. Introduction
    1. The International Cryptography Experiment (ICE) is an informal international alliance of individuals and organisations with an interest in the wider exploitation of cryptographic (and related) mechanisms for the provision of confidentiality, integrity, authentication, access control and digital signatures within emerging national and global information infrastructures.
    2. A central focus of ICE is the demonstration of 'plug and play' cryptography - that is computer applications built to exploit externally provided cryptographic mechanisms through the use of one or more standard interfaces.
    3. Interfaces between application programs and underlying cryptographic mechanisms are generally referred to as Cryptographic Application Programming Interfaces (CAPIs). Such interfaces allow applications developers to build secure applications without the need for expertise in cryptography. They also allow many different applications to make use of the same underlying security mechanisms.
    4. Such interfaces can also be looked at from a cryptographic point of view in that they allow different cryptographic mechanisms to be 'plugged' into computer applications without making changes to the latter. Viewed in this way such interfaces are often called Cryptographic Algorithm Portability Interfaces (CAPIs).
    5. In this paper the term CAPI will be used to cover either concept.
  2. Requirements For CAPI Demonstration
    1. In order to demonstrate CAPIs in the international context set by ICE it will be necessary to show their use with a wide range and variety of:
      • cryptographic mechanisms, and
      • computer applications
      from organisations and companies in a number of countries. Since the aim of ICE is to demonstrate CAPIs, not to develop them, it will be important to select from those which other groups are already defining. Here the NSA report(1) appears to offer a good basis for CAPI selection.
    2. These CAPIs and the associated applications and algorithmic mechanisms should be chosen in such a way that a truly international experiment results. In other words, the span of applications and cryptographic mechanisms should be such that as many Nations and as many organisations as possible are involved. Since there is no central funding for ICE, any demonstration will need to be sufficiently attractive to participants to justify their commitment of resources.
    3. The CAPIs selected must meet the following requirements:
      • they must be openly and freely(2) available internationally;
      • they must be complete and fully specified;
      • they must support a wide range of cryptographic mechanisms;
      • they must support a wide range of computer applications.
  3. Cryptography Requirements for CAPI Demonstration
    1. Within the United States a significant amount of study work has been undertaken to identify and categorise national requirements for cryptographic information protection. This work has led to the three tier approach illustrated in Figure 1.
    2. In Figure 1 the grey outline indicates the need for a mode to provide interoperability between Tiers 1 and 2. Such a policy can be generalised to provide a 'generic' national viewpoint as illustrated in Figure 2.
    3. In Figure 2 the 'International Interoperability Mode' is an equivalent of the US interoperability mode which it might be possible to demonstrate in an international context. An additional relevant factor here is the announcement by the US Administration that they may allow the expedited export of cryptography up to 64 bits in strength if a key escrow feature is implemented. This suggests that a possible way of pursuing ICE could be the open international specification of:
      • A fully defined Commercial Key Escrow (CKE) Encryption Scheme using public algorithms and meeting the proposed US expedited export requirements.
    4. The ICE demonstration could then include the following:
      • the demonstration of interoperable international software reference implementations the above scheme using common CAPIs;
      • the demonstration of interoperable hardware implementations;
      • the demonstration of these CAPIs with private Government schemes such as the US MISSI/Fortezza encryption product;
      • the use of a wide range of demonstration applications including electronic mail, WEB clients and servers, transaction processing, database query and update and custom military applications.
    5. Such a demonstration is illustrated in Figure 3 where the grey box outlines the core of the 'international interoperability mode' demonstration, with multiple implementations of a publicly specified and freely available Commercial Key Escrow Scheme.
    6. Since the aim is to demonstrate common CAPIs, not the specifics of underlying security mechanisms, it will also be important to attract other government and commercial involvement and this might be achieved as shown in Figure 3 by pursuing a number of interface compatible PCMCIA based security tokens.
    7. The four interfaces proposed for demonstration are the three identified in NSA's paper with the addition of a hardware PCMCIA interface. For the latter it is assumed that the normal 'non-security' PCMCIA interface is standardised elsewhere - the ICE interest is in the security syntax and semantics of this interface - that is the software view of the security functions implemented on the PCMCIA card. As with other CAPI interfaces, not all elements of the ICE demonstrations will need to make use of all the identified CAPI interfaces. It is possible, for example, that only a subset of the ICE participants will be interested in the PCMCIA format and hence in interface standards at this level.
    8. An important consideration which cannot be overemphasised is that the use of a CKE scheme as a focus for demonstration should not detract from the primary aim of practical CAPI demonstration in an international context. Thus the CKE aspect of the demonstration is a means to an end, not an end in itself.
  4. Algorithm Choice For The ICE CKE Scheme
    1. There is a need for any ICE/CKE demonstration to be credible and this requires sensible algorithm choices within the constraints set by the proposed new US export criteria. Although confidentiality algorithms involve particular difficulties, signature, digest and integrity algorithms also provide some difficult patent and royalty issues and this will mean that careful decisions will be necessary. Nevertheless choices will be needed in at least the areas described in the following paragraphs.
    2. Message Confidentiality Algorithms. These must be limited to an effective key length of 64 (or less) bits and the most obvious choice is DES at 56 bits. There is now concern about the strength of this algorithm at this key length but the proposed export rules would allow the extension of the key length to 64 bits (this would require cryptographic expertise to extend the design). On the positive side, however, DES is free of license costs and has stood up well to extensive scrutiny over many years. It must therefore be a strong candidate.
    3. There are possible alternatives to DES but only a few are sufficiently well thought of for serious consideration. IDEA is increasingly popular but its use requires a license fee and its natural key length is 128 bits.
    4. Message Encryption Key Generation Algorithms. In many modes of operation the encryption key used to encipher a message - the Message Encryption Key (MEK) - is generated from a random or pseudo-random number generator. This is then 'wrapped' in a Key Encryption Key (KEK). The most obvious choice for situations (such as messaging) where MEK generation can be undertaken at a single point is a true hardware based random number generator but this approach has the disadvantage that it cannot be duplicated in software.
    5. For some applications it may be useful to be able to generate the MEK in parallel at more than one point and this suggests that a pseudo-random sequence generator should be used. Such a generator will also allow completely equivalent hardware and software implementations but it does introduce possible vulnerabilities. Nevertheless, given the pitfalls involved in this aspect of cryptographic system design, it may be preferable to use a well respected pseudo-random sequence generator rather than a flawed but apparently 'random' one (as Netscape did).
    6. Of the sequence generators available the Blum-Blum-Shub (BBS) generator is highly respected but has the disadvantage of being very slow. Much faster schemes have been published but less is known publicly about their strength. Again this is a critical area of cryptographic system design where expert advice will be vital.
    7. Key Exchange Algorithms. The RSA algorithm is by far the most obvious choice but not necessarily the right one. The problem with RSA is that the same public/private key pairs will normally be used with many individual message exchanges and a single compromise of the private key used will allow past and future messages to be decrypted. Such extensive key reuse is generally considered to be unwise. RSA also involves license costs within the US although it is free elsewhere.
    8. The Diffie-Hellman scheme involves the negotiation of a key which depends on both the originator and recipient and this has the useful by-product of originator and recipient authentication (assuming that the public key components are certified as belonging to their owners). However it still has the weakness that the compromise of a private key component will allow past and future messages from (to) this source (destination) to be read. Diffie-Hellman involves royalties until 1997.
    9. There are further developments of the Diffie-Hellman scheme which introduces a random component into each key and this reduces the above weaknesses. Again, however, this introduces higher overheads, speed reductions and additional potential vulnerabilities. Because the choice of the KEK algorithm will have a critical impact on security it will again be vital to obtain expert advice in this area.
    10. Message Digest (Hash) Algorithms. There appear to be two alternatives here: MD5 (Rivest) or the Secure Hash Algorithm (SHA). SHA seems to be the most sensible choice.
    11. Digital Signature Algorithms. The choice here appears to be either the RSA or the DSA algorithm. A license is needed for RSA in the US but not elsewhere; for DSA the license situation is confused by a long running patent infringement dispute which still appears unresolved.
    12. In some of these areas it may well be essential to allow for multiple alternatives using dynamic selection within the defined CKE protocols.
    13. Lastly, readers should note that the aim of this section is to provoke debate, not to provide definitive or expert advice. The author is not an expert on algorithms or patents - and these ARE areas for the experts!
  5. Acknowledgements
    1. I would like to thank Steve Walker, David Balenson and Denny Branstad of Trusted Information Systems for their efforts in pursuing ICE and for their assistance in the development of the ideas contained in this paper. I am also grateful to Russ Housley of Spyrus for his comments on an earlier version of the paper. My special thanks also go to all participants in the ICE Workshops who have generously given their time and their support and without whom ICE simply would not exist.
    2. Last but not least, I acknowledge the support of my many close friends and colleagues in the United States and in the United Kingdom who have given me the encouragement and support necessary to pursue ideas that are an undoubted challenge to the traditional ways of doing business in the world of algorithmic(3) information security.
  6. Endnotes
    1. Security Service API: Cryptographic API recommendation, NSA Cross Organisation CAPI Team, June 12, 1995.
    2. Possibly a licensed scheme provided that the terms, conditions and costs are reasonable and not discriminatory.
    3. The term `algorithmic' is used here rather than `cryptographic' in recognition of the fact that only a few of the algorithms involved are cryptographic.
    The International Cryptography Experiment
    Version 1.6, dated 8th December 1995