Protocollo di trasmissione proprietario

SOMMARIO

Nell'ipotesi di mettere in comunicazione seriale (via cavo, infrarosso o RF) due dispositivi con caratteristiche diverse (quanto a frequenza di lavoro e potenza di calcolo, per esempio), si discute un protocollo di trasmissione seriale per l'invio di informazione cifrata, come realizzata nel post  Algoritmi di cifratura proprietari.

CRITERI DI RIFERIMENTO

Dovendosi applicare anche a dispositivi a batteria, un criterio-base è la minimizzazione dei consumi: il protocollo deve minimizzare l'invio della portante. Un altro criterio è l'autosincronizzazione del segnale: nella codifica-dati deve essere intrinseco il segnale di sincronizzazione fra il dispositivo trasmittente e ricevente. Un terzo criterio è una buona immunità al rumore.
Per nostra fortuna, questi criteri sono già stati presi in considerazione in moltissime consolidate applicazioni: in particolare, sono alla base della maggior parte dei protocolli usati per i segnali dei telecomandi ad infrarosso, ai quali ci ispireremo.

CODIFICA DATI

La codifica-dati suggerita è rappresentata schematicamente in Fig.1.

Fig.1

L'unità di informazione (per esempio 64, 128 o 256 bit) che rappresenta un comando o la misurazione di una o più variabili di stato del dispositivo trasmittente, viene generalmente ripetuta più volte.
Per assicurarsi che il dispositivo ricevente agganci il segnale correttamente dall'inizio e ad esso si sincronizzi, il primo impulso è più lungo e caratterizza lo start bit. Seguono una serie di corti impulsi (la cui durata è ininfluente, l'unico discrimine è farli più lunghi di eventuali impulsi di disturbo della trasmissione). L'informazione è contenuta nelle pause, cioè nell'intervallo fra un impulso e l'altro. Un intervallo di durata DT codifica uno "0", mentre un intervallo di durata 2DT codifica un "1".
Poichè l'informazione scambiata è cifrata, il dispositivo ricevente generalmente conosce la lunghezza dell'unità di informazione ricevuta; perciò alla fine della sequenza un end bit serve principalmente a separare una ripetizione dell'invio dell'informazione.
Una pausa più lunga di 3DT denota assenza di trasmissione.

STRUTTURA DELL'UNITA' DI INFORMAZIONE

Nel caso più completo, l'unità di informazione trasmessa contiene i seguenti elementi, visibili in Fig.2:

  • un numero di invio che viene incrementato ad ogni invio
  • un codice identificativo del trasmittente
  • un codice identificativo del ricevente
  • un codice che rappresenta un comando o altro dato rilevante

Fig.2

DISCUSSIONE

Lo scopo principale della cifratura è quella di rendere sicura e non riproducibile la comunicazione fra i dispositivi. Sfortunatamente se si usa una portante a radiofrequenza, per esempio a 433MHz come alcuni componenti a bassissimo costo usano, il segnale trasmesso può essere facilmente captato, registrato e ritrasmesso. Una strategia per evitare intrusioni e utilizzi fraudolenti della comunicazione si può realizzare con un uso accorto della struttura dell'unità di informazione descritta precedentemente. Per fissare le idee, supponiamo che fra trasmittente e ricevente avvenga la trasmissione di un'unità d'informazione a 128 bit, cioè 16 byte. Supponiamo, per esempio, che i quattro elementi dell'unità d'informazione siano rappresentati ciascuno da 4 byte, cioè da un valore fra i 4.294.967.296 possibili per ciascun elemento.
Se il ricevente ricevesse una stringa di dati di 16 byte, inviata da un intruso che tenta, con algoritmi di forza bruta, di trasmettere comunicazioni fraudolente, non conoscendo l'algoritmo di cifratura, avrebbe scarsissime possibilità di venire ingannato. Il ricevente, infatti, dopo la decifrazione della stringa, cercherà il suo codice identificativo e l'intruso ha 1 probalilità su 4 miliardi di inviare l'esatto codice identificativo. Inoltre anche la decodifica del comando o del dato ricevuti potrebbe rivelare una struttura non valida o senza significato.
Un potenziale problema potrebbe essere dato dalla possibilità che un intruso capti e registri una stringa valida trasmessa, con l'intento di riutilizzare successivamente, per propri fini, la trasmissione (si pensi ad un comando a distanza di apertura auto o saracinesca ). Se però ad ogni trasmissione, il dispositivo trasmittente incrementa il suo contatore di invio, il ricevente può registrare, per ciascun trasmettitore identificato dal suo codice identificativo, il progressivo di invio. Se dovesse ricevere una stringa da un dato trasmettitore, considerererà valida la stringa che avrà un progressivo maggiore di quello registrato (solo dopo 4.294.967.296 il numero d'invio tornerebbe a zero, ma per dare un'idea, anche se si trasmettesse ininterrottamente una volta al secondo, occorrerebbero oltre 136 anni per tornare a ripetere il numero di invio).
Ecco l'importanza del numero progressivo d'invio, mentre l'identificativo di trasmittente potrebbe essere omesso, se si assumesse che esista un solo dispostivo a trasmettere. Anche il codice di comando o dato potrebbe essere omesso, se una trasmissione valida desse luogo sempre ad un solo comando (per esempio di azionare qualcosa). Un identificativo di ricevente è invece sempre opportuno, per evitare che casualmente una stringa generata in modo casuale risulti valida dopo la decodifica o nel caso siano presenti più di un dispositivo ricevente, con cui comunicare in modo esclusivo.

SIMULATORE

Usando l'algoritmo descritto nel post Algoritmi di cifratura proprietari, ecco di seguito come avverrebbe la trasmissione a 128 bit (16 byte) fra la trasmittente AABBCCDD che cominciasse a trasmettere (quindi con codice iniziale d'invio 00000000) alla ricevente 12345678 il comando AAAAAAAA:


Premendo invia codice il simulatore incrementa il contatore di invio e in CODICE TRASMESSO si può vedere come si trasforma il codice in chiaro per effetto della cifratura. Quindi, per esempio, il codice in chiaro: 00000001AABBCCDD12345678AAAAAAAA diventa FE12E8247C7016F133B3717A150FD3C7. Se a questo punto si preme ricevi codice il simulatore esegue la decifratura del codice trasmesso. Se non riconosce l'identificativo ricevente 12345678 e/o il comando AAAAAAAA risponde Codice NON Corretto. Se riconosce i codici verifica che il contatore d'invio letto sia maggiore dell'ultimo riconosciuto: se lo è risponde Codice Corretto, altrimenti Codice Scaduto. Per provare il reinvio di un codice già usato, premere ripeti codice.
Una volta inviato il codice è possibile alterare il codice cifrato prima di farlo ricevere: si simula un difetto di trasmissione, basta alterare la sequenza di un solo bit (per esempio cambiando un 1 in 3 per verificare quanto si altera la decifratura e di conseguenza fallisce il riconoscimento dei codici. Per esempio, se dopo l'invio del codice 00000001AABBCCDD12345678AAAAAAAA si modifica il codice trasmesso FE12E8247C7016F133B3717A150FD3C7 in FE12E8247C7016F333B3717A150FD3C7, invece di 00000001AABBCCDD12345678AAAAAAAA dopo la decifratura si ottiene 7FC70FA870964F78AB33C9A523995EC7, completamente diverso. D'altronde lo stesso risultato si ottiene confrontando la cifratura di:
00000001AABBCCDD12345678AAAAAAAA che dà FE12E8247C7016F133B3717A150FD3C7,
00000002AABBCCDD12345678AAAAAAAA che dà C8F3BF74ECCB10C79170D06903959E87.