The purpose of the Joint Airborne SIGINT Architecture (JASA) Information Security (INFOSEC) annex is to provide program offices, engineers, and users with an INFOSEC guide that focuses on unique airborne requirements and standards. This annex provides background and analysis to support the standards selection.
1.2 Scope
This annex addresses unique JASA INFOSEC needs. If another applicable standard, such as the Joint Technical Architecture (JTA) or Defense Information Infrastructure Common Operating Environment (DII-COE) adequately addresses an INFOSEC requirement, this annex will only reference the overarching document.
This Annex will:
1.3 Background
The INFOSEC annex uses the DoD-accepted International Standards Organization (ISO) Open Systems Interconnect (OSI) Reference Model as a method of organizing and presenting standards. The layers of the OSI model are application, presentation, session, transport, network, data link, and physical. The four primary layers used in this annex are application, transport, network, and data/physical. The application layer deals with INFOSEC issues related to applications such as word processing, and e-mail. The transport layer deals with issues associated with the operating system. The network layer addresses issues such as network operating systems and addressing. The physical layer consists of hardware and electrical implementation issues. OSI simplifies the organization of the standards and identifies logical boundaries.
1.4 The Role of INFOSEC
INFOSEC plays a vital role in ensuring interoperability. First, INFOSEC equipment and methods must be interoperable - a data connection with incompatible cryptography does not deliver valid information. Second, INFOSEC provides the equipment, methods, and systems necessary to mitigate the possible compromise of vital intelligence information. Furthermore, as interoperability increases, the need to protect information also increases because interoperability makes it easier for the friend and foe to receive, process, and analyze data.
2 JASA INFOSEC Risk Model
Airborne platforms intended for use over denied or hostile areas must perform a risk analysis. The JASA Risk model uses three components. First, the risk model defines an information workflow – or thread – for each information element. Second, it quantifies the vulnerability associated with each step in the workflow. Third, the model quantifies the cost to mitigate the vulnerability. The JASA Risk Model produces a repeatable process that identifies information risks and the associated costs, for each step in an information workflow.
2.1 INFOSEC Risk Analysis
TBD
3 Application Layer Standard
3.1 Security Doctrines and Guides for Application Programming
Since airborne applications must remain compatible with ground-based systems, the application layer standards that the JTA proposes are relevant and applicable.
3.2 Cryptologic and Security Application Program Interfaces
A Standard Security Application Program Interface (API) provides a common and consistent interface to cryptographic services. The security services application interface would serve as a common function to all applications. Consequently, a word processing, spreadsheet, or digital signal processing application would invoke a security service with a simple function call. For example, a word processing application would invoke encrypt_file(name_of_file) to encrypt a file prior to storage. The API would invoke security and cryptographic details necessary to support the application. The encrypt_file(name_of_file) function would require considerable cryptographic support to complete the task. Some of the tasks that the API supports are:
The rational behind a security API is to separate application developers from the details of cryptography and security which makes it easier for application developers to deploy security and cryptography. Similarly, the security API allows the security community to focus on enhancing existing security services. In short, a security API has two effects. First, the applications community can implement security without too much concern for the specific cryptographic engine in use. Second, the cryptographic community can develop new cryptography without too much concern for software changes and upgrades. Both of these effects help the applications and cryptographic communities deploy products and services more effectively. Furthermore, APIs are more hardware independent than traditional solutions because the basic API can remain constant with the addition of a new hardware encryption device.
Thus far, the use of a security API has been discussed in general terms. There are significant initiatives underway to develop an API-oriented security architecture. Both Intel and Microsoft have published their security API standards. Intel’s interest comes from the lower layer of the architecture stack. Microsoft’s interest stems from a need to establish a common security interface for all its products.
The following analysis demonstrates that JASA-compliant systems need a security framework that establishes APIs. The following sections discuss Intel’s Common Data Security Architecture (CDSA), and Microsoft’s Cryptologic API (CrytoAPI). A notional JASA INFOSEC framework that implements media encryption is also presented.
3.2.1 The Intel Common Data Security Architecture (CDSA) Specification
CDSA (Figure 1) provides a layered security framework. CDSA’s goal is to provide applications with open, modular, and interoperable security architecture. CDSA does not assume any specific level of trust, nor does it assume any specific application or cryptography. CDSA is middleware that separates a horizontal plane of applications from the complexities of security, trust, and cryptography. CDSA consists of three basic layers:
The System Security Services layer provides the highest level of abstraction necessary to support applications with services such as encrypt_this_email. The Common Security Services Manager (CSSM) – CDSA's middle layer – performs the bulk of the functions that CDSA provides. CSSM manages service requests between the System Security Services layer and specific Security Add-In Modules. Security Add-In Modules are the actual interfaces to Cryptographic Service Providers (i.e., RSA, PGP) and specific trust and certificate services (i.e., Switchboard’s Trust Certificate Service Engine). The Data Storage Library stores certificate information to support trust and key recovery.
The CSSM is CDSA’s workhorse. This layer of the model interfaces with all cryptographic services (i.e., encrypt, decrypt, hash, digital signature, and random number generation) and buffers the higher layers to changes. As new cryptographic hardware and software are deployed, CSSM provides a common interface. This common interface isolates applications from the low-level cryptographic changes. Changing a specific cryptographic engine may only require minor changes to the Service Provider Interface (SPI) – CSSM’s Cryptographic Service Provider device driver interface. This eliminates an across-the-board modification to numerous applications.
Figure 1 Intel’s Common Data Security Architecture
CSSM has interface modules for trust, certificates, and data storage. These modules interface with external application services that support trust management. For example, CSSM would access an external Trust Model Library (Figure 1) to determine whether to grant access to a server. The Certificate Library (Figure 1) provides CSSM with the user’s X.509 identity. If revocation of access is needed, the Data Storage Library would retain a revocation list. All three of these modules are pieces needed to establish trust on a per call/connection basis. CDSA supports per connection/call trust determination.
CDSA creates a layered framework that is designed to grow and accommodate the changes associated with a JASA networked environment. Furthermore, security solutions must also be scaleable to satisfy local, enterprise national, and global requirements. CDSA’s approach provides scalability or extensibility.
3.2.2 The Microsoft Cryptographic API (CryptoAPI)
CryptoAPI provides Win32™ applications with security services. The CryptoAPI implementation enables the following functionality:
A hash (also referred to as a message digest) is a cryptographic function that maps an input message to an output. Without knowledge of the key and hash function, it is computationally impossible to determine the original input. A hash is typically used to verify the integrity of a document. If the input is changed by even a bit, the resulting hash value changes.
The CryptoAPI can use various commercial encryption algorithms to encrypt and decrypt files. The CryptoAPI also has the ability to exchange encryption keys.
3.2.3 CrytoAPI vs. CDSA
CryptoAPI and CDSA both exemplify commercial implementations of cryptologic APIs. An API permits an application to use different encryption algorithms without affecting application services. This flexibility would allow JASA systems to readily modify encryption engines – either because of changes in technology or changes in level of trust. However, CryptoAPI falls short because it does not establish a larger framework that can address certificate and trust policy management. (Note: As JASA becomes part of an internetworked intelligence community, exchanging X.509 certificates and establishing a trust relation prior to sharing data will become vital.) In contrast, CDSA addresses trust and certificate management challenges. Clearly, APIs make security easier to implement and deploy. Therefore, JASA’s objective architecture must include a security framework with APIs.
3.3 JASA Usage of CDSA and a CAPI – the Media Encryption Example
APIs and security frameworks, such as CDSA and CryptoAPI, enhance INFOSEC services. Media Encryption, or Encrypted Storage is one of many implementation examples of an API approach. Another example would be the use of an API to support a family of cryptographic modules – where modules could be exchanged based on risk and trust requirements. The following analysis provides an example JASA framework for JASA media encryption (Figure 2) that is CDSA and CryptoAPI inspired. Actual performance requirements would dictate specific implementation.
Figure 2 JASA Media Encryption Framework (CDSA-Compliant)
3.3.1 Cryptographic File System
A Cryptographic File System (CFS) is simply a software module that an application can call to encrypt or decrypt files. In its simplest form, an application need only provide source file, destination directory, and a key. A more sophisticated CFS can provide key and algorithm agility. CFS functions above the transport layer but below the presentation layer. Several off-the-shelf file services include: Secure File System (SFS), SecureDrive, Secure Device, Locksmith, and Matt Blaze's Cryptographic File System.
A CFS pools the encryption in a general, secure, and convenient environment. The principal strength of the CFS approach over a dedicated embedded hardware controller approach is that CFS is hardware independent. Since the approach is hardware independent, different hardware can share the same encryption service. The advantages of CFS are:
Furthermore, CFS handles the details associated with cryptography, isolating the user from the encryption process. By operating within a normal operating system environment, encrypted and unclassified files can be stored on the same server or storage device.
Given the significant risks to JASA’s data and applications, media encryption and other security services needs to be readily accessible to applications and users. A CFS approach does just that by making it easier for applications to use media encryption.
3.3.2 Application Layer Encryption as an Alternative to CFS
There are other methods of encrypting a file written to disk. Encryption can be performed at the application layer where each application encrypts data written to disk. This is a viable option, but it does add complexity to each individual application (i.e. each application would have to have a trust evaluation performed on its encryption). Furthermore, if applications need to share an encrypted file, there is an added level of design complexity required for key exchange. In short, an inter-networked JASA community would incur unnecessary cost and complexity by implementing application specific encryption.
3.3.3 Embedded Hardware Encryption
System level media encryption embeds the encryption in the disk drive controller. The principal strength of embedded encryption is that it is completely transparent to the user. Because it is hardware based, embedded media encryption provides the greatest level of assurance – assurance of hardware is more deterministic than software assurance. This approach does have several disadvantages. First, all data must be stored with the same key. Having to store all data with the same key makes data sharing more difficult – a higher layer mechanism must be put in place to establish trust and exchange keys. Second, the data is only protected by encryption from the disk controller to the drive. If the data flows on a network, the data is no longer encrypted. Third, this solution is hardware dependent. Although there are some limitations, JASA may have a need to use embedded media encryption in situations where data sharing and data vulnerability are not concerns.
3.3.4 Key Recovery Service
A key recovery service reissues lost or zeroed key. If key recovery is desired during a JASA mission, key recovery must be made available over-the-air. Unlike link encryption, a media encryption device cannot be rekeyed with a new key. The original key that was used to encrypt the file to disk must be reissued. Within JASA’s environment, key recovery needs to be part of a standard trusted key exchange between the components involved in a common data sharing operation.
3.3.5 Security Manager Service
This service is responsible for the following security functions:
The security manager performs classic security audit functions. The audit would also verify the integrity of trusted software. The Vulnerability Agent would monitor system vulnerability by evaluating the following questions and taking appropriate countermeasures:
The Vulnerability Agent is a proactive security measure whereas the Audit function is reactive and documentary in nature.
The last security service provided is revocation. In a military operating environment, the revocation strategy is vital. If the physical media storage device is compromised (i.e., loss of device), revocation must prevent unauthorized users from reading data. More than likely a unique JASA revocation strategy must be used based upon specific operational requirements.
Possible revocation strategies include:
A one-time-use-and-revoke strategy would permit the application (e.g., signal processing algorithm) to read the data once and then revoke the key. When the mission is complete, an escrowed key would be used to read the data on the ground. Although this approach limits usage to one read or write, its strengths are in the high level of security provided and simplicity of implementation. A revoke unless trust established is also a very secure method, but there is added complexity in establishing trust relationships. The last strategy only revokes when notified. This approach has the highest risk and lowest cost to implement.
3.3.6 Common Security Services Manager Layer
This layer corresponds to the INFOSEC middleware layer proposed in the CDSA. All of the functions may not be utilized by media encryption, but CSSM manages the connections with the cryptographic service provider (i.e., cryptographic hardware and software, trust management, and integrity).
3.3.7 Crypto-Service Provider Layer
This layer consists of the device drivers for each cryptographic service provider – Fortezza, Krypton, KGV-135, or some other type of hardware or software encryption algorithm.
3.3.8 Media Layer
In the proposed JASA INFOSEC framework, the media can consist of hard disk, floppy drive, CD-ROM, magneto-optical, or compact flash memory. The framework must make it possible to change media seamlessly without affecting encryption.
3.3.9 Media Encryption Performance Considerations
Before selecting a detailed media encryption approach, the following performance requirements must be determined.
Table 1 Bus Technology
3.4 Key Standards
TBD
3.5 Trusted Databases
TBD
3.6 X.509 Trust Certificates
TBD
3.7 MIL-STD-2045-48501 Common Security Labeling Standards
This MIL-STD establishes a common security labeling standard. MIL-STD-2045-48501 is compatible with TCP/IP, TP4, and CLNP and it enables the appropriate labeling of data. The labels permit standard communications devices—such as routers, guards, and servers—to read the label and, based on a rule, permits the transfer of the data. Labeling is a critical component of future multi-level security environments. For example, a rule-based system would permit a rule based object to autonomously verify the classification of data before release.
3.8 Emerging Technologies and Standards
TBD
4 Network Layer
4.1 FASTLANE (ATM Encryption)
The 53-byte ATM payload consists of a 48-byte payload with a 5-byte header (Figure 4). The FASTLANE encryption device is designed to encrypt only the payload and leave the address and header in plain text. The FASTLANE encryption device supports the following physical interfaces: DS-1, DS-3, SONET OC-3c/STS-3c and OC-12c/STS-12c. FASTLANE’s compatibility with the ATM Forum’s User-to-Network-Interface (UNI) 3.1 permits interoperability with commercial ATM switches and products.
The FASTLANE can be used as either a host or a network encryption device. As a host encryption device, FASTLANE accepts ATM cells from a host and encrypts the payload. After the payload is encrypted, FASTLANE provides a UNI 3.1 network interface for a WAN (Figure 3). As a network device, FASTLANE operates at the LAN/WAN interface. As cells travel from the local network to the ATM WAN, FASTLANE encrypts the payload.
When a connection, also referred to as call, is set-up with the FASTLANE, a unique key can be used for each connection. After FASTLANE Release 2, each connection will use X.509 Certificates to determine the classification of the connection and select the encryption key based upon the certificate and level of trust. Furthermore, a future release of FASTLANE will permit algorithm agility – changing encryption algorithms on a per connection basis. Algorithm agility and key agility on a per connection basis make FASTLANE a critical piece of architectures that seek to share information with trusted and less-trusted users.
ATM provides numerous communications benefits, but it also provides a means of achieving multi-level security. Encrypting information at the cell level – and leaving the header in plain text – permits users at different levels of security to share an ATM network. Once an ATM payload is encrypted, it can share a LAN or WAN with other cells regardless of their classification. The only other alternative on the horizon is IP based encryption. However, IP based encryption is not robust enough to support time-sensitive applications such as speech.
4.2 Multilevel Security
JASA will focus on specific pieces of a multi-level security (MLS) architecture. The specific pieces of the architecture are: guards, firewalls, trusted object request brokers, and trusted-mirrored servers. The initial JASA MLS objective is to share information and resources with networks that have a lower level of trust. (Note: The terms MLS and Multilevel Trust can and will be used interchangeably.) Actual implementation would be based in part on the JASA INFOSEC Risk Model.
4.2.1 Multilevel Guards
The most basic guards are unidirectional guards (Figure 5). The unidirectional guard controls the flow of data between systems, servers, and clients. For example, a unidirectional guard would control the flow of message traffic between a Top-Secret JWICS/Intelink network and a Secret SIPRNET. Highly structured data inputs simplify the guard’s design. The disadvantage of a unidirectional guard is that it is difficult to implement new data types. Every change in a data set structure or a new data set requires a software change and recertification of the guard.
For limited, cost sensitive applications the unidirectional guard is the best solution. Unidirectional guards do satisfy needs in highly trusted and broadcast based systems. Unidirectional guards do not satisfy needs in push-pull environments.
Figure 5 Unidirectional Guard stripping off a field from a classified message prior to disseminating the information via a lower classification system/network
4.2.2 Network Firewalls
Network firewalls mitigate risk when dealing with unknown or less-trusted transactions. A Network firewall consists of hardware and software that restricts access to a network, device, application, and/or user. There are three basic types of firewalls:
(1) Packet Filtering
(2) Circuit Relay
(3) Proxy and Transparent Proxies
JASA would use a network guard to control access to a payload or ground-station network. For example, if a user wanted to reset a demodulator on board a sensor, a firewall may be used to control what commands are permitted and from which source IP address the commands are sent.
4.2.3 Network Firewalls: Packet Filtering
The packet filtering firewall permits or denies network access and release based upon the source and destination address (i.e., Host/server IP address) or the type of IP service requested (i.e., e-mail, rlogin, telnet, ftp, www, http). The advantages of the network packet filter are that it is a simple, low cost, commercial-off-the-shelf solution that provides a great deal of security. The rules governing the packet filter are relatively simple. For example, a simple rule set would consist of:
The key disadvantage of a packet filter is that once a bi-directional connection is established the protected host is vulnerable to attack. A rogue host with a lawful established connection could launch a direct attack on the protected host. Since the host is actually connected to the rogue host, the rogue could also launch undesired applications that could harm the protected network. During the rogue’s attack, the packet filter firewall is oblivious to the harm carried inside every "authorized" TCP/IP address or service packet.
4.2.4 Network Firewalls: Circuit Relay
TBD
4.2.5 Network Firewalls: Proxy
The proxy firewall acts as a go-between for the protected network and an external network (i.e., Internet, SIPRNET, JWICS, etc.). The proxy firewall runs on a separate server. Every time a protected host requests an Internet application, the request must go to the proxy server. The proxy server acts as an intermediary and runs the request for the host. The proxy server connects to the external network. Once the transaction is completed, the proxy server disconnects with the external network and responds to the original protected host.
The main advantage of a proxy server is that the protected host never encounters unregulated external networks (e.g. Internet) because the proxy server shields the host from the external network. This shield function of the proxy server provides better security than a simple packet filtering firewall. Enhanced protection comes with the following disadvantages:
4.2.6 Network Firewalls: Transparent Proxies
The transparent proxy provides packet filtering and connection verification. The transparent proxy runs on a separate server. Each time a protected host makes a service or connection request the transparent proxy verifies the address and the application or service requested. This verification is similar to the function a packet filtering firewall performs. When the protected host establishes a connection with the external server, the transparent proxy continuously monitors the connection verifying that the addressing and command set stay within trusted rules. Additionally, the transparent proxy monitors each connection for unusual data patterns. Unusual patterns are based upon previous connection history. The transparent proxy does this in real-time by permitting the host to talk directly to the outside world. The transparent proxy monitors the connection in real-time for any command, address, or data pattern anomalies. Any violation would cause the transparent proxy to sever the connection.
4.2.7 Emerging Network Firewalls: Trusted Object Request Brokers
TBD
4.2.8 Summary of Firewalls and Guards
Unidirectional guards satisfy simple broadcast and multicast requirements, but the guards do not satisfy interactive, bi-directional applications. Network firewalls satisfy bi-directional requirements, but trust and assurance issues make implementation troublesome. The use of standard processes to evaluate risk and trust would alleviate some of the security concerns with network firewalls. By its very nature, a network firewall presents a risk because the underlying software is complex and non-deterministic. This makes complete assurance testing both complex and virtually impossible. In a JASA environment, a risk and trust analysis may reveal that network firewalls may sufficiently mitigate risk to justify use in both a trusted and less-trusted environments. Table 2 lists a summary of the findings.
The longer-term solution is to begin an architecture that permits the use of trusted object request brokers (ORB). Each trusted ORB can be fully tested once, and combined with other fully tested trusted ORBs to provide a more deterministic – and therefore more trusted – firewall than is currently available today.
Table 1 Firewall and Guard Summary
|
UNIDIRECTIONAL GUARDS: ADVANTAGES |
UNIDIRECTIONAL GUARDS: DISADVANTAGES |
|
|
|
NETWORK FIREWALLS: ADVANTAGES |
NETWORK FIREWALLS: DISADVANTAGES |
|
|
5 Physical/Data Standards
The Common Data Link (CDL) is migrating to the KGV-135. The KGV-135 is an air to ground in-line encryption device. To comply with JAS, all future programs that seek to interoperate with the CDL must implement the KGV-135 both on-board the platform and the ground/surface station. The KGV-135 is backward compatible with the KGV-68.
6 Glossary of Terms
| Cryptographic Service Providers (CSPs) | Modules that provide secure key storage and cryptographic functions. The modules may be software only or hardware with software drivers. The cryptographic functions provided may include: |
|
|
| Common Data Security Architecture (CDSA) | A set of layered security services that address communications and data security problems in the emerging PC business space. The CDSA consists of three basic layers: |
|
|
|
|
| Common Security Services Manager (CSSM) | The central layer of the Common Data Security Architecture (CDSA) that defines: |
|
|
|
|
|
|
|
|
| Digital signature | A data block that was created by applying a cryptographic signing algorithm to some other data using a secret key. |
| Hash algorithm | A cryptographic algorithm used to hash a variable-size input stream into a unique, fixed-sized output value. Hashing is typically used in digital signature algorithms. |
| Levels of Trust | A trust network among people who know and communicate with each other. Digital certificates are used to represent entities in the web of trust. |
Acronym List
ANSI American National Standards Institute
API Application Program Interface
ATM Asynchronous Transmission Protocol
CAPI Cryptologic Application Program Interface
CDL Common Data Link
CDSA Common Data Security Architecture
CFS Cryptographic File System
CLNP Connectionless Network Protocol
COE Common Operating Environment
CSDF Collected Signals Data Format
CSP Cryptographic Service Provider
CSSM Common Security Services Manager
DII Defense Information Infrastructure
DII-COE Defense Information Infrastructure Common Operating Environment
DoD Department of Defense
FTP File Transfer Protocol
IDE Integrated Device (drive) Electronics
INFOSEC Information Security
IP Internet Protocol
ISO International Standards Organization
ITSA Integrated Tactical SIGINT Architecture
ITU International Telecommunications Union
JASA Joint Airborne SIGINT Architecture
JSH JASA Standards Handbook
JTA Joint Technical Architecture
LAN Local Area Network
MLS Multilevel Trust
NSA National Security Agency
ORB Object Request Broker
OSI Open Systems Interconnect
PGP Pretty Good Privacy
SFS Secure File System
SIGINT Signals Intelligence
SPI Service Provider Interface
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TP4 OSI Transport Protocol Class 4
UNI User Network Interface (ATM)
USCS U.S. Cryptologic System
VME Virtual Memory Extender
WAN Wide Area Network
WWW World Wide Web