NIER Ingegneria è diventata Società Benefit →
TORNA AGLI ARTICOLI
21 Settembre 2023

CRITTOGRAFIA: CYBER SECURITY NEI SISTEMI DI COMUNICAZIONE DI SEGNALAMENTO FERROVIARIO.

Approfondimento sulla crittografia in ambito ferroviario.

A cura di Emiliano La Cara
[Direttore Area Ingegneria del Software]


INTRODUZIONE.

Nelle infrastrutture ferroviarie, i sistemi di comunicazione sono una parte molto sensibile, sia quando la comunicazione avviene su una rete chiusa, sia quando essa avviene su rete aperta. Infatti, la gestione del traffico in tali infrastrutture dipende completamente da come gli attori coinvolti comunicano gli uni con gli altri.

Ad esempio:

  • il computer centrale (detto ACC – Apparato di Comando e Controllo), comunica con gli attuatori sulla linea, detti Trackside Element (TE), come deviatoi, semafori, passaggi a livello, etc.
  • il computer centrale comunica, inoltre, con i treni grazie ad un altro attore chiamato Radio Block Center (RBC) che si interfaccia col treno da una parte e con ACC dall’altra.

Ma cosa significa “reta aperta” o “rete chiusa”?

Una rete aperta è un sistema di comunicazione accessibile a tutti nel quale ogni utente può collegarsi liberamente a qualsiasi altro. L’esempio più comune è Internet.

Una rete chiusa è un sistema di comunicazione locale, ovvero non connesso a reti esterne. Il sistema consente l’accesso e l’utilizzo solo a un certo numero di utenti individuati con un identificativo univoco: non è possibile alcun accesso non autorizzato. L’esempio più comune è rappresentato dalle reti aziendali private, non connesse ad Internet, utilizzabili solo dai dipendenti dell’azienda.

Mentre una rete chiusa è, a livello intrinseco, sicura nei confronti di introduzione malevola dall’esterno (attacco cyber), quella aperta è più esposta e soggetta ad azioni di intrusione avversa (hacking).

Lo standard GSM (Global System for Mobile communications), riferimento globale per le comunicazioni telefoniche mobili, è un sistema di comunicazione aperto ed è stato adottato, ed adattato, come mezzo di comunicazione nel sistema europeo standardizzato di gestione del traffico ferroviario, l’ERTMS/ETCS (European Rail Traffic Management System/European Train Control System) e prende il nome di GSM-R (GSM-Railways). Questo sistema, fino ad ora presente solo per le linee ad Alta Velocità (AV), nei prossimi anni sarà adottato anche nelle tratte regionali e ne deriverà, quindi, una sua diffusione capillare sul territorio.

La Figura 1 mostra l’utilizzo del sistema GSM-R all’interno dell’ERTMS di Livello 2[1]. Le informazioni necessarie per il controllo del traffico ferroviario (stato segnali, disponibilità di sezioni di binario, stato deviatoi ecc.) sono scambiate tra gli elementi di linea (TE) e ACC tramite uno standard di comunicazione, definito protocollo vitale Standard PVS, via Ethernet. Sulla base di tali informazioni e sulla base di quelle che RBC riceve dal treno (posizione, velocità senso di marcia etc.) utilizzando un altro standard di comunicazione, definito Euroradio ER, via rete GSM-R, RBC trasmette i permessi di movimento ai singoli treni.

Queste informazioni e i protocolli con cui esse vengono veicolate, sono detti Vitali: a fronte di errori e/o malfunzionamento (che impattano l’integrità, la freschezza e la correttezza delle  informazioni trasmesse) si potrebbero verificare incidenti mortali se non fossero previste contromisure sicure per mitigarne l’effetto potenzialmente disastroso.


[1] ERTMS/ETCS può essere di 3 livelli, a secondo di come le informazioni del treno (velocità, direzione, senso di marcia etc) vengono trasmesse e scambiate. Per semplificare al massimo lo schema in Errore. L’origine riferimento non è stata trovata. sono state omesse le eurobalise.

crittografia
Figura 1 – GSM-R ed ER, Ethernet e PVS in un’architettura ERTMS/ETCS

La precedente descrizione, estremamente semplificata, ha il solo scopo di fornire un quadro generale della complessità insita nelle comunicazioni alla base di un sistema di segnalamento ferroviario, nella fattispecie ERTMS/ETCS.

In questi sistemi la crittografia è fondamentale per garantire una protezione contro potenziali interventi malevoli che avrebbero come fine ultimo quello di introdursi nella rete ferroviaria e causare problemi che metterebbero in pericolo convogli e passeggeri.

Esistono diversi algoritmi e livelli di crittografia che possono essere adottati a seconda del livello di sicurezza da garantire ed in funzione del protocollo che deve essere protetto. Per il protocollo ER esistono due livelli di cifratura (DES[2]+ CMAC[3]) così come accade per l’altro standard di comunicazione ferroviario PVS (AES[4]+ CMAC).

In quest’ultimo, in origine, era presente un solo livello di cifratura (AES) ma successivamente è stato aggiunto un secondo livello di cifratura, CMAC, a seguito del rilevamento di una debolezza per cui un utente malintenzionato avrebbe potuto compromettere la sicurezza della comunicazione.

  1. Analisi degli algoritmi implementati dal software applicativo
  2. Analisi bibliografica dello stato dell’arte degli algoritmi di crittografia CMAC ed AES
  3. Identificazione di algoritmi alternativi a quelli del software di processo per garantire la software diversity della soluzione proposta
  4. Test del software secondo gli standard di riferimento della crittografia e di quelli forniti dalle normative CENELEC 50128. In particolare, La validazione del tool è stata ottenuta applicando il tool ai Test Vectors del documento RFC 4493 (June 2006) e sulle specifiche del PVS di RFI (RFI DTCDNSSS RT IS 05 021 rev.F ).
  5. Validazione del software su trame ethernet prodotte da apparato reale
  6. Stesura della documentazione necessaria alla validazione del tool T3 rilasciato.

COME FUNZIONANO I TOOL?

Innanzitutto, partiamo da una rappresentazione semplificata del messaggio PVS (Figura 2) dove è possibile apprezzare i campi DATA e la parte di dato Cifrato, detto SafetyCode, con i due livelli di encryption.

Figura 2 – rappresentazione schematica semplificata di una trama PVS (DT)

Col primo tool (Figura 3):

  1. Viene acquisita la comunicazione ethernet PVS e da un messaggio si estrae la sua parte di DATI in chiaro, su cui viene calcolata la cifratura CMAC (con algoritmo indipendente da quello utilizzato dal software applicativo);
  2. Dallo stesso messaggio si estrae la parte di ‘SafetyCode_AES_CMAC’, ovvero con già cifratura di secondo livello e si pone in XOR bit a bit con il CMAC calcolato a punto 1 ottenendo il cosiddetto SafetyCode_AES cifratura di primo livello);
  1. Si applica un algoritmo alternativo di decifratura AES (indipendente da quello utilizzato dal software applicativo) del codice ottenuto al punto 2 che fornisce un SafetyCode decifrato a 16 byte: se i primi 8 byte sono uguali ai secondi 8 byte si ha verifica della corretta cifratura di primo e di secondo livello. Infatti, in PVS il SafetyCode è lungo 8 byte ma l’applicazione della cifratura AES richiede uno stream di almeno 16 byte. Per questo motivo l’encryption viene applicata al SafetyCode “duplicato” in modo da avere uno stream di 16 byte su cui calcolare AES: indicando SafetyCode con SC, in pratica AES viene applicato sullo stream di byte SC|SC motivo per cui se il risultato finale fornito dal tool è composto da due word di 8 byte uguali si ha garanzia della corretta cifratura/decifratura;
  2. Vengono confrontati il CMAC del punto 2 (ricavato dal pacchetto) con il CMAC del punto 3 (calcolato indipendentemente) per verificarne l’uguaglianza.

[2] Data Encryption Standard, algoritmo di cifratura asimmetrico, un po’ datata (1977)

[3] Cypher-based Message Authentication Code (MAC) è un piccolo blocco di dati utilizzato per garantire l’autenticazione e integrità di un messaggio digitale, generato secondo un meccanismo di crittografia simmetrica.

[4] Advanced Encryption Standard (AES), è una specifica per la crittografia dei dati stabilita dal National Institute of Standards and Technology (NIST) degli Stati Uniti nel 2001

ESEMPI

Figura 4 – Tool 2 – Algoritmo

Col secondo tool (Figura 4):

  1. Viene acquisito il traffico ethernet PVS e da un pacchetto si estrae la parte di DATI, su cui viene prima calcolato il Safety Code e poi applicata la cifratura AES (con algoritmo indipendente da quello utilizzato dal software applicativo), ottenendo il safetyCode_AES
  2. Si estrae dal pacchetto la parte SafetyCode_AES_CMAC e si mette in XOR bit a bit con il safetyCode_AES calcolato al punto 1, ottenendo il CMAC
  1. Si calcola il CMAC sulla parte dati estratta al punto 1 (algoritmo indipendente)
  2. Vengono confrontati il CMAC del punto 2 (ricavato dal pacchetto) con il CMAC del punto 3 (calcolato indipendentemente) per verificarne l’uguaglianza

Figura 4 – Tool 2 – Algoritmo

DALLE PAROLE AI FATTI .

Contattaci per saperne di più sull’argomento dell’articolo.

    Condividi .