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

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:

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

Cryptome mirror: http://cryptome.org/poet-acm.zip (514KB) (After unzipping, opened with Wordpad; Winword wouldn't open.)

POET documents: http://cryptome.org/poet-docs.htm

See also related documents:

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

15 August 2006

Information invited on these algorithms cited in the document (send to: cryptome[at]earthlink.net):

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.

(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

      (U)  TABLE OF CONTENTS

Section           Page 
 

(U) List of Figures

Section           Page 

(U) List of Tables

Section           Page

2. (U) Introduction

1. 2. (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. 3. (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. 4. (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 Security”; generally includes security mechanisms that provide high assurance that information is protected while in transit or at rest. The process for COMSEC protection of information typically involves encryption of plaintext from the RED side of the cryptographic module to ciphertext on the BLACK side. Decryption of the ciphertext by intended recipients would be realized from BLACK side of a cryptographic module. The original plaintext would be presented on the RED side of the cryptographic module. 

(U) TRANSEC – Acronym for “Transmission Security”; generally includes measures to protect electronic emanations and RF transmissions. TRANSEC may provide anti-jam, Low Probability of Intercept (LPI), Low Probability of Detection (LPD), and Low Probability of Exploitation (LPE). 

(U) TRANSEC Key Stream – A pseudo-random bit stream used in conjunction with TRANSEC functions/processing. TRANSEC key streams are typically consumed within a modem/signal processing system in support of TRANSEC protected transmissions. 

(U) Cover – Application of a pseudo-random key stream to BLACK information. Cover is often used to prevent traffic-flow analysis by an adversary and/or to prevent other adversary attacks. Cover is sometimes referred to as “TRANSEC encryption”. 

(U) Decover – Application of a pseudo-random key stream to BLACK information. Decover removes the application of cover. Decover is sometimes referred to as “TRANSEC decryption”. 

(U) Bulk Encryption – Refers to the encryption function applied to a serial data stream. Bulk encryption may be a second encryption that is applied to data that is separately encrypted by another process. 

(U) Bulk Decryption – Refers to the decryption function that corresponds to a bulk encryption. 

(U) HAIPE Encrypt – A COMSEC function that is used for providing High Assurance Type 1 protection for internet protocol data between two endpoints. 

(U) HAIPE Decrypt – Refers to the decryption function that corresponds to HAIPE encryption. 

(U) Waveform COMSEC – Encryption/decryption functions that are required processing in support of a particular waveform. 

(U) Baseband COMSEC – Encryption/decryption of data that is received/transmitted at the ingress/egress of a host terminal interface to a user.

3. (U) Applicable Documents

1. 2. (U) Program-Specific Documents

Table 1. (U) Program-Specific Documents

UNCLASSIFIED//FOUO (TO BE SUPPLIED)

UNCLASSIFIED//FOUO

1. 3. (U) Government Documents

Table 2. (U) Government Documents

UNCLASSIFIED//FOUO(TO BE SUPPLIED)

UNCLASSIFIED//FOUO

1. 1. 2. (U) Specifications, Standards, or Handbooks

Table 3. (U) Specification, Standards, or Handbooks

UNCLASSIFIED//FOUO (TO BE SUPPLIED)

UNCLASSIFIED//FOUO

1. 4. (U) Other

1. 1. 2. (U) Standards

Table 4. (U) Standards

UNCLASSIFIED//FOUO (TO BE SUPPLIED)

UNCLASSIFIED//FOUO

4. (U) Technical Requirements

1. 2. (U) Notional Advanced-High-Speed-Embeddable Cryptographic Module (ACM)

(U) Figure 3-1 is a notional functional block diagram of the ACM, which will serve as the basis for the discussions and the requirements in this document. The ACM is an embeddable, reprogrammable cryptographic module which provides cryptographic services to its host (terminal or platform). 

(U) The ACM should be designed for reuse within a variety of host platforms having differing performance and SWAP requirements. The initial ACM design will provide the functionality and performance required for a core set of cryptographic services demanded by a broad range of host platforms.  The ACM architecture should allow for modular design and expansion capabilities to support candidate platforms and applications as they evolve. 
 
 
 
 

Figure 3-1. (U) Notional Advanced Cryptographic Module (ACM) 
 

UNCLASSIFIED//FOUO 

1. 1. 2. (U) ACM Capabilities

(U) The ACM provides the following major capabilities:

• A single cryptographic capability that supports:
  2. Simultaneous, high-speed key stream generation for independent waveforms

  3. COMSEC support concurrent with high-speed key stream generation

  4. COMSEC support for network management and remote control using HAIPE IS V3.x [TBD] or IPSEC as required

  5. Control/status bypass for terminal management

  6. High Assurance Guard for Ciphertext bypass

• Scalability Throughput and Power
• Multiple Single Security Levels
• Bulk Encryption for resource management and control information for some waveforms
• Programmable Algorithm & Cryptographic Modernization Initiative compliance
• Remote Management
• Unattended Operation
• Key Management
• Algorithm Interoperability
• SCA Security Supplement compliance
• Access Control with use of Token
• Anti-tamper and Zeroization
• Non Type 1 support

1. 3. Requirements Organization

(U) The ACM requirements are primarily categorized into the following areas: 

• Functional
• External Interfaces
• Processor Capacity
• Memory Capacity
• Internal Battery
• Power 
• Physical
• Environmental 
• Thermal
• Maintainability
• Reliability
• Interchangeability
• Workmanship
• Documentation
• Logistics

1. 4. (U) Functional

(U) The ACM functional requirements can be categorized based on following capabilities:

• General Capabilities
• Waveform Specific Capabilities
• Levels of Security and Classification
• Remote Management
• Unattended Operation
• Cryptographic Modernization Initiative
• SCA Security Compliance
• Cryptographic Services
• Cryptographic Control and Status
• Clock Management 
• Built-In Test and Health Status
• Alarm
• Tamper
• Interoperability

1. 1. 2. (U) Cryptographic Services

(U) The ACM is a set of hardware, software, and firmware that provides cryptographic services to a host terminal. The ACM will provide cryptographic services to the host via a well defined set of primitives/functions. Each primitive/function will provide an implementation of a cryptographic process such as encryption/decryption, key stream generation, authentication, etc. 

(U) The ACM must support TRANSEC key stream generation, cover/decover key stream generation, bulk encryption/decryption, waveform COMSEC encryption/decryption, baseband COMSEC encryption/decryption, bypass processing, and ancillary key management, key agreement, digital signature, and utility services that are provided for the host. These general cryptographic services provided by the ACM are discussed in more detail in the subsections that follow. 

(U) The different types of cryptographic services are presented separately so that it is clear what types of functionality the ACM must support. This does not imply that there must be some difference in implementation among the different cryptographic services. For example, the same algorithm and implementation could apply for bulk encryption/decryption and waveform COMSEC encryption/decryption. In general, it is desired for the cryptographic services provided by the ACM to be as flexible as possible in order to accommodate application in different types of terminals and evolvability within the terminals. 

(U) In the requirements that follow, some of the algorithms identified may be in the process of TBD, but are necessary for terminal level interoperability with existing systems. These algorithms will no longer be used within the ACM when there is no longer a requirement for interoperability with existing systems.

1. 1. 1. 2. Identification and Authentication (I&A)

(U) It is expected that the ACM ICD will identify management commands that require identified and authenticated entities to accomplish; however, the ACM will not store or manage identity or role information related to the entities authorized to execute those commands.  It is anticipated the ACM host will accomplish entity I&A and role validation.  Subsequently, if an entity requires access to ACM stored information to accomplish specific activities including adding or deleting ACM stored data, accessing audit information, effecting changes to ACM internal configuration then the host will verify I&A and assigned role then pass the validated request to the ACM over the command interface.  The ACM will act on the command IAW the applicable security policy.  At a minimum, the ACM acting on the management command shall generate an audit entry that includes entity identity, time, role, requested service, and summarization of request result. 

(U) The ACM shall support the following minimum roles, security administrator, system maintainer, and user. 

(U) Security administrator:  At a minimum and as allowed by security policy, the Security Administrator role shall be able to query ACM status, accomplish key management tasks such as request an inventory of stored keys, delete keys, or request keys be added to the key store using ACM key management primitives, command a load of updated algorithms to the protected store or delete stored algorithm images from the protected stored, or access all audit entries.  Note, it is recommended that the host establish high robustness, multifactor, I&A processes for the Security Administrator. 

(U) System Maintainer.  At a minimum and as allowed by security policy, the System Maintainer role shall be able to query the ACM for information related to ACM heath and performance including he results of the last full BIT, command the ACM to accomplish a BIT or specific performance tests the ACM may be designed to accomplish, or access health or performance audit records.  Note, it is recommended that the host establish high robustness I&A processes for the System Maintainer. 

(U) User:  Consistent with security policy, the user shall be able to request ACM status (is it up or down).  Note, ACM status requests may cause the ACM to accomplish performance testing; however, the user will only be provided summarized test results.

1. 1. 1. 3. Key Stream Generation

(U) The ACM must support key stream generation for both TRANSEC key streams and cover/decover key streams. These functions are required for some of the waveforms that must be supported by future terminals. In addition to these waveforms, additional waveforms could subsequently be specified at the terminal level that also require key stream generation. This could occur, for example, if a waveform is added to the list of waveforms that must be supported by a particular terminal or if a new type of terminal is defined that will be supported by POET. It is expected that the ACM implementation will provide flexibility to accommodate such changes, if necessary, as the terminal programs mature. 

(U) The ACM shall be able to operate with the following cryptographic TRANSEC and cover/decover algorithms:

1. AES Counter (CTR) mode

2. AES Galois Counter (GCM) mode

3. AES Electronic Code Book (ECB) mode

4. AES Cipher Block Chaining (CBC) mode

5. MEDLEY mode(s) in accordance with the classified supplement of this document

6. SHILLELAGH TBD mode

7. BATON TBD mode

8. KEESEE TBD mode

9. SAVILLE TBD mode

< Are these modes classified?  If so use the same statement as for MEDLEY>

1. 1. 1. 1. 2. TRANSEC Key Stream Generation

(U) The ACM must support TRANSEC key stream generation for the Milstar, AEHF, TSAT, and MIL-STD-188-EEE waveforms. The following requirements are applicable to TRANSEC key stream generation. A TRANSEC key stream may be a continuous stream of bits, a periodic sequence, or a waveform specific request/reply function between the host and the ACM. 

  (U) The ACM [CR0130] shall support TRANSEC key stream generation for AEHF as defined in Appendix A, Table A-1 (U) AEHF Algorithms and concurrent with the other cryptographic services identified as simultaneous.

Note: The requirements for TRANSEC key stream generation for the AEHF system are a superset of the requirements for TRANSEC key stream generation for the Milstar system. 

(U) The ACM shall support TRANSEC key stream generation for TSAT as defined in Appendix A, Table A-5 (U) TSAT Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall support cover/decover key stream generation for MIL-188-EEE as defined in Appendix A, Table A-3 (U) MIL-188-EEE Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall provide the capability to output TRANSEC key streams to either a BLACK side ACM interface or a RED side ACM interface based on the ACM security policy.

Note: This provides flexibility to the host. Existing hosts process TRANSEC key streams on the BLACK side, but some hosts may process TRANSEC key streams on the RED side. 

(U) The ACM shall be capable of simultaneously providing TRANSEC key stream and cover/decover key stream generation functions for up to four independent configurable waveforms having a maximum aggregate rate of (2 Gbps, threshold; 10 Gbps, objective).

<Recommend replacing this with a requirement that captures the worst case simultaneous waveforms based on the processing requirements rolled up in appendix A> 

(U) The ACM shall provide at least eight (8) independent TRANSEC Key Stream cryptographic channels for up to four waveforms.

<Recommend replacing this with a requirement that captures the worst case simultaneous waveforms based on the processing requirements rolled up in appendix A> 

(U) When applicable (e.g., some algorithms require TOD for crypto sync), the ACM shall use time-of-day (TOD) functions for key stream generation. 

(U) When applicable, the ACM shall synchronize clock for key stream generation. 

(U) The ACM shall define primitives required to facilitate the high speed TRANSEC functions required for the terminal waveforms.

1. 1. 1. 1. 3. Cover/Decover Key Stream Generation

(U) The ACM must support cover/decover key stream generation for the Milstar, AEHF, TSAT, and MIL-STD-188-EEE waveforms. The following requirements are applicable to cover/decover key stream generation. A cover/decover key stream may be a continuous stream of bits, a periodic sequence, or a waveform specific request/reply function between the host and the ACM. 

(U) The ACM shall support cover/decover key stream generation for AEHF as defined in Appendix A, Table A-1 (U) AEHF Algorithms and concurrent with the other cryptographic services identified as simultaneous.

Note: The requirements for cover/decover key stream generation for the AEHF system are a superset of the requirements for TRANSEC key stream generation for the Milstar system. 

(U) The ACM shall support cover/decover key stream generation for TSAT as defined in Appendix A, Table A-5 (U) TSAT Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall support cover/decover key stream generation for MIL-188-EEE as defined in Appendix A, Table A-3 (U) MIL-188-EEE Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall provide the capability to output cover/decover key streams to either a BLACK side ACM interface or a RED side ACM interface based on the ACM security policy.

Note: This provides flexibility to the host. Existing hosts process cover/decover key streams on the BLACK side, but some hosts may process cover/decover key streams on the RED side. 

(U) The ACM shall provide at least four independent cover/decover key stream generation cryptographic channels for up to four waveforms.

<Recommend replacing this with a requirement that captures the worst case simultaneous waveforms based on the processing requirements rolled up in appendix A> 

(U) The ACM shall be capable of supporting multiple cover/decover key stream generation functions with different cryptographic algorithms and keys over the same TRANSEC Key stream generation cryptographic channel in accordance with the security policy. 

(U) When applicable, the ACM shall use time-of-day (TOD) functions for TRANSEC key stream generation. 

(U) When applicable, the ACM shall synchronize clock for TRANSEC key stream generation.

1. 1. 1. 4. Bulk Encryption/Decryption

(U) The “Bulk Encrypt/Decrypt” function provides a COMSEC function which is necessary when plaintext control data is multiplexed with ciphertext data. The ACM must support bulk encryption/decryption operations for the CDL and MIL-188-165 waveforms and may also be required for operation over commercial SATCOM systems. In addition to these requirements, additional waveforms could subsequently be specified at the terminal level that also require bulk encryption/decryption. 

(U) The ACM shall support bulk encryption/decryption for MIL-188-165 as defined in Appendix A, Table A-2 (U) MIL-188-165 Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall perform legacy CDL encryption/decryption for all CDL control information along with the user data. 

(U) The ACM shall support bulk encryption/decryption for CDL as defined in Appendix A, Table A-4 (U) CDL Algorithms and concurrent with the other cryptographic services identified as simultaneous.

1. 1. 1. 5. Waveform COMSEC Encryption/Decryption

(U) The ACM must support the COMSEC encryption/decryption processing that is required by the AEHF, TSAT, MIL-188-165, and MIL-188-165 waveforms. In addition to these waveforms, additional waveforms could subsequently be specified at the terminal level that also require COMSEC encryption/decryption functions. It is expected that the waveform COMSEC encryption/decryption requirements specified here will provide ample flexibility for such changes, if necessary, as the terminal programs mature. 

(U) The ACM shall support waveform COMSEC encryption/decryption using the following Suite A algorithms: MEDLEY, SHILLELAGH, BATON. 

(U) The ACM shall support waveform COMSEC encryption/decryption using the following Suite B algorithms: AES. 

(U) The ACM shall support waveform COMSEC encryption/decryption for AEHF as defined in Appendix A, Table A-1 (U) AEHF Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall support waveform COMSEC encryption/decryption for TSAT as defined in Appendix A, Table A-5 (U) TSAT Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall support waveform COMSEC encryption/decryption for MIL-188-165 as defined in Appendix A, Table A-2 (U) MIL-188-165 Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall support waveform COMSEC encryption/decryption for MIL-188-EEE as defined in Appendix A, Table A-3 (U) MIL-188-EEE Algorithms and concurrent with the other cryptographic services identified as simultaneous. 

(U) The ACM shall provide the capability to receive waveform message to be encrypted from either a BLACK side ACM interface or a RED side ACM interface based on the ACM security policy.

Note: This provides flexibility to the host. For example, waveform processing functions and information may be within the BLACK side host.

1. 1. 1. 6. Baseband COMSEC Encryption/Decryption

(U) The ACM must support the COMSEC processing that is required for terminals that support encryption/decryption of end user data that is received on a baseband interface. These requirements are not specified as simultaneous with the waveform processing requirements outlined in the previous sections because there may be a functional separation at the terminal level between waveform cryptographic processing and cryptographic processing for end user data. For example, physically separate instances of the ACM could be used within different components of the terminal (e.g., signal processing system module versus baseband I/O module). It may also be necessary to use physically separate instances of the ACM in order to avoid multiple levels of processing for waveforms and end user information at the terminal level. Even though the following baseband COMSEC encryption/decryption requirements are not specified as simultaneous with the waveform processing requirements, it is still desirable for the ACM to provide the maximum capability. An affordable and certifiable implementation that supports simultaneous baseband COMSEC encryption/decryption and waveform cryptographic processing is preferable as long as the existing threshold requirements are met. 

(U) The ACM shall support baseband COMSEC encryption/decryption using the following Suite A algorithms: MEDLEY (TBD), SHILLELAGH (TBD), BATON (TBD), SAVILLE (TBD), WALBURN (TBD). 

(U) The ACM shall support baseband COMSEC encryption/decryption as defined in Appendix A, Table A-10 (U) Baseband COMSEC.

1. 1. 1. 7. HAIPE Encryption/Decryption

(U) The terminals will utilize HAIPIS compliant encryption/decryption for control, monitoring, and management of RED side terminal functionality from a remote management site. The threshold requirements that follow are specified based on the encryption/decryption rate that must be supported for control, monitoring, and management. It is expected that this threshold provides ample margin for control type traffic for different terminal types. It is desirable that a much higher data rate be supported for HAIPIS compliant encryption/decryption of baseband traffic because this makes the ACM more generally capable and useful for different terminal/military applications. The objective requirements that follow capture the desired data rate for HAIPIS compliant encryption/decryption as a COMSEC baseband function. It is important to note that the objective requirements are not specified as simultaneous with the threshold waveform processing requirements. 

The ACM shall provide HAIPE cryptographic services compliant with the core and extension HAIPE IS Version 3.x [TBD] requirements.

Note: The requirements traceability matrix provided in Appendix B indicates the allocation of requirements between the ACM and the host. 

(U) The ACM shall support HAIPE IS v3.x compliant encryption/decryption as defined in Appendix A, Table A-6 (U) HAIPE Algorithms. 

(U) The ACM shall support HAIPE IS v3.x compliant encryption/decryption as defined in Appendix A, Table A-6 (U) HAIPE Algorithms for as many as 4 simultaneous interfaces between the host and remote management workstations. 

(U) The ACM should support HAIPE IS v3.x compliant encryption/decryption for the objective data rates defined in Appendix A, Table A-6 (U) HAIPE Algorithms. 

(U) The ACM shall provide HAIPE IS V3.x encryption/decryption for IPv4.

Note: This may be unnecessary if IPv4 is no longer required to be supported during the time period that the terminals will be fielded. 

(U) The ACM shall provide HAIPE IS V3.x encryption/decryption for IPv6. 

(U) The ACM should support bulk encryption/decryption for CDL as defined in Appendix A, Table A-4 (U) CDL Algorithms and concurrent with the other cryptographic services identified as simultaneous simultaneously with HAIPE IS v3.x compliant encryption/decryption for the objective data rates defined in Appendix A, Table A-6 (U) HAIPE Algorithms.

Note: This would allow a terminal that must simultaneously perform CDL bulk encryption/decryption and end-to-end packet encryption/decryption using the same ACM. 

(U) The ACM shall provide HAIPE cryptographic services compliant with the High Assurance Internet Protocol Encryptor Interoperability Specification Guide, Traffic Protection – Suite A Cryptography, Version 3.0.1, 30 September 2005. 

(U) The ACM shall provide HAIPE cryptographic services compliant with the High Assurance Internet Protocol Encryptor Interoperability Specification Guide, Traffic Protection – Suite B Cryptography, Version 3.0.1, 30 September 2005. 

(U) The ACM shall provide HAIPE cryptographic services compliant with the High Assurance Internet Protocol Encryptor Interoperability Specification Guide, Traffic Protection – Legacy Cryptography, Version 3.0.1, 30 September 2005.

Note: The legacy crypto extension specification will be removed in HAIPIS version 4.0.0. This requirement may be contingent on the required interoperability at the time that the ACM will be used. 

(U) The ACM shall provide the maximum throughput for each of HAIPE encryption algorithm per cryptographic channel as identified in APPENDIX A, Table A-6 (U) HAIPE Algorithms. 

(U) The ACM shall support the Cryptographic Suite B for HAIPE IS V3.x [TBD] Suite B extension.

1. 1. 1. 8. Non Type 1 Services

(U) Terminals will support both Type 1 and non Type 1 cryptographic processing. For example, TSAT terminals will communicate with the TSAT network management system using a medium robustness confidentiality mechanism. TSAT terminals will utilize Medium Assurance DoD PKI device certificates to perform key agreement and negotiate shared session keys with the TSAT network management system. TSAT terminals will also use medium robustness confidentiality mechanisms to secure the network control plane connection to a TSAT payload. Additionally, terminals are expected to utilize DoD PKI certificates for identification and authentication of their own operators and administrators. 

A particular terminal integration could choose to implement the required medium robustness confidentiality mechanisms using a separate cryptographic product. There are several advantages, however, to using the ACM to support both Type 1 and non Type 1 cryptographic processing. These advantages are include: common and very secure storage for private keys; no need to build/buy and NIAP certify an additional product; and existing algorithm overlap between Suite B and NIAP  

The following requirements describe the capabilities the ACM must provide to support interoperability with the DoD PKI system and non type 1 cryptographic processing using DoD PKI certificates or other non Type 1 key material. In some cases, an algorithm listed as a non Type 1 algorithm may be the same algorithm as a Suite B algorithm. A single ACM implementation of such algorithms may be possible, but differences in key management are expected.

1. 1. 1. 1. 2. Key Pair Management

(U) A public/private key pair shall be generated within the ACM and the public keys output to the DOD PKI for publication. Additionally, the ACM must accept and manage X.509v3 certificates and their corresponding keys over the instruction interface to the host in support of DOD PKI interoperable confidentiality, integrity, and authentication services. The following are requirements for DoD PKI key pair management functions that the ACM must support. 

(U) The ACM shall generate Public/Private key pairs when commanded by the red or black side Cryptographic Control Interface. 

(U) After generation of a public/private key pair, the ACM shall retain the Private key and wrap it for storage within the cryptographic boundary. 

(U) After generation of a public/private key pair, the ACM shall export the Public key over the Cryptographic Control Interface. 

(U) The ACM shall support the loading of DoD PKI Certificates and their corresponding public keys over the Cryptographic Control Interface. 

(U) The ACM shall implement processes necessary to validate offered certificates.

Note.  Validation may range from offering the credential particulars, e.g., serial number, valid from / to dates, etc., to an external, terminal resident process that proxies the validation to incorporating an OCSP or other lightweight validation protocol client and/or a full certificate validation process capable of downloading and scanning a CRL.  At a minimum, validation will include verifying offered certificate root is valid and known and verifying certificate has reached its valid-from date and not exceeded its valid-to date.  The desired maximum is verifying root, date, and certificate revocation status.

1. 1. 1. 1. 3. Non Type 1 IPSec

(U) TSAT terminals will use non Type 1 Internet Protocol Security (IPSec) to communicate with the TSAT network management system and to secure the network control plane connection to a TSAT payload and possible future network management systems. IPSec will provide security services including access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality, and limited traffic flow confidentiality. 

(U) The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The IPSec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. Terminals will use the Encapsulating Security Payload (ESP) and may use the Authentication Header (AH) to protect data being sent over an IPSec Security Association (SA). IKE provides a mechanism to negotiate which algorithms should be used in any given association, and two IPSec systems cannot interoperate unless they share common algorithms. The ACM therefore needs to support the current set of mandatory IPSec algorithms as well as algorithms that may be promoted to mandatory in the future. 

(U) From the perspective of encryption/decryption algorithms, the algorithm that is used to support non Type 1 IPSec may be identical to a Type 1 Suite B algorithm. A single ACM implementation of such algorithms may be possible, but differences in key management must be addressed. The following requirements relevant to non Type 1 encryption/decryption may be redundant with other requirements in this TRD for Type 1 services, but are repeated here as non Type 1 requirements so that the context and intended applications are clear. 

(U) The ACM shall support TripleDES-CBC in accordance with RFC 2451 for use with non Type 1 IPSec. 

(U) The ACM should support AES-CBC in accordance with RFC 3602 for use with non Type 1 IPSec.

Note: All AES key sizes should be supported. 

(U) The ACM should support AES-CTR in accordance with RFC 3686 for use with non Type 1 IPSec.

Note: All AES key sizes should be supported. 

(U) The ACM should support AES-GCM in accordance with TBD for use with non Type 1 IPSec.

Note: All AES key sizes should be supported. 

(U) The ACM should support AES-XCBC-MAC-96 in accordance with RFC 3566 for use with non Type 1 IPSec.

Note: All AES key sizes should be supported. 

(U) The ACM shall support HMAC-SHA1-96 in accordance with RFC 3566 for use with non Type 1 IPSec. 

(U) The ACM shall support IPSec compliant encryption/decryption as defined in Appendix A, Table A-7 (U) IPSec Algorithms.

1. 1. 1. 1. 4. Other Encryption/Decryption

Support for IPSec is one application of non Type 1 encryption/decryption that is known to be required for TSAT terminals. The following are additional encryption/decryption capabilities that are specified in order for the ACM to provide a more generally useful non Type 1 cryptographic capability. These functions are objectives and are believed to not significantly increase the complexity of the ACM, but would provide capabilities for additional waveforms/applications within the terminal. 

(U) The ACM should support Rivest, Shamir, and Adelman (RSA) compliant encryption/decryption in accordance with TBD.

1. 1. 1. 1. 5. Authentication Processing

(U) The ACM shall provide generation of a cryptographic signature for the RSA with signatures method of authentication. 

(U) The ACM shall provide cryptographic signature verification for the RSA with signatures method of authentication. 

(U) The ACM shall allow for configuration of shared secret authentication, in lieu of RSA with signatures method of authentication.

1. 1. 1. 9. Integrity Services

The ACM must support algorithms to verify the integrity of ACM software/firmware loads, signed ACM security policies, and terminal software/firmware loads. Integrity services are also required for HAIPE and IPSec interoperability. The following requirements summarize the integrity functions that the ACM must support. 

(U) The ACM shall support the hash algorithms defined in Federal Information Processing Standards Publication 180-2, “Secure Hash Standard (SHS)”, 1 August 2002. 

(U) The ACM shall support the HMAC SHA1 96 integrity algorithm in accordance with RFC 2404. 

(U) The ACM shall support the AES PRF 128 integrity algorithm in accordance with TBD. 

(U) The ACM shall return results of integrity processing to the host.

1. 1. 1. 10. Digital Signature Services

The ACM must provide digital signature services, including generation and validation, to the host for both Type 1 and non Type 1 digital signature algorithms. The following requirements summarize the digital signature functions that the ACM must support. 

(U) The ACM shall support the digital signature algorithms defined in Document: Federal Information Processing Standards Publication 186-3, “Digital Signature Standard”, 27 January 2000, Change Notices (October 2001). 

(U) The ACM shall support the digital signature algorithms defined in ANSI X9.31. 

(U) The ACM shall support the digital signature algorithms defined in ANSI X9.62. 

(U) The ACM shall support digital signature verification for ACM software/firmware in accordance with “Standard for Signing and Obtaining a Hashword for a Software Package to Support INFOSEC Applications (for Signature Verification Only)”, KM-TG-0002-96 Rev 9, April 1997. 

(U) The ACM shall return results of cryptographic authentication processing to the host.

1. 1. 1. 11. Host Utility Services

(U) The ACM will be a trusted (high assurance) component within a terminal and may be the only high assurance component within a terminal. The ACM is expected to provide cryptographic utility services for ensuring that other entities within the terminal are running valid software/firmware. The following are the requirements applicable to utility services provided by the ACM to the host. An underlying assumption is that terminal software/firmware is downloaded as a package that is encrypted and signed by a designated authority.  

(U) The ACM shall provide the capability to encrypt terminal software for data at rest storage using Suite A. 

(U) The ACM shall provide the capability to encrypt terminal software for data at rest storage using Suite B. 

(U) The ACM shall encrypt a TBD MB terminal software file within TBD seconds. 

(U) The ACM shall provide the capability to decrypt and integrity check terminal software taken from data at rest using Suite A. 

(U) The ACM shall provide the capability to decrypt and integrity check terminal software taken from data at rest using Suite B. 

(U) The ACM shall decrypt and integrity check a TBD MB terminal software file within TBD seconds. 

(U) The ACM shall provide the capability to decrypt and integrity check terminal software updates loaded during “on air” terminal operation. 

(U) The ACM shall provide file encryption/decryption service using a unique File Encryption Key (FEK) for non cryptographic software/firmware images.

<Encryption/decryption already covered; do we need separate requirements for file system encryption versus file encryption? Is there a difference?>

1. 1. 1. 12. Other Services

Requirements for other cryptographic services provided by the ACM are included below. 

(U) When configured for Suite A operation, the ACM shall provide the capability to decrypt Type 1 cryptographic algorithms using the JOSEKI-1 algorithm. 

(U) When configured for Suite B operation, the ACM shall provide the capability to decrypt Type 1 cryptographic algorithms using the TBD algorithm.

1. 1. 3. Key Management

The ACM must support key management functionality for both Type 1 (Suite A and Suite B) and non Type 1 cryptographic algorithms. ACM key management requirements are complicated by several factors. 

First, the future Key Management Infrastructure (KMI) will replace the existing Electronic Key Management System (EKMS) sometime during the ACM development or the follow on terminal development and integration efforts. The ACM must therefore include the functionality that is required to be a “KMI enabled” cryptographic product. The KMI is an evolutionary system that will field as capabilities in phased increments, and the KMI delivery schedules are likely to be fluid. For these reasons, it is expected that the ACM will need to support key fill from both the EKMS and KMI systems. There may also be terminal level reasons for this (e.g., a terminal waveform that can receive key material only from EKMS). 

Second, the current goal is to develop the ACM as a fully releasable cryptographic product that can be integrated, if necessary, into a foreign partner or Homeland Defense (HLD) terminal system. It is expected that the ACM will be able to be configured as either a fully releasable cryptographic product (i.e., only Suite B) or as a non releasable cryptographic product (i.e., inclusion of Suite A). This implies that the ACM must support both the Suite A and Suite B key management operations. 

Third, the goal of supporting both Type 1 and non Type 1 cryptographic services in the ACM further complicates key management. Different processes will be used to deliver Type 1 key material to the ACM compared to non Type 1 key material. The ACM must therefore support non Type 1 key management mechanisms in addition to what is required for Suite A and Suite B. 

Key management functions include key agreement and key exchange, key update, key fill, key identification, key accounting, key storage and retention, and zeroization. In some cases, particular key management requirements are specified by the HAIPIS and LEF cryptographic family specifications. Key management requirements are specified in the sections that follow.

1. 1. 1. 2. Key Agreement and Key Exchange

The ACM must support key agreement and key exchange functionality for both Type 1 (Suite A and Suite B) and non Type 1 cryptographic algorithms.

1. 1. 1. 1. 2. Type 1

The ACM must support the following key agreement and key exchange requirements for Type 1 key material. 

(U) The ACM shall support the FIREFLY exchange in accordance with EKMS 322B in order to generate Suite A encryption keys (either for traffic or key encryption). 

(U) The ACM shall perform Enhanced FIREFLY key calculation in accordance with EKMS 322 and the classified appendix to the LEF IS. 

(U) The ACM shall support the Menezes-Qu-Vanstone (MQV) exchange in order to generate Suite B encryption keys.

1. 1. 1. 1. 3. Non Type 1

The ACM must support the following key agreement and key exchange requirements for Non Type 1 key material. 

(U) The ACM shall support the calculation of shared secret keys using Diffie-Hellman MOD Group 2 in accordance with TBD. 

(U) The ACM shall support the calculation of shared secret keys using Diffie-Hellman MOD Group 14 in accordance with TBD. 

(U) The ACM shall support the calculation of shared secret keys using Diffie-Hellman Elliptic Curves in accordance with TBD.

1. 1. 1. 3. Key Fill

(U) ACM key material can be filled either directly over a fill port interface to the ACM or from the host-to-ACM instruction interface. The ACM must support both RED fill and benign/BLACK fill of key material. Key material received in this manner can include a seed, operational, or one-time-use FIREFLY vector set or traditional key material. Delivery may be in RED form, BLACK form (using a pre-placed key encryption key), or utilizing benign techniques. The following requirements apply to kill fill in general. Subsequent sections capture the requirements specific to RED key fill and benign/BLACK key fill. 

(U) The ACM shall provide a DS-101 key fill interface to support key fill.

Note: The ACM key fill interface may or may not be extended to the platformÂ’s exterior for a particular terminal/platform integration. 

(U) The ACM shall support the DS-101 protocol for key fill in accordance with EKMS 308. 

(U) The ACM shall provide positive confirmation following each successful key fill.

<Positive confirmation to whom?> 

(U) The ACM shall provide indication in the event of key fill failure.

<Indication to whom?> 

(U) The ACM shall provide the capability to accept key and control/status information from the DS-101 fill interface. 

(U) The ACM shall provide the capability to send control/status information to the DS-101 fill interface. 

(U) The ACM shall support accepting key loads in accordance with EKMS 308.

1. 1. 1. 1. 2. RED Fill

The ACM must support RED fill of key material. Even if RED key fill is not required for operational systems (e.g., AEHF), the ACM must support RED fill for terminal development, testing, and integration efforts. Without this capability, a full key management system must be present at the terminal developerÂ’s facility in order to load key material into the ACM (including test key material). The intent is to avoid this. 

(U) The ACM shall accept RED key fill using the DS-101 protocol.

Note: It is assumed the RED key fill is only via the DS-101 interface and is not applicable to the host-to-ACM instruction interface. 

(U) The ACM shall support the capability to disable support for RED key fill through software configuration. 

(U) The ACM shall accept RED fill of keys with DS-100-1 key tag information in accordance with EKMS 308. 

(U) The ACM shall accept RED fill of keys without DS-100-1 key tag information.

(U) The ACM shall support the loading of DoD PKI Certificates over the host instruction interface. 

(U) The ACM should support the loading of DoD PKI Certificates over the DS-101 key fill interface. 

(U) The ACM shall support RED fill of non Type 1 keys over the host instruction interface.

<Symmetric keys? Asymmetric keys? In accordance with what standard?> 

(U) The ACM should support RED fill of non Type 1 keys over the DS-101 key fill interface.

<Symmetric keys? Asymmetric keys? In accordance with what standard?> 

(U) The ACM shall cryptographically validate the integrity of the data of RED messages. 

(U) The ACM shall cryptographically validate the integrity of RED key material.

1. 1. 1. 1. 3. Benign Fill

(U) The ACM must support benign fill of key material in support of the AEHF, TSAT, and TBD waveforms. Benign fill may also be applicable to the keys for other waveforms and/or for HAIPE or baseband COMSEC functions. It is also expected that the KMI system will send key material to the ACM using some form of benign fill. 

(U) All the keys filled to an operational terminal in the field are expected to be in benign or BLACK form. However, to support benign/BLACK key fill, some unencrypted key material (trust anchors certificates, KEK, FF or EFF seed key material, etc.) must first be loaded. It is expected that such unencrypted key material will be loaded in a trusted facility. Subsequent to initialization, key material within the ACM may be protected using a CIK/CRK like mechanism. 

(U) The ACM shall accept benign key fill using the DS-101 protocol. 

(U) The ACM shall accept benign fill of keys without DS-100-1 key tag information.

Note: Some AEHF keys are benign filled that do not have a DS-100-1 tag. 

(U) The ACM shall accept BLACK fill of keys without DS-100-1 key tag information.

Note: AEHF BLACK keys are not filled with a DS-100-1 tag. 

(U) The ACM shall accept benign fill messages from the host instruction interface. 

(U) The ACM shall support benign fill capability (in accordance with, EKMS 217, EKMS 308, EKMS 317 and EKMS 322).  

(U) The ACM shall support benign fill capability in accordance with EKMS 217, EKMS 308, EKMS 317, and EKMS 322. 

(U) The ACM shall support EKMS Benign Techniques in accordance with EKMS 217. 

(U) The ACM shall generate keys via Firefly processing for Benign Fill. 

(U) The ACM shall accept FIREFLY vector sets formatted in accordance with EKMS 322. 

(U) The ACM shall accept Enhanced FIREFLY vector sets formatted in accordance with EKMS 322. 

(U) The ACM should accept MAYFLY key material in accordance with TBD.

Note: Support for MAYFLY is expected in order for the ACM to be KMI compatible. 

(U) The ACM should support benign fill of key material via MAYFLY processing.

Note: Support for MAYFLY is expected in order for the ACM to be KMI compatible. 

(U) The ACM shall accept keys in both EKMS 317 generic fill format and DS-100-1 tagged key data formats. 

(U) For AEHF, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A benign fill. 

(U) For AEHF, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A benign fill during “on air” terminal operation. 

(U) For TSAT, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A benign fill or Suite B benign fill. 

(U) For TSAT, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A benign fill or Suite B benign fill during “on air” terminal operation. 

(U) For CDL, the ACM shall provide the capability to handle, manage and store keys up to TOP SECRET/SECRET COMPARTMENTED INFORMATION (TS/SCI) using Suite A benign fill. 

(U) For CDL, the ACM shall provide the capability to handle, manage and store keys up to TOP SECRET/SECRET COMPARTMENTED INFORMATION (TS/SCI) using Suite A benign fill during “on air” terminal operation.

1. 1. 1. 1. 4. BLACK Fill

The ACM must support BLACK fill of key material in support of the AEHF and TBD waveform. BLACK fill may also be applicable to the keys for other waveforms. BLACK fill is distinguished from benign fill because BLACK fill implies that a key is encrypted by another existing key and benign fill implies that a key is encrypted by a key that was negotiated via a benign key agreement algorithm. 

(U) All the keys filled to an operational terminal in the field are expected to be in benign or BLACK form. However, to support benign/BLACK key fill, some unencrypted key material (trust anchors certificates, KEK, FF or EFF seed key material, etc.) must first be loaded. It is expected that the user will accomplish RED key fill at a trusted facility. Subsequent to initialization, key material within the ACM may be protected using a CIK/CRK like mechanism.

(U) The ACM shall accept BLACK key fill using the DS-101 protocol. 

(U) The ACM shall accept BLACK fill of keys with DS-100-1 key tag information in accordance with EKMS 308. 

(U) The ACM shall accept BLACK fill of keys without DS-100-1 key tag information.

Note: AEHF BLACK keys are not filled with a DS-100-1 tag. 

(U) The ACM shall accept BLACK keys from the host instruction interface. 

(U) The ACM shall support the use of host selectable Key Encryption Keys (KEK) to support Black key fill. 

(U) The ACM should automatically determine the correct KEK to use during a BLACK key fill. 

(U) The ACM shall support BLACK key fill operations in accordance with EKMS 217 (EKMS Benign Techniques Specification). 

(U) For AEHF, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A BLACK fill. 

(U) For AEHF, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A BLACK fill during “on air” terminal operation. 

(U) For TSAT, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A BLACK fill or Suite B BLACK fill. 

(U) For TSAT, the ACM shall provide the capability to accept, decrypt, and store keys up to SECRET using Suite A BLACK fill or Suite B BLACK fill during “on air” terminal operation. 

(U) For CDL, the ACM shall provide the capability to handle, manage and store keys up to TOP SECRET/SECRET COMPARTMENTED INFORMATION (TS/SCI) using Suite A BLACK fill. 

(U) For CDL, the ACM shall provide the capability to handle, manage and store keys up to TOP SECRET/SECRET COMPARTMENTED INFORMATION (TS/SCI) using Suite A BLACK fill during “on air” terminal operation. 

(U) The ACM shall provide the capability to accept, process, and store unencrypted Suite A key material on a fill port interface to support crypto initialization. 

(U) The ACM shall provide the capability to accept, process, and store unencrypted Suite B key material on a fill port interface to support crypto initialization. 

(U) The ACM shall cryptographically validate the integrity of the data of BLACK messages. 

(U) The ACM shall cryptographically validate the integrity of BLACK key material. 

(U) The ACM shall accept BLACK key material encrypted in ACCORDION version 3.0 in accordance with TBD. 

(U) For AEHF, the ACM shall accept BLACK key material encrypted in ACCORDION version 1.3 in accordance with TBD.

1. 1. 1. 4. Key Identification

The ACM must be able to identify keys and must be able to process information such as key classification from the key tag for a key. The ACM must also be able to provide key tagging information to the host. Also, in order to provide flexibility and the capability of supporting different waveforms with different key tagging standards, the ACM should provide the capability for the host to append key tagging information to a key. 

(U) The ACM shall provide an interface through which information (e.g., update count, key tag, description) about one or more keys may be requested and provided. 

(U) The ACM shall identify keys using the DS-100-1 key tag standard in accordance with EKMS 308. 

(U) The ACM shall identify keys using the AEHF key tag format in accordance with the AEHF key tag specification. 

(U) The ACM shall be capable of binding key tagging and ID information to a key. 

(U) The ACM should provide the capability for the host to append information to the DS-100-1 key tagging information. 

(U) The ACM should provide the capability to incorporate key tag format changes that may be defined by updates to EKMS 308 or other TBD specifications. 

(U) The ACM shall provide capability to output key tagging and ID information to the host.

1. 1. 1. 5. Key Allocation and Usage

The ACM must enforce some security policies for keys based upon the identification information that is bound to the key. 

(U) The ACM shall instantiate the use of keys according to their tag or ID information. 

(U) The ACM shall enforce the security policy that specifies the classification level of each channel based on the classification of the RED Interface of the cryptographic channel. 

(U) The ACM shall ensure that keys are instantiated for a specific application. For the purposes of this requirement, a “specific application” of a key is:

1. Using the specified classification key

2. Using the specified key type (e.g., TEK, KEK, TSK, etc)

3. Using a key with the specified algorithm (e.g., a KEESEE key with a KEESEE algorithm)

4. Using the key for the specified compartment (e.g., US, NATO, Allied)

5. Using key with a specified waveform

6. Using key with specified instance of the waveform

<Recommend splitting these out to individual requirements  MOVE TO POLICY SECTION> 

(U) The ACM shall test the keys for integrity at instantiation.

1. 1. 1. 6. Key Accounting and Audit

In general, the ACM is not required to maintain accountability and audit records for key material as it is loaded, utilized, and destroyed (TBD). The following requirements do apply. 

(U) The ACM shall maintain the identification of cryptographic key holdings correlated with waveform, algorithm, and key data. 

(U) The ACM shall maintain the identification of keys currently loaded.

1. 1. 1. 7. Key Storage

The following requirements apply to storage of key material within the ACM. 

(U) The ACM shall provide a minimum storage capacity of TBD MB of working memory for key material including the information that is bound to the key (i.e. key tag, effective date, etc).

Note: Key material includes TEKs, KEKs, TSKs, FEKs, FIREFLY Vectors and associated information, public/private key pairs, and key splits. 

(U) The ACM shall store persistent keys in BLACK form. 

(U) The ACM shall provide a minimum storage capacity of TBD MB of persistent storage for key material including the information that is bound to the key (i.e. key tag, effective date, etc).

Note: Key material includes TEKs, KEKs, TSKs, FEKs, FIREFLY Vectors and associated information, public/private key pairs, and key splits. 

(U) The ACM shall bind keys to their respective identification information in storage. 

(U) When configured for Suite A operation, the ACM shall encrypt keying material for storage using ACCORDION. 

(U) When configured for Suite B operation, the ACM shall encrypt keying material for storage using AES Key Wrap. 

(U) The ACM shall encrypt updated keys for storage. 

(U) The ACM shall provide the capability to store DoD PKI private keys. 

(U) The ACM shall protect keys stored within ACM.

1. 1. 1. 8. Key Update

The ACM must support key update functions for certain algorithms. The following requirements apply to ACM key update functions. 

(U) The ACM shall perform deterministic update of a TEK used to protect MEDLEY encrypted traffic using ACCORDION 3.0 in accordance with R21-TECH-03-02, “NSA MEDLEY Implementation Standard: An ACCORDION MEDLEY”, 7 Feb 2002. 

(U) The ACM shall perform deterministic update of a TEK used to protect BATON encrypted traffic using ACCORDION 1.3 in accordance with KM-TG-0001-87, “ACCORDION 1.3”, 30 Oct 1987. 

(U) The ACM shall perform deterministic update of a TEK using ACCORDION 3.0. 

(U) The ACM shall perform deterministic update of a Suite B TEK using the algorithm specified in R21-TECH-02-05, “R21 Information Technical Report dated 10 January 2005: A Key Update Function Based on the AES Key Wrap”, 10 Jan 2005. 

(U) The ACM shall provide a key update function, as applicable, for each supported cryptographic algorithm. 

(U) When configured for Suite A operation, the ACM shall provide a key update using ACCORDION for US only missions.

1. 1. 1. 9. Key Rollover

Support for HAIPE requires the ACM to provide the capability to do a rollover from one key variable to another. The following requirements apply to ACM key rollover functions. 

(U) The ACM shall provide a function for the host to command a rollover from one key to another. 

(U) The ACM shall support a rollover command from the host. 

(U) The ACM shall support rollover as specified by the performance documents of the waveform being supported.

1. 1. 1. 10. Key Zeroization

The ACM must support different types of key zeroization. Zeroization requirements are discussed in the sections that follow.

1. 1. 1. 1. 2. Selective zeroization

Selective zeroization is a process through which the host can selectively zeroize one or more keys within the ACM. Selective zeroization applies to both “working” key material and key material in persistent storage. 

(U) The ACM shall provide for the selective zeroization of Type 1 keys when commanded on the Cryptographic Control Interface. 

(U) The ACM shall provide for the selective zeroization of private keys when commanded on the Cryptographic Control Interface. 

(U) The ACM shall provide for the selective zeroization of trust anchors and/or public keys when commanded on the Cryptographic Control Interface. 

(U) The ACM shall provide for the selective zeroization of key split material when commanded on the Cryptographic Control Interface.

1. 1. 1. 1. 3. Recoverable zeroization

Recoverable zeroization is a process through which all application key material within the ACM is zeroized, but ACM specific key material is left intact. ACM specific key material is intended to mean key material that would be used to fill new application key material into the ACM. An ACM does not have to be reinitialized after a recoverable zeroization has been done

1. 1. 1. 1. 4. Destructive zeroization

Destructive zeroization is a process through which the ACM is completely zeroized and all key material within the ACM is rendered unrecoverable. An ACM must be reinitialized after a destructive zeroization has been done. 

(U) The ACM shall provide a message to the host that the ACM is in the destructive zeroize state. 

(U) The ACM shall accept a hardware discrete destructive Zeroize signal. 

(U) The ACM shall, upon detection of the assertion of the destructive Zeroize hardware discrete line signal, zeroize the RED keys and internal active key splits. 

(U) The ACM destructive zeroization function shall function in all states and modes, with or without prime power or terminal battery backup power.

1. 1. 1. 1. 5. OTAZ

Over-the-Air Zeroization (OTAZ) messages may or may not be processed directly by the ACM. Instead, an OTAZ command may first be sent to the host system. After authenticating the OTAZ message, the host would “action” the OTAZ message by executing the appropriate zeroization commands (e.g., selective, recoverable, or destructive zeroization) using its control interface with the ACM. Future systems, or possibly the future KMI, may send OTAZ type messages directly to the appropriate ACM that are not processed/interpreted first by the host system. It is desirable for the ACM design and functionality to be able to be extended to allow direct processing of OTAZ messages. The following objective requirements summarize the flexibility that is desired for OTAZ functionality within the ACM. 

(U) The ACM should receive, cryptographically authenticate, and process and respond to Over the Air Zeroize (OTAZ) messages.

Note: This does not imply that the ACM has an “over-the-air” interface. The term OTAZ is used to indicate a remote zeroization command. A remote zeroization command is considered to be any zeroization command that originates from a source other than the host. 

(U) The ACM should cryptographically authenticate remote zeroization commands prior to execution in accordance with the ACM security policy. 

(U) The ACM should provide the capability to zeroize all RED keys and internal active key splits, in accordance with the ACM security policy, when an authenticated OTAZ message is received. 

(U) The ACM should provide the capability to zeroize the RED keys and other key material associated with a specific waveform/application.

Note: This allows for the capability to action an authenticated OTAZ message that is limited to a specific waveform or application.

1. 1. 1. 11. OTAR

Over-the-Air Rekey (OTAR) messages may or may not be processed directly by the ACM. Instead, an OTAR message may first be sent to the host system. In this case, the host would format the OTAR message as required for the ACM and load the key(s) received via the OTAR using its control interface with the ACM. Future systems/waveforms may require OTAR processing within the ACM itself. It is desirable for the ACM design and functionality to be able to be extended to allow direct processing of OTAR messages. The following requirements summarize the flexibility that is desired for OTAR functionality within the ACM. 

(U) The ACM shall support Over-the-Air-Rekey (OTAR), as required, by the configured waveforms/applications. 

(U) The ACM should provide the capability to cryptographically authenticate OTAR messages.  

(U) The ACM should be capable of providing notification that an OTAR initiated transaction has occurred. 

(U) The ACM should provide the capability to cryptographically authenticate Over-the-Air-Transfer (OTAT) messages as required by the configured waveforms for waveform specific keys/data.

1. 1. 4. Cryptographic Modernization

The ACM must satisfy the requirements of the Cryptographic Modernization Initiative (CMI) in accordance with NSA policy number 3-9, “Cryptographic Modernization Initiative Requirements for Type 1 Cryptographic Products”. Some of the CMI requirements, such as the requirement to implement Suite A and/or Suite B modernization algorithms, are discussed elsewhere in this TRD. This section organizes the additional CMI requirements that are not discussed elsewhere.

1. 1. 1. 2. Configurability

The ACM must support configurable capabilities in order to be useful for different terminal/platform types. Some platforms are not required to provide high or multi-channel throughput capability, but low power consumption is critical. Ideally, the ACM would be configurable simply via software/firmware. This is not the definition of “configurability”, however, because it is recognized that additional components may be required for the full ACM capability and fewer components may be required for a low power ACM capability. 

(U) The ACM should be reconfigurable over the complete range of ACM capabilites via software/firmware load. 

(U) The ACM should be configurable for different levels of aggregate throughput from 100 Kbps to 10 Gbps (objective).  Move to worst case section and make part of intro. 

(U) Different configurations of the ACM to support varying levels of capability and/or power consumption shall share a common control and management scheme.

<I think this HAS to be a threshold versus a “should”> 

(U) Different configurations of the ACM to support varying levels of capability and/or power consumption shall implement a common design.

1. 1. 1. 3. Programmability

The ACM must be programmable in a tactical environment. The ACM must be capable of changing crypto algorithms and keys based on the mission to be supported (e.g., Coalition interoperable vs. US only). Programmability includes general requirements related to the architecture of the ACM and functional requirements for cryptographic software/firmware loading, identification, storage, accounting, and zeroization. Programmability requirements are specified in the sections that follow.

1. 1. 1. 1. 2. Programmable Architecture

The following requirements are applicable to the general architecture of the ACM. The overall ACM architecture is an important consideration in the programmability of the device. It is expected that the ACM will be implemented using General Purpose Processor (GPP) and/or Field Programmable Gate Array (FPGA) devices. These devices are inherently reprogrammable, offer implementation flexibility, and provide lower cost, schedule, and capability risks for development than an Application Specific Integrated Circuit (ASIC). This TRD does not abrogate the use of an ASIC for the implementation of the ACM as long as all requirements can be satisfied. In order to support CMI goals, the ACM should be completely reprogrammable in order to support algorithms and cryptographic services required by future waveforms. A GPP/FPGA implementation allows for new and updated algorithms to be installed without hardware upgrade, and may be preferably evaluated. 

(U) If the ACM implementation utilizes FPGA technology, in whole or in part, the following requirements are applicable: 

(U//FOUO) The classified FGPA images shall be saved in BLACK form when ACM is not operational. 

(U//FOUO) The classified FPGA images shall be decrypted and loaded only when ACM is operational. 

(U) If the ACM implementation utilizes ASIC technology, in whole or in part, the following requirements are applicable: 

(U//FOUO) The ASIC shall be fabricated in a DoD approved Trusted Foundry. 

(U//FOUO) An ASIC implementing classified algorithm shall require the use of NSA approved method(s) that allows the ASIC to be handled as a COMSEC Controlled Item (CCI).

1. 1. 1. 1. 3. Cryptographic Software/Firmware Loading

The following requirements are applicable to the functionality that the ACM must provide in order to support (re)programmability and field upgrade of the ACM software/firmware. In the requirements that follow, the implementation of a Type 1 cryptographic algorithm is assumed to be part of the ACMÂ’s software/firmware that is encrypted and signed by NSA and not a standalone software/firmware package. It is assumed that NSA requires that all security-related software/firmware components that will be executed on the ACM must be bundled together in a single package and evaluated as a whole. Under these assumptions, a set of algorithms would be packaged together based on typical mission requirements (e.g., US only versus foreign interoperable). These assumptions should not preclude novel alternative implementations that are advantageous and capable of NSA certification. 

(U) The ACM shall provide field upgrade and reprogramming of the cryptographic software/firmware. 

(U) The ACM shall support the use of Trust Anchors for the purpose of providing signature verification for software/firmware downloads. 

(U) The ACM shall only accept cryptographic software/firmware packages signed by NSA. 

(U) The ACM should be capable of supporting the cryptographic algorithms for the evolving requirements for upgrading of software/firmware using the Cryptographic Message Syntax (CMS) for protecting firmware packages for Type1 Cryptographic Modules (Objective). 

(U) The ACM should be capable of supporting the cryptographic algorithms for the evolving standards of the Trust Anchor Management Protocol for use with Type 1 Cryptographic Modules (Objective). 

(U) The ACM shall perform authentication and integrity checks of received cryptographic software/firmware packages. 

(U) The ACM shall report the result of a failed integrity check for received cryptographic software/firmware as an auditable event. 

(U) The ACM shall be capable of being configured to not accept a version of a cryptographic software/firmware package that is older than the currently installed version. 

(U) The ACM shall maintain the type and version of the cryptographic software/firmware package(s) that is (are) loaded. 

(U) The ACM shall provide the capability to accept and store Suite A or Suite B cryptographic algorithms up to TOP SECRET using over-the-network algorithm update during “on air” terminal operation 

(U) The ACM shall be capable of being software/firmware upgraded and reconfigured without the need to be returned to the factory, depot, or a trusted facility. 

(U) The ACM shall be delivered complete with all test equipment, harnesses and software tools needed for Depot support.

1. 1. 1. 1. 4. Cryptographic Algorithm Identification

The host and the ACM must be able to identify the algorithms that are implemented within the ACM software/firmware. The following requirements apply to algorithm identification. 

(U) The ACM shall provide an interface through which algorithm information (e.g., supported algorithms, supported modes, version, etc.) may be requested and provided. 

(U) The ACM should identify algorithms in accordance with TBD.

1. 1. 1. 1. 5. Cryptographic Software/Firmware Storage

The following requirements are applicable to storage of cryptographic software/firmware within the ACM. 

(U) The ACM shall encrypt cryptographic software/firmware for storage.

Note: It is assumed that the algorithm that is used to encrypt cryptographic software/firmware for storage can be different than the algorithm that is used to encrypt cryptographic software/firmware for distribution. It is desirable for cryptographic software/firmware to be encrypted for distribution using a mechanism that does not require management of individual decryption symmetric key segments for each ACM. 

(U) The ACM shall decrypt stored cryptographic software/firmware.

Note: It is assumed that the algorithm that is used to decrypt stored cryptographic software/firmware can be different than the algorithm that is used to encrypt cryptographic software/firmware for distribution. It is desirable for cryptographic software/firmware to be encrypted for distribution using a mechanism that does not require management of individual decryption symmetric key segments for each ACM. 

(U) The ACM shall perform integrity checks on Security Critical Packages and files prior to instantiation or use. 

(U) The ACM shall have the capability to store a minimum of (TBD) different Cryptographic software/firmware images in BLACK form.

<ShouldnÂ’t this be specÂ’d as a storage size instead of a number of packages?> 

(U) Algorithm information (e.g., algorithm type, supported modes, version, etc.) shall be bound to the algorithm in storage. 

(U) The ACM shall have the capability to maintain at least two versions for each cryptographic software/firmware image.

<This one needs rationale> 

(U) The ACM shall have the capability to rollback the version of the cryptographic software/firmware image.

1. 1. 1. 1. 6. Cryptographic Software/Firmware Erasure

The following requirements are applicable to erasure/zeroization of cryptographic software/firmware within the ACM. 

(U) The ACM shall have the capability to overwrite the previous version of the stored cryptographic software/firmware when a new version of the software/firmware is downloaded and after its authenticity and integrity has been verified.

1. 1. 1. 4. Releasability

(U//FOUO) The ACM shall be capable of supporting a programmable Positive Access Control (PAC) ing and privileges to support foreign releasability. 

(U) The ACM shall support Type 1 Suite B algorithms required for foreign interoperability, when required.

1. 1. 1. 5. Cryptographic Family Interoperability

1. 1. 1. 1. 2. HAIPIS

<Recommend that we need to get specific about which HAIPIS extension specifications are required and which are not (if any are not)> 

The ACM shall provide HAIPE cryptographic services in accordance with appendix B.

Note: The requirements traceability matrix in Appendix B indicates the allocation of requirements between the ACM and the host.

1. 1. 1. 1. 3. LEF

(U) The ACM shall support the cryptographic requirements for Link Encryptor Family LEF 2.0. 

The ACM shall provide LEF cryptographic services in accordance with appendix C.

Note: The requirements traceability matrix in Appendix C indicates the allocation of requirements between the ACM and the host.

1. 1. 5. Software Communications Architecture (SCA)

(U) The host terminals will be SCA compliant terminals. The goals established by the SCA are to increase software portability, increase software reuse and increase use of COTS software. This typically applies to both the RED side and BLACK side of the host terminal. The SCA uses the Common Object Request Broker Architecture (CORBA), which is considered to provide a low level of assurance, in order to provide an environment for software portability and reuse.   While the ACM may use a non SCA compliant internal implementation in order to provide the necessary high assurance, it must provide an SCA compliant host interface on both the RED and BLACK sides. 

(U) The SCA includes a security supplement that establishes security requirements for SCA compliant systems. The SCA security supplement includes both system level (terminal level) requirements and requirements on the cryptographic subsystem. Because the host terminals will be SCA compliant terminals, the ACM must satisfy the requirements from the SCA security supplement that are allocated to the cryptographic subsystem. 

(U) [CR0000] The ACM shall support the requirements listed in section 4.2 of the Security Supplement to the SCA Specification, JTRS-5000SEC, rev 3.0. 

(U) [CR0000] The ACM shall provide a native and/or software adaptor interface that implements the SCA Security API Service Definition, as defined in Attachment 1 to JTRS-5000SEC, rev 3.0. 

(U) [CR0000] The SCA interface to the ACM shall support all ACM functions otherwise available through any other interfaces. 

(U) [CR0000] ACM functions invoked through the SCA interface will satisfy the performance requirements (e.g., encrypt/decrypt rates, latency, etc.) specified elsewhere in this document.

1. 1. 6. Lifecycle

The following requirements are applicable to the life cycle processes for the ACM and for the cryptographic services supported by the ACM. Elements of the ACM lifecycle include ACM startup and ACM shutdown. Elements of the lifecycle for cryptographic services include algorithm initialization, cryptographic channel instantiation, cryptographic channel runtime, and cryptographic channel termination.

1. 1. 1. 2. ACM Startup

(U)  The ACM shall perform startup in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) Startup refers to the boot and function initialization processes of the ACM. The following requirements apply to the ACM startup process. 

(U) The ACM shall provide services to decrypt, verify, install, and execute its run-time application. 

(U) The ACM run-time application shall not execute if integrity verification fails. 

(U) The ACM shall provide notification to the host when it is operationally ready to provide services to the host. 

(U) Notification shall include a status output indicating that boot and test were completed without error or indicate that an error occurred and provide error information.  

(U) The ACM shall be operational within 5 seconds after power on. 

(U) The ACM shall be designed to restart properly independent of the previous shutdown (orderly shutdown or unscheduled shutdown).

1. 1. 1. 3. ACM Shutdown

(U)  The ACM shall perform shutdown in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) Shutdown refers to the process of executing a shutdown operation for the ACM. Shutdown could be a scheduled (orderly) shutdown or an unscheduled shutdown (e.g., removal of power). The following requirements apply to the ACM shutdown process. 

(U) (U) The ACM shall be capable of shutting down and reverting to a CCI state within TBD seconds after a receipt of a shutdown command.

1. 1. 1. 4. Algorithm Initialization

(U) Algorithm initialization refers to the process of starting an algorithm to provide a cryptographic service to the host. The following requirements apply to the algorithm initialization process. 

(U) The ACM shall provide the capability to instantiate cryptographic algorithms with different modes/options supported by the algorithm. 

(U) The ACM shall decrypt and instantiate algorithms prior to use. 

(U) The ACM shall test instantiated cryptographic algorithms for correct function prior to operational use.

1. 1. 1. 5. Cryptographic Channel Instantiation

(U) In the following requirements, a cryptographic channel is defined as a cryptographic service provided to the host system that is associated with a particular key. A cryptographic channel may be used to support TRANSEC key stream generation, COMSEC encryption/decryption, or any of the other cryptographic services supported by the ACM. The ACM performs cryptographic operations on a cryptographic channel as allowed by the ACM security policy. The following requirements apply to cryptographic channel instantiation. 

(U)  The ACM shall perform cryptographic channel instatiation in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) The ACM shall verify against the resident security policy that there are no policy violations prior to cryptographic channel instantiation. 

(U) The ACM shall instantiate cryptographic functions for a cryptographic channel within TBD seconds of the request to instantiate the channel.

1. 1. 1. 6. Cryptographic Channel Run-time

(U) The following requirements apply to cryptographic channels during runtime processing on the cryptographic channel. 

(U) The ACM shall provide the ability to perform periodic tests to assure that instantiated ACM operations on a cryptographic channel are maintained. 

(U) The ACM shall provide cryptographic channel status outputs on request. 

(U) The ACM shall provide the capability to change a cryptographic channel or the cryptographic channel operating parameters without affecting the operation of other cryptographic channels. 

(U) The ACM shall provide the capability to turn on/off on a cryptographic channel without affecting the operation of other cryptographic channels.

1. 1. 1. 7. Cryptographic Channel Termination

(U) The following requirements apply to cryptographic channel termination. Termination includes the cases of routine termination of a cryptographic channel and abnormal termination. 

(U) In the event of internal failure, the ACM shall terminate the cryptographic channel in accordance with the tailored UIC for POET. 

(U) The ACM shall provide abnormal cryptographic channel failure status as audit event to the host. 

(U) In the event of abnormal termination of a cryptographic channel, the ACM shall be capable of supporting the operation of the remaining cryptographic channels.

1. 1. 7. Levels of Security and Classification

(U) The following requirements clarify the different levels of security that must be supported by the ACM and the requirements for supporting different levels of security concurrently. 

(U) The ACM shall support cryptographic operations using unclassified, SECRET, or TOP SECRET key material. 

(U) The ACM should support cryptographic operations using unclassified, CONFIDENTIAL, SECRET, or TOP SECRET key material. 

(U) The ACM should support cryptographic operations using SECRET compartmented key material. 

(U) The ACM should support cryptographic operations using TOP SECRET compartmented key material. 

(U) The ACM shall support unclassified and SECRET level cryptographic services simultaneously. 

(U) The ACM should support unclassified, CONFIDENTIAL, SECRET, and TOP SECRET level cryptographic services simultaneously. 

(U) The ACM should support collateral and compartmented cryptographic services simultaneously. 

(U) The ACM shall support TOP SECRET/Sensitive Compartmented Information (TS/SCI) cryptographic services in a system-high configuration.

1. 1. 8. ACM Security Policy

(U) A security policy is a set of rules which are tested for compliance and then enforced by a given security function. Security policies are expected to be different for different waveforms and/or applications that the crypto must support. Security policies are expected to be created by the terminal vendor. TBD may be used as the format for the security policy definition. 

(U) The ACM shall protect the security policy rules for cryptographic bypass within the ACM. 

(U) The ACM shall accept waveform security policy elements from the Cryptographic Control Interface prior to cryptographic channel instantiation. 

(U) The ACM shall authenticate the cryptographic signature of each security policy. 

(U) The ACM shall provide security policy status upon authenticated request. 

(U) The ACM shall authenticate the signature of each security policy prior to use. 

(U) The ACM shall enforce the internal security policy for security critical items prior to reporting status. 

(U) The ACM shall report any attempted violation of the security policies as audit events.

1. 1. 9. Bypass Processing

(U) The following requirements are for high assurance cryptographic bypass processing that must be supported by the ACM. Cryptographic bypass processing includes both cryptographic channel bypass and control/status bypass. There is also a waveform specific bypass function that must be supported for the CDL waveform for terminals with a RED core architecture. There may also be waveform specific bypass functions that must be supported for other waveforms. This highlights the fact that the ACM bypass policy must be flexible as well as secure and capable of NSA certification.

1. 1. 1. 2. Cryptographic Channel Bypass

The following requirements are applicable to cryptographic channel bypass. Cryptographic channel bypass is defined as the bypassing of information from the plaintext to the ciphertext side of the ACM for information that will eventually egress the terminal on an external interface. 

(U) The ACM shall perform traffic header bypass for packet encryption/decryption cryptographic channels in accordance with the cryptographic channel bypass security policy for the cryptographic channel. 

(U) The ACM shall perform waveform specific bypass functions in accordance with the cryptographic channel bypass security policy for the waveform. 

(U) The ACM shall have a mechanism to terminate communication on the cryptographic channel if the bypass policy is violated. 

(U) If policy violation exceeds a policy-determined threshold, the ACM shall support a mechanism to terminate the channel, resulting in termination of the operation of the affected channel. 

(U) The ACM bypass mechanism shall block messages that violate the bypass security policy.

1. 1. 1. 3. Control/Status Bypass

The following requirements are applicable to control/status bypass. Control/status bypass is defined as the bypassing of information from the plaintext to the ciphertext side of the ACM for internal control/status information that will not egress the terminal on an external interface. A certain amount of control/status bypass is expected for any terminal architecture that includes both RED side and BLACK side processing functions. 

(U) The ACM shall support control/status bypass in accordance with the control/status bypass security policy. 

(U) The ACM control/status bypass mechanism shall be non-bypassable. 

(U) The ACM control/status bypass mechanism shall always be invoked. 

(U) The ACM bypass mechanism shall block messages that violate the bypass security policy. 

(U) The ACM control/status bypass mechanism algorithm shall check for valid format of bypass messages. 

(U) The ACM control/status bypass mechanism algorithm shall check for valid length of bypass message. 

(U) The ACM control/status bypass mechanism algorithm shall check for valid frequency of bypass messages for a given bypass mechanism.

1. 1. 1. 4. CDL Bypass

(U//FOUO) A waveform specific bypass function must be supported for the CDL waveform for terminals with a RED core architecture. Legacy CDL communications require link control information to be exchanged between the two communicating systems via encrypted transmissions in order to securely aid in signal acquisition as well as to maintain directional links with moving platforms. On the legacy CDL waveforms, link control information is exchanged by multiplexing it together with the end-to-end traffic on the CDL link and then bulk encrypting the multiplexed signal. The end-to-end traffic may or may not be encrypted separately before bulk encryption. A RED core terminal can support CDL links where the end-to-end traffic is separately encrypted. After bulk decryption, the end-to-end traffic can be bypassed to the BLACK side of the terminal for transmission to the next hop on the end-to-end path. This is a type of bypass function that must be supported by the ACM. This type of bypass is discussed separately because it is specific to the CDL waveform and because of the high data rates that are involved. Below are requirements for the CDL specific bypass. 

(U) The ACM shall provide a security guard function restricting CDL plaintext control information to the RED side. 

(U) The ACM shall provide a high speed control bypass function commensurate with the <maximum> CDL waveform data rate to allow for the transfer of Bulk decrypted data from RED side to the Black side.

1. 1. 1. 5. Network Management Bypass

(U//FOUO) The TSAT waveform, and potentially all network centric waveforms, may require BLACK side terminal functionality to be managed via a Type 1 security association (TBD). Since management commands/messages would terminate on the RED side of the terminal, there must be some RED-to-BLACK and BLACK-to-RED bypass in order to support this type of management. This type of bypass is discussed separately, but may only be a particular case of control/status bypass. The fact that network management bypass is discussed separately should not be interpreted to mean that this must be a unique bypass mechanism in addition to control/status bypass. Below are requirements for network management bypass. 

(U) The ACM shall support bypass of network management data from the RED side to the BLACK side in accordance with the bypass security policy. 

(U) The ACM shall support bypass of network management data from the BLACK side to the RED side in accordance with the bypass security policy.

1. 1. 10. Unattended Operation

(U) The ACM must support terminals that operate unattended in the ground tactical and airborne environments.  Unattended operation requires that the ACM be activated using a physical token and/or pass phrase and remain activated when the token is removed. Unattended operation also requires a robust anti-tamper mechanism and ability to perform remote zeroization of the ACM. 

(U) The ACM shall be capable of supporting the use of CRK over the host interface for initial setup. 

(U) The ACM shall be capable of supporting the use of host provided CRK equivalent variables for initial setup 

(U) The ACM shall be capable of supporting unattended operation after the initial setup. 

(U) The ACM shall allow configuration through a remote operator interface. 

(U) The ACM shall provide a cryptographically authenticated mechanism for loading the requisite key information for remote re-activation without the use of a CRK. 

(U) The ACM will be used in ground terminals/platforms that operate unattended at the unclassified or SECRET level. POET will not support unattended ground terminals/platforms at the TOP SECRET level.

1. 1. 11. Unclassified Handling

(U) The ACM shall provide the capability to be rendered unclassified for storage/shipping. 

(U) The ACM shall support the means to disable classified processing capabilities (i.e., transition to an Unclassified Controlled Cryptographic Item (CCI)). 

(U) The ACM shall support the recovery from Unclassified CCI to Classified Operation state. 

(U) The ACM shall require the CRK to be physically attached to the CRK interface. 

(U) The ACM shall have exclusive access to the physical CRK, when present.

1. 1. 12. Tamper

(U) The ACM shall support tamper in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) The ACM shall be provided with field tamper recovery capability. 

(U) ACM anti-tamper capabilities shall be available in the absence of external power. 

(U) ACM zeroization capabilities shall be available in the absence of external power.

1. 1. 13. Identification and Authentication (I&A)

1. 1. 14. Audit

The ACM shall provide audit capabilities in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) The ACM shall be capable of reporting audit events over the Cryptographic Control Interface. 

(U) The ACM shall support TBD of internal storage for audit events. 

(U) The ACM control/status bypass mechanism shall output all violations of bypass security policy as audit events. 

(U) The ACM should support recording of audit messages as required by KMI. 

(U) The ACM should support reporting of audit messages, as required by KMI, via the fill port interface or the host instruction interface.

1. 1. 15. Alarm

The ACM shall provide alarm capabilities in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET. 

(U) The ACM shall be capable of detecting faults and provide alarm events. 

(U) The ACM shall be capable of supporting segregation of major and minor alarms events. 

(U) The ACM shall be capable of recovery from compromise events (e.g. loss of key, equipment failure). 

(U) The ACM shall default to a secure state in the event of a failure.

1. 1. 16. Built-In Test (BIT) and Health Status

The ACM shall provide BIT and health status capabilities in accordance with the tailored Unified INFOSEC Criteria (UIC) for POET.

1. 1. 1. 2. BIT

(U) The ACM BIT function can be categorized as follows:

• Power-on BIT (PBIT)
• Continuous BIT
• Initiated BIT

(U) The ACM BIT function shall detect no less than 95 percent of all faults, by failure rate.

1. 1. 1. 1. 2. Power-on BIT

(U) The ACM shall perform PBIT upon reset or power-up. 

(U) The ACM PBIT shall include test for each type (volatile, non volatile) of memory. 

(U) The ACM PBIT shall include tests for all processors and FPGAs.

1. 1. 1. 1. 3. Continuous BIT

(U) The ACM CBIT function shall detect no less than 95 percent of all tested fault conditions by failure rate. 

(U) The ACM CBIT shall monitor the battery voltage of the internal battery.

1. 1. 1. 1. 4. Initiated BIT (IBIT)

(U) The ACM shall support IBIT function in an offline state. 

(U) The ACM shall have the capability to perform IBIT when requested from the Cryptographic Control Interface. 

(U) The ACM shall complete IBIT within TBD seconds after IBIT has been initiated. 

(U) Upon request, the ACM shall perform additional diagnostics during the terminal initialization sequence. These diagnostics will include known answer tests (to verify the encrypt/decrypt path) and tests that verify the correct operation of the cryptographic bypass.

1. 1. 1. 3. ACM Health Status

(U) The ACM shall provide a Health discrete signal and BIT status messages for reporting health status. 

(U) The ACM shall provide the results of the diagnostic tests. 

(U) The ACM shall provide the overall POET ACM version identifier.

1. 5. External Interfaces

(U) Industry standards shall be used, where possible, for external interfaces.

(U) The ACM shall accept a PPS (pulse-per-second) clock. 

(U) The ACM shall include a DS-101 Cryptographic fill port interface IAW EKMS-308. 

(U) The ACM shall accept a RESET signal 

(U) The ACM shall accept a Tamper signal 

(U) The ACM shall provide an interface to support connection to a CRK interface. 

(U) The ACM shall accept a destructive Zeroize hardware signal. 

(U) The ACM shall provide a Health signal. 

(U) The ACM shall receive RED power from the host.  

(U) The ACM shall receive BLACK power from the host.  

(U) The ACM shall accept the Time of the Day.

.

(U) The ACM shall accept the Date Time from the host in a TBS format.

1. 6. Design margins

(U) The ACM shall provide TBD design margin reserve capacity to accommodate new cryptographic algorithms and services for alternate/future waveforms.

1. 1. 2. Processor Capacity

(U) The ACM shall have 50 percent of processor capacity reserve required for the worst case scenario, when it is configured with cryptographic channels for TRANSEC channels for four waveforms, Bulk Encryption/Decryption for CDL waveform and supporting multiple HAIPE tunnels for NMS.

1. 1. 3. Memory Capacity

(U) The ACM shall have 100 percent memory capacity reserve required for the worst case scenario, when it is configured with cryptographic channels for TRANSEC channels for four waveforms, Bulk Encryption/Decryption for CDL waveform and supporting multiple HAIPE tunnels for NMS.

1. 7. Power

1. 1. 2. General

The following requirements are general requirements related to the power required to operate the ACM within a terminal/platform. 

(U) Some platforms are not required to provide high or multi-channel throughput capability but low power consumption is critical. Reasonable means to conserve power shall be employed, including reducing ACM power consumption when high performance is not needed. 

(U) The ACM shall scale its power requirements in relation to the configured throughput and channels supported, lower throughput using less power. 

(U) Reasonable means to conserve power shall be employed, including reducing ACM power consumption when high performance is not needed. 

(U) The POET ACM shall be configurable for the number of independent channels supported from one to four.  The POET ACM shall scale its power requirements in relation to the configured throughput and channels supported, lower throughput using less power. 

(U) The ACM shall receive a RED external power of TBD VDC.  

(U) The ACM shall receive BLACK external power of TBD VDC.  

(U) The ACM shall consume power less than TBD watts.  

(U) The ACM shall locally generate any additional internal voltages required.

(U) The ACM power consumption shall be defined in its interface control document so that the host terminal can provide sustaining voltage in the event of an external un-commanded power interruption. The ACM full load operating conditions shall be used to derive this parameter. Given the ACM scalability requirements, several sets of power interface specifications may be necessary to characterize performance.

1. 1. 3. Battery

(U) The ACM shall include a hold-up battery that will detect the absence of external power and transition the device into its cryptographic safe mode as specified in the UIC. It is desired that this battery be capable of being recharged from the host when external power is available in order to maximize field service life. The ACM shall provide an output status to the terminal when its battery reaches 85 percent of its useful life. In the absence of external power under nominal room ambient temperature conditions the ACM battery shall have a minimum installed shelf life of not less than 10 years to provide UIC specified capabilities. The ACM battery must deliver required UIC capability over the full range of temperature and shock exposure but the shelf life under these extreme conditions shall be reduced to no less than three years. 

(U) The ACM shall have the capability to detect the absence of external power and transition without power loss to use the ACM internal battery supply. 

(U) When external power is present, the ACM shall use the external power in place of the internal battery. 

(U) The ACM shall have the capability to report the status of the internal battery. 

(U) The ACM shall provide internal battery with a life of at least TBD years.

1. 8. Physical

(U) The ACM shall not exceed a width of TBD inches, a length of TBD inches and a height of TBD inches.  

(U) The ACM shall have a maximum weight of TBD pounds.

1. 9. Environmental

(U) The ACM shall operate at a temperature range of between TBD°C to TBD °C at sea level.  

(U) The ACM shall operate at altitudes up to TBD feet above sea level.  

(U) The ACM shall operate when subject to random vibration IAW TBD.  

(U) The ACM shall operate when subject to operational shock IAW TBD.  

(U) The ACM shall meet the EMI/EMC requirements IAW TBD.  

(U) The ACM shall operate when subjected to a relative humidity of TBD% to TBD%.  

(U) The ACM shall survive exposure to temperature ranging from TBD°C to TBD°C while non-operational.  

(U) The ACM shall survive exposure to altitudes up to TBD feet above sea level while non-operational.  

(U) The ACM shall meet the requirements for thermal design IAW TBD.  

(U) The ACM design shall not rely on cooling air coming into contact with internal electrical parts, circuitry, or connectors.  

(U) The ACM shall not require or use internal electrical heaters, fans, blowers, or similar devices unless specifically approved by the Government.

1. 10. Maintainability

(U) The ACM shall be designed such that preventive maintenance is not required other than battery replacement.

1. 11. Reliability

(U) The ACM shall have a Mean Time between Failures (MTBF) of TBD hours.

1. 12. Interchangeability

(U) The ACM as part of the TERMINAL INFOSEC module shall be fully interchangeable, both mechanically and electrically IAW TBD.

1. 13. Workmanship

(U) The ACM workmanship shall be IAW TBD.

1. 14. Documentation

(U) The ACM implementation shall document the software interface/primitives as part of the ACM Embedment Manual. 

(U) The ACM primitives for a specific implementation shall be documented in the ACM Embedment Manual. 

(U) The ACM implementation shall document the physical interfaces as part of the ACM Embedment Manual. 

(U) The ACM implementation shall document the physical interface signaling including data rate, signal structure including duty cycle and shape, trigger [edge or signal level],  levels and current, allowable jitter or skew, and timing relationships to other ACM interface signals as part of the ACM Embedment Manual.

1. 15. IA Standards and Certification

(U) The ACM incorporates both NSA approved Type 1 and NIST approved Non Type 1 cryptographic algorithms. The ACM is required to have UIC Certification. The NIST approved Non Type 1 cryptographic algorithms are subject to FIPS-140-2 requirements. The FIPS-140-2 certification process is for use by commercial cryptographic modules.  

(U) The ACM may be subject to both UIC and FIPS certification. The UIC Certification process involves Cryptographic Verification (CV) and Security Verification (SV) tests for the ACM. The UIC Certification provides a much higher assurance than the FIPS 140 certification. If the NIST approved algorithms are verified as part of the CV and SV tests for UIC Certification, the FIPS Certification can probably be avoided. 

(U) The ACM shall be developed in accordance with (IAW) the IA “Defense in Depth” standards by CJSCI 6510.01C, DoD Directive 8500.1 Information Assurance and DoD Directive 8500.2 Information Assurance Implementation. 

(U//FOUO) The ACM shall meet the requirements of the Tailored System Security Requirements (SSR) and Fail Safe Design Analysis (FSDA) requirements from NSA. 

(U//FOUO) The ACM security design shall be documented and submitted to NSA for approval IAW the Contract Data Requirements List (CDRL) identified in the Telecommunications Security Requirements Document (TSRD). 

The ACM design shall meet the information assurance requirements described in the following sections and must satisfy the security and certifiability of the cryptographic application by the National Security Agency (NSA). The principal sections of Interim Information Assurance Directorate (IAD) Procedure No. 01-02 that must be addressed during the design include: 

14.a(4) Proper Classification

14.b Development Requirements-Building Assurance Levels 1, 2, and 3

14.b(1)(a) Cleared Personnel

14.b(1)(b) Cleared Facilities

14.b(1)(c) Established Development Methodology and Standards

14.b(2) High Level System Requirements Review             

14.b(8)(c)(1) Informal Review-Requirements

14.b(8)(c)(3) Informal Review-Code Review 

The ACM shall be designed such that follow-on product delivery is capable of achieving Type 1 certification by NSA. Certification is a process involving meeting the security requirements provided by NSA as well as evolution of the technology and policy requirements as defined by the process documented in the User Partnership Agreement (UPA) between the Army and NSA. This process defines both the policy, technical capability, and testing needed for certification for a particular use. 

The ACM will comply with the security and information assurance (IA) requirements provided in a document by the NSA as part of the User Partnership Agreement (UPA) for NSA cryptographic certification. 

ACM security and IA requirements will be developed in accordance with tailored Unified INFOSEC Criteria (UIC), and documented in a Theory of Design and Operation (TDO). 

The ACM shall include security mechanisms sufficient to satisfy the NSA requirements allocated to the ACM. The NSA will provide a document containing these requirements as part of the UPA for NSA cryptographic certification.  

The ACM will demonstrate compliance with any additional security or IA requirements imposed outside of the TDO by ACM Type 1 certification with the NSA. 

The ACM shall protect sensitive software and firmware within the ACM tamper boundary. 

The ACM shall support Type-1 security classification up to TS/SCI for a single compartment. 

The ACM shall include means of enforcing the least privilege principle. The least privilege principal requires that each subject be granted the most restrictive set of privileges needed for the performance of authorized tasks. 

The ACM shall include services that allows the terminal to enforce that the system manager is authenticated before the terminal accepts its commands. 

The ACM shall audit security relevant events. Security relevant events will be identified in the appropriate security document. 

The ACM shall provide audit data to host upon request or when the memory is full. 

The ACM shall perform cryptographic testing in order to become operational. The ACM will not transition to the operational state until the ACM passes all security-relevant tests. 

The operational ACM shall provide the capability to automatically perform specified periodic cryptographic testing. The ACM must pass all security-relevant tests in order to remain operational.

(U) NOTES

2. (U) Definitions

1. 3. (U) Acronyms

AEHF    Advanced Extremely High Frequency

AES    Advanced Encryption Standard

API   Application Program Interface

ASIC    Application Specific Integrated Circuit

ATOW   Acquisition Tracking Orderwire

BER   Bit Error Ratio/Rate

BF   Benign Fill

BIT   Built in Test

BLOS   Beyond Line Of Sight

CBC    Cipher Block Chaining

CCI   COMSEC Controlled Item

CDL    Common Data Link

CDRL   Contract Data Requirements List

CIK   Crytpo Ignition Key

COI   Communities Of Interest

COMSEC  Communications Security

CORBA  Common Object Request Broker Architecture

COTH   Communication on the Halt

COTM   Communications On The Move

COTQH   Communications On The Quick Halt

COTS   Commercial Off The Shelf

CRK   Cryptographic Recovery Key

CSS   Crypto Sub System

DoD   Department of Defense

DoDAF  Department of Defense Architecture Framework

DoS   Denial of Service

EC-MQV  Elliptic Curve Menezes-Qu-Vanstone

ECU   End Cryptographic Unit

EFF   Enhanced Firefly

EHF    Extremely High Frequency

EKMS   Electronic Key Management System

EMC   Electromagnetic Compatibility

EMI   Electromagnetic Interference

FCAPS  Fault, Configuration, Account, Performance, Security

FCC    Federal Communications Commission

FF   Firefly

FPGA   Field Programmable Gate Array

FSDA   Fail Safe Design Assurance

GCM   Galois Counter Mode

GBS    Global Broadcast System

GIG   Global Information Grid

GPP   General Purpose Processor

GPS   Global Positioning System

HAIPE   High Assurance Internet Protocol Encryptor

HAIPE IS  HAIPE Interoperability Specification

HC3   High Capacity Communications Capability

HCLOS  High Capacity Line of Site

HDR   High Data Rate

HF   High Frequency

IA   Information Assurance

I&A   Identification and Authorization

IAW   In Accordance With

IKE   Internet Key Exchange

INFOSEC  Information Security

IO   Input Output

IP   Internet Protocol

IPSec   Internet Protocol Security

IPv4   Internet Protocol, version 4

IPv6   Internet Protocol, version 6

JTRS    Joint Tactical Radio System

KB   Kilo Byte

KEK   Key Encryption Key

LDR    Low Data Rate

LOS   Line of Sight

MDR    Medium Data Rate

MTBF   Mean Time Between Failures

MTTR   Mean Time To Repair

N-CDL  Networked Common Data Link

NDL   Network Data Link

NIST   National Institute of Standards and Technology

NSA   National Security Agency

OTAR   Over The Air Rekey

OTAT   Over The Air Transfer

OTAZ   Over The Air Zeroize

OTNK   Over The Network Keying

PKI   Public Key Infrastructure

PPK   Pre-Placed Key

RSA   Rivest, Shamir, and Adelman

SA   Security Association

SATCOM  Satellite Communications

SBU   Sensitive But Unclassified

SCA     Software Communications Architecture

SNMP   Simple Network Management Protocol

SW   Software

SWAP   Size, Weight and Power

TBD   To Be Determined

TDN   Tactical Data Network

TOD   Time of Day

TRANSEC  Transmission Security

TSAT   Transformation Satellite Communications

TSRD   Telecommunications Security Requirements Document

UAV   Unmanned Aerial Vehicle

UIC   Unified INFOSEC Criteria

VDC   Voltage Direct Current

VHF   Very High Frequency 

WGS    Wideband Gapfiller System

WIN-T   Warfighter Information Network-Tactical

XCP   eXplicit Control Protocol

XDR    eXtended Data Rate

XML    eXtensible Markup Language

2. APPENDIX A: POET ACM REQUIRED ALGORITHMS

(U) POET ACM must provide the traffic algorithms that are required to support each of the terminal waveforms/applications. Some applications require more than one crypto algorithm to be running simultaneously. The algorithms are organized by application and the maximum data rate per algorithm per application is listed. The max data rates listed are draft and need to be confirmed. Each algorithm is also given an algorithm ID which is used to show simultaneity within and among applications. Required simultaneity among waveforms will be established by the terminal programs and is not shown. 

(U)  Type, S = Simplex; F = Full Duplex

(U) Highlighting shows areas that are TBD

(U) Note that no design or future proofing margins are shown

Where references are cited for the mode(s) that must be supported for a given algorithm, assume that all modes in the references must be supported unless otherwise indicated. 
 

Table A-1 (U) AEHF Algorithms 

Notes 

2. Max rate is aggregate. Crypto must support outputting key stream block every TOD.

3. Max assumes one XC2 per frame plus sending OTADD.

4. Max assumes 3 XC3s per frame plus receiving OTADD.

5. Max assumes 10 XC3s or ATOWs per frame.

Table A-2 (U) MIL-188-165 Algorithms 

Notes 

2. Max rate assumes that communication over WGS satellites in RF bypass mode is only used for CDL. The algorithms and maximum rate are therefore already covered by the CDL table.

3. Assume 256 bit key size.

Table A-3 (U) MIL-188-EEE Algorithms 

Notes 

2. Max rate is the maximum data rate for MIL-188-EEE link cover.

3. Assume 256 bit key size.

Table A-4 (U) CDL Algorithms 

Notes 

2. Objective max rate is a full duplex 548 Mbps link.

3. See reference documents for required CDL algorithms.

Table A-5 (U) TSAT Algorithms 

Notes 

2. Needed for backward compatibility with AEHF.

3. Max rate is aggregate. Crypto must support outputting key stream block every TOD.

4. Simultaneity with 5p is worst case if TSAT goes with direct orthogonalization approach.

5. Max assumes one XC2 per frame plus sending OTADD.

6. Max assumes 3 XC3s per frame plus receiving OTADD.

7. Max assumes 10 XC3s or ATOWs per frame.

8. TSAT uplink TRANSEC is still being defined. The max rate assumes simultaneous generation of 5 different keys (worst case for direct orthogonalization approach).

9. Assume 256 bit key size.

10. Max rate assumes (25x9x1024) bit permutation table. Some margin is inherent since terminal should only get 1 column of table, not 25.

11. TSAT link layer security mechanisms are still being defined. Max rate assumes 1 TCRC message per frame with an encrypted, 512 bit authentication tag.

12. Max rate is the maximum expanded cover rate for the XDR+ uplink.

13. Max rate is the maximum expanded cover rate for the XDR+ downlink.

14. Any requirement for cover for TSAT Ka AISR links is TBD.

15. There are no implementation details for cover for TSAT Ka AISR links. The assumption is that Ka AISR cover is implemented similar to XDR+ cover (e.g., same algorithm, same mode, and use of a cover expansion function).

16. Simultaneity column assumes that a terminal is not running XDR/XDR+ and SONET (Ka AISR or lasercomm) concurrently.

17. Max rate is the maximum expanded cover rate for the Ka AISR links.

18. Max rate assumes encryption/decryption for SONET section, line, and path overhead for AISR links (Ka AISR or lasercomm). Any requirement for encryption/decryption of the SONET overhead is TBD.

19. Max rate is worst case. Note that path overhead is probably a separate E2E encryption.

20. SONET overhead is only full duplex for lasercomm. Ka AISR is simplex.

21. Must support all modes defined in NIST 800-38A (TBD).

Table A-6 (U) HAIPE Algorithms

Notes 

2. Max rate assumes HAIPE used only for terminal net management and remote control. Baseband HAIPE rates are specified separately.

3. Max rate taken from Raytheon HC3 study security architecture report.

4. Assume 256 bit key size.

5. Max rate computed assuming 200 Kbps aggregate stream, median packet size of 500 bytes, and 512 bit hash length.

6. Must support all modes defined in NIST 800-38A (TBD).

Table A-7 (U) IPSec Algorithms 

Notes 

2. Max rate estimated based on router convergence after TSAT logon. Assumes 150 route updates, max 4096 bytes per update, and 10s for convergence. All are conservative to estimate worst case data rate.

3. Assume 256 bit key size.

4. Max rate taken from Raytheon HC3 study security architecture report.

5. Uses same max rate as estimated in [1] because it is a similar application.

6. Must support all modes defined in NIST 800-38A (TBD).

(U) The POET ACM must support the following algorithms for key management. The key management algorithms are assumed to be simultaneous with any waveform, but do not have a maximum data rate.  

Table A-8 (U) Key Management Algorithms 

Notes 

2. Required for EKMS compatibility.

3. Required for HAIPE interoperability.

4. Required for KMI compatibility.

5. Required for AEHF key management.

6. Assume that this is required for ECU-to-ECU FIREFLY key agreement (TBD).

7. Required for IPSec interoperability.

8. Required for foreign releasable KMI compatibility.

9. Assume 256 bit key size.

(U) The POET ACM must support the following algorithms for general use. The key management algorithms are assumed to be simultaneous with any waveform, but do not have a maximum data rate.  

Table A-9 (U) Terminal Utility Algorithms 

Notes 

2. Max rate assumes 100 Mb file encrypted or decrypted in 0.5s (TBD).

3. Assume 256 bit key size.

Table A-10 (U) Baseband COMSEC 

(U) The POET ACM must support the following asymmetric key encryption algorithms.  

Table A-11 (U) Asymmetric Encryption Algorithms 

Notes 

2. Required for KMI compatibility (TBD). Assume that a Type 1 asymmetric algorithm will be available in the KMI CI-3 timeframe.

3. Required for IPSec interoperability.

4. Required for DoD PKI compatibility.

5. A schedule for the LANTERN algorithm is not yet available.

(U) The POET ACM must support the following algorithms. 

Table A-12 (U) Other Algorithms 

Notes 

2. Performance is tied to terminal startup timeline. Performance is derived as decrypting a 20 Mb file in 0.5 s.

3. APPENDIX B:  HAIPE IS REQUIREMENT ALLOCATION

(U) The following table presents the allocation of the HAIPE IS 3.0 requirements to the POET ACM, portions of the platform other than the ACM, or to both.  Notes are provided as necessary to provide additional detail or justification. This table is provided for reference purposed only. 

Table B-1 (U) HAIPE IS REQUIREMENT ALLOCATION