in questi giorni ho cercato di investigare alcuni segnali che usano i dispositivi hardware di cifratura KG-84 al fine di individuarne l' impronta al loro interno, nello specifico i segnali usati sono le due largamente usate waveform NATO STANAG-4285 e STANAG-4481-FSK, una delle numerose varianti di STANAG-4285 (probabilmente di origine Croata) e la waveform FSK 600Bd/400Hz impiegata dall'Esercito Turco. Dati questi solo 4 segnali, questo lavoro non ha la pretesa di offrire una vista completa ma piuttosto sara' aggiornato quando avro' a disposizione (leggi "ricevere") altri segnali che usano questo metodo di cifratura.
-
Dato un segnale, l'esistenza della cifratura KG-84 puo' essere rivelata dalla presenza o meno di una sequenza di 64 bits conosciuta e inserita all'inizio di ogni sessione o messaggio:
1111101111001110101100001011100011011010010001001100101010000001
la sequenza (che qui chiamo KG-84 resolver) e' poi seguita dai bit costituenti la chiave di cifratura.
Al fine di evidenziare il resolver dobbiamo lavorare sul bitstream dei dati, ovvero su files contenenti unicamente i valori binari "1" e "0" (files di testo chiamati in gergo ASCII-bits) e ottenibili da decoders quali l'ottimo Sorcerer.
L'operazione non avrebbe successo se andassimo ad esaminare i medesimi dati dopo la decodifica di un analizzatore di segnali quale SA perche' - appunto - SA e' protocol-aware, ovvero non conosce i protocolli. Cosa comporta questa "apparente" limitazione? Il fatto di essere protocol-aware ha come conseguenza che, per esempio, la decodifica di un segnale PSK-8 quale STANAG-4285 restituisce i simboli on-the-air (OTA-symbols, letteralmente "simboli in-aria") e quindi contenenti gli extra-simboli aggiunti dal FEC, che sono poi intercalati dall'interleave (LONG o SHORT che sia) e - per cosi' dire - confusi dallo scrambler. Tutto cio' e' utilissimo in fase di analisi del segnale ma aimhe' oneroso corredo che nasconde irrimediabilmente i dati "utili" o originari trasmessi. Ecco perche' occorre il bistream in uscita da Sorcerer o altro decoder: quest'ultimo conosce il protocollo e se correttamente impostato fa' per noi tutto il lavoro "sporco" (de-scrambling, de-interleaving e decodifica FEC) restituendo i dati in ingresso al modem... ovviamente cifrati.
L'analisi dei bistream e' realizzata con un apposito software per bit-flow editing e processing.
L'operazione non avrebbe successo se andassimo ad esaminare i medesimi dati dopo la decodifica di un analizzatore di segnali quale SA perche' - appunto - SA e' protocol-aware, ovvero non conosce i protocolli. Cosa comporta questa "apparente" limitazione? Il fatto di essere protocol-aware ha come conseguenza che, per esempio, la decodifica di un segnale PSK-8 quale STANAG-4285 restituisce i simboli on-the-air (OTA-symbols, letteralmente "simboli in-aria") e quindi contenenti gli extra-simboli aggiunti dal FEC, che sono poi intercalati dall'interleave (LONG o SHORT che sia) e - per cosi' dire - confusi dallo scrambler. Tutto cio' e' utilissimo in fase di analisi del segnale ma aimhe' oneroso corredo che nasconde irrimediabilmente i dati "utili" o originari trasmessi. Ecco perche' occorre il bistream in uscita da Sorcerer o altro decoder: quest'ultimo conosce il protocollo e se correttamente impostato fa' per noi tutto il lavoro "sporco" (de-scrambling, de-interleaving e decodifica FEC) restituendo i dati in ingresso al modem... ovviamente cifrati.
L'analisi dei bistream e' realizzata con un apposito software per bit-flow editing e processing.
 |
| Sorcerer in modalita STANAG-4285, output ASCII-bits |
STANAG-4285
 |
| pic. 1 - NATO STANAG-4285 |
in questo caso il resolver e' seguito da un gruppo di 512 bits costituito da due sequenze di 64 bits, come si vede chiaramente ciascuna ripetuta quattro volte: le due sequenze formano la chiave di 128 bits e sono indicate da Sorcerer come "inizialization vectors" (potete verificare che sono 2 stringhe ciascuna di 32 caratteri esadecimali). Da quanto si puo' vedere, la chiave e' inserita una sola volta all'inizio del messaggio e non viene re-inserita ciclicamente: in questo modo il messaggio non potra' essere decifrato in caso di sintonizzazione a trasmissione gia' in corso.
STANAG-4481-FSK
 |
| pic. 2 - NATO STANAG-4481-FSK |
dato lo stesso ambiente operativo (NATO), STANAG-4481-FSK adotta il medesimo schema visto per S-4285, ovvero: reversals, resolver di 128 bits e chiave distribuita nel susseguente blocco di 512 bits. Vale la pena notare in figura 3 come le sequenze di 64 bits generino nella parte iniziale della trasmissione spikes ACF di circa 850ms, ovvero di 64 bits dato che la velocita' del sistema e' di 75 bit/secondo(velocita' in Baud = bit/secondo nei sistemi FSK).
 |
| pic. 3 - 850ms ACF spikes due to key insertion |
variante STANAG-4285
 |
| pic. 4 a STANAG-4285 variant |
pur essendo compatibile con NATO S-4285, questa waveform non prevede l'uso della crittografia KG-84 bensi' una crittografia lineare proprietaria (la waveform e' probabilmente usata da organismi civili o militari Croati). Questo mette in evidenza che il processo di crittografia e' di per se' "esterno" al protocollo usato per la comunicazione in HF!
FSK 600Bd/400Hz (Esercito Turchia)
 |
| pic. 5 - the Turkish FSK/600/400 |
per quanto concerne la crittografia KG-84, questa waveform mostra una interessante peculiarita': il resolver non e' seguito dal blocco di 512 bits della chiave come visto nelle implementazioni S-4285 e S-4481 della NATO. Non conosco se i 128 bits immediatamente dopo il resolver sono proprio i bits della chiave o se questa e' ulteriormente "scrambled" e quindi nascosta ai decoders KG-84 standard: del resto e' comprensibile dato che anche questa e' una waveform proprietaria.
Come si vede dallo spettrogramma, la trasmissione consiste in 7 blocchi distinti e quindi e' logico aspettarsi (figura 6) una ripetizione di sette volte del resolver.
 |
| pic. 6 - the seven resolvers |
E' piuttosto inutile, e sarebbe spreco di spazio e banda, riportare qui informazioni e foto relative ai dispositivi KG-84 che sono gia' presenti e agevolmente rintracciabili sul web, giusto qualche link per approfondire:
Saludos!
Antonio, I5-56578
