Encrypting communications

September 15, 2014

Encrypting communications

During the Afghanistan conflict, it was widely reported that insurgents were intercepting and displaying the unencrypted video feeds from UAVs using i...

During the Afghanistan conflict, it was widely reported that insurgents were intercepting and displaying the unencrypted video feeds from UAVs using inexpensive software sourced from the web. This shocking revelation suggests that adding an encryption capability is a difficult task, but in reality, it needn’t be.

Data encryption is an obvious benefit for UAVs, along with many other applications. The download from the payload, such as radar, optical, or infra-red camera can be encrypted to prevent any intercepted signal from being of use to an enemy. The streaming data demands a high-performance encryption engine, but that’s well within the capabilities of intellectual property (IP) cores that can be built into programmable logic. The uploaded control and command signals can also be encrypted to prevent hijacking an aircraft.

The Advanced Encryption Standard (AES) is authorized by the U.S. government’s National Security Agency (NSA) for encryption of classified information. AES combines an extremely high level of security with computational efficiency, suiting it for either hardware or software systems. Low data rates such as the command signals can be accomplished by software in the UAV. Hardware solutions are, of course, much faster and are well suited to video streams.

Applications can exploit an off-the-shelf core which can even be retro-fitted into existing systems if they use programmable logic, such as an FPGA. For example, a wireless application requiring 100 Mbps can be realized by adding a small AES core into unused areas of an FPGA. AES cores can either use 128-bit or 256-bit keys to provide high levels of security. Even systems running to 100 Gbps can be achieved using a larger core. Optimizations within this 1000:1 range provide solutions for a wide range of military and commercial communication applications.

A further security consideration is to ensure that the encrypted message hasn’t been tampered with or corrupted during transmission. This is accomplished using a more complex core such as AES-GCM. These cores also cover data rates to 100 Gbps, but append data to the end of each packet to provide the message authentication. This data is analogous to a CRC function, as it processes the encrypted data to confirm that the packet has been decrypted perfectly.

An important aspect of any encryption system is to keep the keys secure, as a UAV may be captured or shot down. A method is needed to change keys in the event of a security breach. A Key Wrap core uses the algorithm specified by the National Institute of Standards and Technology (NIST) to encrypt the key so that it can be securely transmitted over an insecure link or, in this example, loaded and then unwrapped in the UAV. The key can be injected into the UAV as part of the pre-flight procedure using a key gun. An advantage of this scheme is that the ground crew can’t directly access the encryption key.


This simplified block diagram shows the AES and Key Wrap added to an existing system.

Of course, AES encryption can be added to a wide range of products, including wired and wireless communications, data centers, video, gaming, and storage. Programmable solutions are, without question, the fastest way to market and have thus become ubiquitous in modern system design. Often there are unused resources in the final FPGA that might be sufficient for adding AES into the existing chip, or else a higher capacity device can be substituted.

Integrating AES into an FPGA-based system is straightforward because the cores can be easily incorporated into the chip’s design software. Engineering can then define the performance parameters to match the system requirements and blend the AES into the design. The AES would normally operate under the control of a microprocessor, which would supervise the FPGA configuration at power-up.

Power consumption is an important criteria and is proportional to the clock frequency used to achieve the throughput. A high clock speed will result in higher power consumption and a more difficult design. Well-designed cores will have been crafted to use lower clocks and less logic to minimize power consumption.

Verification is the number one headache in system design. AES and AES-GCM (AES with Galois/Counter mode) were standardized by NIST with a number of different operating modes. NIST also provides a large number of tests with known-answer patterns to be used in implementation validation. For validation, the test vectors are generated by a NIST-approved test lab and aren’t known in advance. Customers can save a lot of work by selecting a vendor that offers a comprehensive test bench implementing all AESAVS tests, ideally with additional vectors as specified in FIPS197 and Special Publication SP800-38A.

The next cost to consider is the silicon. For most systems, assume that this will include an FPGA for interfacing or custom logic. The AES core can co-exist in this device to reduce the required hardware. AES or AES-GCM cores will fit into FPGAs supplied by Xilinx, Altera, Microsemi, and Lattice.

Engineers need to understand how things work, and unlike some software codes, it’s possible to read an HDL (hardware description language) source. HDL code lets them play out what-if scenarios to arrive at the optimal design. For example, users can change generic parameters and recompile to evaluate design trade-offs such as data path widths. They’ll also be expected to verify the core and create test vectors for the final product. The final (and least exciting) task is to document how the design works for archiving. My experience is that FPGA designers find it straightforward and are actively working within a day on plain vanilla cores, but for more demanding designs, it’s wise to select an IP supplier that also offers a safety net with consultancy options.

One special consideration for encryption IP relates to confidence that the security hasn’t been compromised. A concern in any high-security design is to ensure that so called “back door” features haven’t been maliciously included. It’s important, therefore, to select a reputable vendor, which reduces the risk that a hostile intelligence agency has contributed malware or viruses to, say, an open source project. Licensing source code, rather than just a netlist, gives users the option to analyze the design. It also reduces the burden and cost of a detailed analysis of all the security components in the system.

Finally, an important consideration is reuse. In reality, most customers will continue to include the security systems they develop in future products, because reuse of blocks has doubled over the last decade. Larger companies will look for either a site-wide license so they have the flexibility to operate efficiently.

Paul Dillien, a Chartered Engineer, has worked with Algotronix Ltd., based in the UK, for the past six years. He previously worked in the FPGA industry and is the author of The FPGA Market report.

Paul Dillien, Algotronix Ltd.
Categories
Security