Capitolo 3 H.235 – Sicurezza e procedure di crittografia

Capitolo 3

H.235 – Sicurezza e procedure di

crittografia

La sicurezza dell’informazione rappresenta, soprattutto in ambito militare, un aspetto non trascurabile all’interno di ogni tipo di comunicazione. La classifica (il livello di segretezza*_{) associata ad} una data informazione dipende strettamente dall’importanza che ad essa corrisponde. Il contenuto di un messaggio sarà tanto segreto quanto più la sua incauta diffusione, o la conoscenza di esso da parte di un’entità estranea, può arrecare danno alla fonte che lo ha emesso o al destinatario. E’ per questo motivo che, là dove sussiste la necessità operativa, si devono adottare particolari accorgimenti e precauzioni ogni qualvolta avvengono scambi di informazioni sensibili. Un altro aspetto da sottolineare è che il formato elettronico delle informazioni, che oggi circolano sulle reti, se da un lato ne indebolisce la sicurezza, dall’altro rende più automatici i processi di protezione dell’informazione e procedure di crittografia ed

autenticazione. L’architettura del SIT è predisposta

all’implementazione di vari livelli di sicurezza; la specifica tecnica dalla quale è partito questo progetto non impone (almeno all’inizio) regole restrittive in ambito di sicurezza, in quanto non sono previsti scambi di informazioni classificate. E’ anche vero che esigenze operative impongono sempre una precisa politica di autenticazione

che garantisca l’identità del presunto interlocutore e protegga il sistema da eventuali errori o manomissione, da parte di malintenzionati, delle informazioni scambiate.

I sistemi H.323, che funzionano su reti a pacchetto, non garantiscono a priori un servizio sicuro. La comunicazione sicura in tempo reale coinvolge generalmente due importanti settori di interesse: autenticazione e segretezza. La raccomandazione H.235 fornisce il protocollo e gli algoritmi necessari a garantire la sicurezza fra le entità H.323. Essa utilizza le installazioni generali sostenute nell’H.245 e come tale, ogni standard che funziona con questo protocollo di controllo, può usare questa struttura di sicurezza. È previsto che, ove possibile, altri terminali di H-serie possano interoperare e direttamente utilizzare i metodi descritti in questa raccomandazione. Una prima implementazione del SIT potrà garantire l’identità dell’utente attraverso un login ed una password. Successivi upgrades potranno migliorarne la sicurezza e aggiungere nuove funzionalità come ad esempio la cifratura (encipherment)* degli streams di dati, etc... L’H.235 suggerisce algoritmi di crittografia e procedure di gestione e scambio delle chiavi rigorosamente standard: questo assume un carattere importante, sia per l’interoperabilità con altri sistemi, sia per garantire i presupposti, eventualmente in futuro, per adeguare il sistema stesso a standard militari (NATO).

I termini contrassegnati con un asterisco sono definiti meglio nell’Appendice A al termine di questo capitolo.

3.1 Scopo della raccomandazione H.235

Il fine primo di questa raccomandazione è fornire servizi per l’autenticazione*_{, la segretezza}* _{(privacy) e l’integrità}*_.

Gli obiettivi supplementari in questa raccomandazione includono: 1) L'architettura di sicurezza si sviluppa come una struttura

estendibile, flessibile e con servizi indipendenti per i terminali H-series; questo include l’abilità a negoziare e selezionare il tipo ed il modo in cui le tecniche crittografiche possono essere utilizzate. 2) Fornisce la sicurezza per tutte le comunicazioni che sono

conseguenza dell'uso del protocollo H.3xx. Ciò include le funzioni di connessione, del controllo di chiamata e dello scambio di media fra tutte le entità. Questo requisito include l'uso della comunicazione confidenziale (privacy) e può espletare le funzioni per l'autenticazione, così come protezione dell'utente dagli attacchi*_.

3) Questa raccomandazione non preclude l'integrazione di altre funzioni di sicurezza, nelle entità dell’H.3xx, che possono proteggerle dagli attacchi provenienti dalla rete; non limita la possibilità per ognuna delle H.3xx-series ad essere scalabile nella maniera più opportuna. Ciò può includere sia il numero di utenti coinvolti che i livelli di sicurezza forniti

4) Tutti i meccanismi e le facilities sono forniti indipendentemente dal sottolivello di trasporto o topologie.

5) Le disposizioni sono fatte per il funzionamento in un ambiente misto (entità sicure ed entità non garantite).

6) Questa raccomandazione fornisce i mezzi per la distribuzione (amministrazione*_{) chiavi di sessione connesse al metodo} crittografico utilizzato.

Multimedia Applications, User Interface AV

Application Terminal Control and Management

Data Application Audio G.711 G.722 G.723.1 G.729 Video H.261 H.263 Encryption H.225.0 Call Signaling (Q.931) Security Capabilities H.245 System Control Security Capabilities RTP Authentication RTCP H.225.0 Terminal to Gatekeeper Signaling (RAS) TLS*_{/SSL TLS/SSL} T.124 T.125

Unreliable Transport / UDP,IPX Reliable

Transport/TCP,SPX Network Layer / IP / IPSec

Link Layer /….

T.123

Phisical Layer/ … Scope of H.323 Scope of H.235

Come figura 3.1 precisa, l’ H.235 include: segnalazione di chiamata Q.931, controllo di chiamata H.245, protocollo di H.225.0 RAS

(registro, ammissione e sottoscrizione) fra end-point e gatekeeper e RTP (per riservatezza* _{dei media). Rivediamo ciascuno di questi} sub-layers:

1. Sicurezza dell’H.225.0: il Q.931 può essere reso sicuro attraverso il transport-layer security (TLS*_{) o IPSEC}*_, prima ancora dello scambio del messaggio H.225.0. Durante la fase di registrazione (RAS), l’end-point ed il gatekeeper possono scambiare i permessi e le policies sicure per definire i metodi di sicurezza da usare nella sessione di chiamata iniziata.

2. Sicurezza dell’H.245: per la sicurezza dell’H.245, il canale H.225.0 deve scambiare il campo h235SecurityCapability come parte del setup dell’H225.0 user-user information element (UUIE). Un'altra possibilità è di aprire un canaledi sicurezza H.235 come un canale logico aperto dall’H.245 usando IPSEC o TLS per assicurare quel canale.

3. Sicurezza dell’RTP: Per rendere sicuri i canali RTP che trasportano i dati di voce, video e applicazioni per la riservatezza* _{(media privacy), l’ H.323 definisce un metodo} di apertura di un canale RTP sicuro, usando i messaggi di segnalazione H.245. Il metodo usa lo scambio di capacità dell’H245 per aprire canali logici sicuri come parte della fase di scambio delle possibilità. La scelta dell'oggetto h235SecurityCapability dovrebbe essere usata per la negoziazione del meccanismo di sicurezza del canale da usare quali il DES*_{, 3DES}* _{o AES}*_{. Per i media-stream} (canale RTP), la capacità di sicurezza è scambiata in modo che, se applicata al canale, esso è abilitato con riservatezza

(segretezza). La chiave* _{crittografica da impiegare è} scambiata per mezzo del Diffie-Hellman* _{(DH) in modo da} generare la chiave segreta comune.

Per la crittografia dei media stream*_{, il master, determinato nella} determinazione master/slave, è responsabile della generazione della chiave. La lunghezza della chiave dipende dalle procedure di crittografia quali il DES e 3DES. Per esempio, in DES è una chiave 56-bit.

L'architettura di sicurezza, descritta in questa raccomandazione, non suppone che i partecipanti debbano conoscersi a vicenda; tuttavia suppone che siano state prese tutte le precauzioni per assicurare fisicamente gli endpoints H.323. La principale minaccia* _{per la} sicurezza delle comunicazioni, quindi, è presupposta in ascolto di nascosto sulla rete o è un certo altro metodo di diversione dei flussi dei media. Le procedure fornite attraverso il canale logico H.245 esprimono le capacità del trasmettitore e del ricevente; questa raccomandazione include quindi, la capacità di negoziare i servizi e la funzionalità in un modo generico e di essere selettiva riguardo alle tecniche crittografiche ed alle possibilità utilizzate (le trasmissoni sono limitate a quelle che i riceventi possono decodificare). Il modo specifico in cui sono usate si riferisce alle possibilità dei sistemi, ai requisiti dell’applicazione ed ai vincoli specifici della politica di sicurezza adottata. Le possibilità di sicurezza di ogni endpoints sono comunicate nello stesso modo di qualunque altra possibilità di comunicazione; i terminali possono essere utilizzati nelle configurazioni multipunto, infatti il meccanismo di sicurezza descritto dall’H.235 tiene conto del funzionamento sicuro in

ambienti multiutente, compreso il funzionamento centralizzato che decentralizzato dell’ MCU.

Questa raccomandazione sostiene la segnalazione di algoritmi ben noti oltre che le procedure crittografiche non standardizzate o riservate di segnalazione. Non ci sono procedure specificamente obbligate; tuttavia, come già sottolineato, è suggerito fortemente che i endpoints sostengano fin dove è possibile tali procedure per realizzare l’interoperabilità. Ciò mette il concetto in parallelo con il fatto che il supporto H.245 non garantisce l’interoperabilità delle entità con due codecs diversi.

3.2 Introduzione al sistema sicuro H.235

1) Gli utenti possono essere autenticati o durante il collegamento iniziale della chiamata, nel corso dell’instaurazione del canale sicuro H.245 e/o scambiando i certificati sulla canale H.245. 2) Le possibilità di crittografia di una canale di media sono

determinate da estensioni al meccanismo già noto di trattativa di capabilities fra terminali.

3) La distribuzione iniziale del materiale-chiave è effettuato da parte del master attraverso i messaggi H.245 OpenLogicalChannel o di OpenLogicalChannelAck.

4) L’aggiornamento delle chiavi può essere compiuto dagli ordini

del H.245: EncryptionUpdateCommand, EncryptionUpdate

Request, EncryptionUpdate ed Encryption UpdateAck. 5) La distribuzione del materiale-chiave è protetta facendo

funzionare il canale H.245 come canale riservato* _o specificamente proteggendo il materiale chiave usando lo scambio dei certificati.

6) I protocolli di sicurezza presentati sono conformi ai campioni pubblicati ISO o ai campioni proposti IETF.

3.2.1 L'autenticazione

Il processo di autenticazione verifica che i dichiaranti siano proprio chi dicono di essere. L'autenticazione può essere compiuta con lo scambio di certificati* _{basati su chiave}* _{pubblica, ovvero può essere} compiuta tramite uno scambio un segreto comune fra le entità in questione; ciò può essere una parola d'accesso statica o una certa altra informazione nota a priori. Questa raccomandazione descrive il protocollo per lo scambio dei certificati, ma non specifica i tests di verifica con cui sono reciprocamente verificati ed accettati; in generale, i certificati sono garantiti da un’ autorità superiore comunemente riconosciuta e fidata. L'intenzione, dietro lo scambio del certificato*_{, è di autenticare l'utente dell’endpoint, e non} semplicemente l’endpoint fisico. Usando i certificati digitali, un protocollo di autenticazione, dimostra che i dichiaranti possiedono le chiavi riservate che corrispondono alle chiavi pubbliche contenute nei certificati. Questa autenticazione protegge dagli attacchi man-in-the-middle*_{, ma non dimostra automaticamente l’identità dei}

dichiaranti. Fare ciò, richiede normalmente una certa politica che gestisca altri contenuti dei certificati (per esempio, identificazione dell’account dell'utente prescritta dal fornitore di servizio...). La struttura di autenticazione in questa raccomandazione specifica una politica del certificato, oltre quello richiesto dal protocollo di autenticazione. Tuttavia, un'applicazione usando questa struttura, può imporre requisiti di politica ad alto livello come ad esempio presentare il certificato all'utente per la sua approvazione; questa

politica di livello elevato può essere automatizzata all'interno dell'applicazione o richiedere l'interazione umana. Per l'autenticazione che non utilizza i certificati digitali, questa raccomandazione fornisce la segnalazione per piani di challenge/response: questo metodo di autenticazione richiede la coordinazione a priori delle entità di comunicazione in modo da potere decidere un segreto comune. Come terza opzione, l'autenticazione può essere completata all'interno di un protocollo separato di sicurezza quali TLS [ TLS ] o IPSEC [ IPSEC ].

Sia l'autenticazione bidirezionale che unidirezionale è supportata dalle entità uguali e può avvenire su alcuni o su tutti i canali di comunicazioni.

3.2.2 I certificati

La standardizzazione dei certificati*_{, compreso la loro generazione,} gestione e la distribuzione è fuori della portata della raccomandazione H.235. I certificati usati per stabilire i canali sicuri (segnalazione di chiamata e/o controllo di chiamata) saranno conformi a quelli prescritti dal protocollo con cui è stato negoziato il canale sicuro. Va notato che per l'autenticazione che utilizza i certificati a chiave pubblica, gli endpoints devono fornire le firme digitali* _{usando il corrispondente valore di chiave segreta. Lo} scambio di certificati a chiave pubblica da solo non protegge dagli attacchi man-in-the-middle.

3.2.3 La sicurezza dell'instaurazione di chiamata

Ci sono almeno due ragioni per motivare la sicurezza del canale usato per stabilire una chiamata (per esempio Q. 931 usando H.323).

La prima è per l'autenticazione semplice, prima di accettare la chiamata; la seconda deve tenere conto dell’autorizzazione* _ad effettuare la chiamata. Se si vuole questa funzionalità nel terminale, un modo sicuro della comunicazione dovrebbe essere usato (quale TLS/IPSEC per H.323) prima dello scambio dei messaggi di segnalazione di chiamata. Alternativamente, l'autorizzazione può essere fornita con un servizio specifico di autenticazione..

3.2.4 La sicurezza del controllo di chiamata (H.245)

Il canale di controllo di chiamata (H.245) dovrebbe anche essere comunque reso sicuro per garantire la segretezza dei successivi flussi di media. Il canale H.245 sarà reso sicuro utilizzando la procedura* _{di segretezza negoziata (questa include l'opzione "none").} I messaggi H.245 sono utilizzati per segnalare gli algoritmi di crittografia e le chiavi usate nei canali condivisi, privati, o di media. La capacità di fare questo fin dall’apertura del canale logico, permette che canali differenti di media siano cifrati con meccanismi differenti. Per esempio, nelle conferenze centralizzate multipunto, chiavi differenti possono essere usate per i flussi ad ogni endpoint. . Per utilizzare i messaggi H.245 in un modo sicuro, l'intero canale H.245 (canale logico 0) dovrebbe essere aperto in un modo negoziato sicuro; i sistemi che utilizzano questa struttura di sicurezza devono avere la capacità di negoziare e/o segnalare l’apertura del canale H.245 sicuro, prima che realmente sia iniziata la comunicazione. Per esempio, nell’H.323 si utilizza il collegamento H.225.0 (RAS) .

3.2.5 La segretezza del media stream

L’H.235 detta le regole per la privacy per flussi di media trasportati su reti a pacchetto. Questi canali possono essere unidirezionali con il rispetto delle caratteristiche del canale logico H.245, ma non è richiesto che siano unidirezionali a livello fisico o di trasporto. Un primo punto nel raggiungimento della segretezza dei media è l’instaurazione di una canale riservato di controllo su cui scambiare il materiale crittografico e/o installare i canali logici che trasporteranno i media cifrati. A questo fine quando si opera in un congresso sicuro, tutti gli endpoints che partecipano possono utilizzare una canale cifrato H.245. In questo modo, la selezione dell’algoritmo* _{crittografico e le chiavi cifrate, passate nel H.245} OpenLogicalChannel sono protette. Il canale sicuro H.245 può operare con caratteristiche differenti da quelle nel canale(i) riservato dei media nella misura in cui possa comunque fornire un livello reciprocamente accettabile di segretezza. Ciò permette ai meccanismi di sicurezza di proteggere i flussi di media e a tutti i canali di controllo di funzionare in un modo completamente indipendente, fornendo livelli differenti di robustezza e complessità. Se è richiesto che il canale H.245 funzioni in un modo non-crittografato, possono essere cifrate esclusivamente le chiavi specifiche per i flussi di media nel modo segnalato e concordato dalle parti che partecipano. Un canale logico di tipo h235Control, opportunamente concordato può essere utilizzato per tale fine. La segretezza (crittografia) dei dati trasportati nei canali logici sarà nella forma specificata dall’ OpenLogicalChannel. Le informazioni di intestazione specifiche del trasporto non sono cifrate. La segretezza dei dati deve essere basata su sistemi di crittografia end-to-end.

3.2.6 Gli elementi di fiducia

I principi base per l'autenticazione (fiducia) e la segretezza sono definiti dai terminali dei canali di comunicazione. Per un canale di connessione, questo può essere fra il chiamante e un componente della rete ospite. Per esempio, un telefono "si fida" che lo switch della rete lo collegherà con il telefono corrispondente al numero che è stato composto. Per questo motivo, ogni entità che termina un canale cifrato di controllo H.245 o qualunque canale logico del tipo di encryptedData sarà considerato un elemento di fiducia del collegamento; ciò può includere MC(U)s ed i Gateways. Il risultato del “fidarsi di un elemento” è l’atto di rivelare il meccanismo di segretezza (algoritmo* _{e chiave) a quell’elemento. Detto questo, è} fondamentale per i partecipanti alla comunicazione, autenticare tutti gli elementi "di fiducia". Ciò è fatto normalmente tramite lo scambio del certificato come si presenterebbe per l'autenticazione faccia a faccia “standard”. Questa raccomandazione non richiederà alcun livello specifico d’autenticazione, tranne suggerire che è accettabile per tutte le entità utilizzare l'elemento di fiducia. La segretezza può assicurarsi fra i due endpoints soltanto se i collegamenti fra gli “elementi di fiducia” sono dimostrati essere protetti dagli attacchi man-in-the-middle.

3.2.7 I profili di sicurezza

Questa raccomandazione include una coppia di annessi che rafforzano i profili dell’H.235. Un profilo* _{di sicurezza specifica} l'uso specifico e l’applicabilità dell’ H.235 o un sottoinsieme di funzionalità H.235 per gli ambienti ben definiti. Secondo l'ambiente e l'applicazione, i profili di sicurezza possono essere implementati

selettivamente o complessivamente. I sistemi di H.235-enabled (e lo indicano all’interno dell’object identifier, nella segnalazione) dovrebbero scegliere il profilo di sicurezza secondo i loro bisogni. Facoltativamente, gli endpoints possono inizialmente proporre simultaneamente profili multipli di sicurezza, nei messaggi di RRQ/GRQ e lasciare selezionare al gatekeeper quello più adeguato nel messaggio di risposta RCF/GCF. Le transazioni di LRQ/LCF fra i gatekeepers possono anche trasportare parecchi profili di sicurezza.

3.3 Procedure di connessione

Come già sottolineato, il canale del collegamento di chiamata (H.225.0) e il canale di controllo di chiamata (H.245) funzionerà in modo negoziato sicuro o non garantito a cominciare dal primo scambio. Per il canale di chiamata, questo è fatto a priori (un TLS sicuro sarà utilizzato per i messaggi Q.931). Per il canale di controllo, il modo di sicurezza è determinato dalle informazioni comunicate nel setup iniziale del protocollo di collegamento. Nei casi in cui non vi concordanza delle capacità di sicurezza, il terminale denominato può rifiutare il collegamento e l'errore restituito non contiene alcuna informazioni sul motivo del disadattamento della sicurezza. Se i terminali, chiamante e chiamato hanno possibilità compatibili di sicurezza, sarà presupposto da entrambi i lati che il canale H.245 funzioni nel modo sicuro negoziato. La mancata installazione del canale H.245 nel modo sicuro dovrebbe essere considerato un errore del protocollo ed il collegamento dovrebbe terminare.

3.4 H.245 - Segnalazione e procedure

In generale, le funzioni di segretezza dei canali di media sono controllate nello stesso modo di qualunque altro parametro di codifica; ogni terminale indica le relative possibilità, la fonte dei dati, seleziona una disposizione da usare e il ricevente riconosce o nega tale modo. Tutte le funzioni indipendenti dal trasporto del meccanismo, quale la selezione dell’algoritmo sono indicate negli elementi generici della canale logico. Le specifiche di trasporto quale sincronizzazione di algoritmi di key/encryption sono passati in strutture di trasporto specifiche.

3.4.1 Operazione sicure nel canale H.245

Assunto che le procedure di collegamento della clausola precedente (procedure di connessione) indicano un modo di funzionamento sicuro, l’handshake di negoziazione e l'autenticazione avverranno nel canale di controllo H.245 prima che tutti i altri messaggi H.245 siano scambiati. Dopo aver completamente reso sicuro il canale H.245, i terminali usano il protocollo H.245 nello stesso modo che in un modo insicuro.

3.4.2 Il funzionamento non garantito del canale H.245

Alternativamente, il canale H.245 può funzionare in un modo non sicuro, e le due entità possono aprire un canale logico sicuro con cui effettuare l’autenticazione e/o ricavare le chiavi segrete condivise. Per esempio TLS o IPSEC può essere utilizzato aprendo una canale logico con il dataType che contiene un valore per l’h235Control. Questo canale potrebbe allora essere utilizzato per ricavare una

sequenza segreta comune per proteggere tutte le chiavi della sessione di media o per trasportare l’EncryptionSync.

3.4.3 Lo scambio di capacità

Gli endpoints scambiano le capacità usando i messaggi H.245. indicando, all’interno delle definizioni, i parametri di crittografia e di sicurezza. Per esempio, un endpoint potrebbe fornire le possibilità per trasmettere e ricevere il video H.261; può anche segnalare la capacità di trasmettere e ricevere il video cifrato H.261. Ogni algoritmo* _{crittografico che è utilizzato insieme ad un particolare} codec di media implica una nuova definizione di capacità. Agli endpoints è permesso regolare la loro possibilità di sicurezza in base all’overhead e alle risorse disponibili. Dopo che si è completato lo scambio di possibilità, gli endpoints possono aprire i canali logici sicuri per i media nello stesso modo che nel modo insicuro.

3.4.4 Il ruolo del master

Nell’H.245 la funzione master-slave è usata per stabilire l'entità master con lo scopo di svolgere le funzioni bidirezionali e risolvere ogni altra conflitto del canale. Questo ruolo di master inoltre è utilizzato nei metodi di sicurezza. Anche se il modo(s) di sicurezza di un media stream è regolato dalla fonte (in base alle possibilità della ricevente), il master è l’endpoint che genera la chiave crittografica*_{. La generazione della chiave crittografica è fatta,} indipendentemente dal fatto che il master sia il ricevente o la fonte dei media cifrati. Per permettere il funzionamento del canale multicast con le chiavi comuni, il MC (anche il master) genera le chiavi.

3.4.5 La segnalazione nel canale logico

Gli endpoints aprono il canale logico sicuro per i media nello stesso modo in cui aprono i canali logici per i media non garantiti. Ogni canale può funzionare in un modo completamente indipendente dagli altri canali, in particolare se riguarda la sicurezza. Il modo particolare sarà definito nel campo del OpenLogicalChannel dataType. La chiave iniziale di crittografia sarà passata nel OpenLogicalChannel o in OpenLogicalChannelAck secondo il rapporto master/slave del creatore del OpenLogicalChannel. L’OpenLogicalChannelAck fungerà da conferma del modo di crittografia; se l’openLogicalChannel non è accettato dal destinatario, il dataTypeNotSupported o il dataTypeNotAvailable (stato transitorio) sarà inviato nel campo causa del OpenLogicalChannelReject. Durante lo scambio di protocollo che stabilisce il canale logico, la chiave crittografica sarà passata dal

master allo slave (senza riguardo a chi apre

l’OpenLogicalChannel). Per i canali per i media aperti da un endpoint (tranne il master), il master restituirà la chiave iniziale di crittografia ed il punto iniziale di sincronizzazione nel OpenLogicalChannelAck (nel campo del encryptionSync). Per i canali di media aperti dal master, l’OpenLogicalChannel includerà la chiave iniziale di crittografia ed il punto di sincronizzazione nel campo del encryptionSync.

3.4.6 La sicurezza nella modalità Fast Connect

Gli endpoints possono utilizzare la procedura fast-connect usando il segnale fast-start per lo scambio sicuro del materiale chiave (chiave

master, chiavi crittografiche di sessione). La modalità fast-start può funzionare con o senza offerte multiple di algoritmi crittografici.

3.5 Diffie-Hellman

*

Questa raccomandazione supporta il protocollo di Diffie-Hellman per l’accordo di chiavi end-to-end. Secondo le situazioni, la chiave negoziata di Diffie-Hellman può fungere da chiave master o come chiave dinamica di sessione. Il sistema di Diffie-Hellman è caratterizzato dai parametri del sistema g e la p dove la p sarà un numero primo grande e g rappresenta il generatore del gruppo moltiplicativo modp o di un consistente sottogruppo modp; gx _modp

rappresenta la half-key (pubblica) di Diffie-Hellman del chiamato mentre gy _{modp rappresenta la half-key (pubblica) di Diffie-Hellman}

del chiamato.

H.235 trasporta una istanza di Diffie-Hellman (g, p, gx_{) messo} all'interno di un ClearToken dove il dhkey contiene l’ halfkey gx modp (rispettivamente gy _{modp) per una certa x (rispettivamente y)} casuale e segreta, il numero primo p dentro il modsize e il generator g. Un caso particolare è la tripletta (0, 0, 0) o dhkey vuoto che non rappresenta alcuna istanza DH ma sarà usata nella segnalazione che il profilo di crittografia della voce non sarà usato.

Spesso, i parametri p e g del sistema DH sono fissi per un insieme di applicazioni con valori ben definiti, tuttavia i sistemi finali possono anche scegliere il loro proprio insieme di parametri. Il chiamato dovrebbe essere informato del fatto che i parametri DH non standard possono fornire meno sicurezza; per esempio il chiamato potrebbe scegliere un numero non-primo, o il g genera un sottogruppo appena più piccolo. Mentre testare totalmente il parametro non è in pratica

fattibile, spetta alla politica di sicurezza del chiamato determinare se accettare o rifiutare tali offerte. Per i parametri fissi del sistema DH, una descrizione sintetica attraverso un object identifier può rendere i messaggi più compatti e comprensivi di valori letterali. Un ClearToken che trasporta un istanza-DH con i parametri DH fissi e standardizzati, può riferire l’istanza del DH con un DH-OID nel campo tokenOID. Nel caso di parecchie istanze-DH devono essere indicate, ciascuna tramite un DH-OID; i DH-parametri in un CryptoToken distinto saranno omessi lasciando il dhkey assente e tutte le istanze-DH saranno allora trasportate all'interno di ClearTokens separato in cui il tokenOID tiene il DH-OID ed il dhkey può essere lasciato assente; gli altri campi all'interno di quel ClearToken non saranno usati.

Nel caso, un’istanza-DH non standard deve essere indicata; il DH-OID "DHdummy" sarà utilizzato ed i parametri non standard del DH-gruppo saranno forniti esplicitamente nel ClearToken. Il chiamante può presentare uno o parecchi ClearTokens ciascuno che trasporta un caso differente di Diffie-Hellman. Il chiamante è consigliato a fornire dove è possibile istanze-DH nella misura in cui la sua la sua politica di sicurezza consente. Ciò permette che il chiamato scelga un caso adatto per la risposta, ed è aumentata quindi la probabilità di individuazione di un insieme comune di parametri. Il chiamato selezionerà ed accetterà una singola istanza del DH (all'occorrenza) che sceglie dall'insieme non ordinato delle istanze del DH fornite dal chiamante nel messaggio SETUP. Nel caso, il chiamato può selezionare istanza-DH che combacia con i suoi propri bisogni di sicurezza, esso non modificherà un’istanza del DH proposta o non ne restituirà una che non sia stata trasmessa dal

chiamante. La resistenza degli algoritmi crittografici disponibili agli entrambi EPs durante la chiamata dovrebbe garantire la robustezza mentre l’istanza del DH scelta fornisce ciò che è restituito dal chiamato; il chiamato indicherà l’istanza-DH scelta nel messaggio di risposta. Nel caso il chiamato rifiuti alcune delle proposte per motivi di sicurezza o per mancanza di possibilità di elaborazione, il chiamato lascerà il dhkey assente nel messaggio di risposta. Il chiamato includerà il relativo DH-token nella risposta di Set-up-to-Connect. Il chiamato può includere il relativo DH-token nel messaggio di risposta immediato dopo il setup, o può includere il DH-token in qualche fase successiva, ma al più dentro il messaggio di CONNECT.

Per alcuni motivi tuttavia, alcuni routingGKs non possono trasportare tutti le risposte Set-up-to-Connect al chiamante. Così, uno o più messaggi di risposta di segnalazione di chiamata H.225.0 compreso un possibile DH-token, possono cadere e non arrivare al chiamante. Allora il chiamante non potrebbe computare la chiave DH-master ed il key(s) di sessione di media. Per impedire tali casi, il chiamato dovrebbe includere sempre lo stesso DH-token in ciascuno messaggio Set-up-to-Connect di risposta. Nei casi in cui il DH-OID indica un’ istanza-DH differente da quella che realmente sta trasportando dentro modsize e generator, i valori letterali trasportati dentro modsize ed il generator avranno precedenza rispetto il DH-OID nel token. Per la risposta, il chiamato dovrebbe sostituire il DH-OID in conflitto con il DH-OID statico, per esempio, "DH1024," che corrisponde al modsize e generator o "DHdummy" se non vi è il corrispondente DH-OID.

3.6 Procedure multipunto

3.6.1 L'autenticazione

L’ autenticazione si presenterà fra un endpoint ed il MC(u) nello stesso modo che si potrebbe presentare con una conferenza punto-punto. Il MC(u) regolerà la politica riguardo al livello ed al rigore dell'autenticazione. Come già detto l’ MC(u) è garantito (ci si può fidare); gli endpoints, in una conferenza possono essere limitati dal livello di autenticazione impiegato dal MC(u). I nuovi ordini di ConferenceRequest /ConferenceResponse permettono agli endpoints di ottenere i certificati di altri partecipanti al congresso dall’ MC(u). In conformità alle procedure H.245, gli endpoints in una conferenza multipunto possono chiedere certificati di altri endpoint via l’ MC, ma non possono potere realizzare l'autenticazione crittografica diretta all'interno della canale H.245.

3.6.2 La segretezza

MC(U) amministrerà tutti gli scambi master/slave così come fornirà il key(s) di crittografia ai partecipanti ad un congresso multipunto. La segretezza per le diverse fonti all'interno di una sessione comune (assumendo il multicast) può essere realizzata con chiavi private o comuni. Questi due modi possono essere scelti arbitrariamente dall’ MC(U) e non saranno controllabili da alcun endpoint particolare a meno che nei modi consentiti dalla politica del MC(U). Cioè una chiave comune può essere usata attraverso i canali logici multipi così come può essere aperta da fonti differenti.

3.7 Segnalazione e procedure d'autenticazione

L’ autenticazione è in generale basata sull’uso un “segreto comune” (si è autenticati correttamente se si conosce il segreto) o su metodi a chiave pubblica facendo uso di certificazioni (dimostrate la vostra identità possedendo la chiave riservata corretta). Un segreto comune e l'uso successivo della crittografia simmetrica* _{richiede un contatto} precedente fra le entità di comunicazione. Un contatto faccia a faccia sicuro può essere sostituito generando o scambiando la chiave segreta comune con i metodi basati sulla crittografia con chiave pubblica, per esempio tramite lo scambio di chiave di Diffie-Hellman. Le parti che entrano in comunicazione, nella generazione e nello scambio di chiavi devono essere autenticati per esempio usando i messaggi digitalmente firmati; altrimenti le parti interessate alla comunicazione non possono essere sicure sull’identità di coloro con cui ripartiscono il segreto. Questa raccomandazione presenta i metodi di autenticazione basati sulla registrazione, cioè con un contatto precedente per la compartecipazione del segreto ed i metodi di autenticazione con crittografia a chiave pubblica usata direttamente nell'autenticazione o per la generazione del segreto comune.

3.7.1 Diffie-Hellman con l'autenticazione facoltativa

L'intenzione è quella non di fornire l'autenticazione assoluta, a livello di utente. Questo metodo fornisce la segnalazione per generare un segreto comune fra due entità che può produrre le chiavi necessarie per le comunicazioni riservate. Alla conclusione di questo scambio entrambe l’entità possederanno una chiave segreta comune assieme ad una procedura scelta con cui utilizzare questa

chiave. Questa chiave segreta comune può ora essere usata su tutti gli scambi successivi di request/response. Dovrebbe essere notato che in casi rari lo scambio di Diffie-Hellman può generare chiavi deboli. Se ciò avvenisse, l’una o la altra entità si dovrebbero scollegare e ricollegare per stabilire un nuovo insieme di chiavi. La prima fase di figura 3.2 mostra i dati scambiati durante il Diffie-Hellman. La seconda fase permette per l’applicazione o per il protocollo, specifici messaggi di richiesta che devono essere autenticati da colui che risponde. Si noti che un nuovo valore casuale può essere restituito con ogni risposta.

Nota: se i messaggi sono scambiati sopra una canale non sicuro, allora devono essere usate le firme digitali (o un altro metodo di autenticazione di origine del messaggio) per autenticare le parti fra le quali il segreto sarà ripartito. La firma può anche essere fornita come elemento facoltativo.

Response EPB EPA

Figura 3.2 Diffie Helman con autenticazione opzionale [... ...] indica una sequenza del token;

( ) indica una un particolare token che può contenere elementi multilpli; {}E-DH-secret indica che i valori contenuti sono cifrati usando Diffie-Hellman.

EPB sa quale chiave comune deve usare per decrittare il generalIDB dall’associazione di questo con generalIDA 8passato nel messaggio come sendrsIDA

3.7.2 Autenticazione con sottoscrizione

Anche se le procedure descritte qui sono in natura bidirezionali, possono essere utilizzate soltanto in un senso se l'autenticazione è necessaria soltanto in tale senso. Sono descritte sia le procedure two-pass che three-two-pass: l'autenticazione two-two-pass reciproca può essere fatta soltanto in un senso quando i messaggi che provengono dalla direzione opposta non devono essere autenticati. Questi scambi suppongono che ogni estremità possieda un certo contrassegno ben noto (quale un contrassegno di testo) che lo identifica unicamente. Per l’algoritmo two-pass, ulteriore presupposto è che ci sia un riferimento temporale reciprocamente accettabile (da cui derivare i timestamps). La procedura threee-pass usa un challenge number generato casualmente e imprevedibile (che può essere aumentato da un contatore sequenziale “random”). Questo numero casuale consente la protezione dagli attachi ripetuti. Differentemente dalle procedure two-pass, le procedure three-pass non effettuano l’autenticazione del messaggio iniziale che contiene il challenge. Ci sono tre possibili varianti che possono essere implementate in base ai requisiti richiesti:

1) Procedura basata su password con crittografia simmetrica; 2) Procedura basata su password hash*_;

3) Procedura basato su certificati con firme.

In tutti i casi il token conterrà le informazioni come descritte nelle seguenti clausole secondo la variaziante scelta. Si noti che, in tutti i casi, il generalID può essere conosciuto dalla configurazione piuttosto che dal protocollo di scambio della banda. Per facilitare l'elaborazione al ricevente, il mittente include la sua identità

all'interno di sendersID e regolare il generalID per l’identificazione del destinatario.

NOTA 1. In tutti i casi dove i timestamps sono generati e passati come componente di uno scambio di sicurezza, si adottano alcune precauzioni: la discretizzazione del timestamp dovrebbe essere abbastanza fine per garantire la possibilità di incremento con ogni messaggio. Se questo non è garantito, gli attacchi di risposta sono possibili (per esempio se il timestamp viene incrementato ogni minuto, un endpoint "C" può ingannare l’endpoint "A" entro la durata di un minuto dopo che l’endpoint "A" ha trasmesso un messaggio all’ endpoint "B").

NOTA 2. Se il messaggio è multicast, allora il messaggio non è assicurato.

Nota1: il token di ritorno da EPB è facoltativo; se omesso viene fatta solo l’autenticzione in un senso.

Nota2: Ek-pw indica il valore cifrato usando la chiave “k” derivata dalla password “pw”

Nota3: random è un contatore a incremento monotono che genera messagi multipli con

lo stesso timestamps.

Nota4: nel terzo msg EPA fornisce un separato Clear Token che è identificato

attraverso il solito OID del Crypto Token;

EPA _EPB

• Password con crittografia simmetrica*

Le figure 3.3a e 3.3b mostrano la disposizione simbolica e lo scambio dei messaggi per effettuare questo tipo di autenticazione two-pass o three-pass, rispettivamente; è presupposto che un contrassegno e una parola d'accesso associata, siano scambiati durante la registrazione. La chiave crittografica è lunga N ottetti (come indicato dal AlgorithmID) ed ha la seguente forma:

Se lunghezza di password = N, chiave = password;

Se la lunghezza di password < N, la chiave è riempita con zeri; Se la lunghezza della password > la N, i primi N ottetti sono

assegnati alla chiave, quindi l'ottetto N+M-esimo della parola d'accesso è sommato (XOR) all'ottetto di Mmod(N)-esimo (per tutti gli ottetti oltre N) .

• Password con codifica hash*

Le figure 3.4a e 3.4b il formato del token e lo scambio di messaggi richiesti per effettuare questo tipo di autenticazione, rispettivamente two-pass o three-pass .

Nota1: challangeA ed il Crypto Token cifrato di ritorno da B a A non devono essere

avvenire necessariamente se è richiesta l’autenticazione in una direzione

Nota2: Ek-pw indica il valore cifrato usando la chiave “k” derivata dalla password “pw”.

Nota3: nel terzo msg EPA fornisce un nuovo challangeA in chiaro in un separato Clear

Token che è identificato attraverso il solito OID del Crypto Token. EPA risponde con challangeB.

EPA EPB

E’ presupposto che un identificativo e una parola d'accesso associata siano scambiati durante la sottoscrizione.

NOTA: le implementazioni devono accertarsi che le password d’accesso-utente siano sufficientemente sicure. Le parole d'accesso troppo corte o che sono suscettibili agli attacchi del dizionario devono essere rifiutate. In determinati casi può essere conveniente manipolare la pass-phrase d’accesso-utente con una funzione crittografica hash ed usare i bits d'uscita.

EPA _EPB

Figura 3.4a – Password con funzione hash (two passes)

Nota1: il token di ritorno da EPB è facoltativo; se omesso viene fatta solo l’autenticzione in un senso.

Nota2: Hash indica una funzion hash che agishe sui valori in essa contenuti.

Nota1: il token di ritorno da EPB è facoltativo; se omesso viene fatta solo l’autenticzione in un senso.

Nota2: Hash indica una funzion hash che agishe sui valori in essa contenuti. Nota3: nel terzo msg EPA fornisce un nuovo challangeA in chiaro all’interno di un

Clear Token incastrato CryptoHashedToken. EPA risponde con challangeB

• Certificato basato sulle firme

Le figura 3.5 mostra la disposizione del token e lo scambio del messaggio utilizzato per effettuare questo tipo di autenticazione. Si suppone che un contrassegno e un certificato collegato siano assigned/exchanged durante la sottoscrizione.

NOTA: se il messaggio è multicast, allora il contrassegno della destinazione (generalIDB per i messaggi prodotti da A e viceversa)

non dovrebbe essere incluso nel ClearToken.

• Uso del segreto comune e delle parole d'accesso (password) L’H235 applica determinate tecniche crittografiche simmetriche con lo scopo di garantire l'autenticazione, l'integrità e la riservatezza. Quando si usa il termine parola d'accesso (password) e la sequenza segreta comune (shared secret) si intende l’applicazione di tecniche simmetriche. Il shared secret è inteso come il termine generico che identifica una stringa di bit arbitraria. Il shared secret può essere assegnato o configurato come componente del processo di registrazione dell'utente o può fare parte del calcolo in-band quale un segreto comune Diffie-Hellman. Una password potrebbe essere Nota1: il token di ritorno da EPB è facoltativo; se omesso viene fatta solo l’autenticzione in un senso.

Nota2: Sign indica una funzione della firma (ricavata dal certificao associato) costruita con i valori in essa contenuti .

EPA EPB

descritta come una serie di caratteri alfanumerici che gli utenti possono memorizzare. È evidente che l’uso delle password deve essere fatto con cura: esse possono garantire sufficiente sicurezza soltanto se scelte a caso in un grande insieme, sono imprevedibili, sono cambiate periodicamente e sono in definitiva dotate della necessaria “entropia”. Una buona pratica per sfruttare i benefici dalle parole d'accesso e dei segreti comuni è di trasformare la stringa della password ( come il shared secret) dell'utente in una stringa di bit fissa usando una funzione robusta unidirezionale di crittografia hash. Come esempio suggerisce, lo SHA-1* _{applica alla stringa della} password una sequenza segreta comune a 20-byte. Come beneficio, il risultato hashed, non soltanto cela la parola d'accesso reale, ma inoltre definisce una stringa con un formato a lunghezza di bits fissa, senza che realmente sia sacrificata “l’entropia”. Quindi, segreto comune: = SHA1* _(password).

3.8 Procedure di crittografia di media stream

I media streams saranno codificati usando l’algoritmo e la chiave come presentati nel canale H.245. Figure 3.6 e 3.7 mostrano il flusso generale. Si noti che l'intestazione di trasporto è allegata al trasporto SDU (Service Data Unit) dopo che l’ SDU è stato cifrato. I segmenti rossi indicano la segretezza.

Quando nuove chiavi vengono ricevute dal trasmettitore e sono usate nella crittografia, l'intestazione dell’ SDU indicherà comunque al ricevente, che la nuova chiave ora è in uso.

3.8.1 Le chiavi di sessione (media)

Incluse nel encryptionUpdate c’è l’h235Key. L’h235Key, codificato con l’ASN.1 è messo all'interno del contesto dell'albero H.235 ASN.1 e passato come stringa (ottetto) con il rispetto dell’H.245.

La chiave può essere protetta utilizzando uno dei tre meccanismi possibili mentre è passata fra due endpoints:

Se il canale H.245 è sicuro, nessuna protezione supplementare è applicata al materiale chiave. La chiave è passata "in chiaro" riguardo a questo campo; è utilizzata la scelta ASN.1 di secureChannel.

Se una chiave segreta e un algoritmo sono stati stabiliti fuori dal canale H.245 (cioè parte esterna H.323 o su un canale logico dell’H235Control), la sequenza segreta comune è usata per

abcd abcd abcd abcd ENCRYPTION

CODEC

Key # 1 Key # 2

Chiavi passate nel canale H.245

Transport segmentation

SDU header

cifrare la chiave; la chiave cifrata risultante è qui inclusa. In questo caso, è usata la scelta ASN.1 di sharedSecret.

I certificati possono essere usati quando il canale H.245 non è sicuro, ma possono anche essere usati anche con canale sicuro H.245. Quando i certificati sono utilizzati, il materiale chiave è cifrato usando la chiave pubblica del certificato ed l’ASN.1 costruisce il certProtectedKey.

Ad un punto qualunque in una conferenza, un ricevente (o

trasmettitore) può chiedere una nuova chiave

(encryptionUpdateRequest). Un motivo che lo potrebbe indurre a fare questo, è se ha il sospetto di aver perso la sincronizzazione di uno dei canali logici. Il master che riceve questa richiesta genererà il nuovo key(s) in risposta a questo ordine. Il master può anche decidere in modo asincrono di distribuire il nuovo key(s), e in questo caso userà il messaggio di encryptionUpdate. Dopo la ricezione dell’encryptionUpdateRequest, un master spedirà

abcd abcd abcd abcd DENCRYPTION

CODEC Key # 2 Key #1 Chiavi ricevute nel canale H.245 Transport segmentation SDU header

l’encryptionUpdate. Se la conferenza è multipunto, il MC (anche il master) dovrebbe distribuire la nuova chiave a tutte i riceventi prima di fornire questa chiave al trasmettitore. Il trasmettitore dei dati utilizzerà appena possibile sul canale logico la nuova chiave dopo la ricezione del messaggio. Un trasmettitore (assumendo che non sia il master) può anche chiedere una nuova chiave. Se il trasmettitore fa parte di un congresso multipunto l’algoritmo sarà come segue:

Il trasmettitore trasmetterà l’encryptionUpdateRequest al MC (master).

L’MC dovrebbe generare una nuova key(s) e trasmettere un messaggio dell’encryptionUpdate a tutti i partecipanti di congresso tranne il trasmettitore.

Dopo la distribuzione delle nuove chiavi a tutti i altri partecipanti, l’MC trasmetterà il encryptionUpdate al trasmettitore. Il trasmettitore allora utilizzerà la nuova chiave.

3.8.2 Anti-Spamming* di Media

Il ricevente di un RTP media stream può desiderare di monitorare il denial-of-service* _{ed il flooding attack}* _{sulle porte scoperte di}

RTP/UDP. I ricevitori, quando adottano la possibilità anti-Spam, possono determinare rapidamente se un pacchetto RTP ricevuto provenga da una fonte non autorizzata e quindi lo scartano. La capacità anti-Spamming*_{, quando attivata, descrive le modalità} d’uso nei seguenti casi:

per i dati di media in chiaro, senza crittografia:

congiuntamente ai dati cifrati di media quando EncryptionCapability caratterizza un algoritmo di crittografia.

RTPpacketAuthentication sui campi selezionati attraverso il calcolo di un messaggio-codice di autenticazione (MAC*_). Gli algoritmi crittografici sono:

un algoritmo di crittografia (per esempio il DES nel modo del MAC vede ISO/IEC 9797). Il DES-MAC è indicato usando il OID "N" mentre il triplice-DES-MAC è indicato usando OID "O"; usando una funzione unidirezionale crittografica (per esempio

SHA1). Il OID da usare è "M".

L’algoritmo MAC è indicato nel object identifier

dell’antiSpamAlgorithm. L’algoritmo OID indica implicitamente inoltre il formato del MAC; per esempio 1 blocco = 64 bit per il MAC DES. Per conservare la larghezza di banda, il MAC potrebbe essere troncato a patto di sacrificare in parte la sicurezza, per esempio ad un MAC 32-bit; ciò richiederebbe , naturalmente un object identifier differente. Il metodo anti-Spam è indipendente dal payload di tutta la crittografia supplementare (veda i casi 1 e 2 di seguito). Anti-Spamming usa la seguente disposizione del pacchetto di RTP (si veda figura sotto) dove la sequenza del riempimento di RTP va interpretata come segue.

Il bit P nell'intestazione di RTP sarà regolata a 1.

I byte del riempimento saranno collegati all'estremità del carico utile con il seguente significato (figura 3.8):

EncryptionCapability definisce l’algoritmo di crittografia del carico utile mentre il antiSpamAlgorithm definisce il metodo anti-Spamming. Per i motivi di sicurezza, la crittografia di media ed il MAC useranno le chiavi di sessione differenti. La chiave k del MAC è computata inviando la chiave K di crittografia alla funzione* unidirezionale hash SHA1: k=SHA1(k).

Quando l’antiSpamAlgorithm indica un algoritmo di crittografia, allora i bits raccolti costruiranno una chiave corretta di crittografia; dopo che il ricevente verifica con successo l'autenticità del pacchetto di RTP, il payload è decrittato ed allora l’RTP padding è scartato.

3.9 Recupero della sicurezza

L’H.235 non specifica i metodi con cui gli endpoints possono controllare il livello di segretezza. Tuttavia, suggerisce le azioni da prendere quando è rilevata una perdita di sicurezza; se l’ uno o l’altro endpoint rileva una frattura nella sicurezza del canale di collegamento di chiamata (per esempio H.225.0), esso dovrebbe immediatamente chiudere il collegamento dopo le procedure di protocollo adatte al particolare endpoint. Se l’endpoint rileva una frattura nella sicurezza della canale H.245 o del canale logico sicuro di dati (h235Control), deve immediatamente chiudere il collegamento e/o avviare la procedura per chiedere immediatamente una nuova chiave (più encryptionUpdateRequest). A discrezione del MC(U), una perdita di segretezza su una canale logico può indurre la chiusura di tutti gli altri canali logici e/o ad re-keyed. L’MC(u) spedirà più encryptionUpdateRequest, l’ encryptionUpdate a tutti gli endpoints interessati. Nei casi di collegamenti multipunto

l’MC(U) può chiudere i collegamenti su tutti gli endpoints e concludere così la conferenza.

3.10 Profilo di sicurezza di base per il SIT

Dopo aver descritto nella maniera più generica possibile quelle che sono le specifiche di sicurezza contenute nella Raccomandazione H.235, vediamo ora una loro possibile implementazione nel Sistema Integrato di Telecomunicazione, oggetto di questa tesi. Ci viene incontro l’Annesso D/H.235; esso delinea un profilo base di sicurezza che fornisce l'autenticazione e l'integrità per i canali RAS, H.225.0 e H.245. Opzionalmente fornisce la riservatezza per i media stream di RTP/RTCP durante il RAS.

Tutte le informazioni di sicurezza del hop-by-hop (passo a passo, inteso come terminale-terminale) sono immesse nell'elemento di CryptoHashedToken; queste informazioni sono ricalcolate ad ogni passo. In generale, ciò che accomuna la password, la chiave di sessione ed il segreto comune è che sono usati in un sistema di crittografia simmetrico fra due (o più) entità. La differenza fra una password e un segreto di sessione, key/shared è come le chiavi realmente sono applicate; per esempio password per l'autenticazione ed autorizzazione, chiavi di sessione per la crittografia. Il termine "segreto comune" è generalmente neutrale poiché realmente non si riferisce ad alcun uso specifico. La password (potrebbe essere considerata anche come segreto comune) è usata per l’ authentication/integrity per i canali RAS e H.225.0, poichè questa può essere inserita dall'utente. La password ha solitamente un tempo di vita più lungo, è conosciuta a priori e può essere definita come componente del processo generale di sottoscrizione da parte

dell’utente. Una certa procedura (per esempio filtrando la parola d'accesso con una funzione hash) può trasformare la password in una sequenza a lunghezza fissa per facilitarne l'elaborazione nei protocolli. La chiave di sessione per i flussi di media cifrati è generata dal master per una sessione dell’ RTP (su un OLC), per una durata al più di una chiamata. La chiave di sessione generata è cifrata con una chiave che deriva dal segreto comune di Diffie-Hellman che entrambi gli endpoints hanno computato. In questo caso, il segreto DH-shared funge da chiave master per la protezione della chiave di sessione. L’H.235 ClearToken offre un campo denominato random contenente un il numero intero a 32-bit. Questo campo è usato nel seguente senso: random è un numero che cresce in maniera monotona, che parte da un valore e aumenta per ogni messaggio uscente. Il random è usato come un valore supplementare "di randomizzazione" di input nella funzione chiave-hash nel caso in cui parecchi messaggi vengono emessi uno dopo un altro, ognuno con timestamps identici. Ciò potrebbe accadere quando l'orologio del UTC non fornisce la sufficiente risoluzione. Essenzialmente, il valore hash prodotto o il valore del controllo di integrità appaiono differenti a causa del cambiare del valore random Per semplicità di esecuzione, in questo caso, un contatore crescente è preferito ad una sequenza casuale. Il destinatario può mantenere le coppie di timestamp/random ricevute per tutta la durata di una finestra temporale localmente definita (dipendente dalla compensazione delle differenze di sincronizzazione e dei ritardi temporali sulla rete di trasporto). Gli attacchi ripetuti possono essere identificati quando lo stesso accoppiamento di timestamp/random occorre due volte. Questo profilo impone di

regolare il generalID nel ClearToken all’identificativo del destinatario. Ciò realmente significa, che per i messaggi RAS (o di segnalazione di chiamata, H.225) destinati al gatekeeper l’identificativo è quello del GK; per i messaggi RAS (o di segnalazione di chiamata, H.225) destinati all’endpoints l’ID è quello dell’endpoint. Il sendersID sarà regolato alla stringa d'identificazione del mittente. Cioè per i messaggi RAS (o di segnalazione di chiamata, H.225) destinati al GK esso è il l’identificativo dell’endpoints; per i messaggi destinati all’endpoints, è l’identificativo del GK. Un block è un’unità base e rappresenta il pacchetto di bit che la cifrante del blocco può encrypt/decrypt con un’operazione crittografica elementare; per il DES e triplice-DES, il formato di blocco è 64 bit, per l’AES il formato del blocco è 128 bit. Per H.225.0 RAS la protezione d’integrità riguarda l'intero messaggio; per la segnalazione di chiamata riguarda l'intero messaggio di segnalazione di chiamata H.225.0 compreso le intestazioni Q.931.

Le caratteristiche principali di tale profilo sono:

• Autenticazione dell'utente: indipendentemente dal numero di elementi di rete H.235 (GK,GW,MCU,...) attraversati dal messaggio.

• Integrità della segnalazione: riferita ai messaggi interi o alle parti critiche (campi) che giungono ad un’entità attraverso i canali per RAS, di H225.0 e H.245.

• Autenticazione ed integrità: dell’intero messaggio di segnalazione a livello by-hop (si ricorda che con hop-by-hop si intende passo-passo fra le varie entità della rete).

• Riservatezza per il media stream: fornita da crittografia simmetrica.

Tale profilo consente poi di contrastare parecchi attacchi fornendo i suddetti servizi di sicurezza :

attacchi di Denial-of-service: il controllo veloce dei valori crittografici hash può impedire tali attacchi.

Attacchi man-in-the-middle: L'autenticazione e l'integrità del messaggio hop-by-hop impedisce tali attacchi quando ad esempio il malintenzionato e fra un elemento della rete ed un router ostile.

Attacchi ripetuti: l'uso dei timestamps ed di numeri progressivi impediscono tali attacchi.

Spoofing*_{: l'autenticazione dell'utente impedisce tali attacchi.}

Dirottamento di connessione: l’ authentication/integrity per ogni messaggio di segnalazione impedisce tali attacchi. L’ascolto di nascosto del flusso di media è contrastato tramite la

crittografia e l'uso di chiavi segrete.

Altri punti culminanti del profilo semplice di sicurezza includono: Uso di procedure robuste, ben note ed ampiamente impiegate

basate sulle raccomandazioni dell’IMTC/ETSI/IETF. Applicabile a vari scenari quali nei gruppi chiusi, ambienti

scalabili e nelle conferenze multipunto.

La figura 3.9 ricapitola tutte le procedure definite in profilo con differenti requisiti di sicurezza. La tabella in figura include il profilo di sicurezza-base (tonalità azzurra) e il profilo di sicurezza di crittografia della voce (tonalità gialla). Il profilo opzionale che fornisce solo l’autenticazione è indicato in verde.

Call function

Security

services _{RAS H.225 H.245}(a) _RTP

Authentication Password HMAC-SHA1*_-96 Password HMAC-SHA1-96 Password HMAC-SHA1-96 Authentication-only Password HMAC-SHA1-96 Password HMAC-SHA1-96 Password HMAC-SHA1-96 Non-repudiation

Integrity Password HMAC-SHA1-96 Password HMAC-SHA1-96 Password HMAC-SHA1-96 56-bit DES 56-bit RC2*- compa-tible 168-bit triple-DES 128-bit AES

Confidentiality CBC-mode or EOFB-mode Access Control Key Management Subscription-based password assignment Subscription-based password assignment Authenti-cated Diffie-Hellman key-exchange

Integrated H.235 session key management (key distribution, key update using 56-bit DES/56-bit RC2*-compatible/168-bit triple-DES, 128-bit AES)

a)_{Tunnelled H.245 or embedded H.245 inside H.225.0 fast connect.}

Profilo di sicurezza-base Profilo sicuro di crittografia della voce Solo Autenticazione

Per l'autenticazione, l'utente userà uno schema a password. Lo schema basato sulla parola d'accesso, per la relativa semplicità e facilità di esecuzione, farà parte della prima implementazione di sicurezza nel SIT. L’utilizzo di funzioni hash per cifrare tutti i campi nel canale H.225.0 RAS e nei messaggi di segnalazione di chiamata sarà il metodo adottato per l’integrità dei messaggi (anche usando lo schema a password). Le entità sicure H.323, con questo profilo realizzano l'autenticazione insieme con integrità usando lo

stesso comune meccanismo di sicurezza. Per l’opzionale riservatezza della voce, lo schema suggerito è la crittografia usando AES-128, RC2*_{-compatible, il DES o triplice-DES basato su} modello conosciuti e con requisiti di esportabilità. La realtà di utilizzo del SIT, all’interno di un Ente militare con adeguati sistemi di riconoscimento del personale ed un adeguato livello di privacy potrebbe non richiedere la crittografia della voce. In questo caso, l'accordo di Diffie-Hellman come pure le altre procedure d’amministrazione delle chiavi non saranno necessarie. Le entità H.323 quando implementano il profilo di sicurezza con crittografia di voce utilizzano come procedura di default il DES 56-bit; possono impiegare il 128-bit AES o Triplo-DES 168-bit mentre possono effettuare la crittografia esportabile usando 56-bit RC2-compatible.

3.10.1 Una possibile implementazione del Profilo di sicurezza di base

Le entità H.323 che supportano questo profilo di sicurezza di base sostengono le seguenti caratteristiche H.323:

Fast connect; Modello GK-routed.

Secondo la politica di sicurezza, l'autenticazione può essere unilaterale o reciproca applicando l’authentication/integrity pure nel senso inverso e fornendo quindi una maggiore sicurezza. Il GK decide se applicare l’authentication/integrity pure nel senso inverso. I GK che rilevano l'autenticazione e/o la convalida di integrità fallita in un canale RAS o in un messaggio di segnalazione ricevuto da un gatekeeper (o endpoint) sicuro, rispondono con un messaggio corrispondente di rifiuto che indica l’errore di sicurezza settando nel

securityDenial la ragione del rifiuto. Secondo la capacità di riconoscere un attacco , un gatekeeper che riceve un xRQ sicuro con gli object identifier non definiti (tokenOID, algorithmOID), può rispondere con un xRJ non sicuro, settando la motivazione nel securityDenial o può scartare quel messaggio. D'altra parte, l’endpoint scarterà il messaggio non sicuro ricevuto, e può processare nuovamente la richiesta scegliendo un OID differente. Inoltre, un gatekeeper che riceve un messaggio di SETUP sicuro H.225.0 con gli object identifier non definiti (tokenOID, algorithmOID) può rispondere con un RELEASE COMPLETE non sicuro e settare di conseguenza il securityDenied.

L’operazione di autenticazione è effettuata all'estremità di ogni canale che termina un troncone della rete (EP1-GK1, GK1 GK2, GK2-EP2, EP1-GK2, GK1-EP2 o EP1-EP2 secondo le circostanze) e ricalcolata prima della trasmissione del sul troncone successivo. Le figure 3.10 e 3.11 mostrano invece, la presenza di chiavi condivise alla fine del canale di comunicazione, per differenti combinazioni di gatekeeper e di canali H.225 direct-routed. Indipendentemente dal modello di chiamata, una chiave segreta è sempre presente tra un EP ed il suo GK per permettere l’autenticazione e lo scambio dei messaggi RAS. Quando i canali RAS e H.225.0 iniziano e terminano tra gli stessi due nodi, la stessa chiave può essere usata per l’autenticazione e l’integrità dei due canali stessi.

La figura 3.10 mostra lo scenario più scalabile dove entrambi gli endpoints appartengono ad una zona dove è applicato il modello GK-routed; tutti i GKs coinvolti condividono le chiavi mutuamente.

La figura 3.11 mostra invece un modello misto dove un EP è all’interno di una zona GK-routed, mentre l’altro EP fa parte di una zona che applica il modello direct-routed.

Key 2 Key 1 Key 3 EP1 EP2 GK1 GK2 H.225.0 RAS H.225.0 Call Signalling

Figura 3.10 - Profilo base GK-GK con EPs nella zona GK-routed

Key 2 Key 1 Key 3 EP1 EP2 GK1 GK2 H.225.0 RAS H.225.0 Call Signalling

Figura 3.11 - Profilo base in uno scenario misto, EP1 in una zona GK-routed, EP2 in una zona direct-routed

3.10.2 Autenticazione ed integrità dei messaggi EP-GK nel SIT

Come già sottolineato, una prima versione del protocollo di sicurezza implementato nel sistema in esame, prevede l’impiego di password simmetrica per l’autenticazione e l’integrità dei messaggi (di conseguenza verifica dell’identità dell’utente). Lo schema di seguito (figura 3.12) riassume la cifratura di un messaggio nel terminale:

H.225 RAS H.225 Call Signalling

Encoded MSG

....

Default Pattern 96-bit

= hash value

.... ....

Localizzo i bit corrisp. al default pattern nell’Encoded MSG e li sostituisco con 0 (96 bit)

.... ....

0 0 0 .. 0 .. 0 0 0

ASN.1

HMAC-SHA1-96 _PASSWORD

Sostituisco i 96 bit posti a zero con i 96 bit risultato della

funzione HMAC-SHA1-96 0 0 0 .. 0 .. 0 0 0 x x x .. x .. x x x .... ....

AUTHENTICATOR Posto in nel campo hash _{all’interno del CryptoToken}

x x x .. x .. x x x

=

EP:

96 bit

=

Il messaggio con all’interno il CryptoToken siffatto, è inviato al GK. Il GK è inteso come entità intermediaria di fiducia (trusted entity), che provvede quindi al controllo delle corrispondenze, nei modi illustrati in figura 3.13. Nell’esempio qui riportato si utilizza l’algoritmo HMAC-SHA1-96*_{, ma è chiaro che qualsiasi procedura} standard può essere comunque implementata.

L’algoritmo MAC* _{(Message Authentication Code) è una funzione} hpw(x), parametrizzata da una chiave (pw), con x =msg. da verificare.

Decoded MSG .... .... 0 0 0 .. 0 .. 0 0 0 ASN.1 HMAC-SHA1-96 PASSWORD

Confronto il risultato con quello contenuto nella variabile RV

.... ....

0 0 0 .. 0 .. 0 0 0 x x x .. x .. x x x

x x x .. x .. x x x

AUTHENTICATOR Viene estratto “l’autenticatore”

Viene estratto il valore hash (96 bit) e tenuto in una variabile locale RV

RV (96 bit)

: “l’autenticatore”

Sostituisco i bit corrispondenti al modello hash con 96 bit = 0

Figura 3.13 - Autenticazione/Integrità (verifica) GK: