Future-proofing your high-density encrypted storage solution

Story

June 09, 2014

Paul Davis

Curtiss-Wright

Encrypted storage designers must plan ahead - taking into consideration the probable creep in requirements for storage, I/O, and encryption -when architecting a new system that requires data storage. The likelihood of needing to accommodate increased demands makes it prudent to choose a Network Attached Storage (NAS) device or recorder that can grow with those demands.

It’s not news that the amount of critical digital data coming into, being moved, and stored on air, ground, and naval vehicles continues to grow quickly as those platforms take on more sensors and expand their onboard networks. Much of the data needs to be stored and archived, and much of what needs to be stored must be encrypted, depending on its sensitivity, in a range of security levels. System designers seeking a high-density encryption-capable data recorder solution need to consider both current and future needs as protocol types, storage densities, bandwidth, and security requirements continually evolve and expand.

In the past, designers who needed to add additional recording capability for some new data type, such as audio or video, had no option but to source and find room in their already burdened platform for a dedicated recorder for that type of data input. Such a “stovepipe” approach results in additional cost, size, weight, and power dissipation, none of which are desirable.

A better approach, one that takes advantage of the parallel trend toward network-centric platform architectures, is to combine support for all data types in a compact, modular, and scalable system designed for expandability and evolution. This approach eliminates the need for dedicated recorders, and when remote booting is used – such as that supported by PXE (Preboot eXecution Environment) booting – can also eliminate the need for the numerous solid-state drives that each network client currently requires for their Operating System (OS) and application software. A scalable system also builds in the confidence that the multiprotocol data recorder will be able to handle increased future requirements, such as the rapidly approaching demand for 10 Gigabit Ethernet (GbE).

Protocols and I/O

Until recently, most digital recorder solutions focused on NAS to support Ethernet-based networks, primarily for GbE, the most popular data communications protocol. These recorders, designed for GbE, didn’t provide the I/O front-end or protocol support for video, audio, or other types of data.

Today, sensors onboard platforms are capturing a wide range of data types such as radar, Forward Looking Infrared (FLIR), side-aperture radar, video, and audio in the cockpit for post-flight analysis. Handling these different data types required separate dedicated recorders. Now, however, with the advent of networked platforms, users increasingly demand NAS devices. Providing a NAS digital recorder with the additional I/O interfaces and protocol support to handle audio and video, for example, boosts that recorder’s value because it eliminates the need for multiple devices and helps mitigate Size, Weight, Power, and Cost (SWaP-C) constraints.

In a networked environment, the many different network clients – including mission computers, sensor-management computers, and other types of control subsystems and computers – will each likely have its own processor and some particular OS running on it.

With the old stovepipe approach, a recorder hooked up to a Linux client only needed to support that particular client. Part of the challenge for a single-unit multiprotocol recorder is to support all likely network protocols. For example, a Windows-based environment/machine/client will typically support CIFS, while NFS protocol is expected for Linux or VxWorks clients. Other clients may expect FTP or HTTP.

A multiprotocol NAS recorder needs to support a wide variety of industry-standard protocols, including CIFS, NFS, HTTP, FTP, and PXE. The NAS device doesn’t have to be limited to the most common interface and protocols, however; using an expansion card, the multiprotocol recorder can support additional clients as well. For example, if support is required for Fibre Channel (FC), a carrier card can be used to make the recorder act like an FC target disk.

More data requires more bandwidth

Another challenge for system designers is that in addition to the increased number of sensors generating data that must be recorded, modern sensors also tend to operate at higher bandwidths, generating more data per second. In many cases, the platforms themselves, such as unmanned aircraft, are staying in the air longer, which again increases the amount of storage required. This ramp-up means that a recorder must provide scalable storage if it is to be “future-proofed” and not rendered obsolete in a short number of years as requirements inexorably increase. Today’s recorders must be able to support upwards of 8 TB and provide a method to handle even more storage as the applications evolve and grow.

Remote booting reduces SWaP-C

Another significant reduction in cost, weight, and power aboard platforms can be achieved through use of the PXE boot protocol to enable remote booting of clients in a net-centric environment. Typically network clients, like a mission computer, have had their own hard drive, which hosts that client’s OS and unique application. That drive (typically solid-state) has resided inside the client’s ATR chassis and required its own power supply. Moreover, because these drives are located physically inside each client, they are more difficult to access for OS or software updates.

The power dissipated by these drives, as well as the space they require, can be eliminated through the use of a multiprotocol recorder that supports PXE boot. The client need only have a small boot-up program hosted in Programmable Read-Only Memory (PROM).

Upon power up, the client requests the OS and application file from the central recorder via PXE protocol. The recorder then provides the network address and the appropriate OS and application to the client. Since such recorders have removable drives, the OS and application file can be the latest version, which may fix bugs or provide new important features. With this setup, updates are delivered quicker and more efficiently.

Encryption

An ideal multiprotocol recorder is designed around three conceptual pillars: 1) scalable storage, 2) flexible I/O, and 3) support for a variety of cryptographic levels. Encryption is required to protect the stored data from being accessed and used by adversaries. In some cases, no encryption is required if the data is not critical and will reside in an unclassified environment. In that case, a bypass module can be used so that data moves through the recorder unchanged. As security requirements change, the appropriate encryptor, for Secret and Below Information (SABI) or Top Secret and Below Information (TSABI) can be installed using an inline media encryptor with the bypass module removed.

Example solution

An example of a new generation of NAS device that meets these needs is Curtiss-Wright’s Compact Network Storage 4-Slot (CNS4) subsystem (see Figure 1). It supports NSA Type 1 cryptography to ensure the integrity of critical “data-at-rest” in military environments such as those endured by transports, helicopters, Unmanned Aerial Vehicles (UAVs), and mobile radar systems. The device eliminates the need for multiple recorders by providing high-density storage capacity, support for multiple network protocols and expansion, and flexible encryption capabilities.

Figure 1: The Curtiss-Wright Compact Network Storage 4-Slot (CNS4) subsystem provides high-density storage capacity, support for network protocols, and flexible encryption capabilities.

Data protection with Type 1 encryption

In addition to its VPX I/O slot, the CNS4 chassis also accommodates a 3U VPX Inline Media Encryptor (IME) certified for SABI-level data in attended systems. A Crypto Ignition Key (CIK) is mounted on the device’s front panel when this IME is used. By the end of this year, the IME is expected to support Pre-Placed Keys (PPK) and four SATA lanes. Via a DS101 key-fill port, the PPKs can be loaded so the IME can be left in place.

Paul Davis has 30 years of professional experience, holding positions in Product Management, Sales Management, Engineering, and Engineering Management for a variety of technical product companies. Paul has been with Curtiss-Wright for 16 years and has served as Director of Engineering, Director of Sales and Marketing, and Product Manager. He currently serves as Director of Product Management. Paul earned a BSEE from the University of Cincinnati and an MBA from Indiana University. Readers may reach him at [email protected].

Curtiss-Wright Defense Solutions 703-779-7800 www.cwcdefense.com