ZRTP è un protocollo di cifratura e di scambio chiavi che permette di stabilire una telefonata VoIP (Voice over IP) sicura e cifrata punto-punto (end-to-end).
La prima versione del protocollo ZRTP è stata inventata e pubblicata nel 2006 da un gruppo di esperti e famosi crittografi:
Il protocollo, soggetto a revisioni pubbliche e indipendenti per più di 4 anni, è stato sviluppato seguendo un processo di miglioramenti continui a seguito di frequenti e intense analisi di sicurezza da parte della comunità scientifica e dagli esperti di sicurezza di tutto il mondo.
L’ultimo aggiornamento delle specifiche del protocollo è disponibile sul sito IETF nella pagina dedicata a ZRTP.
ZRTP si occupa di gestre uno scambio di chiavi automatico tra due telefoni che supportano tale protocollo, mettendo in sicurezza la telefonata. Vengono in seguito mostrate sullo schermo del chiamante e chiamato due chiavi che vanno comparate verbalmente per avere la certezza che non vi sia in essere una intercettazione.
Se le due chiavi combaciano perfettamente, la chiamata è sicura.
Le chiavi da comparare, sono dette Short Authentication Strings (SAS) e sono prese dalla PGP Word List, parole che hanno la caratteristica di essere foneticamente distinguibili anche fra interlocutori con origini linguistiche differenti. .
Ai fini di migliorare l’usabilità e l’esperienza utente, le SAS possono essere verificate solo la prima volta (per lo stesso contatto); il contatto può essere di seguito alla corretta verifica verbale marcato come “fidato”.
In questo modo i due utenti non devono verificare le SAS ad ogni chiamata. Questa funzione è possibile grazie alla funzione “Key continuity” di ZRTP.
Grazie alla sua diffusione, ZRTP è diventato un protocollo per la cifratura della voce veramente completo, coprendo anche altri scenari d’uso particolari.
PrivateGSM utilizza quindi un set ridotto delle funzioni di ZRTP per alleggerirlo da tutte le funzionalità non necessarie, rendendolo meno pesante, più facile da capire e analizzare:
In questo modo, ZRTP è usato per lo scopo per cui è stato ideato: effettuare telefonate sicure.
Dal punto di vista tecnico, ZRTP ha un grande vantaggio: non richiede alcun supporto protocollare specifico da parte del centralino telefonico SIP, essendo tutte le operazioni crittografiche effettuate “in-band”, cioè all’interno dello stesso canale di comunicazione su cui avviene il trasporto della voce.
Una volta che l’handshake telefonico SIP è completato con successo (il contatto chiamato risponde al telefono), inizia l’handshake delle chiavi ZRTP, seguito dallo scambio di audio criptato:
Inoltre, va evidenziato che ZRTP aumenta la forza crittografica del sistema di generazione di numeri casuali utilizzando come fonti di entropia anche campioni audio registrati dal microfono.
In questo modo l’implementazione ZRTP raccoglie sempre entropia fresca e veramente casuale, raccolta da una sorgente fisica quale è il microfono. Ci atteniamo strettamente a tutte le raccomandazioni ZRTP RFC per la generazione di numeri casuali.
Il protocollo ZRTP, di per sé, non funziona su alcuni PBX (Asterisk per esempio lo blocca). Tuttavia la tecnologia PrivateWave estende il protocollo con qualche lieve miglioria, che noi chiamiamo ZRTP Masquerading.
Lo ZRTP Masquerading permette a PrivateGSM di funzionare anche con un PBX che non supporta il protocollo ZRTP.
Per esaminare e analizzare uno scambio di chiavi ZRTP, visitate la pagina Wireshark ZRTP dissector.
N.B.: ZRTP non è da usarsi per modelli di sicurezza end-to-site perché comporta una eccessiva complessità di gestione per il corretto mantenimento del livello di sicurezza, rendendo di fatto l’intero sistema meno sicuro perché più complesso da mantenere. Per la cifratura end-to-site consigliamo di utilizzare SRTP/SDES che, disponibile fin dal 2004, è già ampiamente diffuso e supportato sulla maggior parte dei PBX aziendali. La messa in sicurezza con SRTP richiede esclusiva mene una appropriate gestione del certificato digitale del server (come l’https nei siti di banking, per esempio). L’uso di ZRTP per la cifratura end-to-site non è quindi supportato da PrivateGSM, richiedendo, rispetto ad SRTP/SDES, un eccessiva complessità di gestione e scarsa interoperabilità con centralini esistenti.