STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)
This document specifies protocol for supporting a Crypto Layer between STANAG 5066 and Modem, following the STANAG 5066 model which is currently deployed using synchronous serial interfaces following STANAG 5066 Ed3 Annex D. This protocol defines a generic framework for use with different encryption algorithms, with a specific mapping for AES encryption.
This document is published in the STANAG 5066 Extension Protocol (S5066-EP) series. The complete set of documents in this series are:
- STANAG 5066 Extension Protocol Index (S5066-EP1)
- STANAG 5066 Padding DPDU (S5066-EP2)
- Pipelining the CAS 1 Linking Protocol (S5066-EP3)
- Data Rate Selection in STANAG 5066 for Autobaud Waveforms (S5066-EP4)
- STANAG 5066 Large Windows Support (S5066-EP5)
- Slotted Option for STANAG 5066 Annex K (S5066-EP6)
- Advertising Extended Capabilities (S5066-EP7)
- Block Based EOTs (S5066-EP8)
- Compact Acknowledgement (S5066-EP9)
- Extension DPDU (S5066-EP10)
- Variable C_PDU Segment Size (S5066-EP11)
- HF Wireless Token Ring Protocol (S5066-EP12)
- STANAG 5066 Routing Sublayer (S5066-EP13)
- STANAG 5066 TRANSEC Crypto Layer using AES and other Protocols (S5066-EP14)
- AES Key Distribution for TRANSEC and Half Loop (S5066-EP15)
Isode whitepapers are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
1. Crypto between Modem and STANAG 5066
Use of Crypto between Modem and STANAG 5066 is the deployed architecture for STANAG 5066 encryption.
1.1. Architecture & Rationale
The architecture is shown above. Crypto is used immediately above the modem, which is the lowest possible point that Crypto could be inserted. A stream crypto is used, so that modem data errors only impact that data. When crypto is synchronized, it does not introduce additional errors. This is an efficient approach.
HF traffic is easy to monitor and even the lowest layers of STANAG 5066 contain information that is of potential interest. Therefore, it makes good security sense to perform encryption at this lowest possible layer.
1.2. Synchronous Serial
STANAG 5066 defines a Synchronous Serial data interface to the lower layers in Annex D, with clocking provided by the lower layer. This can be used to connect directly to a modem, or indirectly through a Crypto, with clocking provided by the modem.
Because there is no clear start/stop for a sync serial interface, it requires that STANAG 5066 uses leading and trailing padding to prevent data loss. It also requires that the receiver performs byte alignment on the received bit stream using the STANAG 5066 Maury-Styles header.
The Crypto is transparent in interface terms, but a STANAG 5066 implementation needs to be aware of Crypto overheads (in particular leading synchronization) which needs to be taken into account when calculating the D_PDU stream to be sent.
Sync serial is a particular problem with modern block-oriented modem protocols, as delays are introduced. This is discussed in detail in the Isode whitepaper [Reducing Turnaround Times in STANAG 5066].
In general, sync serial is awkward to use and introduces performance overheads that are tricky to address.
While sync serial remains the operational standard for many Nations, it is anticipated that in due course Nations using sync serial will cease use of these devices and move to other approaches.
1.3. Benefits of a Protocol Approach
This specification introduces a protocol approach, which gives the benefits of the architecture and removes the overheads and issues associated with use of sync serial. A number of implementation approaches are possible.
An implementation approach that could be taken is:
- Use the open TCP protocol interface specified in MIL-STD-188-110D Annex A to communicate between Crypto Layer and modem.
- Implement the Crypto Layer framing as specified here, as part of the STANAG 5066 server. This can offer:
- Built in AES support.
- Plugin options to drive other Crypto.
2. Crypto Considerations
Use of Crypto with HF is of particular importance to military organizations, that have specific requirements.
AES (Advanced Encryption Standard) is a widely adopted US Government standard for encryption. It is widely used for commercial, government and military operation. .
2.2. Type 1 Crypto and Product
NSA classifies cryptographic systems with different numbers, and Type 1 is required for handling sensitive information. This paper uses the term “Type 1” as a generic definition, as NATO and many countries have similar considerations.
Type 1 systems must use a Type 1 cryptographic algorithm, which includes AES. National cryptographic algorithms are often used in military systems.
A Type 1 product needs to be accredited to national standards, which is typically a slow and expensive process.
2.3. COMSEC vs TRANSEC
COMSEC (Communication Security) is the protection applied to user (red side) data. A Type 1 product is required for COMSEC.
TRANSEC (Transmission Security) is the protection applied at the lowest communication level, of which Crypto between modem and STANAG 5066 is a good example.
TRANSEC may be used to provide COMSEC, provided that the TRANSEC is Type 1 Crypto. COMSEC may be provided separately to TRANSEC, in which case the requirements on products used for TRANSEC encryption are generally lower than Type 1.
2.4. STANAG 5066 Protocol Sensitivity
The STANAG 5066 peer protocol (as distinct from user data) contains sensitive information, in particular addressing and priority information. It is important to encrypt this information, for the same reason that ALE addresses are protected with Linking Protection using AES in the Half Loop protocol (MIL-STD-188-141D).
3. Modes of Protocol Use
The protocol specified here is envisaged to be used in three different ways.
3.1. AES as TRANSEC & COMSEC
This protocol can be used with AES to provide both TRANSEC and COMSEC. This may be a good choice for non-military deployments.
3.2. AES as TRANSEC & IP Crypto as COMSEC
IP Crypto such as HAIPE is being widely adopted.
Use of IP Crypto with STANAG 5066, which will enable a Type 1 IP Crypto to provide COMSEC, as specified in Providing STANAG 5066 services over UDP/IP (S5066-APP4) and associated specifications.
This specification can then be used with AES to provide TRANSEC.
3.3. Type 1 Crypto as TRANSEC & COMSEC
This specification can be used with a Type 1 Product to provide TRANSEC and to achieve COMSEC with the same crypto. This means that only one Crypto layer is required, and the system will have higher performance that for a system that uses independent systems for COMSEC and TRANSE.
It will require accreditation of a Type 1 Product for use with HF, which is likely to be a cost that can only be justified by nations with significant resources for who HF is a priority.
4. Modem Service Specification
In order to understand how the Crypto Layer works, it is important consider the modem service interface.
4.1 Modem Transmission
STANAG 5066 will transmit over the modem a “bounded stream” of D_PDUs. This is sent as a sequence of bytes, with request to start transmission implicit in the first byte. When the last byte of the last D_PDU is sent, it is marked as “end of stream”.
STANAG 5066 will also set parameters for the transmission, which will be fixed for the period of transmission and will deal with any errors reported. Parameters include: speed; interleaver; waveform; waveform-specific parameters; bandwidth.
For duplex and broadcast, transmissions may be of arbitrary length. In other cases, transmissions are limited to 127.5 seconds and each D_PDU is marked with remaining transmission time (EOT) in units of 0.5 seconds. This information is transparent to the modem, but important for overall operation.
STANAG 5066 will know the speed of modem in order to calculate data to send and to keep up with the modem. Transmission length is determined as start of transmission. It is desirable to defer choice of which data to send, to enable insertion of high priority data arriving after a transmission starts.
4.2. Modem Reception
Under good conditions, modem reception of data will be entirely symmetrical, and a bounded stream of D_PDUs will be provide to the receiving server. On reception with modern waveforms, most transmission parameters are determined from the transmission. Dealing with modem reception issues is key to Crypto Layer design.
4.3. Determining Transmission End
Data is often lost or corrupted during transmission. A key problem is to determine end of transmission. There are strict rules for modem transmission. A receiving modem needs to apply heuristics to determine transmission end, particularly with poor HF conditions or aggressive choice of transmission speed.
There are two modem level mechanisms for determining end of transmission:
- Modem Protocol. This is supported in STANAG 5069, but not older protocols. It definitively marks end of transmission.
- EOM Marker. Two special bytes sent in the data stream. Care needs to be taken to handle the case where the “real data” includes this value. Heuristics to validate include ensuring that only “padding data” follows the EOM and that the RF signal falls off after the block is complete.
Both of these mechanisms can be “lost” due to fading or other data corruption. A modem will detect loss of RF signal. This can be an indication of transmission end or it could be a reception gap in a longer transmission. A modem will generally wait for a period before considering the transmission ended due to loss of RF. During this time, the modem will continue to send data to STANAG 5066 at “modem speed” and will maintain synchronization with the transmission (which may have ended).
The D_PDU EOT mechanism is helpful when the modem continues to receive in this way. The STANAG 5066 server can determine the end of transmission time from any single D_PDU. It will “know” that a transmission has finished, even when the modem continues to provide data. It will be able to switch to transmission, while the modem is still sending it data.
4.4. Modem Synchronizing During Transmission
HF Waveforms start with a robust synchronization sequence, and so normal expectation is that modems synchronize at start of transmission, so that data bytes are correctly aligned over the transmission, even when there is loss and corruption.
Modem protocols can resynchronize during a transmission. This means that data can start to be received part way through a transmission. Also, a transmission can be “lost” and then a latter part of the transmission picked up as a new transmission.
Some waveforms, notably STANAG 4539 and STANAG 4285, synchronize very well during when the initial synchronization fails and it is desirable to allow for this on reception.
STANAG 5069 does not synchronize well during a transmission, if the initial synchronization fails. This means that when STANAG 5069 is used, it may be desirable to use longer (and more robust) pre-ambles and may be desirable to avoid overly long transmissions.
5. Crypto Layer
5.1. Service Interfaces
The basic service model of this protocol is that the data interface to and from the crypto layer is essentially the same. This is in line with STANAG 5066 Annex D.
STANAG 5066 needs to be aware of the protocol overheads of the Crypto Layer, so that it can correctly calculate transmission lengths. It may also choose to align D_PDU boundaries to modem block boundaries, which can be done precisely with this protocol stack.
5.2. Crypto Mapping & Counter Mode
The Crypto needs to operate as a stream crypto. Most modern encryption algorithms are block-oriented, which cannot be used directly. This is addressed with Counter (CTR) Mode, which is a mechanism to provide stream encryption from a block cipher. This is now widely recognized as a secure approach.
Counter mode works by initializing the cipher with an Initialization Vector (IV) and/or a Nonce. This then generates a crypto stream of bytes with as many bytes as needed. Sender and Receiver share the IV/Nonce and so can generate identical crypto streams.
The sender will XOR the data stream with the crypto stream to produce a transmission stream, which is sent between the modems. The receiver can then XOR the received transmission stream with the crypto stream to restore the data stream sent by the peer STANAG 5066 server. This received stream may have data corruption due to modem level HF errors.
The strict synchronization of modem data transfer ensures that the streams remain aligned over the complete transmission.
5.3. Crypto Initialization
This section considers crypto initialization in more detail.
5.3.1 General Model
There is information which needs to be shared between sender and receiver which is configured prior to the transmission. This might be an external mechanism such as HAIP pre-placed keys, or longer-term mechanisms such as IPsec Sessions described below.
Then there is information provided for each transmission, which will typically be an IV and/or Nonce, but there could be other information for different encryption mechanisms.
5.3.2. AES Initialization
RFC 3686 "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)" addresses a very similar problem. It uses AES Counter Mode to encrypt the payload of IPsec packets. This protocol adopts the RFC 3686 model and uses the same IV and Nonce sizes. Key points from RFC 3686 on the recommendations for encrypting IP:
- An eight byte IV is used and sent with each IP packet.
- There is a Session, which is implicitly referenced and has:
- AES Key.
- 4 byte Nonce (which does not need to be private)
- It is strongly emphasized the IV must be unique for each IP packet handled in a session.
These recommendations are not used directly, but have provided input to the design choices in this specification. In particular, the same IV and Nonce sizes are used.
AES key and Nonce update are handled in a separate specification, [AES Key Distribution for TRANSEC and Half Loop (S5066-EP15)].
Each transmission will provide a 2 byte reference to the AES Key/Nonce pair. This reference enables:
- Different keys may be used for different pairs of 1:1 communication and multicast/broadcast groups.
- New keys can easily be used in the event of key compromise.
- Giving keys a limited lifetime, with migration to new keys.
Each transmission will include an 8 byte IV that is unique for the AES Key/Nonce pair. Uniqueness can be ensured by simple incrementing or by Linear Feedback Shift Register. The last IV used should be recorded on permanent storage, so the unique IV will be ensured in the event of restart.
5.3.3. Resilience over HF
Transferring the initialization information needs to address potential corruption on transfer. HF errors tend to cluster, so the best approach to resilience is to repeat the information at intervals in the data stream.
The protocol also needs to address the possibility of the initial modem synchronization not happening. This is done by use of extended information that includes:
- A Maury-Styles two byte pair, that enables synchronization.
- A counter to enable the amount of preceding data to be calculated. This will enable to full crypto-stream to be determined, so that the received data can be XOR’d from the correct point.
6. Crypto Layer Protocol
The Crypto protocol defines two PDUs. The Crypto Sync PDU is specified as follows.
For this version of the protocol, Version=0. The Algorithm identifies that Algorithm used. The length and semantics of the Crypto Sync bytes are determined by the Algorithm.
AES has Algorithm=0, and the following encoding to give an 11 byte PDU.
Initialization Vector (IV)
The Key/Nonce Reference is two bytes and identifies the AES Key and Nonce pair to be used.
The Initialization Vector is an 8 byte IV.
The Extended Crypto Sync PDU is defined as follows:
Maury-Styles is a two byte fixed header using the STANAG 5066 Maury-Styles value (90EB). Sync Counter indicates the number of the Extended Crypto Sync PDU. The first one is numbered 1, the second 2, and so on. For AES, this PDU is 15 bytes long.
Because transmission times can vary from less than a second to many minutes and speeds from 75bps to 240 kbps, there is a high variation of size of bounded stream. Repetition of Crypto Sync PDUs needs to be close enough to ensure repetition at the slowest speeds and to provide reasonable spacing at higher speeds.
For the first 4096 bytes of transmitted data, a Crypto Sync PDU is inserted every 256 bytes. The diagram above shows the start of transmitted data. For AES, the Crypto Sync in this region has an overhead of 4.3%.
After the first 4096 bytes and Extended Crypto Sync PDU is inserted every 4096 bytes. The above diagram shows the transition from the end of the first 4096 bytes. For the extended region, AES Crypto Sync overhead is 0.4%.
7. Changes to STANAG 5066
This document defines a new sublayer for STANAG 5066. This would best be incorporated as a replacement for Annex D, which defines the modem data interface.
8. Backwards Compatibility
This protocol is not interoperable with STANAG 5066 Ed3. When it is deployed, all nodes on the network must make use of it.