原创 Enrcypting Optical Transport Network

Anyone knowledgeable of the specifications of telecom protocols will recognize that they are both detailed and complex. So it is surprising -- especially given the revelations of whistle blowers such as Edward Snowdon and the current cyber security fixation -- that the Optical Transport Network (OTN) does not inherently feature any encryption.

The OTN's evolution has seen the successful inclusion of Ethernet packets into the payload. Originally, the OTN was designed to transport SONET/SDH, but it has been adapted to work with the faster Ethernet standards.

There is growing interest among equipment vendors in the notion of adding encryption to provide privacy and tamper detection on OTN systems with minimal added latency. The growing use of networks for applications such as financial transactions is a key driver for this technology.

Encrypting an OTN system requires the equipment vendor to work closely with an intellectual property (IP) vendor for several reasons. First, the method of securely transmitting the encryption keys must be organized. Fortunately, unlike in many systems, the keys in OTN systems are updated fairly infrequently. This allows for pre-computation of some encryption parameters in software, rather than providing hardware to compute them on the fly, as would be necessary in a protocol such as MACsec or IPsec, in which keys can change for every packet. Another issue is to get an efficient, low-latency core to fit into the design. Nearly every system contains a programmable logic chip such as a field programmable gate array (FPGA) to handle a range of protocol, framing, control, and interfacing tasks. The encryption IP core can be included in the FPGA. Where sufficient spare resources exist, this can even be achieved without moving to a larger device.

Algotronix Ltd.'s recently released OTN encryption core offers an interesting solution. The UK vendor has carefully optimized the core to be compatible with the traffic characteristics of the OTN system, such as fixed packet length. As a result, the lookup table (LUT) usage of the duplex AES-GCM core for the OTN is half what would be necessary for a duplex AES-GCM implementation for encrypting and decrypting 10G Ethernet packets.

The core provides AES-GCM with 96-bit IV and a choice of 128-bit or 256-bit keys. This gives privacy as well as confirmation that the decrypted packet has not been altered, which is mandatory for many systems. Designers can use recent FPGA families supplied by all leading vendors and select from a number of implementation options. Another very useful option is the ability to drive the FPGA tools into using certain resource types for key blocks of the core. The AES system requires the creation of what are known as S-Boxes as a significant part of the total resource requirement. Enabling the design tools to favor logic or memory blocks for these elements can allow the design to fit into the available spare capacity and therefore to squeeze the encryption core into a tightly packed layout.

One special consideration for encryption IP relates to confidence that the security has not been compromised. A concern in any high-security design is to ensure that so-called Trojan Horse features have not been maliciously included. It is important, therefore, to select a reputable vendor whose source code can be carefully inspected. It greatly reduces the risk that anybody has contributed malicious code 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.

Verification is the number one headache in system design. AES with Galois/Counter Mode (AES-GCM) was standardized by the National Institute of Standards and Technology (NIST) with a number of different operating modes. The institute also provides a large number of tests with "known answer" patterns to be used in implementation validation. For validation, it is good to know that the core ships with a comprehensive test bench including a behavioral model of AES-GCM. Along with the Algotronix-supplied testbench code, the core can also be simulated in a self-checking configuration within the user design, where it checks its output against a behavioral model.

The introduction of an IP core optimized for OTN systems gives equipment manufacturers the opportunity to differentiate their products with cost-effective, low-latency security features.