Icon-TRANSEC: Providing AES Crypto for STANAG 5066

Why a replacement for current Sync Serial Stream Crypto is desirable

The traditional way to provide crypto for HF is to use synchronous serial stream crypto device, such as the KIV-7 shown above. This usage is set out in Annex D of STANAG 5066. There are a number of reasons why it is desirable to stop using this class of device:

1. Many devices of this class are old and reaching end of life.
2. It is awkward to integrate with a modern software STANAG 5066 product such as Icon-5066, as specialized synchronous serial hardware is needed. This adds cost and reduces deployment flexibility.
3. Padding on start and finish transmission is needed to deal with crypto overheads.
4. For modern block based waveforms, such as STANAG 4539 and STANAG 5069, significant latency is introduced. This is discussed in the Isode whitepaper Reducing Turnaround Times in STANAG 5066. These overheads significantly impact performance.

STANAG 5066 Annex T

STANAG 5066 Annex T “STANAG 5066 TRANSEC Crypto Sublayer using AES and other Protocols” specifies a modern mechanism for providing TRANSEC layer crypto. Key features:

1. Can use AES to protect the link. AES is an open standard widely used crypto, which is also a Type 1 crypto considered suitable for military use.
2. Provides a framework for use of other crypto protocols, so that it can be used with sovereign and other encryption protocols
3. Allows use of multiple keys. This enables convenient key migration without exact changeover times and means that keys for an extended future period can be distributed in advance, for example on a ship.
4. It provides mechanisms to deal with HF corruption of the initial data stream and ensure resilience.

Icon-TRANSEC

Icon-TRANSEC is Isode’s implementation of Annex T. It is currently a prototype, with intention to become a full Isode product. It is used in conjunction with Icon-5066, Isode’s STANAG 5066 server.

The diagram above shows the data flow between Icon-5066 and a modem. There is also a control flow, which is not shown. Icon-5066 core uses a generic “Isode Data Protocol” for internal communication. When Annex T is not used, this protocol is used to communicate with a Data Driver which in turn communicates with a modem. The data driver supports a number of data protocols:

1. Synchronous Serial (using special hardware) to comply to STANAG 5066 Annex D. This is not expected to be used in conjunction with Annex T
2. MIL-STD 188-110D Annex A specifies a TCP protocol designed for driving a modem. Isode recommends this protocol, as it has excellent characteristics.
3. TCP. Some modems support a simple TCP data stream.
4. Asynchronous Serial. some modems allow data using Asynchronous Serial.

Icon-TRANSEC basic operation is a stream service that can sit as an independent module in the modem data stream and implement Annex T.

Annex T adds a small overhead to the data stream (about 1%). STANAG 5066 needs to make calculations on how much data to send, which needs to take into account these overheads. So there is an option on the core to allow for these overheads.

Experience with Annex T

The implementation of the Annex T protocols was able to follow the specification and provide a working implementation. This implementation provides validation of the Annex T specification.

The implementation was built in the knowledge that Annex T was modelled in RFC 3686 “Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)”. This was made clear in the Isode specification S5066-EP14, on which Annex T was based. It has become clear that Annex T needs some clarifying text to define user of AES-CTR mode and either reference or include some text from RFC 3686. These changes will be prepared. They are seen as important to make the specification fully interoperable.

The implementation has a special interpretation of key-id=0, to use fixed encryption key and nonce values and to not increment the IV. This has proved very useful for testing, and it is recommended that this behaviour be included as a testing option in Annex T.

Crypto Sync HF Resilience & Measurements

Annex T is designed to provide resilience against loss of the initial data. When used for bulk traffic, HF speed selection will typically be optimized to lead to 20-50% data loss. HF errors tend to cluster, and can lead to whole blocks of data being corrupted. A simple approach of putting crypto initialization up front is not going to be resilient against initial data loss.

The way that Annex T provides resilience is by repeating crypto sync information. Later repeats also include Maury Styles synchronization so that crypto sync can be provided when modem synchronization occurs during the transmission. The pattern of repeats is designed so that it can support speeds to cover HF/WBHF range from 75bps to 240kbp, particularly to provide protection against loss of first modem block.

This reliability has been proven in the lab with runs using modem simulations.

It is desirable to validate the assumptions of the Annex T design, which leads to a 1% overhead, by testing OTA with real HF. The key test is to measure the percentage of transmissions where the initial sync is missed. If this is around 1% or more, the Annex T design is a clear win. When a transmission fails, the performance loss is greater than just the transmitted data, as there can be application and recovery overhead.

OTA Tests have been conducted using Collins-provided infrastructure between Richardson Texas and Oxford Junction Iowa, using Collins RT-2200A Modem/Radios. Test run made on 9th February 2023. The test alternated transfer of bulk data using STANAG 4406 Annex E messages in both directions. Conditions were mixed with speeds ranging from 75bps up to 96,000 bps. About 75 Mbyte of data was transferred, including retransmissions. The data was analyzed to consider the number of crypto synchronizations where the first sync block was corrupted.

In performing this analysis, it was determined that not all corrupted first blocks were logged, so we believe that these numbers are on the low side. These numbers give a clear indication that the design assumptions for Annex T were correct and that the mechanism of repeating sync blocks is expected to deliver significant operational improvement.

Icon-TRANSEC: Short Term Plans

Isode plans to release Icon-TRANSEC as a prototype that will be available to partners and customers for testing. We see that it is important to gain experience with this new technology as soon as possible.

Requirements for Full Deployment

Icon-TRANSEC provides critical security. To be deployed, a number of issues would need to be addressed:

1. Separation. The model of “sitting in the data stream” may not provide sufficient separation, noting the Icon-5066 server will generally sit on red side and the modem on black side. Icon-TRANSEC offers a second integration mode with the secure GCXP (Guard Content eXchange Protocol) used in Isode’s M-Guard product that provides Red/Black separation and crypto bypass. This would enable Icon-TRANSEC to sit on a boundary device, perhaps using the same hardware as M-Guard.
2. Assurance/Accreditation. There would need to be a clear approach to achieving accreditation of a system to be deployed.
3. Key storage. There would need to be an agreed secure approach for storing the necessary AES keys.
4. Key Management. There would need to be an agreed approach to distributing keys for use on deployed systems.

Isode is keen to progress these issues, but believes that these cannot be addressed in isolation. We are interested to work with partners and customers on an approach that can be deployed.

Conclusions

This white paper has described how STANAG 5066 Annex T has been implemented and validated in Isode’s Icon-TRANSEC prototype product. This looks to be an excellent path for replacing older synchronous serial crypto.