Donate for the Cryptome archive of files from June 1996 to the present


12 November 2013. Revised Cryptome mirror URL for Technical Requirements Document.

19 August 2006. A sends "NSA Encryption Algorithms:"

http://en.wikipedia.org/wiki/NSA_encryption_algorithms

17 August 2006. An original .DOC version (3.8MB), dated 1/1/2006 is available, with figures [now dead]:

https://abop.monmouth.army.mil/baas.nsf/Solicitation+By+Number/C0D0755A5C0CBDF
3852570F300713050/$File/Technical+Requirements+Document.zip

Cryptome mirror converted to PDF: http://cryptome.org/technical-requirements-document.pdf

See also related documents:

https://abop.monmouth.army.mil/baas.nsf/fa51ff5d44ef1e9d85257169006cf805/c0d0755
a5c0cbdf3852570f300713050?OpenDocument

15 August 2006

Information invited on these algorithms cited in the document (send to: [Image]):

ACCORDION
BATON
CDL 1
CDL 2
FFC
FIREFLY
JOSEKI
KEESEE

MAYFLY
MEDLEY
SAVILLE
SHILLELAGH
WALBURN
WEASEL

Figures were not included with the cached document. Irregular paragraph numbering in the Google HTML conversion from DOC.


This is the html version of the file https://abop.monmouth.army.mil/baas.nsf/
Solicitation+By+Number/05BE16D84C0EBD38852570D8006FF570/$File/
DRAFT+TRD+Rev0.3+.doc
.
G o o g l e automatically generates html versions of documents as we crawl the web.
To link to or bookmark this page, use the following url:
http://www.google.com/search?q=cache:nlkVNCM8Z3kJ:
https://abop.monmouth.army.mil/baas.nsf/Solicitation
%2BBy%2BNumber/05BE16D84C0EBD38852570D8006FF570/
%24File/DRAFT%2BTRD%2BRev0.3%2B.doc+%22Medley+
algorithm%22&hl=en&gl=us&ct=clnk&cd=4
Google is neither affiliated with the authors of this page nor responsible for its content.


1146  
 

(U) TECHNICAL REQUIREMENTS DOCUMENT

FOR THE

PROGRAMMABLE OBJECTIVE ENCRYPTION TECHNOLOGIES (POET)

ADVANCED CRYPTOGRAPHIC MODULE (ACM) 
 

DOCUMENT DISTRIBUTION RESTRICTIONS:

This document contains information exempt from mandatory disclosure under the Freedom of Information Act (FOIA). Exemption 3 applies. 

Not Releasable to the Defense Technical Information Center (DTIC) per DOD Instruction 3200.12.  

Unclassified FOUO Information: The document contains unclassified For Official Use Only information which is for the exclusive use of Government and Contractor personnel with a need-to-know the information. Such information is specifically prohibited from posting on unrestricted bulletin boards or other unlimited access applications.

(U) Revision History

 

Rev.

 

Date

 

Description of Change

Affected Pages

0.1

10/13/05

Initial Draft

All

0.2

11/14/05

Second Draft All

0.3

11/17/05

Updated cover sheet “Document Distribution Restrictions” Cover Page
       
       

 
 
 

 

      (U)  TABLE OF CONTENTS

Section           Page 
 

(U) List of Figures

Section           Page 

(U) List of Tables

Section           Page

 

  1. (U) Introduction
    1. (U) Scope

(U) The Programmable Objective Encryption Technologies (POET) program will design and develop an Advanced Cryptographic Module (ACM) capable of meeting the communications security needs outlined below.  This document provides the technical requirements of the POET ACM.  

(U) Future terminal architectures will require enhanced high-speed cryptographic capabilities in order to support the higher data rates and increased information security (INFOSEC) demands imposed by modern waveforms and ever-increasing security regulations.   

(U) These future terminals are envisioned to be a family of multi-band, multi-mode, transportable, modular, flexible, Software Communications Architecture (SCA) compliant, satellite and Line of Sight (LOS) systems supporting simultaneous communications between ground, airborne and surface/subsurface units for a range of missions across all services in tactical operational environments.   

(U) These terminals will be capable of operating with the military and commercial satellites, envisioned to be operational in the 2010 and beyond timeframe, utilizing X, Ku, Ka, and Q-band frequencies (above 2 GHz). These systems include, but are not limited to, the Wideband Gapfiller System (WGS), Advanced Extremely High Frequency (AEHF), Global Broadcast System (GBS) and Transformational Satellite Communications System (TSAT) constellations. Commercial satellite support will include both Ku and Ka-band systems.  The terminals will also provide high-capacity line-of-sight (LOS) communications utilizing Common Data Link (CDL) / Networked Common Data Link (N-CDL) links or future variations thereof.    

(U) Because the family of terminal systems will operate with many legacy waveforms currently used by military and civilian agencies and incorporate new waveforms as they are developed, the cryptographic components of the terminal system will need to be programmable and scaleable to meet specific user operational needs. The desire is that the cryptographic capability provides flexibility through an open system architecture that enables technology insertion (via re-programmability or other means). The terminal system will be capable of high data throughput rates per Radio Frequency (RF) channel; incremental RF channel expansion; high levels of reliability, availability, and maintainability; technological enhancement; and commercial support service compatibility. 

(U) The emphasis of the initial POET development will be to mitigate the risks to the terminal developments by establishing a flexible and scalable cryptographic capability for which the long lead time development and certification efforts are already complete. The emphasis is not to develop a particular “one size fits all” cryptographic product, but rather a capability that can be reused, scaled, and/or repackaged to satisfy the particular constraints of the different terminal developments. Achieving NSA certification of the POET Engineering Development Models (EDMs) is considered an important aspect of mitigating the risks to the terminal developments.

    1. (U) System Overview

(U) POET ACM flexibility is important due to the wide range of applications envisioned for these future terminals, which may differ significantly in their mission applications and their size weight and power (SWAP) requirements. In turn, the performance capabilities and the SWAP requirements to be imposed on the ACM may vary significantly. For example, a man-pack embedment would likely trade-off some multi-band/multi-channel capability and data rate capacity in return for a more stringent SWAP. In this case, an ACM might be required to support two RF channels at lower data rates. Fixed terminals will likely require the maximum functionality and capabilities and ACM embedments will be capable of utilizing the increased SWAP available. Therefore, flexibility, modularity, and scalability of design and architecture are necessary for the ACM.  

(U) It is also anticipated that the ACM will be used in terminals with different INFOSEC architectures. Some terminals are expected to implement a “RED core” terminal architecture while other terminals are expected to implement a “RED” terminal architecture. A RED core terminal is defined as a terminal that may internally process classified information as required by one or more waveforms, but for which all external interfaces are unclassified. External interfaces include baseband Input/Output (I/O) interfaces, locally connected operator interfaces, and RF interfaces. A RED core terminal is capable of unattended operation in the ground tactical environment. A RED terminal is defined as a terminal that may internally process classified information and may also support classified external interfaces. A RED terminal is not capable of unattended operation in the ground tactical environment. 

(U) A notional “RED core” terminal architecture with embedded ACM is depicted in Figure 1-1. A RED core terminal with an embedded ACM will:

  • (U) Support only BLACK baseband traffic interfaces. All “Red” user data will be encrypted prior to entering the terminal.
  • (U) Provide the requisite Transmission Security (TRANSEC) functionality for communications with RF frequencies above 2 GHz. 
  • (U) Provide the requisite Communications Security (COMSEC) functionality for communications with above 2 GHz systems.
  • (U) Incorporate an embedded Type 1 High Assurance Internet Protocol Encryptor (HAIPE) capability within the INFOSEC boundary of the terminal in order to support terminal remote control/management requirements.

 

Figure 1-1. (U) Notional RED Core Terminal Block Diagram

UNCLASSIFIED//FOUO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

UNCLASSIFIED//FOUO 

(U) A notional “RED” terminal architecture with embedded ACM is depicted in Figure 1-2. A RED terminal with an embedded ACM will:

  • (U) Support BLACK and/or RED baseband traffic interfaces. All “Red” user data will be encrypted within the terminal.
  • (U) Provide the requisite TRANSEC functionality for communications with RF frequencies above 2 GHz. 
  • (U) Provide the requisite COMSEC functionality for communications with above 2 GHz systems.
  • (U) Incorporate an embedded Type 1 HAIPE capability within the INFOSEC boundary of the terminal in order to support requirements for remote control/management of the terminal.

 

Figure 1-2. (U) Notional Red Terminal Block Diagram

UNCLASSIFIED//FOUO 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

UNCLASSIFIED//FOUO

    1. (U) Definition of Terms

 

(U) The following paragraphs provide definitions for terminology that is used in the remainder of this TRD. These terms are defined here to promote uniform understanding of the requirements for the ACM. 

(U) Encryption – The process of converting Plaintext into Ciphertext by means of a code or cryptographic system. 

(U) Decryption – The process of converting Ciphertext into Plaintext by means of a code or cryptographic system. 

(U) Plaintext – Unencrypted information. 

(U) Ciphertext – Encrypted information. 

(U) Cryptographic Algorithm – Well-defined procedure or sequence of rules or steps, or a series of mathematical equations used to describe cryptographic processes such as encryption/decryption, key generation, authentication, signatures, etc. 

(U) RED interface – An interface on which plaintext may enter or emerge from the ACM. 

(U) BLACK interface – An interface on which unclassified plaintext and/or ciphertext may enter or emerge from the ACM. 

(U) RED – Pertaining to plaintext. 

(U) BLACK – Pertaining to unclassified and/or ciphertext. 

(U) RED Core Terminal – A terminal that may internally process classified information as required by one or more waveforms/applications, but for which all external interfaces are unclassified. A RED Core terminal implies a terminal with the following attributes:

  • (U) No RED user data is exposed at any of the terminalÂ’s interfaces. All RED user data is externally converted to BLACK data prior to being presented to any terminal interface.
  • (U) No RED user data is displayed on the terminal itself.
  • (U) All keys and cryptographic algorithms are stored in BLACK form, except when needed for processing within an approved cryptographic boundary within the terminal and only if using an approved embedment with a certified cryptographic module to provide the required information assurances.
  • (U) When the terminal is placed into a specific non-operational mode, its classification sensitivity is unclassified CCI.
  • (U) When the terminal is operating, its classification sensitivity depends on the mission profile and operating mode of the terminal.

 

(U) RED Terminal – A terminal that may internally process classified information and may also support classified external interfaces. 

(U) COMSEC – Acronym for “Communications Secur