11 November 1999. Thanks to RP.
Source:
http://www.clark.net/pub/bonnerk/MSH%20Technical%20Standards%20Validation%20Report.pdf
There are no classification markings on the original: Full 65-page document: http://cryptome.org/msa-tsv.pdf (PDF, 805K)
[Graphic]
Naval Electronic Combat Surveillance Systems
Space and Naval Warfare Systems Command
PMW163
(Version 4)
Prepared By
Space & Naval Warfare Systems Command
PMW 163, OTC-1-1051
4301 Pacific Highway
San Diego, CA 92110-3127
Prepared For
Naval Security Group Command
N6/N9
9800 Savage Road
Fort George G. Meade, MD
[Excerpts from pages 1-15]
DRAFT 10 Feb 99
MARITIME SIGINT ARCHITECTURE
TECHNICAL STANDARDS VALIDATION
REPORT
Executive Summary
The Maritime SIGINT Architecture (MSA) Study Group was formed in April 1997 to determine the feasibility of developing a common technical architecture that would serve the needs of tactical cryptologic systems for the maritime services. The group produced the Maritime Signals Intelligence (SIGINT) Architecture Standards Handbook (MSH), a set of technical standards intended to foster interoperability and commonality among maritime systems. In February 1998 CNO (N20/N64) submitted the MSH to the Force Warfare Systems Engineering Board (FWSEB) Executive Committee and U.S. Special Operations Command (USSOCOM) (PEO C4I) for review and endorsement.
On 22 July 1998, the DON (CIO), Dr. Ann Miller “…endorsed in principle, the recommendation of the final report, thereby clearing the way for a formal department of the Navy (DoN) decision.” However, before submitting it for formal DON Chief Information Officer (CIO) decision, DON (CIO requested “…a program manager to test the recommendations to see if the MSA meets the objectives.” On 29 September 1998, Commander Naval Security Group Command (COMNAVSECGRU) (N6/N9) tasked Space and Naval Warfare (SPAWAR) Systems Command to conduct and MSHA standards and verification againstassessment of the Ship's Signals Exploitation Equipment (SSEE) and Advanced Cryptologic Carry-on Exploitation System (ACCES).
MSH standards and specifications were compared to those being implemented in SSEE/ACCES Increment D(2), the baseline system chosen for this assessment. Seventy-five percent of the MSH requirements that apply to Increment D(2) are being used; the remaining 25% will be evaluated for implementation in future incremental upgrades. This report also contains a number of recommendations for improving the MSH prior to formal approval and implementationwhen it is updated.
The MSH is a comprehensive collection of existing standards and specifications that will enable developers of cryptologic systems to reduce development costs and infuse new technology to increase the capabilities of systems provided to the fleet. Increasingly rapid advancements in technology dictate that the MSH must be a “living” document, assigned a custodian responsible for maintaining and updating it, as required.
DRAFT 10 Feb 99
1.1 - Introduction
Technology continues to change at a very rapid pace. Developing maritime signals intelligence (SIGINT) systems to keep abreast of these changes is a daunting task, given today’s declining defense budget. To maximize the Navy’s Research and &Development dollars, developers must use commercial technology in developing systems to address the complex problems encountered in today’s communication environment. Maximum benefit is gained from using a common set of technical development standards in designing new or modified capabilities across all of the Navy’s systems. The Maritime SIGINT Architecture Technical Standards Handbook (MSH) documents the standards agreed to by developers of Navy maritime systems. This report is the result of verifying those standards against one of the Navy’s newest cryptologic systems.
1.2 - Background
The Maritime SIGINT Architecture (MSA) Study Group was formed in April 1997 to determine the feasibility of developing a common technical architecture that would serve the needs of tactical cryptologic systems for the maritime services. The MSA developed the MSH, a set of technical standards for interoperability and commonality among maritime systems. The MSH is posted on the internet, at http://www.doncio.navy.mil/links/Initiatives/Center_For_Architecture_and_Standards/). [Cryptome Note: Document not found at this URL. A pointer would be welcome.] In February 1998 CNO N20/N64 submitted the MSH to the Force Warfare Systems Engineering Board (FWSEB) Executive Committee and U.S. Special Operations Command (USSOCOM) (PEO C4I) for review and endorsement.
On 22 July 1998, the DoN (CIO), Dr. Ann Miller, "…endorsed in principle, the recommendation of the final report, thereby clearing the way for a formal department of the Navy (DoN) decision.” However, before submitting it for formal DON Chief Information Officer (CIO) decision, the board requested a program manager test the recommendations to see if the MSA meets its objectives. On 29 September 1998, Commander Naval Security Group Command (COMNAVSECGRU) (N6/N9) tasked Space and Naval Warfare (SPAWAR) Command to conduct an MSHA standards verification againstnd assessment of the Ship's Signals Exploitation Equipment (SSEE) and Advanced Cryptologic Carry-on Exploitation System (ACCES).
1.3 - Scope of Study
As tasked by CNSG, the study was to "…execute [a] standards verification." For this assessment, standards verification is "…comparing the standards and specifications identified in the MSH to those used in a selected system and determine if they will foster leveraging functionality across systems and reduce development costs." As documented in the MSA Final Report of 17 February 1998, “the MSA Study Group found that establishing a common technical SIGINT architecture to meet the needs of the maritime community is not only feasible, but highly practicable. Such an architecture will facilitate cross-platforms interoperability and system adaptability and perhaps most importantly, reduce the number of stovepiped systems extant in the force.”
1.3.1 - Definition
The scope of the study was defined by answering the following questions:
· What is the definition of standards verification?
· What are the objectives of the study?
· What configuration of the SSEE/ACCES systems will be used?
· How will the results of the analysis be reported?
1.3.2 - Objectives
Using the above definition (in conjunction with the purpose of the MSH as defined on page 2 of the draft Handbook dated 19 February, 1998), this report has three objectives:
1. Determine what standards and specifications apply to SSEE/ACCES and if are they used.
2. Identify deficiencies and recommendations to improve the MSH when it is updatedfor use by programs.
3. Identify examples where use of these standards and specifications:
· Facilitate incorporation of new technology.
· Permit development of capabilities to respond quickly to operational requirements.
· Support efforts to leverage existing capabilities with minimal investment.
· Promote and support improved connectivity and interoperability for the timely exchange of critical mission information and data. Determine if the MSH standards promote and support internal connectivity and interoperability between SSEE software elements, equipment and subsystems, as well as external mission essential systems.
1.3.3 - Baseline Selection
COMNAVSECGRU (N6/N9) message DTG 291600Z SEP 98 tasks SPAWAR PMW163 to “execute [a] standards verification against the Navy’s Ship's Signals Exploitation Equipment (SSEE) and Advanced Cryptologic Carry-on Exploitation System (ACCES) systems. Numerous configurations of SSEE and ACCES are currently deployed. The SSEE program has Phase I, Phase II Increment B1/B2, and Increment C2 systems installed on a variety of ship classes, including CG-47, DD-963, and AGF-11. ACCES, under the Cryptologic Carry-On Program (CCOP) is a slightly different portable version of SSEE. ACCES suites are maintained at Fleet Electronic Support (FES) shore sites worldwide, to be installed when and where required.
Eight ACCES Increment C and numerous SSQ-80 systems are deployed throughout the fleet. SSEE and ACCES have completely merged hardware and software baselines with the Increment D system, which recently completed development and testing and was approved for full fleet introduction. Increment D(2) is currently under development as the first upgrade to this approved baseline, and will be the fleet release configuration of SSEE. Increment D(2) is the baseline used in this analysis, and is further described in section 2.1. In addition to the “core” functionality provided by Increment D(2), modular functionality can be added to the system to increase capability. Presently two modular subsystems can be added to the system: a Transportable Direction Finding Subsystem (T-RDF) and a high speed RF scanning subsystem (BLACKBIRD), both of which are described in sections 2.2 and 2.3. These subsystems were compared to the MSH, but as they are commercial off-the-shelf (COTS) systems, the level of detail and insight was limited to a brief review.
1.4 - Verification Process
Once the scope of the task had been defined, the process for how the analysis would be conducted was defined. The task was to “execute [a] standards verification” of the MSH against a Navy cryptologic system. The ideal approach for this type of analysis would have been to prepare a detailed requirement matrix of every item and the MSH and referenced documents (e.g. the JTA and DII COE documents) and then compare each requirement against the actual system. These comparison methods would have been based on desktop engineering analysis (e.g. code verification), system performance and capability measurements from tests using the appropriate tools and measuring devices, and a review of previously conducted tests, to name a few. The approach used to conduct this analysis was not as extensive, however, given the limited resources (no additional funding), little time (approximately two months) and ongoing tasks (Y2K drills, for example).
1.4.1 - Assumptions
Before describing the analysis approach and reporting structure, it’s important to identify the assumptions or ground-rules used in the development of this report.
1) Increment D(2) will be used as the baseline configuration for this analysis. Although there are numerous configurations of SSEE and ACCES systems in use, Increment D(2) is the most capable system. Delivery to the fleet is planned to begin in 1QFY00.
2) No testing or detailed review of documentation or coding will be conducted. Due to limited resources, this verification was conducted via a “desktop engineering analysis” by individuals with expert knowledge of the system and MSH standards and specifications.
3) Emerging technologies will not be included. Although the MSH identifies various emerging technologies for future use (e.g. ANSI/VITA 1.1-1995 (VME64-E) is identified as an emerging technology for Backplanes (MSH section 8.3.1)), this report only addresses standards currently being used. As improvements to the SSEE/ACCES systems are defined, these standards will be evaluated for use.
4) Sections or standards deemed “N/A” were not evaluated. Certain sections and standards in the MSH do not apply to SSEE/ACCES at this time. In these instances there was no attempt made to determine if these standards were “appropriate” (i.e. the correct choice). As future improvements to the SSEE/ACCES systems are defined, these standards will be evaluated for use. This report only addresses the standards currently being used.
1.4.2 - Approach
1) Each requirement in the MSH (or referring document) was identified. The requirements in the MSH are defined as either mandated, recommended, acceptable, or preferred. A requirement was defined as the standard or specification cited (e.g. IEEE 1003.1b: 1993, POSIX - Part 1: System Application Program Interface (API) Amendment 1; Real-Time Extension [C Language]*, as profiled by FIPS Pub 151-2: 1993) or MIL-STD-461D, EMI Compatibility Standard, Electromagnetic Emission and Susceptibility Requirements for the Control of Electromagnetic Interference), or an actual value or format stated in the MSH (e.g. navigation position accuracy <16 meters), or plain text documents using ASCII formatted text using “.txt” extension). The attachments provide a complete list of the requirements used in this verification.
2) Each requirement was reviewed to determine if it was applicable to the system. As stated in the MSH, each program should evaluate each requirement in the MSH and determine if it applies, prior to implementation. Since Increment D and D(2) development began prior to release of the MSH, each requirement was reviewed and judged if it would have been applicable if the MSH had been released during the requirements generation process.
3) The system was evaluated as to if it had implemented (or satisfied) the applicable requirement, by people having expert knowledge of the system and its design. There was no attempt to verify correct implementation of the standard or specification—when the system used an MSH standard or specification, it was assumed that it was correct implementation.
4) Scoring was used to quantify the number of requirements met. Two scores were generated for each system. The first represents the percentage of “implemented requirements” considering the total “applicable requirements,” to provide a quantitative figure for evaluating how many of the applicable requirements were implemented. The second score represents the percentage of “applicable requirements” considering all “MSH requirements,” providing a quantitative figure for evaluating how many of the total MSH requirements were implemented. This scoring in no way determines the level of compliance with the MSH. Standards verification compliance is a very complex process requiring a well-structured and documented approach. As stated in the MSH (section 1.4), compliance for these systems will be the responsibility of the NSA TSPO, but has not yet been defined.
[Snip]
SSEE/ACCES Increment D(2) was used for this standards verification. Two CNO sponsors support Increment D(2). CNO (N64) supports permanently installed cryptologic systems onboard a variety of surface combatants (SSEE). CNO (N20) supports portable cryptologic systems that are installed on surface and subsurface platforms (ACCES). N64 and N20 have combined efforts to jointly develop and field a low-cost cryptologic system based entirely on COTS, leveraging existing programs throughout the Navy and other services and agencies.
SSEE/ACCES Increment D began development in April 1997, and received authorization for full production and fleet introduction in November 1998. Increment D(2) is the first upgrade to the Increment D system, and will be the actual fielded version. The Increment D(2) Critical Design Review was held at SSC Charleston on 22-23 Nov 98.
Increment D(2) consists of a "core cryptologic capability" and two modular subsystems that may be added for increased capability: a Transportable Radio Direction Finder subsystem (T-RDF) and a fast scanning RF subsystem (BLACKBIRD). The core system consists of two subsystems: an intercept subsystem and a CCWS subsystem. Figure 1 shows Increment D(2), the two modular subsystems and interfaces.
[Figure 1 omitted]
SSEE/ACCES INCREMENT D(2) SYSTEM DIAGRAM
2.1 – SSEE/ACCES Increment D(2)
Increment D(2) is a low-cost cryptologic system based entirely on COTS, leveraging existing programs throughout the Navy, other services and agencies. The SSEE Increment D System Specification, SSEE Test and Evaluation Master Plan (TEMP), SSEE Increment D Test Results (TECHEVAL and OPEVAL) and SSEE/ACCES Increment D(2) Critical Design Review documents are available, for information about requirements, capability and performance. There are two subsystems. The intercept subsystem provides threat detection, identification and analysis functions required in the Shipboard Cryptologic Systems ORD #346-06-93, while the Common Cryptologic Work Station (CCWS) subsystem provides the cryptologic management and communications functions. Figure 2 shows the CG-47 physical rack layout of the system.
[Figure 2 omitted]
SSEE/ACCES INCREMENT D(2) RACK
2.1.1 - Software Description
The intercept subsystem provides the ability to detect, identify and analyze signals of interest (SOIs). The primary operator interface for detecting signals and receiver management is the Privateer Local Monitor Station (LMS) software, developed and sponsored by the U.S. Special Operations Command (SOCOM). SSEE/ACCES leveraged the software to provide a common user interface and reduced development cost. Privateer LMS upgrades are included in SSEE/ACCES upgrades. SSEE/ACCES unique changes are incorporated as required.
DESPERADO is an Army system modified and updated for shipboard use, to provide threat identification and analysis functions. It is a collection of analysis tools (e.g. BirdDog and FRIAR) that identify and exploit various signals. It also includes a recognizer to determine signal types semi-automatically. HONEYCOMB is a modified NSA system. HONEYCOMB+ provides threat identification and analysis for additional signals of interest. Because of their classification, detailed requirements of DESPERADO and HONEYCOMB can be provided via the appropriate security channels. The intercept subsystem also provides speech enhancement (provided by Rome Laboratories), record/playback/archive, and built-in-test.
The CCWS subsystem provides cryptologic management and communications functions via the primary interface, Cryptologic Unified Build (CUB) software, developed and managed by SPAWAR PMW-163. CUB provides a common look and feel for all platforms using cryptologic functions, using DII COE/GCCS-M compliant software "tools" to perform day-to-day cryptologic operations, like BE-3, RFMS, CM, KL writer, TWS, NIPS, SIC, and DF Manager, to list a few. CUB updates are provided periodically and integrated in conjunction with other system upgrades. Figure 3 on the next page, describes the software components.
[Figure 3 omitted]
SSEE/ACCES INCREMENT D(2) SOFTWARE COMPONENTS
2.1.2 - Hardware Description
Hardware used in the Increment D(2) system is completely COTS. The three operator workstations have access to all functions, at all times. Each workstation contains a multi-media keyboard equipped with speaker, headphones, keyboard, and trackball. Flat panel displays are used in racks #1 and #2 (rack#3 was part of the previous baseline). There are fourteen receivers in the system: six HF digital receivers (WJ 8721), two manual HF receivers (CUBIC 2411), four digital VHF/UHF receivers (WJ 8629), and two manual VHF/UHF receivers (CUBIC 2412). The manual receivers are included for degraded mode operation. The system also contains disk farms, for storing digitally recorded signals. Figure 4 is the hardware architecture for the system.
[Figure 4 omitted]
SSEE/ACCES INCREMENT D HARDWARE
2.2 - Portable Direction Finding Subsystem (T-RDF)
T-RDF is a passive HF and VHF/UHF direction finding system that provides lines-of-bearing on signals of interest (SOIs). This COTS system is a single rack of hardware containing all the necessary components for operation, plus one VHF/UHF and six HF antennas. It is a product developed by Southwest Research Institute (SwRI). T-RDF interfaces to SSEE in one of two ways. The most basic way is directly to the CCWS via a CUB RPL segment that allows an operator to task T-RDF to generate an LOB on a signal. A new interface is being developed that provides automated tasking. Figure 5 provides a system diagram of the T-RDF system.
[Figure 5 omitted]
MBS-200 HF/VHF/UHF TRDF System
2.3 - High Speed RF Scanning Subsystem
The HP3238S Blackbird is used to provide the functions required for the High Speed RF Scanning Subsystem. Blackbird is a COTS product developed by Hewlett Packard that employs a wideband front end hardware architecture to provide high performance spectral search for possible signals of interest. The standard Blackbird product has capabilities to calculate emitter energy externals (frequency, amplitude, bandwidth, etc…) that are tracked in an internal database of energy history. Based on these externals, users configure Blackbird to alarm on these signals. This process is concisely described by the progression of processing stages from left to right in the Search System portion of the diagram below.
For Increment D(2), Blackbird will be operated as a manual RF search tool, interfaced to SSEE/ACCES via the CUB RPL segment. Future SSEE increments will incorporate new energy alarms, automatic SOI handoffs to the receiver pool, and other automated SOI features described above. Figure 6 is a block diagram of the Blackbird system.
[Figure 6 omitted]
Blackbird Block Diagram
[End Section 2.]
Full 65-page document: http://cryptome.org/msa-tsv.pdf (PDF, 805K)