20 June 2022

"Akula" almost always holds surprises

"Akula" almost always holds surprises when it happens to came across its transmissions, is the case of a recording kindly sent me by my friend ANgazu that is characterized by at least three points:

1) the transmitter was used as soon as it was powered-on or in-standby: you may notice a slight frequency increase of a few seconds, about 37, before reaching the working frequency (figure 1): say that it's a kind of "cold-start" maybe due to an urgency call?

Fig. 1

2) one of the bursts is sent in inverse polarity (figures 2,3)

Fig. 2

Fig. 3

3) the initial bursts consist of a train of pulses (not always of the same number) instead of the usual 500Bd BPSK (figure 4)

Fig. 4

Also notice the transmission of the lower tone before and after the messages, it seems that the involved modems have different behavior. The number of the exchanges is also unusual.

However, it must be borne in mind that the current times are ...quite "particular".


18 June 2022

Some comments about the German Navy STANAG-4285 fleet broadcast

I noticed that in their STANAG-4285 600bps/Short fleet broadcast the German Navy use a 7-bit framing consisting of [5-bit data] + [one parity bit (even parity)] + [one pahsing bit], such framed stream is differential encoded and then forwarded to the S4285 modem.

Fig. 1 - 7-bit framing adopted in S4285 600bps/Short broadcasts

Fig. 2 - the differential decoded stream is parity bit checkd

Such peculiar framing, a "new one" for me, is used in several frequencies (see Table I) and most likely is thinked for their "domestic" fleet broadcast (as the French Navy does with their characteristic 21-bit framing); indeed in other S4285 frequencies the German-Ny run the NATO "standard" fleet broadcast consisting of the S4285 600bps/Long sub-mode and KW-46 encryption (figure 3).

Fig. 3 - KW-46 sync sequence in S4285 600bps/Long broadcasts

The 5-bit user data are most likely encrypted, the quality of the cryptography can be evaluated with a statistical method or by calculating the Shannon Entropy of a stream. The statistical test determines the randomness of the bit stream, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: If the information is not systematic, the adjacent columns should be half the size of the previous ones. The tes for these bit streams show good encryption quality. The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5

Fig. 4 - measurements about the presence of encryption in the 5-bit user data sub-frames

I also noticed that each 773 frames (5411-bit length blocks) a sequence of 588 bit length is inserted into the stream for a total length of 5999 bits (figures 5,6): that sequences are not repetitive, do not have a defined period, do not have a parity bit check, and do not seem  generated by a polynomial (at least in my attempts).

Fig. 5

Fig. 6

Just two coincidences:
1) in differential mode the bits after the inserts are of the same number of the inserted 7-bit frames (84)
2) as you know, the block consisting of 773 7-bit frames plus the 588 inserted bits has a length of 5999 bits that corresponds to a 10 seconds interval of a  stanag-4285 transmission at 600 bps (unless 1 bit)
In my opinion the 588-bit blocks are inserted before the differential encoder:

and they could be the "control bits" (also termed "EDAC bits", Error Detection And Correction bits) which are appended to the source bits after their comparison with a parity check matrix (1). If so, the dimension of the check sub-matrix shall be:

- (588 rows, 5411 columns) if the check is applied to [5-bit data]+[parity bit]+[phasing bit], ie to the whole 7-bit frame
- (588,4638) if the check is applied to [5-bit data]+[parity bit]
- (588,3865) if the check is applied to [5-bit data] only
Obviously, the possibility of such a matrix presupposes the use of a polynomial of degree 588 (!). 
But I have still some doubts. Data integrity is in some way "ensured" by the use of the parity bit and the differential encoder, moreover data are FEC encoded (rate 1/2) and interleaved by the S4285 modem, so why use a such complex CRC? It is also necessary to take into account the processing time necessary for the formation of one 588-bit block (and check it at receive side) since up to 5411 comparisons are required for each single EDAC bit (more than 3 million comparisons per block in the worst case, more than 2 million  in the better one).
Frequencies/modes so far monitored along with DFs of Tx sites (TDoA algorithm) are reported in this page.
18th June update
Discussing with my friend cryptomaster we think that the differential mode probably does not apply, indeed this "trick" of converting the phasing-bit to the parity-bit was noticed for istance some times ago when anaylzing the Chinese PSK2 2400Bd serial waveform:
Repeating the tests of my friend, I took a small amount of bits from an unsystematic stream (fig. 7a) and reshaped them to a 10-bit period stream (fig. 7b), then I edited the last column by inverting some bits and turned them into a phasing bits column (fig. 1c). As a result of the differential decoding, I received a uniform parity check, except for the first combination of bits (fig. 7d).
Fig. 7

That said, it could be that they use a channel which is designed to work with a 7-bit framing (for istance the one used in the "standard" NATO fleet broadcast) to send 5-bit encrypted data. If so, they have to add two bits (1's) to the 5-bit encrypted data and two bits (0's) to the 5-bit framed Initialization Vectors (perhaps to distinguish them?). The 588-bit CRC (computed on 773/761 frames) instead is sent as-is. Is not clear if CRC is computed on five or seven bit frames.

(1) As usual, code verification is carried out by comparing each line of code in turn with all the 588 rows of the check sub-matrix: the vertical correspondences of the "1s" positions in the code line and in the row #n of the check sub matrix are counted. If the matches are even then the correspondent position #n in the EDAC bits will be "1", otherwhise (ie matches are a odd number) will be "0". The values 1/0 of the EDAC bit will be the opposite in case of odd parity.