HARRIS CUSTOMIZABLE CRYPTOGRAPHIC ARCHITECTURE Michael Kurdziel Harris Corp., RF Communications Div. Rochester, New York 14610 Robert Clements Harris Corp., RF Communications Div. Rochester, New York 14610 ABSTRACT The need for protection of information has dramatically increased in recent years as equipment that can be used for interception of sensitive data has become more readily available. The need to secure non-DOD sensitive data in both the government and private sectors has required the development of very robust, high grade information security solutions that can be tailored to meet specljlc security needs. Harris has made a long term R & D investment into developing a robust information securip architecture, that can be used in applications where Type 1 securi~ is not required. The architecture is based on Harris’s proprietary cryptographic algorithm technology. It supports Sensitive But Unclassljled (SBU) requirements and international markets requiring customer unique encryption. It is an ideal solution for the protection of defense and other national level interests, and provides state-of-the-art protection for both domestic and international users over a~ of the media used in modern communications. The first embedment of this architecture is the CITADEL m integrated circuit. CITADEL m is Harris’ prime export enc~ption solution for all of its new products requiring security, such as the FALCON II HF, VHF, and Multi-band radio platjorms. This paper presents an overview of the Harris Customizable Cryptographic Architecture and discusses various applications in which the CITADEL m can be used. 1. INTRODUCTION Information Security has become a major concern for the export, non-US DOD, and US SBU communities. International customers desire information security (INFOSEC) solutions that offer features traditionally available in Type 1 INFOSEC applications. These are introduced in the following paragraphs. 1.1 Security Autonomy Unlike the commercial INFOSEC community, domestic and foreign DOD and Government users require Security Autonomy. That is, they require that their INFOSEC algorithms be unique and not publicly disclosed. Many countries even have a need for several unique algorithms. This allows network separation to be guaranteed without relying on an elaborate key management plan. 1.2 High Cryptographic Strength In the past, the availability of intercept and decode technology was limited. For this reason, the tactical environment often allowed the use of a wider range of INFOSEC solutions. The dissemination of technology makes prediction of an adversary’s cryptanalysts capability increasingly difficult. Users now require that an INFOSEC solution be secure against all known cryptanalytic techniques. Many providers of INFOSEC solutions have focused on specifications such as key length to demonstrate the quality of their products. In reality, key length is only one component of a high quality INFOSEC solution. Few will dispute that a very strong cryptographic algorithm will be of little value if it uses a 20 bit key. However, it is also true that a weak algorithm which supports a 128 bit key is also of limited utility. Sophisticated customers will not accept key length as verification of an algorithm’s strength. 1.3 Functional Requirements In addition to the previously described requirements, it is desirable for an INFOSEC architecture to include the features discussed below. These features will allow the architecture to support a wide range of applications. A cryptographic algorithm is only part of a core INFOSEC architecture. An additional layer of the architecture controls the feedback structure for the algorithm and performs other simple mathematical operations. The algorithm defines the cryptographic strength of the architecture, but the traffic mode defines the ability of an architecture to recover from channel errors. Several traffic mode options should be available to allow the architecture to be configured for specific channel conditions. These modes allow the architecture to recover in the presence of both toggled bit errors and bit synchronization (dropped or added bits) errors. It is desirable to include a separate mode to be used only for traffic key wrapping (encryption) and unwrapping (decryption), A separate mode guarantees fictional separation between traffic functions and key management functions. This will eliminate the possibility of logical paths existing between key 1/0 and traffic 1/0 in embedments of the architecture. Another desirable feature is that the architecture have a scalable key length, This is particularly important in the application of the architecture to exportable embedments. By using an architecture with a scalable key length, new embedments will be able to accommodate changes in export policy without drastic changes to the INFOSEC core. This will allow compatibility with le~acy equipment to be maintained. 0-7803-4902-4/98/$10.00 (c) 1998 IEEE