|
|
|
|
|
Sicurezza di ZRTP |
|
|
Perché ZRTP è meglio
Il
protocollo ZRTP ha delle caratteristiche interessanti
che mancano in altri approcci alla cifratura del VoIP.
Utilizza un algoritmo pubblico ed evita la complessità
dell'Infrastruttura
a Chiave Pubblica - PKI. In effetti non
impiega alcun sistema pubblico di distribuzione delle
chiavi crittografiche. Utilizza l'algoritmo
Diffie-Hellman di
generazione e scambio delle chiavi e consente il
rilevamento di attacchi di tipo
Man in The Middle
(MiTM), visualizzando una breve stringa di
autenticazione che gli utenti leggono e confrontano al
telefono. Ha una
Forward Secrecy Perfetta,
nel senso che le chiavi crittografiche di sessione sono
distrutte alla fine della chiamata, caratteristica che
preclude la possibilità di decrittare vecchie
conversazioni registrate, rendendo impossibili
ritrovamenti futuri delle chiavi crittografiche. Anche
se gli utilizzatori non si preoccupano di leggere l'un
l'altro la stringa di autenticazione, rimane ancora una
certa difesa contro gli attacchi MiTM basata su una
forma di continuità delle chiavi. ZRTP fa questo
prelevando parte dei dati delle vecchie chiavi da
utilizzare nel
segreto condiviso
Diffie-Hellman della chiamata seguente, dando delle
proprietà di continuità delle chiavi analoghe all'SSH.
Tutto questo è fatto senza fare affidamento su una
Infrastruttura a Chiave Pubblica, sulla certificazione
delle chiavi, sulle
autorità di certificazione,
o sulla complessità dei sistemi di gestione delle chiavi
che affliggono il mondo della cifratura delle e-mail.
ZRTP non fa neppure affidamento sulla trasmissione dati
SIP per la gestione
delle chiavi, in effetti non si appoggia a nessun
server. Gestisce il processo di costruzione e scambio
delle chiavi crittografiche in modalità peer - to - peer
pura, lungo il flusso di pacchetti di dati
RTP. ZRTP utilizza
anche la
cifratura opportunistica,
rilevando automaticamente se il client VoIP chiamato
supporta ZRTP.
Ci
sono delle buone ragioni per cui ZRTP non fa affidamento
su un approccio PKI. Esistono grossi problemi e
complessità con la costruzione, manutenzione e
affidamento ad una PKI. Ecco perché negli anni novanta
un numero di società sono scomparse cercando di
costruire e vendere tecnologie PKI. Vedere il documento
di Ellison e Schneier: "Quello
Che Non Ti E' Stato Detto Sulle Infrastrutture a Chiave
Pubblica" ed il documento di Ellison "Migliorie
Sulle Credenze Convenzionali PKI".
Nel
luglio 2005 il protocollo di ZRTP è stato presentato al
meeting
Black Hat Briefings e
sono state annunciate alcune importanti innovazioni.
Anche se sono state utilizzate in passato in altre forme
ed in altri ambienti, come cifratura PSTN e accesso a
terminali remoti, non erano state applicate in
precedenza per negoziare le
chiavi crittografiche di sessione
per flussi di dati RTP sicuri. Le innovazioni sono:
Primo
protocollo a fare uso di stringhe brevi di
autenticazione - SAS - (Short Authentication String),
per rilevare attacchi MiTM, calcolate in modo tale da
costringere l'intercettatore MiTM ad un unico tentativo
per generare la stringa SAS da usare nel
suo attacco, fatto che implica che la stringa SAS può essere
estremamente breve. Questo era fatto già da
PGPfone, ma non per le
chiavi crittografiche su flussi multimediali RTP
sicuri.
Primo
protocollo ad utilizzare il principio di continuità
delle chiavi specificamente per negoziare chiavi
crittografiche per flussi multimediali RTP sicuri.
SSH
lo aveva già fatto, ma per altre applicazioni non
pertinenti.
Primo
protocollo che esegue la sua negoziazione delle chiavi
nel canale dei dati. Questo era fatto già da
PGPfone ma non per le
chiavi crittografiche per flussi multimediali RTP
sicuri.
Primo
protocollo ad eseguire la cifratura secondo il "miglior
tentativo" (Best Effort Encryption o Opportunistic
Encryption,
cifratura opportunistica)
per negoziare le chiavi per l'RTP sicuro, Questo
significa che il protocollo auto-rileva se l'altro
interlocutore VoIP supporta lo stesso protocollo, senza
lasciare cadere la chiamata nel caso questo non sia
verificato.
ZRTP diventerà uno
standard IETF
Alan
Johnston, Jon Callas e Philip Zimmermann hanno inoltrato
il protocollo ZRTP alla
IETF per iniziare il
processo di standardizzazione. ZRTP è utilizzato per negoziare le chiavi crittografiche. Alan
Johnston è coautore dell'RFC
326 che definisce lo standard SIP, Jon Callas
è il CTO (Direttore Tecnico) alla
PGP Corporation.
ZRTP
rispetta le leggi in materia di telecomunicazioni
L'architettura
di ZRTP rende eventuali dubbi in merito irrilevanti. Le
leggi in materia di assistenza all'Autorità Giudiziaria
si applicano agli
operatori di reti fisse,
mobili e VoIP. La legge impone agli operatori di dare
accesso alla Magistratura a qualsiasi tipo di
informazione o servizio in loro possesso che, nel caso
di ZRTP, sarebbero solo pacchetti di dati criptati. ZRTP
esegue la negoziazione delle chiavi in modalità Peer to
Peer, cioè fra i due dispositivi esclusivamente e gli
operatori di rete non hanno alcun accesso alle chiavi.
Solo gli utilizzatori finali sono coinvolti nel processo
di creazione e negoziazione delle chiavi crittografiche
e la legge non si applica loro.
I governi e
la cifratura (crittografia) robusta
La
domanda è lecita nel clima post 11 settembre 2001.
L'interrogativo se la crittografia forte dovesse essere
ristretta nei suoi usi dal governo, è stato dibattuto a
lungo negli Stati Uniti negli anni novanta. Il dibattito
è stato partecipato dalla Casa Bianca, dalla National
Security Agency, dall'FBI, dalle Corti dei tribunali,
dal Congresso, dall'industria dei computer, dagli
accademici e dalla stampa. Questo dibattito ha preso in
considerazione pienamente l'eventualità che i terroristi
utilizzino la crittografia forte ed in effetti questo è
stato uno dei punti chiave del dibattito. Nonostante
tutto, la decisione finale della società nel suo insieme
è stata (nonostante le obiezioni dell'FBI) di avere la
crittografia forte disponibile per tutti, senza
backdoors
governative. I controlli sull'esportazione furono
eliminati e nessun controllo sulla crittografia negli
USA fu istituito. Questa fu una buona decisione, perché
le fu dedicato del tempo ed ha avuto una larga
partecipazione di esperti in materia. Gli attacchi
dell'undici settembre non hanno cambiato la saggezza di
quella decisione collettiva, ed anche se le libertà
civili sono state erose da allora, il diritto all'uso
della crittografia forte non è andato perso.
La
comunità delle Forze dell'Ordine è comprensibilmente
preoccupata dagli effetti della crittografia forte sul
VoIP e sulla loro capacità di intercettare legalmente.
Ma quale sarebbe il risultato globale sul sistema della
giustizia criminale se il VoIP non venisse criptato?
Storicamente, le Forze dell'Ordine hanno goduto di una
forte asimmetria nella fattibilità di esecuzione delle
intercettazioni delle linee fisse e mobili rispetto ai
criminali. Con la progressiva migrazione verso il VoIP,
questa asimmetria collassa.
L'intercettazione del VoIP è così
facile ed il crimine organizzato sarebbe in
grado di intercettare Pubblici Ministeri e Giudici,
entrando in possesso di dettagli di investigazioni in
corso, nomi di testimoni ed informatori e conversazioni
con le loro mogli sugli orari in cui vanno a prendere i
loro figli a scuola. La comunità delle Forze dell'Ordine
riconoscerò che la cifratura del VoIP in effetti è
necessaria per i loro interessi vitali.
Come ZRTP protegge
contro gli attacchi Man in The Middle
Il
protocollo
Diffie-Hellman di per
se non protegge contro attacchi
Man in The Middle
(MiTM). Per autenticare lo scambio delle chiavi, ZRTP
usa una Short Authentication String - SAS (Stringa Breve
di Autenticazione), che essenzialmente è un
Hash crittografico dei
due valori Diffie-Hellman. Il valore Hash è visualizzato
ad entrambe le estremità comunicanti. Per eseguire
l'autenticazione, il valore SAS è letto da entrambi i
partecipanti alla conversazione lungo la linea voce. Se
i valori alle due estremità non combaciano, questo
indica la presenza di un attacco Man in The Middle. Se
invece combaciano, c'è un'elevata probabilità che non
sia in atto alcun attacco Man in The Middle. L'uso del
valore di Hash nello scambio Diffie-Hellman costringe
l'eventuale attaccante a potere fare solo un tentativo
di indovinare la stringa SAS durante il suo attacco, il
che implica che la stringa SAS può essere piuttosto
breve. Una SAS di 16 bit, per esempio, dà all'attaccante
solo una probabilità su 65536 di non essere rilevato.
ZRTP
fornisce anche un secondo livello di autenticazione
contro gli attacchi MiTM, basato su una forma di
continuità delle chiavi crittografiche. ZRTP fa questo
prelevando parte dei dati delle vecchie chiavi da
utilizzare nel
segreto condiviso
Diffie-Hellman della chiamata seguente, dando delle
proprietà di continuità delle chiavi analoghe all'SSH.
Se l'attaccante MiTM non è presente nella prima
chiamata, è chiuso fuori alla successiva. Quindi anche
se la stringa SAS non è mai usata, la maggior parte
degli attacchi MiTM sono bloccati. Le caratteristiche di
continuità delle chiavi di ZRTP hanno delle proprietà di
auto riparazione che sono migliori rispetto
all'approccio di SSH.
Perchè ZRTP non utilizza DTLS-SRTP
Il
DTSL-SRTP derivato dal
TLS, è un protocollo
progettato per i browser Web per il loro dialogo con i
server Web e fa uso di una struttura PKI con gestione
centralizzata. Un protocollo come il TLS funziona bene
in un ambiente client-server, ma una chiamata telefonica
fra due esseri umani è una relazione Peer-to-Peer ad
hoc e la negoziazione delle chiavi crittografiche
dovrebbe riflettere questo fatto. Anziché riciclare un
protocollo client-server, ZRTP è nuovo progettato
appositamente per il VoIP. Tutti questi protocolli
crittografici hanno l'obiettivo negoziare le chiavi in
modo di bloccare gli attacchi del tipo Man in The Middle
(MiTM). Per fare questo, ZRTP non necessita di una
struttura PKI e non servono server controllati dalla
compagnia telefonica. Invece, ZRTP vede due esseri
umani che verbalmente confrontano la stringa SAS per
rilevare se c'è un attacco MiTM in corso. Gli esseri
umani possono vedere velocemente se c'è un attacco MiTM
grazie all'evidenza ed al buon senso. ZRTP sfrutta le
immense risorse alle due estremità che hanno ciascuna un
cervello con centinaia di miglia di miliardi di sinapsi
ed il potere unico dell'intuizione umana.
Il
DTSL-SRTP cerca di adattarsi all'ambiente Peer to Peer
del VoIP, ma non può sfuggire alle sue radici
client-server, ecco perché dipende così completamente
dai server
SIP per mettere in
sicurezza la connessione. La protezione contro gli
attacchi MiTM di DTLS-SRTP collassa in assenza della
protezione di integrità punto a punto nel layer SIP.
L'unico meccanismo per questo nel SIP (a parte S/MIME
che è in circolazione da sei anni senza alcuna
implementazione) è l'Enhanced SIP Identity (RFC
4474). Comunque, accade che se si sta
utilizzando il telefono SIP per chiamare un normale
numero di telefono, allora l'RFC 4474 non fornisce
alcuna protezione di integrità e la protezione MiTM per
l'SRTP collassa. Perchè? Perchè per un normale numero di
telefono l'identità SIP è nella forma
+13145551212@example.com asserito da example.com. Un
attaccante MiTM potrebbe semplicemente rimuovere la
firma RFC 4474, cambiare l'impronta digitale
a=fingerprint, rifirmare l'identità come SIP
+13145551212@example2.com, asserito da example2.com.
Come fa il chiamato a sapere che questo numero è in
effetti originato da example.com e non è example2.com?
Non c'è un modo per dirlo, quindi DTLS-SRTP non ha
protezione contro gli attacchi MiTM. Normali numeri
telefonici saranno utilizzati come identificativo per i
clienti SIP per molto tempo, quindi questo continuerà ad
essere una debolezza nella sicurezza importante per il
DTSL-SRTP.
Anche
se questo problema con i normali numeri telefonici fosse
risolto, rimarremmo comunque con il classico
Elefante nella Stanza,
nel senso che in definitiva, la sicurezza del protocollo
DTLS-SRTP richiede una infrastruttura PKI. La dipendenza
dalla PKI è contenuta nel DTLS-SRTP stesso o entro il
SIP, a causa della dipendenza del DTLS-SRTP
sull'integrità punto a punto del SIP. Tutti i meccanismi
di integrità punto a punto SIP richiedono una
infrastruttura PKI, con le conseguenti
complessità e burocrazia.
Molti anni di esperienza nell'industria crittografica
portano a credere che quello dell'infrastruttura PKI sia
un approccio inappropriato per raggiungere la sicurezza
del media nel VoIP.
Alcune
società che pianificano di implementare il protocollo
DTLS-SRTP dicono che loro utilizzeranno certificati a
chiave pubblica auto emessi, se non è disponibile alcuna
infrastruttura PKI. Ma un certificato del genere non
protegge contro gli attacchi MiTM. Se non utilizzano una
PKI e non hanno alcun'altra contromisura contro gli
attacchi MiTM, come la continuità della chiave o una
stringa SAS, semplicemente il loro non sarà un telefono
sicuro.
Anche
se piuttosto meno importante del problema sopra
menzionato, c'è un'altro problema contro questo
protocollo, il DTSL-SRTP deve sopportare il costo
addizionale del calcolo dei certificati di firma su di
se stesso, in aggiunta ai calcoli di firma che il layer
SIP usa per raggiungere la sua protezione di integrità.
ZRTP non ha bisogno di nessun calcolo di firma per
appoggiarsi ai calcoli di firma eseguiti nel layer SIP.
Questo fatto potrebbe essere importante per le
piattaforme mobili con bassa potenza di calcolo o per
server ad alto carico.
Il mio telefono VoIP
già usa SDES per negoziare le chiavi
Non
è una buona idea. Mentre la maggior parte dei telefoni
VoIP non cripta le conversazioni, alcuni hanno
implementato il protocollo
SDES (RFC
4568) per la negoziazione delle
chiavi crittografiche di sessione
per la cifratura della chiamata. Di tutti i metodi che
la IETF ha considerato per questo scopo, SDES è il meno
sicuro. Funziona in questo modo. Si supponga che Alice
voglia parlare con Bob che risiede in Cina. Il telefono
di Alice genera una chiave casuale di sessione per
criptare la conversazione, ma in qualche modo Alice deve
fare arrivare nelle mani di Bob questa chiave parchè
entrambi possano usarla. Il suo telefono trasmette
questa chiave via SIP al suo Service Provider VoIP, per
esempio la sua compagnia telefonica locale. La compagnia
telefonica, che ora ha piena conoscenza di questa chiave
crittografica, la trasmette alla compagnia telefonica di
Bob in Cina. La compagnia telefonica di Bob, posseduta
dal governo cinese, ha adesso piena conoscenza della
chiave crittografica, la trasmette al telefono di Bob.
Ora i telefoni di Alice e Bob sono in grado di iniziare
la chiamata criptata.
Cosa c'è di sbagliato in questo
schema? Se Alice desidera parlare con Bob di
argomenti che riguardano i diritti umani, o di come
potrebbero aggirare le barriere commerciali, il governo
cinese può facilmente monitorare la chiamata.
Per
rimanere competitivi nell'economia globale, è bene che
una società utilizzi la cifratura punto a punto,
per proteggere le sue comunicazioni di lavoro dai
governi stranieri. E alcuni di noi hanno dubbi sul
fatto che le compagnie telefoniche domestiche agiscano
sempre con i nostri interessi in mente.
Se
PGP avesse implementato un protocollo così scadente,
avrebbe incontrato la diffidenza della comunità dei
crittografi. Ma i venditori di prodotti VoIP sembrano
cavarsela comunque, perché la cifratura non è una parte
centrale delle competenze dell'industria VoIP.
Perché non
utilizzare IPsec per cifrare le chiamate VoIP
Sarebbe
una cattiva idea nella maggior parte dei casi. La
cifratura
IPsec è fatta nel layer
IP della
suite di protocolli Internet,
che è troppo in profondità per fare sapere
all'utilizzatore se sta girando. Alcuni router
supportano IPsec ed altri non lo supportano. Non si può
sapere se la controparte supporta IPsec, così alcune
connessioni saranno non criptate e non lo si saprà mai. Se
non sappiamo se una chiamata è criptata o meno, che c'è
di valido nel protocollo? E' meglio fare la cifratura
nel layer di dell'applicazione, così che l'utente sappia
dire se la conversazione è criptata oppure no.
Perché usare
ZRTP se già si ha SRTP
A
dispetto della similitudine nei due nomi, non c'è una
scelta fra ZRTP e
SRTP. Uno non
sostituisce l'altro. SRTP è il protocollo impiegato per
criptare i pacchetti voce a basso livello. SRTP da solo
non è la soluzione. SRTP non può essere impiegato fino a
quando entrambe le parti non concordato le chiavi
crittografiche da utilizzare per la cifrature SRTP. Ecco
dove entra in gioco ZRTP. ZRTP è il protocollo ch
le due parti impiegano per negoziare le chiavi
crittografiche di sessione. ZRTP usa SRTP, ma negozia le chiavi di sessione SRTP. |
|
|
|
|
|
|
|
|
|
ZRTP
è Open Source e non solo
Philip Zimmermann
crede fermamente nella pubblicazione del codice sorgente
di software crittografico per la Peer Review, per
costruire la confidenza pubblica sul fatto che il codice
non contenga
backdoors, una
tradizione iniziata nel 1991 con
PGP. PGP è un prodotto
proprietario, anche se il codice sorgente è disponibile
pubblicamente per le revisioni indipendenti. Pubblicare
il codice per la Peer Review non è la stessa cosa che
renderlo disponibile sotto una licenza Open Source.
Philip Zimmermann ha pagato di tasca propria i costi per lo
sviluppo di ZRTP e desidera continuare a pagare i suoi
ingegneri per fare miglioramenti e sopravvivere mentre
fa queste cose. A causa di questo, Zimmermann è
stato riluttante a dare in licenza ZRTP sotto una
licenza Open Source, ma un numero di persone hanno
sostenuto che egli avrebbe comunque potuto guadagnare se
avesse reso disponibile ZRTP sotto una licenza duale,
con
AGPL, per l'inclusione
in progetti Open Source e con una licenza commerciale
per per prodotti proprietari. Certi software, come MySQL,
hanno avuto un percorso simile. Così Zimmermann ha
deciso di impiegare una politica di licenza a doppio
binario.
ZRTP
ha diverse componenti principali e non tutti sono
inquadrati sotto lo stesso schema di licenza. Il corpo
intero del
codice sorgente per il
client software ZRTP completo è pubblicato per la Peer
Review. In aggiunta, la libreria libZRTP SDK è
pubblicata sotto
AGPL versione3. La
libreria libZRTP SDK può essere inclusa in qualsiasi
progetto AGPL. Comunque, il resto dell'applicazione
ZRTP nel suo intero (contrapposta alla libreria libZRTP
SDK) rimane proprietaria ed è pubblicata per la Peer
Review ma non sotto una licenza Open Source.
ZRTP supporta
il protocollo Diffie-Hellman a Curve Ellittiche
Nella
versione a pagamento, ZRTP supporta il protocollo
Diffie-Hellman nella versione a
Curve Ellittiche, come definito dallo
standard NIST SP 800-56A e dalla
Suite B NSA (National
Security Agency) che usa le stesse curve
ellittiche usate dalla ECDSA nello standard FIPS 186-3.
Gli algoritmi a curve ellittiche sono la prossima
generazione di crittografia a chiave pubblica, ed
offrono un livello di sicurezza che sposa meglio la
robustezza delle chiavi dell'AES-256.
Entrambe le
parti devono usare ZRTP per una chiamata sicura
Questo
è necessario in maniera simile a quanto accade per le
telefonate stesse. Servono due telefoni per fare una
chiamata, due fax per inviare un documento e due ZRTP
per una chiamata criptata sicura.
La
continuità delle chiavi ZRTP confrontata con SSH
Le
caratteristiche di continuità delle chiavi
crittografiche fornite da ZRTP sono simili a quelle di
SSH, ma differenti in
un aspetto. SSH memorizza nella cache le chiavi di
firma digitale, che non
cambiano mai ed utilizza una chiave di firma permanente
privata che deve essere protetta dall'esposizione. Se
qualcuno si impossessa della chiave di firma SSH
privata, allora è possibile impersonare e sostituirsi al
legittimo proprietario in tutte le future sessioni di
comunicazione e mettere in piedi un attacco del tipo
Man in The Middle
efficace, in qualsiasi momento.
ZRTP
memorizza nella cache il materiale delle
chiavi crittografiche simmetriche
che viene mescolato nelle
chiavi segrete delle sessioni
di chiamata successive, le quali cambiano ad ogni sessione.
Se qualcuno si impossessa della
cache segreta condivisa
di ZRTP, questi avrebbe a disposizione solo una
possibilità per un attacco MiTM, nella sessione di
chiamata immediatamente successiva. Se l'attaccante
perde quella opportunità, il segreto condiviso è
modificato con un nuovo valore e la finestra di
vulnerabilità si auto ripara. Questo significa che ogni
futura opportunità di costruire un attacco MiTM viene
bloccata. Questo conferisce ad ZRTP una caratteristica
di auto riparazione nel caso venga compromesso del
materiale delle chiavi crittografiche.
Un
attaccante MiTM dovrebbe essere sempre nel canale dei
dati multimediali. Questo presenta delle difficoltà
operative per l'attaccante in molti scenari di utilizzo
del VoIP, perché essere nel canale dati per ogni
chiamata è spesso molto più difficile che essere nel
canale dei dati di chiamata
(signalling). Questo crea dei gap di copertura alla
possibilità di mettere in piedi degli attacchi MiTM. Le
caratteristiche di auto riparazione della continuità
delle chiavi di ZRTP sono migliori rispetto ad SSH per
la copertura di finestre temporali per sferrare attacchi
MiTM. Quindi lo ZRTP recupera velocemente da ogni
esposizione temporanea del materiale delle chiavi
memorizzato nella cache.
La
vulnerabilità nella debolezza delle chiavi poco
conosciuta del
Debian OpenSSL
(scoperta e riparata nel maggio 2008) offre un esempio
dal mondo reale sul perché lo schema di auto riparazione
di ZRTP è un buon modo di usare la continuità delle
chiavi. Il bug di Debian ha avuto l'effetto di produrre
un numero elevato di di chiavi SSH deboli, che ha
consentito di compromettere la sicurezza anche dopo che
il bug è stato riparato. In contrasto, lo schema di
continuità delle chiavi crittografiche di ZRTP aggiunge
ulteriore entropia al materiale delle chiavi memorizzato
nella cache per ogni chiamata, così vecchie debolezze
nell'entropia sono spazzate via con ogni nuova sessione
di chiamata.
C'è
un ulteriore beneficio per la forma di continuità delle
chiavi di ZRTP. Conferisce una misura di immunità da
ogni futura scoperta nel campo dei
computer quantici, che
potrebbero
minare la robustezza degli
algoritmi a chiave pubblica come
Diffie-Hellman. Probabilmente i rischi ed i timori sui
computer quantici sono sovrastimati a causa di
difficoltà pratiche
importanti nella costruzione di computer quantici
efficaci. Soprattutto considerando le
dimensioni delle chiavi
Diffie-Hellman utilizzate dal protocollo.
Nonostante
questo, assumendo anche che computer quantici con la
necessaria complessità possano essere costruiti,
gli
algoritmi simmetrici
con lunghezza delle chiavi di 256 bit rimangono sicuri
da attacchi con computer quantici. Questo significa che
la continuità delle chiavi di ZRTP può fare il suo
lavoro, a patto che l'intercettatore non sia presente
alla prima chiamata nel canale multimediale. Questo
perché l'intercettatore non conosce il segreto condiviso
ereditato dalla prima chiamata effettuata che sarà
mescolato nelle chiavi di sessione delle chiamate
successive. Nel qual caso egli non può determinare la
nuova chiave di sessione anche se può violare il
Diffie-Hellman.
Questo
implica anche che si può utilizzare AES-256 con chiavi
Diffie-Hellman a 3072 bit ed avere comunque la
robustezza della chiave AES a 256-bit. Sembrerebbe una
variante rispetto alle linee guida del NIST che
raccomandano l'uso di AES-128 con il protocollo
Diffie-Hellman 3072, perché il work factor di violazione
di entrambi è circa lo stesso. Ma se ZRTP può mescolare
256 bit aggiuntivi di entropia condivisa segreta,
provenienti dalle sessioni precedenti quando calcola una
nuova chiave crittografica di sessione, la robustezza
del risultato può eccedere quella del Diffie-Hellman
3072. Questo assumendo che l'intercettatore non sia
stato in grado di osservare la prima sessione.
La
gestione delle chiavi nel canale dati
Alcuni
propositori di altri schemi di cifratura del VoIP dicono
che vedere ZRTP negoziare le chiavi crittografiche nel
flusso dei dati multimediali anziché nel layer di
segnalazione, urta la loro sensibilità. La chiamano
"violazione del layer". Però, per Zimmermann e per un
numero di altri specialisti di protocolli, sembra chiaro
che il layer di segnalazione dovrebbe occuparsi
esclusivamente delle proprie chiavi per l'autenticazione
del canale ed il layer dei dati voce dovrebbe negoziare
le proprie chiavi per la cifratura dei dati
multimediali. Ciascuno dei due layer dovrebbe farsi
carico di negoziare le chiavi per le proprie necessità
di cifratura. In effetti al contrario, si può dire che
la negoziazione delle chiavi per la cifratura dei dati
multimedia fatta nel layer di segnalazione è la vera
violazione.
Sulla
stessa linea, si può dire che i Service Provider VoIP
non sempre agiscono negli interessi dell'utente, quindi
è bene non coinvolgere i loro server SIP nella
negoziazione delle chiavi. Se si vuole parlare
Navajo (la lingua degli
indiani) con un amico, al telefono, non deve essere
prima necessario accordarsi con la compagnia telefonica.
Semplicemente non è affar loro. E questo e parte delle
caratteristiche che rendono ZRTP così attraente.
Vale
anche la pena notare che i
telefoni di sicurezza
tradizionali nel mondo della telefonia fissa, come l'AT&T
TSD-3600 e lo
STU-III facevano la
loro negoziazione delle chiavi nel flusso di dati voce.
Utilizzavano un modem per creare un canale digitale su
una normale linea telefonica voce, negoziavano le chiavi
crittografiche ed inviavano anche le chiamate vocali non
protette sullo stesso canale. Nessuno parlava al tempo
di violazione di layer. Questo è il modo in cui i
telefoni sicuri hanno sempre funzionato prima
dell'arrivo del VoIP.
ZRTP non ha backdoors
Chiunque
conosca qualcosa su Philip Zimmermann sa che è così. In effetti egli ha un'intera
pagina sull'argomento per PGP, che si applica
allo stesso modo a ZRTP. Il software è in via di
sviluppo e non è possibile assicurare che sia esente da
bug. Dei test e delle revisioni sono tuttora in corso.
Tuttavia,
una buona regola base per sapere se vi sono backdoors in
un prodotto è di farsi la domanda: "pubblicano il codice
sorgente per le revisioni indipendenti?". Philip
Zimmermann lo fa, pubblica cioè il codice sorgente di
ZRTP. E' quindi possibile controllarlo e creare un
programma eseguibile a partire da esso. In generale non
è bene fare affidamento su un prodotto di cifratura se
non viene pubblicato il codice sorgente.
La stringa SAS non è
attaccabile da un imitatore della voce
La
protezione fornita dalla Stringa Breve di Autenticazione
SAS in termini pratici non può essere violata da un
imitatore della voce. E' un errore pensare che un
attacco del genera sia meramente un esercizio di
imitazione della voce. Anche se esistono tecniche di
processamento digitale per cambiare la voce di una
persona, questo non significa che un attaccante
Man in The Middle può
irrompere in sicurezza in una conversazione telefonica
ed iniettare la sua Stringa Breve di Autenticazione SAS.
proprio al momento giusto. Egli non sa esattamente
quando o in quale modo gli utilizzatori sceglieranno di
leggere la stringa SAS, o in quale contesto lo faranno.
Inoltre, alcuni metodi per visualizzare la stringa SAS
prevedono l'uso di una lista di parole, in particolare
la
lista di PGP, in un
modo analogo a quanto fanno i piloti
NATO con l'alfabeto fonetico
per convogliare informazioni. Questo può rendere ancora
più complicato l'attacco, perché queste parole possono
essere impiegate nella conversazione in un modo non
predicibile. E' bene tenere presente che l'attaccante
ritiene di grande importanza il fatto di non essere
scoperto, se commette un errore tutti i suoi sforzi
sarebbero compromessi.
Per
ridurre ulteriormente la probabilità di un attacco con
imitazione della voce, le parti dovrebbero ripetere
entrambe la stringa SAS, se pensano che la chiamata
verosimilmente richiami l'attenzione di un avversario
dotato di ingenti risorse e che desidera affrontare il
rischio.
Alcuni
hanno sollevato il dubbio che se anche l'attaccante non
possiede le capacità di imitazione della voce, potrebbe
essere insicuro per persone che non si conoscono fare
affidamento sulla lettura della stringa SAS. Questo non
è un problema grande quanto potrebbe sembrare, perché
non è necessario che i due si riconoscano attraverso la
voce, è solo necessario che essi rilevino che la voce
utilizzata per la lettura della stringa SAS è la stessa
che sentono durante la conversazione.
Sono disponibili le prime
analisi indipendenti di ZRTP
La
società di analisi sulla sicurezza di Andy Clark,
Detica Forensics, ha
eseguito una
analisi indipendente
disponibile pubblicamente. I risultati sono stati buoni.
tuttavia questo non significa che non ci siano in
assoluto falle nella sicurezza di ZRTP. Eppure,
questa analisi consente di creare una maggiore
confidenza, almeno negli aspetti coperti dall'analisi.
ZRTP cripta
i toni DTMF della tastiera
ZRTP
cripta tutto il traffico RTP, inclusi i toni
DTMF. I toni DTMF sono
trasportati nel flusso multimediale di RTP usando metodi
definiti dallo standard
RFC 2833, integrati
come dati RTP speciali. E' importante cifrare anche
questi dati perché vengono utilizzati, per esempio, per
inserire i dati delle carte di credito quando vengono
fatte chiamate alle banche.
ZRTP non protegge contro
l'analisi del traffico
ZRTP
semplicemente cripta il contenuto della chiamata. Un
modo per proteggersi dall'analisi
del traffico è quello di passare attraverso
intermediari multipli, che è una tecnica impiegata per
proteggere le e-mail e la navigazione Internet (vedere
il
Progetto Tor), ma
questo aggiunge della latenza alla comunicazione, che
può essere ininfluente per le e-mail e la navigazione
Internet, ma intollerabile per le chiamate voce.
Inoltre, queste contromisure potrebbero essere
inefficaci contro avversari pieni di risorse ed
intelligenti, perché è difficile nascondere la lunghezza
ed i tempi della comunicazione, specie se ci sono
esigenze di comunicazioni in tempo reale.
ZRTP non verifica
l'identità della persona chiamata
Non
prova neppure. Non è necessario verificare l'identità
dell'altra persona per mettere in piedi una
comunicazione sicura. In una normale chiamata sulla
linea fissa accade che chiamando una persona, per
esempio, risponde la moglie. Semplicemente si usa il
proprio intuito per capire la situazione. Questo è il
modo in cui funziona il telefono e non è una novità.
Certamente questa non è una ragione per non fare una
chiamata sicura. La più importante vulnerabilità
potenziale è l'attacco del tipo Man in The Middle, da
cui ZRTP difende utilizzando la stringa SAS, la
continuità delle chiavi, oppure entrambe.
Certamente
aiuta conoscere l'identità del chiamate prima di
rispondere al telefono. come per l'identificativo
del chiamante per una chiamata sulla linea
fissa. Il protocollo
SIP cerca di trattare
questo problema nel
canale di segnalazione,
ma è un problema diverso, certamente degno di
attenzione, ma non è lavoro per lo ZRTP. Lo ZRTP non
lavora fino a che l'utente risponde al telefono e la
chiamata sta iniziando. ZRTP stabilisce meramente una
connessione sicura resistente alle intercettazioni con
un altro punto terminale ZRTP e lo fa piuttosto bene,
restringendo lo scopo della propria missione.
Probabilmente
diverse persone si bloccano di fronte al problema di una
chiamata non autenticata. E' un problema difficile e
forse non vale la pena affrontarlo. La maggior parte dei
telefoni, sia di casa che di lavoro, sono utilizzati da
più di una persona. Molte persone utilizzano comunemente
il telefono di altri. Non c'è una relazione uno ad uno
fra persone e telefoni. Poi c'è il problema di definire
un'identità digitale. Si potrebbe avere una burocrazia
complessa che crea una
infrastruttura a chiave pubblica
che rilascia
certificati che si
possono applicare al telefono e che potrebbero essere
visualizzati sugli altri telefoni. Non solo questo ha un
valore discutibile, ma è
anche difficile. Un
numero di persone di valore, incluso Carl Ellison, hanno
scritto sulla
difficoltà e la complessità
di creare nomi unici non ambigui e applicarli in maniera
fissa alle persone.
E'
un errore guardare al mondo attraverso uno schermo
radar, occorre sempre utilizzare i propri occhi ed il
buon senso. Lo ZRTP non può dire chi sia la persona con
cui si sta parlando, oppure se questa stia dicendo la
verità. E non può neppure dire se la controparte sta
inoltrando la conversazione verso qualcun altro. Ma
questo non è possibile per nessun altro dispositivo. |
|
|