Cosa è ZRTP
ZRTP è un nuovo protocollo per telefonate sicure che consente di effettuare chiamate criptate sulla rete Internet. Il suo designer principale è Philip Zimmermann, creatore di PGP, il software di cifratura delle e-mail più diffuso al mondo (PGP è stato definito da Bruce Schneier, uno dei più stimati crittografi ed esperti in sicurezza al mondo come: "Il sistema probabilmente più vicino alla crittografia di livello militare").
ZRTP ha una migliore architettura rispetto ad altri approcci per mettere in sicurezza il VoIP. Il protocollo ZRTP intercetta e filtra tutti i pacchetti di dati VoIP che entrano ed escono dal telefono e mette in sicurezza la chiamata in tempo reale.
Il software ZRTP rileva quando la chiamata comincia, ed inizia una sessione di generazione delle chiavi crittografiche fra le due parti e poi procede nel criptare e decrittare i pacchetti di dati voce in tempo reale. Ha la sua piccola GUI - Interfaccia Utente Grafica - e dice all'utilizzatore se la chiamata è sicura.

ZRTP utilizza i migliori algoritmi disponibili
Per la cifratura viene impiegato l'AES, Advanced Encryption Standard, l'algoritmo destinato a proteggere le informazioni del governo degli Stati Uniti.
La generazione e lo scambio delle chiavi avvengono con il protocollo Diffie-Hellman, per il quale è supportata anche la versione a Curve Ellittiche.

ZRTP Rispetta le Norme FIPS, FISA ed NSA
ZRTP viene attualmente sviluppato per ottenere la certificazione FIPS-140, e per potere quindi vendere i prodotti che lo utilizzano ai clienti del Governo degli Stati Uniti o ai governi di alcuni altri paesi. Per questa ragione ZRTP fa uso esclusivamente di algoritmi approvati dal FIPS in tutte le categorie significative.
Per rispettare le specifiche di validazione fissate dallo standard NIST FIPS PUB 140-2 Annex A e dal NIST FIPS PUB 140-2 Annex D, ZRTP rispetta le specifiche:
NIST SP 800-56A. Raccomandazioni per gli Schemi di Creazione delle Chiavi fra Pari Utilizzando la Crittografia ad Algoritmi Discreti.
NIST SP 800-108. Raccomandazioni per la Derivazione delle Chiavi Utilizzando Funzioni Pseudo Casuali.
NIST FIPS PUB 198-1. Codice di Autenticazione del Messaggio con Chiave Hash (HMAC)
NIST FIPS PUB 180-3. Standard per gli Hash Sicuri (SHS)
NIST SP 800-38A. Raccomandazioni per le Modalità Operative dei Cifrari a Blocchi.
NIST FIPS PUB 197. Advanced Encryption Standard (AES)
NSA Suite B

Mobile Privacy Ltd è la prima società pubblica al mondo ad offrire Sistemi di Sicurezza integrati per la difesa dalle intercettazioni telefoniche ed informatiche, progettati secondo le linee guida della Security Engineering, sul modello sviluppato da Iridium per il Dipartimento della Difesa (DoD) americano attraverso il Gateway e la struttura dedicata di Wahiawa nelle Isole Hawaii (servizi Enhanced Mobile Satellite Services).
Mobile Privacy propone dei Sistemi di Sicurezza Anti Intercettazioni in cui vengono integrati crittografia, canali di comunicazione anonimi e protocolli di sicurezza per l'impiego dei terminali mobili, oltre a servizi di supporto forniti ai Clienti, erogati anch'essi con procedure di sicurezza.
Fra i servizi ed i prodotti forniti, SIM Anonime GSM/GPRS/EDGE/HSDPA, SIM Anonime Satellitari, Connessioni Internet Anonime, una vasta gamma di terminali GSM e Satellitari criptati, hardware e software cifranti, fax criptati e reti GSM/ISDN/IP sicure.

 Mobile Privacy ha progettato, formalizzato e reso disponibili pubblicamente dei modelli di attacco simili agli Attack Tree (alberi degli attacchi) inventati da Bruce Schneier introducendo una nuova forma di modello di attacco denominata Probabilistic Attack Matrix (matrice probabilistica degli attacchi).
Questi modelli descrivono efficacemente le modalità investigative utilizzate nella realtà quotidiana da coloro che si occupano di investigazioni (lecite ed illecite), fondate sull'impiego delle intercettazioni telefoniche, dei tabulati telefonici e di tutti i dati associati ed associabili alle telecomunicazioni e consentono, tra l'altro, di progettare dei Sistemi di Sicurezza affidabili.
Mobile Privacy ha accordi commerciali con i maggiori produttori mondiali di software ed hardware cifranti e di sistemi per la protezione delle telecomunicazioni.
Serve con successo centinaia di Clienti appartenenti a tutte le categorie, Società, Privati, Investigatori, Ordini Professionali, Forze dell'Ordine, Agenzie Militari e Gruppi Politici.

Vedere cellulari spia e spy phone

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.