8 February 2017

STANAG-4538: 3G-ALE FLSU calls with Linking Protection

Chasing 3G-HF transmissions in the 11 MHz band I copied several Fast Link SetUp calls carried by Burst Waveform 5 (BW5) payloads that after decoding appeared at least strange. Other than FLSU protocol, BW5 is also used by its closely associated FTM protocol and their PDUs (ie their Protocol Data Units) are distinguished by the first three bits of the 50-bit paylod: "001" for an FLSU PDU versus "100" for an FTM PDU:

Fig. 1
Well, a large part of the FLSU PDUs did not exhibit a valid protocol identifier but rather the not expected value "000"; other fields have inconsistent values in respect of the context and the destination/source addresses in the responses do not match the ones in the calls (Fig. 2). Decoder errors? yep, it could be... certainly is not a manufacturer implementation.

Fig. 2
Another sample of such weird BW5 PDUs is shown in Figure 3, probably an async FLSU call: decoder errors are still possible but, as you see, repeated errors in the same positions are rather unlikely. Moreover, the first 15 PDUs clearly exhibit alternating patterns that, in my opinion, make sense only in case of Linking Protection mode enabled.

Fig. 3
But how Linking Protection works in 3G-ALE networks?
Linking Protection (LP) encrypts only the PDUs used for link setup, traffic setup, link maintenance, link termination, and data link acknowledgement. LP scrambles PDUs using a scrambling algorithm that depends on a key variable, the time of transmission of the PDU, and the frequency on which it is sent (the latter two dependencies enter via a so-called “seed” that is distinct from the key variable): this achieves the two purposes of authenticating each transmission, and combining the called-PU network number with the other bits in an LSU PDU. Indeed, the network number of the called station is used in the linking protection as shown in Figure 4:  the network number is replicated to match the length of the LP encryption key in use in the network, and then exclusive-ored with that key for use as the key in the LP algorithm. 

Fig. 4
The seed format is shown in Figure 5, one may read the description of the fields in the paragraph "9.2 Seed Format" of STANAG-4538 profile: for the scope of this post I consider only the fields CVI and Word 

Fig. 5
The CVI (Code Validity Interval) field specifies time-units within each day. Normally, this field contains a count of the number of CVIs that have completely elapsed since midnight network time; the Word field is used to count PDUs within a CVI.

For what concerns the formation of the seed and the scrambling procedure, it's important to note that  once a linking process is started using a specific CVI, the calling PU must not change the CVI even if a CVI boundary is crossed during the linking process.
That said, the scanning asynchronous-mode call PDUs are scrambled using alternating Word Numbers 00000000 and 00000001 and the call PDU that concludes an asynchronous-mode call is scrambled using Word Number = 00000010. This means that the same 50-bit PDU is scrambled 15 times (in this sample) using two alternating keys, that's the reason of the alternating patterns seen above (Fig. 6).

Fig. 6
One could say that  the last PDU contains a valid 3-bit identifier in the protocol field  ("001") but I think it's a coincidence. Indeed, the scrambling procedure use the SoDark-6 algorithm (48-bit length) and then only the last rightmost 48 bits of each FLSU PDU are scrambled so the remaining bits, ie the first leftmost two bits, are sent without scrambling.
An example of "unprotected" asynchronous FLSU call can be read here

No comments:

Post a Comment