19 August 2006
Errata in Google conversion of DOC to HTML.
|
(U) TECHNICAL
REPORT
(U) REQUIREMENTS
DESCRIPTION
FOR
AN
ADVANCED CRYPTOGRAPHIC MODULE
(ACM)
TO SUPPORT
THE
HIGH CAPACITY COMMUNICATIONS CAPABILITY
(HC3)
(U) This document supports a requirements
definition activity to specify an Advanced Cryptographic Module (ACM) for
embedment future terminals such as the High Capacity Communications Capability
(HC3) terminal. Requirements statements in this document may be used, modified,
or discarded during a subsequent requirements definition activities in which
requirements from other sources will be
synthesized.
(U) Document No. 1041021, Rev. 002
October 18,
2005
(U) Contract DAAB07-03-D-B012, Task
Order #0056(A), Solicitation #CR-1021
(U) Prepared by ViaSat, Inc. under subcontract to:
VSE CORPORATION
Cage Code 31902
2550 Huntington Avenue
Alexandria, VA 22303
(U) Prepared for:
Cryptographic Modernization Project Management Office
ATTN: AMSRD-CER-ST-IA-CM (Mr. Bob Chu)
BLDG 2700 Myer Center
Fort Monmouth, NJ
07703
DOCUMENT DISTRIBUTION RESTRICTIONS:
Releasability:
This document contains information exempt from mandatory disclosure under
the Freedom of Information Act (FOIA), exemptions apply. This document is
Not Releasable to the Defense Technical Information Center (DTIC) per DOD
Directive 5100-38.
Unclassified FOUO
Information: The document contains unclassified For Official Use
Only information which is for the exclusive use of Government and Contractor
personnel with a need-to-know the information. Such information is specifically
prohibited from posting on unrestricted bulletin boards or other unlimited
access
applications.
(U) Revision History
| Rev. |
Date |
Description of Change |
Affected Pages |
| 001 | 10/3/05 | Initial Release | All |
| 002 | 10/18/05 | Removed “PROPIN†from footers in document. | All |
(U) TABLE OF CONTENTS
Section Page
(U) List of Figures
Section Page
(U) List of Tables
Section Page
(U) The purpose of this document is
to provide a stand-alone requirements description for the specification and
development of an Advanced-High-Speed-Embeddable Cryptographic Module (ACM).
(U) The ACM is a re-programmable,
embeddable cryptographic module that provides cryptographic services for
future terminals such as the High Capacity Communications Capability (HC3)
terminal.
(U) This document is intended to support the requirements definition and specification of an Advanced Cryptographic Module (ACM). Requirements statements in this document may be used, modified, or discarded during a subsequent requirements definition activity in which requirements from other sources may be synthesized.
(U) The system context and need for an ACM are identified in Section 1.2.1. Key terminology needed to specify the ACM is identified in Section 1.2.2. A notional ACM is identified in Section 1.2.3.
(U) Future terminals, such as the High
Capacity Communications Capability (HC3) terminal, 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 INFOSEC requirements.
(U) These future terminals are envisioned to be capable of operating with both military and commercial satellite communications systems having RF frequencies above 2 GHz and envisioned to be operational beginning in the year 2010. These systems include but are not limited to the following:
(U) In addition, these future terminals
are also envisioned to be capable of operating with high-capacity line-of-sight
(LOS) communications systems that utilize CDL/NCDL links or future variations
or follow-on systems thereof.
(U) Because the family of systems will
operate with many legacy waveforms currently used by military and civilian
agencies, and will incorporate new waveforms as they are developed, the
cryptographic components of these systems will need to be programmable and
scaleable to meet the specific user operational needs. The desire is that
these systems will incorporate flexibility through an architecture that enables
technology insertion via re-programmability or other means. These future
terminal architectures will be capable of high data throughput rates per
channel; incremental channel expansion; high levels of reliability, availability,
and maintainability; technological enhancement; commercial support service
capability, and lower life cycle costs due to their flexibility and
re-programmability.
(U) Flexibility in the ACM is of great
importance 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 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 and modularity
of design and architecture are necessary for the ACM.
(U) It is also anticipated that the ACM design will be driven by a core set of INFOSEC requirements that must be satisfied by all of these future terminal applications. A notional future terminal architecture, with embedded ACM, is depicted in Figure 1-1. Future terminals with an embedded ACM will:
Figure 1-1. (U) Notional Terminal Block Diagram
UNCLASSIFIED//FOUO
UNCLASSIFIED//FOUO
(U) The process of translating Plaintext
into Ciphertext is known as encryption, and the corresponding process of
translating Ciphertext into Plaintext is known as decryption. The Encrypt/Decrypt
processes are usually accomplished using a protected key and a cryptographic
algorithm.
(U) Plaintext refers to data entering
into a COMSEC encryption process or emerging from a COMSEC decryption process.
Figure
1-2 shows the relationship
between plaintext and ciphertext as well as red and black interfaces when
two distinct encryption processes (COMSEC and TRANSEC) are performed
sequentially.
Figure 1-2. (U) COMSEC and TRANSEC Terminology
UNCLASSIFIED//FOUO
UNCLASSIFIED//FOUO
(U) In
Figure
1-2, notice that the plaintext
is encrypted twice (i.e., COMSEC and TRANSEC processing) whereas
“OTHER Data†is encrypted once (TRANSEC
processing only).
(U//FOUO) The term “RED data†is often used to refer to plaintext data. However, when data is doubly encrypted the usage becomes confusing. For example, the input to a TRANSEC Encrypt function has already been HAIPE encrypted and it consists of Ciphertext data along with an unencrypted IP header that needs to be TRANSEC encrypted for Radio Frequency (RF) transmissions. The term “BLACK data†is often used to refer to ciphertext data; however HAIPE IS uses the somewhat confusing terminology “BLACK header†to refer to an unencrypted IP header.
(U) The concept of a BLACK terminal is implied by the concept of a BLACK network core. The term BLACK terminal implies a terminal with the following attributes:
(U) COMSEC is an acronym for
“Communications Security.†It generally
includes security mechanisms that provide high assurance that the information
is protected while the data is “in
transit.†For example, prior to data transit via a
telecommunications system, information is COMSEC-protected which makes the
data unintelligible to potential unauthorized interceptors. Subsequent to
data in transit via a telecommunications system, the information can be converted
back to its original form only by intended recipients of the COMSEC-protected
information with high assurance.
(U) The process for COMSEC protection of information for “data in transit†applications typically involves encryption of plaintext from 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 is an acronym for
“Transmission Security.†TRANSEC typically
involves a number of measures to protect electronic emanations and radio
frequency (RF) transmissions. TRANSEC usually provides hop-by-hop link
protection, whereas, COMSEC usually provides end-to-end protection. TRANSEC
may provide antijam, LPI, LPE, TFS and as a last resort it may provide
confidentiality.
(U) TRANSEC methods protect transmissions from interception and exploitation by means other than crypto-analysis. TRANSEC employ low probability of intercept (LPI) techniques, frequency hopping, spread spectrum transmission and the use of highly directional antennae, etc. One purposes of TRANSEC is to randomize data such that there is no apparent change of activity on a circuit/transmission; i.e., it cannot be determined when a circuit is busy (in use) or not. In this regard, TRANSEC methods provide a measure of “Operational Security†(OPSEC). In addition, TRANSEC can be used to protect BLACK routers, which are vulnerable to the threats that may cause denial of service.
(U) TRANSEC keystreams are used for
various functions in a modem/transceiver to protected transmissions. Typically,
the TRANSEC keystream is a pseudo-random bit stream used in conjunction with
spread spectrum waveforms that employ direct-sequence and/or frequency hopping
techniques to provide communications with anti-jam, low-probability of intercept,
low-probability of detection, and/or low-probability of exploitation (LPI,
LPD, LPE) characteristics. The TRANSEC keystreams are generated by the
cryptographic module in response to specific requests. The TRANSEC keystreams
are typically outputs only. For example, a TRANSEC keystream is needed for
both outbound (e.g., uplink) and inbound (e.g., downlink) data; in both of
these cases, a TRANSEC sequence is an output of the cryptographic module
to be used by an RF modem with TRANSEC functionality associated with that
TRANSEC keystream.
(U) A TRANSEC keystream generator could be used in conjunction with an exclusive-OR function on a data bit stream in a sequential manner (i.e., prior to the modem functions when transmitting and subsequent to the modem functions when receiving).
(U) The “TRANSEC encrypt/decrypt†function is sometimes referred to as a “cover/de-cover†function or operation. The TRANSEC encrypt/decrypt function operates on the BLACK side of a cryptographic module. TRANSEC encrypted/decrypted data may use a common, bi-directional BLACK side interface. One application of this function is to encrypt the IP packet headers prior to transmission on an RF link so as to prevent traffic-flow analysis by an adversary and also to prevent denial of service attacks by an adversary. To accomplish the TRANSEC encrypt/decrypt function, an internal keystream generator may be employed using either a serial or block algorithm.
(U) Bulk Encrypt/Decrypt refers to the encryption/decryption function applied to a multiplexed data interface. Requests for Bulk Encryption are received from the RED side of the cryptographic module, for which the response is sent to the BLACK side. Requests for Bulk Decrypt are received from the BLACK side of the cryptographic module, for which the response is sent to the RED side.
(U) HAIPE Encrypt/Decrypt is a COMSEC function that is used for providing High Assurance Type 1 protection for IP data between two end nodes.
(U)
Figure
1-3 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 because candidate platforms and
applications are expected to evolve.
Figure 1-3. (U) Notional Advanced Cryptographic Module (ACM)
UNCLASSIFIED//FOUO
(U) The ACM provides the following major capabilities:
(U) The ACM provides the following functional external interfaces:
Table 2-1. (U) Program-Specific Documents
UNCLASSIFIED//FOUO
| Doc ID | Name | Classification |
| CR-1021 | CR2P Performance Work Statement (PWS) 05 April 2005 | None |
| CDRL A001 | HC3 Study Modular Architecture Report, Raytheon Company, July 2004 | None |
| CDRL A005-2 | HC3 Study Security Architecture Report, Raytheon Company, 29 March 2005 | None |
| CDRL A001 | HC3 Study Modular Architecture Report, The Boeing Company, 01 October 2004 | None |
| CDRL A005 | HC3 Study Security Architecture Report, The Boeing Company, 01 August 2005 | None |
UNCLASSIFIED//FOUO
Table 2-2. (U) Government Documents
UNCLASSIFIED//FOUO
| Doc ID | Name | Classification |
| JROCM 134-01 | Capstone Requirements Document Global Information Grid | |
| DoD Directive 8500.1 | Information Assurance | |
| NSA 03-01A | Cryptographic Interoperability Specification for Link Encryptor Family (LEF) Equipment Version 2.0 | (U//FOUO) |
| JTRS 5000-SEC | Security Supplement to the Software Communications Architecture Specification V2.2.1 | (U) |
| EKMS 308
Rev. D |
EKMS Data Tagging and Delivery Standard, | (U//FOUO) |
| EKMS 217
Rev G |
EMKS Benign Techniques Specification | (U//FOUO) |
| EKMS 317 | Generic Fill Format Specification, EKMS Phase 4 Baseline | (U//FOUO) |
| Programmability Design Guidance for Crypto Modernization, Version 4.0, 17 November 2003 | (U//FOUO) | |
| Using CMS to Protect Firmware Packages: Algorithms for use with Type 1 Cryptographic Modules, Draft 0.4 September 2003 | (U//FOUO) | |
| Trust Anchor Management Protocol (TAMP), Draft 0.8, 13 October 2003 | (U//FOUO) | |
| Trust Anchor Management Protocol (TAMP): Algorithms for use with Type 1 Cryptographic Modules, Draft 0.0, August 2003 | (U//FOUO) | |
| KMI 3001 | Electronic Serial Number Standard, Draft 0.7, 23 October 2003 | (U//FOUO) |
| Certificate and CRL Profiles for Use by End Crypto Units (ECUs) Version 0.92, 14 October 2003 | (U//FOUO) |
UNCLASSIFIED//FOUO
Table 2-3. (U) Specification, Standards, or Handbooks
UNCLASSIFIED//FOUO
| Doc ID | Name | Classification |
| FIPS Pub 186 | Digital Signature Standard, 19 May 1994 | None |
| FIPS Pub 180-1 | Secure Hash Standard, 17 April 1995 | None |
| FIPS Pub 180-2 | Secure Hash Standard, 1 August 2002 | None |
UNCLASSIFIED//FOUO
Table 2-4. (U) Standards
UNCLASSIFIED//FOUO
| Doc ID | Name | Classification |
| RFC4109 | Algorithms for Internet Key Exchange version 1, P. Hoffman, May 2005 | None |
| RFC4108 | Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages , Rich Housley, August 2005 | None |
| ANSI X9.62-1998 | Public Key Cryptography For the Financial Services Industry: The Elliptical Curve Digital Signature Standard (ECDSA), January 7, 1999 | None |
| RFC3369 | Cryptographic Message Syntax (CMS), August 2002 | None |
UNCLASSIFIED//FOUO
(U) The ACM requirements are primarily
categorized into the following areas:
(U) At the current stage of requirements
definition, the most relevant requirements are functional and/or key performance
requirements, external interfaces (relative to the ACM) and ACM reserves
capacity for future expansion (processor and memory). Therefore, the requirements
provided are focused in these areas.
(U) As the ACM applications are further
defined, it is expected that additional requirements will result from analysis
and flow down of requirements from the systems and subsystem levels. Some
requirements may differ from one family of terminal to another. Therefore,
it is assumed that more detailed implementation requirements will be available
at a future date as the analysis of host terminals evolves. Evolving terminal
requirements will specify physical characteristics, environmental conditions,
thermal characteristics, maintainability, reliability, concept of operations
that will define the human interactions associated with configuring and operating
the future terminals. Although this document makes an attempt to include
requirements statements with sufficient generality to encompass likely future
requirements, many specific parameters are not yet identified, e.g., the
specific temperature ranges over which the ACM shall perform (either while
in storage or while operating) are not yet included.
(U) Additional security requirements will be levied on the ACM from a Tailored Unified INFOSEC Criteria (TUIC) for future terminal(s), such as HC3
(U) The ACM functional requirements can be categorized based on following capabilities:
(U) The ACM shall be capable of
simultaneously providing TRANSEC Keystream and TRANSEC Encrypt/Decrypt functions
for up to four independent configurable waveforms having a maximum aggregate
rate of (2 Gbps, threshold; 10 Gbps, objective).
(U) The ACM shall be capable of providing
TRANSEC Keystream and TRANSEC Encrypt/Decrypt functions for any single
configurable waveform having a maximum rate of (1 Gbps, threshold; 5 Gbps,
objective).
(U) The ACM shall be capable of
simultaneously providing HAIPE IS V3.0 for four independent interfaces, each
with a maximum full-duplex data rate of (200 Kbps, threshold; 250 Kbps,
objective) and an overall maximum full-duplex aggregate data rate of (800
Kbps, threshold; 1 Mbps, objective).
(U) The ACM shall provide HAIPE IS
V3.0 encryption/decryption for IPv4.
(U) The ACM shall provide HAIPE IS
V3.0 encryption/decryption for IPv6.
(U) The ACM shall be capable of supporting
controlled bypass for pre-defined terminal management messages, based on
a pre-defined security filter policy.
(U) The ACM shall meet the applicable
requirements of the Security Supplement to the Software Communications
Architecture (SCA).
(U) The ACM shall meet the requirements
of the Tailored UIC for any terminal within which an ACM is
embedded.
(U) The ACM shall be capable of being software/firmware upgraded and reconfigured without the need to be returned to the factory, depot, or KLIF.
(U) The ACM shall be capable of supporting
the simultaneity requirements for the terminal waveforms (Table is TBD by
the HC3 Program Management Office (PMO)).
(U) The following sub-sections detail the ACM requirements for waveform specific capabilities and needs.
(U)
The ACM shall be capable of simultaneously supporting the cryptographic
algorithms, modes, TRANSEC keystream rates, and TRANSEC Encrypt/Decrypt rates
as identified in
Table
3-1. (U) AEHF Waveform
Requirements.
Table
3-1. (U) AEHF Waveform Requirements
| Algorithm | Mode | Waveform data rate |
TRANSEC
Keystream rate |
TRANSEC
Encrypt/ |
Simplex/ Duplex |
| MEDLEY | Secret | 1 Mbps | TBD | TBD | Duplex |
| SHILLELAGH | Secret | 1 Mbps | TBD | TBD | Duplex |
| BATON | Secret | 1 Mbps | TBD | TBD | Duplex |
| KEESEE | Secret | 1 Mbps | TBD | TBD | Duplex |
UNCLASSIFIED//FOUO
(U) The ACM shall be capable of
simultaneously supporting the cryptographic algorithms, modes, TRANSEC keystream
rates, and TRANSEC Encrypt/Decrypt rates as identified in
Table
3-2. (U) GBS Waveform
Requirements.
Table 3-2. (U) GBS Waveform Requirements
UNCLASSIFIED//FOUO
| Algorithm | Mode | Waveform data rate |
TRANSEC
Keystream rate |
TRANSEC
Encrypt/ |
Simplex/ Duplex |
| TBD | Classified | 24 Mbps | TBD | TBD | Simplex |
(U) The ACM shall be capable of
simultaneously supporting the cryptographic algorithms, modes, TRANSEC keystream
rates, and TRANSEC Encrypt/Decrypt rates as identified in
Table
3-3. (U) WGS Waveform
Requirements.
Table 3-3. (U) WGS Waveform Requirements
UNCLASSIFIED//FOUO
| Algorithm | Mode | Waveform data rate |
TRANSEC
Keystream rate |
TRANSEC
Encrypt/ |
Simplex/ Duplex |
| TBD | TBD | TBD | TBD | TBD | TBD |
UNCLASSIFIED//FOUO
(U//FOUO)
Figure
3-1 depicts the communications
processing needed for legacy CDL links. Legacy CDL communications require
link control information to be exchanged end-to-end via encrypted transmissions
in order to securely aid in signal acquisition as well as to maintain directional
links with moving platforms. Legacy CDL waveforms exchange link control
information by multiplexing it together with other data (which may or may
not have its own encryption protection).
Figure 3-1. (U) Legacy CDL Processing
UNCLASSIFIED//FOUO
UNCLASSIFIED//FOUO
(U) The ACM shall perform legacy CDL
encryption/decryption for all CDL control information along with the user
data.
(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 CDL waveform data rate to allow
for Bulk decrypted data from RED side to the Black side.
(U) The ACM shall be capable of
simultaneously supporting the cryptographic algorithms, modes, keystream
rates, and BULK Encrypt/Decrypt rates as identified in
Table
3-4. (U) CDL Waveform
Requirements.
Table 3-4. (U) CDL Waveform Requirements
UNCLASSIFIED//FOUO
| Algorithm | Mode | Waveform data rate |
Bulk
Encrypt/Decrypt
rate |
TRANSEC
Keystream rates |
Simplex/ Duplex |
| CDL1
(TBD) KGV-135 A |
Classified | 274 Mbps | 10 Mbps/274 Mbps | TBD | Duplex |
| CDL2 (TBD) | Classified | 274 Mbps | 10 Mbps/274 Mbps | TBD | Duplex |
UNCLASSIFIED//FOUO
(U) The ACM shall be capable of
simultaneously supporting the cryptographic algorithms, modes, TRANSEC keystream
rates, and TRANSEC Encrypt/Decrypt rates as identified in
Table
3-5. (U) X, Ku, Ka Band Waveform
Requirements.
Table 3-5. (U) X, Ku, Ka Band Waveform Requirements
UNCLASSIFIED//FOUO
| Algorithm | Mode | Waveform data rate |
Bulk
Encrypt/
Decrypt rate |
TRANSEC
Encrypt/ |
Simplex/ Duplex |
| WALBURN | Classified | 51.84 Mbps | 51.84 Mbps | TBD | Duplex |
| AES | ECB | 153.6 Kbps | 153.6 Kbps | TBD | Duplex |
| AES | CBC | 24.576 Mbps | N/A | TBD | Duplex |
| TBD | Classified | 100 Mbps | N/A | TBD | Duplex |
UNCLASSIFIED//FOUO
(U) In addition to TRANSEC functions,
TSAT waveform requires IPsec support for its network and control
planes.
(U) The ACM shall support security
downgrade function when passing TSAT control data from RED to Black
side.
(U) The ACM shall support select
cryptographic algorithms for the IPsec protocol for TSAT control/management
data.
(U) The ACM shall be capable of
simultaneously supporting the cryptographic algorithms, modes, TRANSEC keystream
rates, and TRANSEC Encrypt/Decrypt rates as identified in
Table
3-6. (U) TSAT Waveform
Requirements.
Table 3-6. (U) TSAT Waveform Requirements
UNCLASSIFIED//FOUO
| Algorithm | Mode | Waveform data rate |
TRANSEC
Keystream rate |
TRANSEC
Encrypt/ |
Simplex/ Duplex |
| MEDLEY | Secret | 1 Mbps | TBD | TBD | Duplex |
| SHILLELAGH | Secret | 1 Mbps | TBD | TBD | Duplex |
| BATON | Secret | 1 Mbps | TBD | TBD | Duplex |
| AES | TBD | 2 Mbps | TBD | TBD | Duplex |
| AES | Counter | 150 Mbps | TBD | TBD | Simplex |
| AES | Counter | 450 Mbps | TBD | TBD | Simplex |
UNCLASSIFIED//FOUO
(U) The ACM shall provide domain separation
to support Multiple Single Levels of Security (MSLS) from unclassified to
Secret Level for TRANSEC functions for four independent
waveforms.
(U) The ACM shall provide domain separation
to support Multiple Single Levels of Security (MSLS) from unclassified to
Secret Level for the four independent Red interfaces.
(U) The ACM shall support a single level Top Secret/Sensitive Compartmented Information (TS/SCI) in a system-high configuration.
(U) The HC3 terminal may require a
flexible network management architecture that supports terminal management
from multiple security domains including user network management networks
like WIN-T Network Management System (NMS) or waveform network management
like TCM NMS. To provide the flexible support, the ACM provides low bandwidth
HAIPE to support secure connectivity to multiple NMS.
(U) Refer to
Figure
3-2, in relation to potential
centralized management of terminals with embedded ACM. Because each Network
Management System (NMS) may be at a different classification level, the ACM
will be required to provide domain separation between the each of the RED
interfaces.
Figure
3-2. (U) Network Management View of ACM
UNCLASSIFIED//FOUO
(U) The ACM shall support a minimum
of four (4) HAIPE separate tunnels for each of the separate network management
systems.
(U) The ACM shall provide the security domain separation for the RED data over the HAIPE tunnels based on the security policy.
(U) Unattended operation requires that
the ACM be activated using a physical token and/or pass phrase and remain
activated when the token is removed. This implies that the use of a Cryptographic
Ignition Key (CIK) is not a viable option for the ACM. The use of Cryptographic
Recovery Key (CRK) is an option. However, there are still issues related
to remote re-activation of the terminal.
(U) Unattended operation also requires
a robust anti-tamper mechanism and ability to perform remote zeroization
of the ACM. Over the Air Zeroize (OTAZ) and Over the Air Rekeying are some
mechanisms that provide the means for unattended operation if supported by
the operating waveform.
(U) The ACM shall be capable of supporting
the use of CRK 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, when available.
(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 may be implemented using
General Purpose Processor (GPP), Field Programmable Gate Arrays (FPGA) and/or
Application Specific Integrated Circuits (ASIC). In order to support
Cryptographic Modernization Initiatives, it is recommended that the ACM be
completely reprogrammable in order to support algorithms and cryptographic
services required by future waveforms. An FPGA implementation allows for
new and updated algorithms to be installed without hardware
upgrade.
(U) The ACM shall provide field upgrade
and reprogramming of the Cryptographic Software/Firmware.
(U) The ACM shall support the cryptographic
requirements for Link Encryptor Family LEF 2.0.
(U) The ACM shall be capable of supporting
future Key Management Infrastructure (KMI) standards.
(U) The ACM shall be capable of supporting
a unique Electronic Serial Number as required by the evolving KMI 3001
standard.
(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 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.
(U) The ACM shall be capable of supporting
the cryptographic algorithms for the evolving standards of the Trust Anchor
Management Protocol for use with Type 1 Cryptographic
Modules.
(U) The ACM shall support Type 1 Suite
B algorithms required for foreign interoperability, when
required.
(U) The ACM shall provide TBD design margin reserve capacity to accommodate new cryptographic algorithms and services for alternate/future waveforms.
(U) If the ACM is built using an FPGA,
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 is built using an ASIC,
the following requirements are applicable:
(U//FOUO) The ASIC shall be fabricated
in foundries approved for classified processing.
(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).
(U) The goals established by the Software
Communication Architecture (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 HC3 terminal that use Common Object
Request Broker Architecture (CORBA), which is considered to provide a low
levels of assurance.
(U) SCA is not directly applicable to the ACM. The ACM can use a custom implementation that provides the necessary high assurance with appropriate software adaptors available on both RED and Black side Processors.
(U) The Security Supplement to the
SCA is applicable to the ACM. The SCA Security Supplement does not address
a lot of issues associated with system boot, synchronization and termination.
Also, for high speed TRANSEC rates, it is foreseeable that the existing SCA
model of software processing may be a potential
bottleneck.
(U) The ACM architecture shall provide
a standard control interface for cryptographic control of the ACM software
in order to enhance extensibility and technology
insertion.
(U) The ACM shall provide a set of
primitives as software adaptor that is open and
non-proprietary.
(U) The ACM primitives shall be compliant
with the SCA Security Supplement.
(U) The ACM shall define primitives
required to facilitate the high speed TRANSEC functions required for the
HC3 waveforms.
(U) The ACM primitives for a specific implementation shall be documented in the ACM Embedment Manual.
(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).
(U) The ACM needs some level of operator
configuration and an operator interface in order to allow field configuration
of the ACM. The following interfaces are subject to operator
interaction:
(U) The Startup is composed of boot and function initialization of the ACM. The run-time involves stability during actual operations. Terminations may either be normal teardown of functions, or abnormal termination due to some type of error or failure.
(U) The ACM shall perform validity
checks of data stored in non-volatile memory.
(U) The ACM shall instantiate the
cryptographic algorithm decryption capability.
(U) The ACM shall instantiate the key
fill capability.
(U) The ACM shall instantiate the key
decryption capability.
(U) The ACM shall instantiate the
randomization capability.
(U) The ACM shall provide notification
and upon completion of the boot sequence.
(U) The ACM shall disable all the Red
interfaces during the boot process.
(U) The ACM shall be operational within TBD seconds after power on.
(U) The ACM shall provide the capability
to instantiate cryptographic algorithms with different modes/option 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.
(U) The ACM shall be capable of being shutdown within TBD seconds after a receipt of an authorized command to shutdown.
(U) A Cryptographic Channel is a communications path within the cryptographic boundary. Within this communication path, the ACM performs the following operation as allowed by security policy.
(U) The ACM shall sanitize all
message/cryptographic data memory as part of cryptographic channel
instantiation.
(U) The ACM shall validate the
cryptographic algorithm and mode requested for the cryptographic channel
with the security policy, prior to instantiation.
(U) The ACM shall instantiate red keys
as requested on cryptographic channel instantiation.
(U) The ACM shall verify against the
resident security policy that there are no violations in matching classification
levels of algorithms, waveforms, and keys during cryptographic channel
instantiation.
(U) The ACM shall instantiate cryptographic functions for the cryptographic channel within TBD seconds on channel instantiation.
(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.
(U) The ACM shall zeroize Red cryptographic
channel key(s) upon cryptographic channel teardown.
(U) The ACM shall include cryptographic channel teardown completion as audit event.
(U) In the event of internal failure
on a cryptographic channel, the ACM shall execute internal security policy
for termination or suspension of operation on the cryptographic
channel.
(U) The ACM shall provide cryptographic
channel failure status as audit event.
(U) The ACM shall zeroize Red key(s)
for the cryptographic channel upon abnormal termination.
(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.
(U) The ACM shall supports the following types of cryptographic channels
(U) The ACM shall support simultaneous operation of all cryptographic channels for TRANSEC, HAIPE tunnels and Bulk Encryption/Decryption channels.
(U) There are two types TRANSEC Keystream channels associated with any waveform: uplink and downlink channels. There may be multiple uplink and downlink TRANSEC keystreams for different functions like frequency hopping and spread spectrum etc. These TRANSEC keystream rate differs for each waveform ranging from low speed to high speed. In order to allow for extensibility of the ACM and reuse capabilities, it is better for all TRANSEC Keystream channels to use high speed interfaces. These functions are provided by the ACM within the context of a TRANSEC Keystream cryptographic channel.
Figure 3-3. (U)TRANSEC Keystream
Channels
UNCLASSIFIED//FOUO
(U) The ACM shall provide eight (8)
independent TRANSEC Keystream cryptographic channels for up to four waveforms.
(U) The ACM shall support the creation
of a separate TRANSEC Keystream cryptographic channel for an uplink and downlink
for a total of two TRANSEC Keystream cryptographic channels for each
waveform.
(U) The ACM shall provide physical
separation for the uplink and downlink TRANSEC Keystream cryptographic
channel.
(U) The ACM shall instantiate the uplink
and downlink TRANSEC Keystream cryptographic channel on request from the
Cryptographic Control Interface.
(U) The ACM shall teardown the uplink
and downlink TRANSEC cryptographic channel upon receipt of a command within
TBD seconds.
(U) The ACM shall be capable of supporting multiple TRANSEC keystreams with different cryptographic algorithms and keys over the same TRANSEC Keystream cryptographic channel in accordance with the security policy.
(U) The “TRANSEC encrypt/decrypt†function is sometimes referred to as a “cover/de-cover†function or operation. TRANSEC Encrypt/Decrypt functions are requested by the BLACK side of the ACM and the results are returned to the same BLACK side interface on which the requests are received. These functions require the creation of a TRANSEC Encrypt/Decrypt cryptographic channel.
Figure 3-4. (U)TRANSEC Encrypt/Decrypt
Channel
UNCLASSIFIED//FOUO
(U) The ACM shall provide four independent
TRANSEC Encrypt/Decrypt cryptographic channels for up to four waveforms.
(U) The ACM shall instantiate TRANSEC
Encrypt/Decrypt cryptographic channel on request from the Cryptographic Control
Interface.
(U) The ACM shall teardown the TRANSEC
Encrypt/Decrypt cryptographic channel upon receipt of a command within TBD
seconds.
(U) The ACM shall be capable of supporting multiple TRANSEC Encrypt/Decrypt functions with different cryptographic algorithms and keys over the same TRANSEC Encrypt/Decrypt cryptographic channel in accordance with the security policy.
(U) The HAIPE tunnels are required
for supporting the low bandwidth connections for the purposes of remote network
management of the ACM. These HAIPE tunnels may be dynamically created or
static based on configuration.
Figure 3-5. (U) HAIPE Encrypt/Decrypt
Channel
UNCLASSIFIED//FOUO
(U) The ACM shall support HAIPE key
exchange to establish Security Associations upon receipt of a command on
the Cryptographic Control Interface.
(U) The ACM shall establish HAIPE Security
Association cryptographic channels upon completion of HAIPE key
exchange.
(U) The ACM shall establish Pre-Placed
Key (PPK) HAIPE Security Association cryptographic channels upon receipt
of command on the Cryptographic Control Interface.
(U) The ACM shall teardown HAIPE Security Association cryptographic channels upon receipt of a command on the Cryptographic Control Interface within TBD seconds.
(U) The “Bulk
encypt/decrypt†provides a COMSEC function which is primarily
when plaintext control data is multiplexed with ciphertext data. The
Bulk Encypt is requested from a RED side and the results are returned to
BLACK side. The Bulk Decrypt is requested from the BLACK side and the
results are returned to the RED side. These functions require the creation
of a Bulk Encyrpt/Decrypt cryptographic channel.
Figure 3-6. (U) Bulk Encrypt/Decrypt
Channel
UNCLASSIFIED//FOUO
(U) The ACM shall instantiate a Bulk
Encrypt/Decrypt cryptographic channel on request from the Cryptographic Control
Interface.
(U) The ACM shall teardown a Bulk Encrypt/Decrypt cryptographic channel upon receipt of a command within TBD seconds.
(U) Within a cryptographic channel,
the ACM provides a Cryptographic Service referred to by a well defined set
of procedures (primitives/functions) that provides an implementation of the
cryptographic process such as encryption/decryption, key generation or
authentication. These services within the context of a cryptographic channel
are referred to as Channel Cryptographic Services.
(U) The Channel Cryptographic Services are broken down into the following:
(U) TRANSEC keystreams are generated
within a TRANSEC Keystream cryptographic channel. The TRANSEC keystream may
be a continuous stream of bits or a periodic sequence or on a request by
the waveform
(U) The ACM shall support the independent
request for uplink and downlink TRANSEC key streams.
(U) The ACM shall generate uplink TRANSEC
keystream over the uplink physical interface for the
waveform.
(U) The ACM shall generate downlink
TRANSEC keystream over the downlink physical interface for the waveform.
(U) When applicable (e.g., some algorithms
require TOD for crypto sync), the ACM shall use time-of-day (TOD) functions
for keystream generation.
(U) When applicable, the ACM shall
synchronize clock for keystream generation.
(U) The ACM shall embed the following cryptographic TRANSEC algorithms:
(U) TRANSEC Encrypt/Decrypt services
are used within a TRANSEC Encrypt/Decrypt cryptographic channel. The request
for TRANSEC Encrypt/Decrypt is received from BLACK side and the response
is returned over the same interface.
(U) The ACM shall support the TRANSEC
Encrypt request from the BLACK side interface and return response on the
same interface.
(U) The ACM shall support the TRANSEC
Decrypt request from the BLACK side interface and return response on the
same interface.
(U) When applicable, the ACM shall
use time-of-day (TOD) functions for TRANSEC
Encryption/Decryption.
(U) When applicable, the ACM shall
synchronize clock for TRANSEC Encryption/Decryption.
(U) The ACM shall perform the TRANSEC
Encryption/Decryption as specified in the Tailored UIC for the HC3
terminal.
(U) The ACM shall embed the following cryptographic TRANSEC algorithms:
(U) The ACM shall embed the following cryptographic HAIPE encryption/decryption algorithms for the protection of classified network management information:
(U) The ACM shall provide the following
max throughput for each of HAIPE encryption algorithm per cryptographic channel
as identified in
Table
3-7.
Table 3-7 (U) HAIPE Cryptographic Channel Rates
| UNCLASSIFIED | ||
| Algorithm | Mode | Data rate |
| MEDLEY | Long Cycle | 200 Kbps |
| BATON | Long Cycle | 200 Kbps |
| AES | TBD | 200 Kbps |
| WEASEL | Classified | 64 kbps |
| UNCLASSIFIED | ||
(U) The ACM shall embed the following Bulk Encryption/Decryption cryptographic algorithms:
(U) The ACM shall support the following Type 1 cryptographic services:
(U) The ACM shall provide hardware acceleration to aid in the Firefly specification and Enhanced Firefly specification.
(U) The ACM shall support the following Suite B algorithms:
(U) The TSAT waveform may use Non Type 1 IPsec for link control and network management control planes. The ACM is required to support some of cryptographic algorithms that IPsec used for HAIPE Foreign Interoperability. The following are additional requirements for the ACM to support IPsec that should not impose additional SWAP requirements and impede NSA UIC Certification.
(U) The ACM shall support the generation
of Public/Private key pairs for DoD PKI Certificates when commanded from
the Cryptographic Control Interface.
(U) The ACM shall retain the Private
key and wrap it for storage within the cryptographic
boundary.
(U) The ACM shall support the export
of the Public key over the Cryptographic Control
Interface.
(U) The ACM shall allow the loading
of DoD PKI Certificates over the Cryptographic Control
Interface.
(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.
(U) The ACM shall support encryption/decryption for IPsec using the following algorithms and modes:
(U) The ACM shall support the following Pseudo-random functions:
(U) The ACM shall support the following integrity algorithms:
(U) The ACM shall support the calculation of the Diffie-Hellman shared secret for IPsec key exchange for the following modes:
(U) The ACM shall cryptographically
authenticate the identity of the signatory of BLACK
messages.
(U) The ACM shall cryptographically
authenticate the identity of the signatory of RED
messages.
(U) The ACM shall return results of
cryptographic authentication processing.
(U) The ACM shall provide for the following
Digital Signature Standard (DSS) cryptographic processing (DSA, RSA [ANSI
X9.31], or ECDSA [ANSI X9.62]).
(U) The ACM shall generate DSS authentication messages.
(U) The ACM shall cryptographically
validate the integrity of the data of BLACK messages.
(U) The ACM shall cryptographically
validate the integrity of the data of RED messages.
(U) The ACM shall return results of
integrity processing.
(U) The ACM shall provide Secure Hash
Algorithm (SHA-1) processing.
(U) The ACM shall generate SHA-1 based
integrity checks.
(U) The ACM shall generate standard integrity checks [e.g., parity, cyclic redundancy check (CRC)] for data.
(U) HC3 terminal is considered a BLACK
terminal. All the keys filled in the operational field are expected to be
in BLACK form for both System and waveform keys. However, to support Black
key fill, some Red System keys (Trust Anchors Certificates, Key Encryption
Keys, EFF, FF keys etc) are required to allow for Black fill or Benign Fill.
The Red key fill may be performed in a protected facility like a Key Loading
and Initialization Facility (KLIF). These Red keys loaded on the ACM may
be protected using a CRK like mechanism.
(U) Key Management Function is broken down into the following subfunctions:
(U) The ACM shall provide DS-101 key
fill interface to support key fill.
(U) The ACM shall be capable of performing
key fill when fully powered.
(U) The ACM shall perform DS-101 protocol
in accordance with EKMS 308D.
(U) The ACM shall accept BLACK and
RED keys using the DS-101 protocol.
(U) The ACM shall support the disable
the capability to load RED keys through software
configuration.
(U) The ACM shall accept keys with
DS-100-1 key tag information in accordance with EKMS 308.
(U) The ACM shall accept keys with
any newly developed key tag format for the HC3 terminals.
(U) The ACM shall be capable of binding
key tagging and ID information to a key.
(U) The ACM shall provide positive
confirmation following each successful load.
(U) The ACM shall provide indication
in the event of key loading failure.
(U) The ACM shall provide capability
to output the key associations and key classification information to the
Cryptographic Control Interface.
(U) The ACM shall use Tamper detection keys.
(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 the use of
multiple Key Encryption Keys (KEK) to support Black key
fill.
(U) The ACM shall generate keys via Firefly processing for Benign Fill.
(U) The ACM shall store RED keys in
working registers and memory within the cryptographic
boundary.
(U) The ACM shall provide TBD MB of
working memory of keys including the information that is bound to the key
(i.e. key tag, effective date, etc). The term key refers to RED TEK, KEK,
Firefly Vectors and TSK keys.
(U) The ACM shall store persistent
keys in BLACK form.
(U) The ACM shall provide TBD MB of
persistent storage for File Encryption Keys (FEK), Other System keys, KEK,
TEK, TRANSEC Keys and Firefly Vectors including the information that is bound
to the key (i.e. key tag, KEK key tag, effective date,
etc).
(U) The ACM shall bind keys to their
respective identification information in storage.
(U) The ACM shall provide a key rollover
function when provided with date and time.
(U) The ACM shall encrypt all keying
material for storage using ACCORDION for US only missions. (Also, see Foreign
Interoperability).
(U) The ACM shall encrypt updated keys
for storage.
(U) The ACM shall provide update function
as required by embedded cryptographic algorithms.
(U) The ACM shall provide a key update using ACCORDION for US only missions. (Also, see Foreign Interoperability).
(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 KGV-11 key with a KGV-11 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
(U) The ACM shall test the keys for
integrity at instantiation.
(U) The ACM shall permit Unclassified keys to be passed outside of the Cryptographic Boundary for specific purposes (e.g. Black Processor or Modem generated TRANSEC) in accordance with the security policies.
(U) The ACM shall provide for the selective
zeroization of keys when commanded on the Cryptographic Control
Interface.
(U) The ACM shall cryptographically
authenticate remote key zeroization commands prior to execution in accordance
with the security policies.
(U) The ACM shall receive,
cryptographically authenticate, and process and respond to Over the Air Zeroize
(OTAZ) messages when required.
(U) The ACM shall zeroize all RED keys
and internal active key splits when an authenticated OTAZ message is
received.
(U) If the authenticated OTAZ message
is limited by design to a specific waveform, ACM shall zeroize the Red keys
associated with the specific waveform.
(U) The ACM shall accept a hardware
discrete Zeroize signal.
(U) The ACM shall, upon detection of
the assertion of the Zeroize hardware discrete line signal, zeroize the RED
keys and internal active key splits.
(U) The ACM zeroization function shall function in all states and modes, with or without prime power or terminal battery backup power.
(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.
(U) The ACM shall support
Over-the-Air-Rekey (OTAR) as required by the configured waveforms for waveform
specific keys.
(U) The ACM shall provide the capability
to cryptographically authenticate OTAR messages.
(U) The ACM shall be capable of providing
notification that an OTAR initiated transaction has
occurred.
(U) The ACM shall provide the capability
to cryptographically authenticate Over-the-Air-Transfer (OTAT) messages as
required by the configured waveforms for waveform specific
keys.
(U) The ACM shall generate keys for
ACM internal use only.
(U) The ACM shall support the generation
of key splits
(U) The ACM shall be capable of providing
notification of a key rollover to the Cryptographic Control
Interface.
(U) The ACM shall be capable of supporting future Over the Network Keying (OTNK) protocols.
(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 provide a Cryptographic
Recovery Key (CRK) Interface.
(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
(U) The ACM shall support the Cryptographic
Suite B for HAIPE IS V3.0 Suite B extension.
(U) The ACM shall encrypt keying material
for storage using AES Key wrap for foreign
interoperability.
(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 the loading
of DoD PKI Certificates.
(U) When required, the ACM shall support the loading of Non Type 1 keys.
(U) The Cryptographic Algorithms are
part of the Cryptographic Software/Firmware of the ACM. The assumption is
that the cryptographic algorithms are not standalone but part of a package
of cryptographic software/firmware encrypted and signed by
NSA.
(U//FOUO) NSA requires that all security-related software/firmware components that will be executed on the ACM at one time shall be bundled together in a single package and evaluated as a unit. A set of algorithms are packaged together based on typical mission requirements. Separate cryptographic algorithm packages may be created for US Only and Foreign Interoperability missions.
(U) The ACM shall decrypt all classified
cryptographic algorithms package using the JOSEKI
algorithm.
(U) The ACM shall only accept cryptographic
algorithm packages signed by NSA.
(U) The ACM shall perform authentication
and integrity checks of received algorithm packages.
(U) The ACM shall report the results
of integrity checks as auditable events.
(U) The ACM shall not accept versions
of a cryptographic algorithm package that are older than the currently installed
version.
(U) The ACM shall maintain the type and version of the cryptographic algorithm package.
(U) The ACM shall store Cryptographic
software/firmware in BLACK form.
(U) The ACM shall have the capability
to store a minimum of (TBD) different Cryptographic software/firmware images
in BLACK form.
(U) The ACM Cryptographic algorithms
and Cryptographic Equipment Modes shall be bound to their version and type
identification in storage.
(U) The ACM shall maintain cryptographic separation between cryptographic algorithm packages and non-security software packages.
(U) The ACM shall have the capability
to maintain at least two versions for each Cryptographic software/firmware
images.
(U) The ACM shall have the capability
to rollback the version of the Cryptographic software/firmware
image.
(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.
(U) A security policy is a set of rules
which are tested for compliance and then enforced by a given security function.
The security policy originates from multiple sources like HC3 terminal and
waveforms. The definition varies based on mission profile. XML may be used
as the format for the security policy definition. XML processing may be performed
outside the ACM boundary within the HC3 terminal or outside the HC3 terminal.
(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
source 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 accept security policy
in binary format.
(U) The ACM shall authenticate the
NSA signature on the security policy.
(U) The ACM shall report any attempted violation of the security policies as audit events.
(U) Cryptographic Bypass Requirements are broken down into the following subfunctions:
(U) The ACM shall perform Traffic Header
bypass in accordance with the Security Policy for the cryptographic
channel.
(U) The ACM shall perform the bypass
function according to the waveform security policy.
(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 close the channel, resulting in termination of the operation of the affected channel.
(U) The ACM control/status bypass
mechanism(s) shall accept bypass policy either on a per application basis
or create a separate bypass mechanism per policy.
(U) The ACM control/status bypass mechanism
shall be distinct from channel control/status bypass
mechanism.
(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 control/status bypass mechanism
shall be provided tamper protection.
(U) The ACM control/status bypass mechanism
shall output all violations of bypass security policy as audit
events.
(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.
(U) The ACM shall authenticate and integrity checks the bypass policy prior to use.
(U) The ACM shall decrypt stored Security
Critical Packages.
(U) The ACM shall encrypt Security
Critical Packages for storage.
(U) The ACM shall perform integrity checks on Security Critical Packages and files prior to instantiation or use.
(U) The ACM as a trusted entity within
an HC3 terminal is expected to provide cryptographic services for ensuring
that other entities within the HC3 terminal are running valid software/firmware.
The following are the requirements for software download and boot services.
The assumption is that software/firmware is downloaded as a package that
is encrypted and signed by a designated authority.
(U) The ACM shall provide decryption
services for software packages (non cryptographic
software/firmware).
(U) The ACM shall provide integrity
checks for the software packages (non cryptographic software/firmware).
(U) The ACM shall provide file encryption/decryption service using a unique File Encryption Key (FEK) for non cryptographic software/firmware images.
(U) The ACM shall accept control messages
from the Cryptographic Control Interface.
(U) The ACM shall accept requests from
the Cryptographic Control Interface.
(U) The ACM shall provide status messages
and alarms to the Cryptographic Control Interface.
(U) The ACM shall enforce a security policy that specifies responses to alarms generated internal to the ACM.
(U) The ACM shall accept a PPS clock
signal.
(U) The ACM shall accept the Time of the Day.
(U) The ACM BIT function can be categorized as follows:
(U) The ACM BIT function shall detect no less than 95 percent of all faults, by failure rate.
(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.
(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.
(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) The ACM shall provide a Health discrete signal and BIT status messages for reporting health status.
(U) The ACM shall report audit events over the Cryptographic Control Interface.
(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 be capable of defaulting to a secure state in the event of a catastrophic failure.
(U) The ACM shall provide Anti-Tamper
and zeroization capabilities.
(U) The ACM Anti-Tamper and zeroization
shall be available in the absence of external power.
NOTE 1: These requirements need further HC3 terminal system analysis and requirements allocation.
(U) The ACM shall include a full duplex
high speed Cryptographic Control Interface.
(U) The ACM shall include eight (8)
high speed synchronous interfaces as the TRANSEC interface to the
Modem/Transceivers.
(U) The ACM shall include four full
duplex high speed Black I/O port interfaces. (This may be a Rapid I/O
interface.)
(U) The ACM shall include four full
duplex high speed Red I/O port interfaces. (This may be a Rapid I/O
interface.)
(U) The ACM shall provide a redundant
Port Disable for each of the Red I/O ports.
(U) The ACM shall include a full duplex
high speed interface for the Cryptographic Control Interface. (This may
be a Rapid I/O interface.)
(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 provide a CRK
interface.
(U) The ACM shall accept a Zeroize
hardware signal.
(U) The ACM shall provide a Health
signal.
(U) The ACM shall receive a RED external
power of TBD VDC. (See Note 1)
(U) The ACM shall receive BLACK external
power of TBD VDC. (See Note 1)
(U) The ACM shall receive RED external battery power.
(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.
(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.
(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 receive power from
the internal battery on the ACM.
(U) The ACM shall have the capability
to report the status of the internal battery.
(U) The ACM shall use the internal
battery power to supply tamper detection and zeroize circuitry, whenever
external power is not available.
(U) The ACM shall provide internal battery with a life of at least TBD years. (See Note 1)
(U) The ACM shall receive a RED external
power of TBD VDC. (See Note 1)
(U) The ACM shall receive BLACK external
power of TBD VDC. (See Note 1)
(U) The ACM shall consume power less
than TBD watts. (See Note 1)
(U) The ACM shall locally generate
any additional internal voltages required.
(U) The ACM shall use external power to supply tamper detection and zeroize circuitry whenever it is available.
(U) The ACM shall not exceed a width
of TBD inches, a length of TBD inches and a height of TBD inches. (See Note
1)
(U) The ACM shall have a maximum weight of TBD pounds. (See Note 1)
(U) The ACM shall operate at a temperature
range of between TBD°C to TBD °C at sea level. (See
Note 1)
(U) The ACM shall operate at altitudes
up to TBD feet above sea level. (See Note 1)
(U) The ACM shall operate when subject
to random vibration IAW TBD. (See Note 1)
(U) The ACM shall operate when subject
to operational shock IAW TBD. (See Note 1)
(U) The ACM shall meet the EMI/EMC
requirements IAW TBD. (See Note 1)
(U) The ACM shall operate when subjected
to a relative humidity of TBD% to TBD%. (See Note 1)
(U) The ACM shall survive exposure
to temperature ranging from TBD°C to TBD°C while
non-operational. (See Note 1)
(U) The ACM shall survive exposure to altitudes up to TBD feet above sea level while non-operational. (See Note 1)
(U) The ACM shall meet the requirements
for thermal design IAW TBD. (See Note 1)
(U) The ACM design shall not rely on
cooling air coming into contact with internal electrical parts, circuitry,
or connectors. (See Note 1)
(U) The ACM shall not require or use internal electrical heaters, fans, blowers, or similar devices unless specifically approved by the Government. (See Note 1)
(U) The ACM shall be designed such that preventive maintenance is not required other than battery replacement. (See Note 1)
(U) The ACM shall have a Mean Time between Failures (MTBF) of TBD hours. (See Note 1)
(U) The ACM as part of the HC3 INFOSEC module shall be fully interchangeable, both mechanically and electrically IAW TBD. (See Note 1)
(U) The ACM workmanship shall be IAW TBD. (See Note 1)
(U) The ACM implementation shall document the software interface/primitives as part of the ACM Embedment Manual.
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
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