Jump to content

ZRTP: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Prz (talk | contribs)
105 edits
Made link to ZRTP Internet Draft that will not need to be repeatedly updated with each new draft
Prz (talk | contribs)
105 edits
mNo edit summary
 
(235 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{short description|VoIP key-agreement protocol}}
'''ZRTP''' is an extension to [[Real-time Transport Protocol]] (RTP) which describes a method of [[Diffie-Hellman]] [[Key-agreement protocol|key agreement]] for Secure Real-time Transport Protocol ([[Secure Real-time Transport Protocol|SRTP]]). It was submitted to the [[IETF]] by [[Phil Zimmermann]], Jon Callas and Alan Johnston on March 5, 2006. [[Session Initiation Protocol]] (SIP) is a [[VoIP]] standard.
{{primary sources|date=December 2012}}
'''ZRTP''' (composed of Z and [[Real-time Transport Protocol]]) is a cryptographic [[key-agreement protocol]] to negotiate the [[Key (cryptography)|keys]] for [[encryption]] between two end points in a [[Voice over IP]] (VoIP) phone telephony call based on the [[Real-time Transport Protocol]]. It uses [[Diffie–Hellman key exchange]] and the [[Secure Real-time Transport Protocol]] (SRTP) for encryption. ZRTP was developed by [[Phil Zimmermann]], with help from [[Bryce Wilcox-O'Hearn]], Colin Plumb, [[Jon Callas]] and Alan Johnston and was submitted to the [[Internet Engineering Task Force]] (IETF) by Zimmermann, Callas and Johnston on March 5, 2006 and published on April 11, 2011 as {{IETF RFC|6189}}.


==Overview==
==Overview==
⚫
ZRTP ("Z" is a reference to its inventor, Zimmermann; "RTP" stands for Real-time Transport Protocol)<ref>[http://countingfromzero.wordpress.com/2011/04/12/zrtp-published-today-as-rfc-6189/ ''Alan B. Johnston's Blog: ZRTP Published Today as RFC 6189'']. Retrieved 2013-01-13</ref> is described in the [[Internet Draft]] as a ''"key agreement protocol which performs Diffie–Hellman key exchange during call setup in-band in the Real-time Transport Protocol (RTP) media stream which has been established using some other signaling protocol such as [[Session Initiation Protocol]] (SIP). This generates a shared secret which is then used to generate keys and salt for a Secure RTP (SRTP) session."'' One of ZRTP's features is that it does not rely on SIP signaling for the key management, or on any servers at all. It supports [[opportunistic encryption]] by auto-sensing if the other VoIP client supports ZRTP.


⚫
This protocol does not require prior shared secrets or rely on a [[Public key infrastructure]] (PKI) or on certification authorities, in fact ephemeral Diffie–Hellman keys are generated on each session establishment: this allows the complexity of creating and maintaining a trusted third-party to be bypassed.
⚫
ZRTP is described in the [[Internet-Draft]] as a ''"key agreement protocol which performs Diffie-Hellman key exchange during call setup in-band in the Real-time Transport Protocol (RTP) media stream which has been established using some other signaling protocol such as Session Initiation Protocol (SIP). This generates a shared secret which is then used to generate keys and salt for a Secure RTP (SRTP) session."'' One of ZRTP's features is that it does not rely on [[SIP]] signaling for the key management, or on any servers at all. It supports [[opportunistic encryption]] by auto-sensing if the other VoIP client supports ZRTP.


⚫
These keys contribute to the generation of the session secret, from which the session key and parameters for SRTP sessions are derived, along with previously shared secrets (if any): this gives protection against [[Man-in-the-middle attack|man-in-the-middle (MiTM) attacks]], so long as the attacker was not present in the first session between the two endpoints.
⚫
This protocol does not require prior shared secrets or rely on a [[Public key infrastructure]] (PKI) or on certification authorities, in fact ephemeral Diffie-Hellman keys are generated on each session establishment: this allows to bypass the complexity of creating and maintaining a trusted third-party.


⚫
ZRTP can be used with any signaling protocol, including SIP, [[H.323]], [[Jingle (protocol)|Jingle]], and [[distributed hash table]] systems. ZRTP is independent of the signaling layer, because all its key negotiations occur via the RTP media stream.
⚫
These keys will contribute to the generation of the session secret, from which the session key and parameters for SRTP sessions will come, along with previously shared secrets (if some): this gives protection against [[man in the middle attack|man in the middle (MitM) attacks]], assuming the attacker was not present in the first session between the two endpoints.


ZRTP/S, a ZRTP protocol extension, can run on any kind of legacy telephony networks including GSM, UMTS, ISDN, PSTN, [[Communications satellite|SATCOM]], [[UHF]]/[[VHF]] radio, because it is a narrow-band bitstream-oriented protocol and performs all key negotiations inside the bitstream between two endpoints.
To ensure that the attacker is indeed not present in the first session (when no shared secrets exist) , the [[Short Authentication String]] method is used: the two endpoint compare a value by reading it aloud.
In case the two values match, then no MitM attack has been performed.


Alan Johnston named the protocol ZRTP because in its earliest Internet drafts it was based on adding header extensions to RTP packets, which made ZRTP a variant of RTP. In later drafts the packet format changed to make it syntactically distinguishable from RTP. In view of that change, ZRTP is now a [[pseudo-acronym]].
⚫
ZRTP can be used with any signaling protocol, including [[Session_Initiation_Protocol|SIP]], [[H.323]], [[Jabber]], and [[Distributed_hash_table|Peer-to-Peer SIP]]. ZRTP is independent of the signaling layer, because it does all its key negotiations in the RTP media stream.


==Authentication==
==Authentication==
{{further|Password-authenticated key exchange}}
⚫
The [[Diffie-Hellman]] key exchange by itself does not provide protection against [[man in the middle attack|man in the middle (MitM) attacks]]. To authenticate the key exchange, ZRTP uses a ''Short Authentication String'' (SAS), which is essentially a [[Cryptographic_hash_function|cryptographic hash]] of the two Diffie-Hellman values. The SAS value is rendered to both ZRTP endpoints. To carry out authentication, this SAS value is read aloud to the communication partner over the voice connection. If the values on both ends do not match, it indicates the presence of a man-in-middle attack. If they do match, there is a high probability that no man-in-the-middle is present. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct SAS in his attack, which means the SAS can be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected.
The [[Diffie–Hellman key exchange]] by itself does not provide protection against a man-in-the-middle attack. To ensure that the attacker is indeed not present in the first session (when no shared secrets exist), the ''Short Authentication String'' (SAS) method is used: the communicating parties verbally cross-check a shared value displayed at both endpoints. If the values do not match, a man-in-the-middle attack is indicated. A specific attack theorized against the ZRTP protocol involves creating a synthetic voice of both parties to read a bogus SAS which is known as a "[[Rich Little]] attack", but this class of attack is not believed to be a serious risk to the protocol's security.<ref name=zrtp>{{cite web
|url=http://tools.ietf.org/html/draft-zimmermann-avt-zrtp
⚫
|title=Internet-Draft. ZRTP: Media Path Key Agreement for Unicast Secure RTP
|access-date=2010-06-17
|last=Zimmermann
|first=Phil
|date=2010-06-17
}}</ref>
⚫
The SAS is used to authenticate the key exchange, which is essentially a [[Cryptographic hash function|cryptographic hash]] of the two Diffie–Hellman values. The SAS value is rendered to both ZRTP endpoints. To carry out authentication, this SAS value is read aloud to the communication partner over the voice connection. If the values on both ends do not match, a man-in-middle attack is indicated; if they do match, a man-in-the-middle attack is highly unlikely. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct SAS in the attack, which means the SAS may be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected.


===Key continuity===
ZRTP provides a second layer of authentication against a MitM attack, based on a form of key continuity. It does this by caching some hashed key material to use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to [[SSH]]. If the MitM is not present in the first call, he is locked out of subsequent calls. Thus, even if the SAS is never used, most MitM attacks are stopped, because they weren't present in the first call.
ZRTP provides a second layer of authentication against a MitM attack, based on a form of key continuity. It does this by caching some hashed key information for use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to [[Secure Shell|SSH]]. If the MitM is not present in the first call, he is locked out of subsequent calls. Thus, even if the SAS is never used, most MitM attacks are stopped because the MitM was not present in the first call.
<!--Speculative news:
ZRTP provides yet a third layer of protection against a MitM attack. The IETF plans to add integrity protection to the delivery of [[Session Initiation Protocol]] (SIP) information,{{Citation needed|date=February 2010}} and that integrity protection will rely on a [[Public key infrastructure|PKI]]. When this eventually deploys, ZRTP can take advantage of this. See the ZRTP Internet Draft on how ZRTP can leverage an integrity-protected SIP layer to provide integrity protection for ZRTP's Diffie–Hellman exchange in the media layer. This protects against a MitM attack, without requiring the users to verbally compare the SAS. However, no VoIP clients yet offer a fully implemented SIP stack that provides end-to-end integrity protection for the delivery of SIP information. Thus, real-world implementations of ZRTP endpoints will continue to depend on SAS authentication for quite some time. Even after there is widespread availability of SIP products that offer integrity protection, many users will still be faced with the fact that the signaling path may be controlled by institutions that do not have the best interests of the end user in mind. In those cases, ZRTP's built-in SAS authentication will remain the gold standard for the prudent user.
-->


==Operating environment==
==Implementation==
* ZRTP protocol has been implemented and used on the following platforms: [[Windows]], [[Linux]], [[Android (operating system)|Android]]
ZRTP has been implemented into a program called [[Zfone]] which is available for different operating systems. Along with the source code and an [[SDK]], it is available on [http://www.philzimmermann.com/zfone/index.html Phil Zimmermann's website].
* ZRTP protocol has been implemented in the following languages: [[C (programming language)|C]], [[C++]], [[Java (programming language)|Java]]
* ZRTP protocol has been used successfully on the following transport media: [[WiFi]], [[UMTS]], [[EDGE]], [[GPRS]], [[Satellite modem|Satellite IP modem]], [[GSM CSD]], [[ISDN]]


==Implementations==
[[Ekiga]], [[Twinkle (software)|Twinkle]] and [[Asterisk (PBX)|Asterisk]] also implement ZRTP and are available under [[GNU General Public License|GPL]]. [[X-Lite]], [[eyeBeam (software)|eyeBeam]] and [http://www.m5t.com/products/zrtp.php M5T ZRTP SAFE] implement ZRTP but are proprietary.
ZRTP has been implemented as
* [[GNU ZRTP]] which is used in [[Twinkle (software)|Twinkle]]<ref>{{cite web |url=http://twinklephone.com/ |title=Twinkle - SIP softphone for Linux |newspaper=Twinklephone.com |date=25 February 2009 |access-date= 4 March 2016}}</ref>
* GNU ZRTP4J which is used in [[Jitsi]] (formerly SIP Communicator).<ref>{{cite web |url=https://jitsi.org/Documentation/ZrtpFAQ |title=Zrtp FAQ |newspaper=jitsi.org |access-date= 4 March 2016}}</ref>
* ortp for use in [[Linphone]].<ref>{{cite web |url=http://www.linphone.org/eng/documentation/dev/ortp.html |title=oRTP, a Real-time Transport Protocol (RTP, RFC3550) library &#124; Linphone, an open-source video sip phone |publisher=Linphone.org |access-date=2014-06-07 |archive-date=2013-12-09 |archive-url=https://web.archive.org/web/20131209204938/http://www.linphone.org/eng/documentation/dev/ortp.html |url-status=dead }}</ref>
* libzrtp which can be used in [[FreeSWITCH]].<ref>{{cite web|url=https://wiki.freeswitch.org/wiki/ZRTP |title=ZRTP - FreeSWITCH Wiki |publisher=FreeSWITCH Wiki |date=2009-05-21 |access-date=2016-01-20}}</ref><ref>{{cite web |url=https://freeswitch.org/freeswitch-now-supports-zrtp/ |title=FreeSWITCH Now Supports ZRTP! |newspaper=FreeSWITCH|date=21 May 2009 |access-date= 4 March 2016}}</ref>
* [[Signal (messaging app)|Signal]] and its predecessor, [[RedPhone]], used ZRTP for encrypted calls on Android and iOS.<ref>{{cite web| url=https://www.wired.com/2014/07/free-encrypted-calling-finally-comes-to-the-iphone/ |title=Your iPhone Can Finally Make Free, Encrypted Calls |publisher= Wired |author= Andy Greenberg |date=2014-07-29 |access-date= 2015-01-18}}</ref> As of March 2017, Signal's voice and video calling functionality uses the app's [[Signal Protocol]] channel for authentication instead of ZRTP.<ref name="signal-video-calls-beta">{{cite web|last1=Marlinspike|first1=Moxie|title=Video calls for Signal now in public beta|url=https://whispersystems.org/blog/signal-video-calls-beta/|publisher=Open Whisper Systems|access-date=15 February 2017|date=14 February 2017}}</ref><ref name="Mott-2017-03-14">{{cite web|last1=Mott|first1=Nathaniel|title=Signal's Encrypted Video Calling For iOS, Android Leaves Beta|url=http://www.tomshardware.com/news/signal-encrypted-video-calling-ios-android,33898.html|website=Tom's Hardware|publisher=Purch Group, Inc.|date=14 March 2017|access-date=14 March 2017}}</ref>
* CSipSimple is a free application for Android OS which fully supports ZRTP<ref name=guardianproject>{{cite web |url=https://guardianproject.info/2012/02/22/free-sip-providers-with-zrtp-support/ |title=Free SIP Providers with ZRTP support |publisher=The Guardian Project|date=22 February 2012 |access-date= 4 March 2016}}</ref>
* [[PhonerLite]] softphone for Windows supports ZRTP<ref>{{cite web |url=http://phonerlite.de/index_en.htm |title=PhonerLite |newspaper=Phonerlite.de |access-date= 4 March 2016}}</ref>


Commercial implementations of ZRTP are available in RokaCom from RokaCom,<ref>{{cite web|url=https://www.rokacom.com |title=RokaCom | publisher=RokaCom |date=2014-11-29}}</ref> and PrivateWave Professional from PrivateWave<ref>{{cite web|url=http://www.privatewave.com |title=PrivateWave |publisher=PrivateWave |date=1999-02-22 |access-date=2014-06-07}}</ref> and more recently in Silent Phone from Silent Circle, a company founded by Zimmermann.<ref>{{cite web|author=Join us for a Live Webinar |url=http://silentcircle.com |title=Silent Circle |publisher=Silent Circle |access-date=2014-06-07}}</ref> There is also Softphone from Acrobits.<ref>{{cite web|url=http://www.acrobits.cz/products/retail#tab_softphone |title=Softphone | publisher=Acrobits |access-date=2015-01-21}}</ref> [[Draytek]] support ZRTP in some of their VoIP hardware and software.<ref>{{cite web|url=http://www.ipbusinessphones.co.uk/draytek-ippbx-v2820n-detailed-specification/ |title=Specification of Draytek 2820Vn ADSL modem/router/switch |publisher=Ipbusinessphones.co.uk |date=2013-08-13 |access-date=2014-06-07}}</ref><ref>{{cite web|url=http://www.draytek.co.uk/products/business/softphone |title=Draytek Softphone (software) description |publisher=Draytek.co.uk |access-date=2014-06-07}}</ref>
== See also ==
* [[Opportunistic encryption]]
* [[Zfone]]
* [[PGPfone]]
* [[Pretty Good Privacy]]


A list of free SIP Providers with ZRTP support has been published.<ref name=guardianproject/>
⚫
== External links and references ==
*[http://zfoneproject.com/ Zfone home page]
*[http://www.philzimmermann.com Phil Zimmermann official website]
⚫
*[http://zfoneproject.com/zrtp_ietf.html Internet Draft: ZRTP: Media Path Key Agreement for Secure RTP]
*[http://www.m5t.com/products/zrtp.php M5T ZRTP SAFE Page]


==References==
⚫
[[Category:Cryptographic protocols]]
<references responsive />


⚫
==External links==
[[de:ZRTP]]
* [http://tools.ietf.org/html/rfc6189 RFC 6189] — ZRTP: Media Path Key Agreement for Unicast Secure RTP
[[es:ZRTP]]

{{Cryptographic software}}

{{DEFAULTSORT:Zrtp}}
⚫
[[Category:Cryptographic protocols]]

Latest revision as of 22:39, 20 October 2024

ZRTP (composed of Z and Real-time Transport Protocol) is a cryptographic key-agreement protocol to negotiate the keys for encryption between two end points in a Voice over IP (VoIP) phone telephony call based on the Real-time Transport Protocol. It uses Diffie–Hellman key exchange and the Secure Real-time Transport Protocol (SRTP) for encryption. ZRTP was developed by Phil Zimmermann, with help from Bryce Wilcox-O'Hearn, Colin Plumb, Jon Callas and Alan Johnston and was submitted to the Internet Engineering Task Force (IETF) by Zimmermann, Callas and Johnston on March 5, 2006 and published on April 11, 2011 as RFC 6189.

Overview

[edit]

ZRTP ("Z" is a reference to its inventor, Zimmermann; "RTP" stands for Real-time Transport Protocol)[1] is described in the Internet Draft as a "key agreement protocol which performs Diffie–Hellman key exchange during call setup in-band in the Real-time Transport Protocol (RTP) media stream which has been established using some other signaling protocol such as Session Initiation Protocol (SIP). This generates a shared secret which is then used to generate keys and salt for a Secure RTP (SRTP) session." One of ZRTP's features is that it does not rely on SIP signaling for the key management, or on any servers at all. It supports opportunistic encryption by auto-sensing if the other VoIP client supports ZRTP.

This protocol does not require prior shared secrets or rely on a Public key infrastructure (PKI) or on certification authorities, in fact ephemeral Diffie–Hellman keys are generated on each session establishment: this allows the complexity of creating and maintaining a trusted third-party to be bypassed.

These keys contribute to the generation of the session secret, from which the session key and parameters for SRTP sessions are derived, along with previously shared secrets (if any): this gives protection against man-in-the-middle (MiTM) attacks, so long as the attacker was not present in the first session between the two endpoints.

ZRTP can be used with any signaling protocol, including SIP, H.323, Jingle, and distributed hash table systems. ZRTP is independent of the signaling layer, because all its key negotiations occur via the RTP media stream.

ZRTP/S, a ZRTP protocol extension, can run on any kind of legacy telephony networks including GSM, UMTS, ISDN, PSTN, SATCOM, UHF/VHF radio, because it is a narrow-band bitstream-oriented protocol and performs all key negotiations inside the bitstream between two endpoints.

Alan Johnston named the protocol ZRTP because in its earliest Internet drafts it was based on adding header extensions to RTP packets, which made ZRTP a variant of RTP. In later drafts the packet format changed to make it syntactically distinguishable from RTP. In view of that change, ZRTP is now a pseudo-acronym.

Authentication

[edit]
Further information: Password-authenticated key exchange

The Diffie–Hellman key exchange by itself does not provide protection against a man-in-the-middle attack. To ensure that the attacker is indeed not present in the first session (when no shared secrets exist), the Short Authentication String (SAS) method is used: the communicating parties verbally cross-check a shared value displayed at both endpoints. If the values do not match, a man-in-the-middle attack is indicated. A specific attack theorized against the ZRTP protocol involves creating a synthetic voice of both parties to read a bogus SAS which is known as a "Rich Little attack", but this class of attack is not believed to be a serious risk to the protocol's security.[2] The SAS is used to authenticate the key exchange, which is essentially a cryptographic hash of the two Diffie–Hellman values. The SAS value is rendered to both ZRTP endpoints. To carry out authentication, this SAS value is read aloud to the communication partner over the voice connection. If the values on both ends do not match, a man-in-middle attack is indicated; if they do match, a man-in-the-middle attack is highly unlikely. The use of hash commitment in the DH exchange constrains the attacker to only one guess to generate the correct SAS in the attack, which means the SAS may be quite short. A 16-bit SAS, for example, provides the attacker only one chance out of 65536 of not being detected.

Key continuity

[edit]

ZRTP provides a second layer of authentication against a MitM attack, based on a form of key continuity. It does this by caching some hashed key information for use in the next call, to be mixed in with the next call's DH shared secret, giving it key continuity properties analogous to SSH. If the MitM is not present in the first call, he is locked out of subsequent calls. Thus, even if the SAS is never used, most MitM attacks are stopped because the MitM was not present in the first call.

Operating environment

[edit]

Implementations

[edit]

ZRTP has been implemented as

Commercial implementations of ZRTP are available in RokaCom from RokaCom,[13] and PrivateWave Professional from PrivateWave[14] and more recently in Silent Phone from Silent Circle, a company founded by Zimmermann.[15] There is also Softphone from Acrobits.[16] Draytek support ZRTP in some of their VoIP hardware and software.[17][18]

A list of free SIP Providers with ZRTP support has been published.[11]

References

[edit]
  1. ^ Alan B. Johnston's Blog: ZRTP Published Today as RFC 6189. Retrieved 2013-01-13
  2. ^ Zimmermann, Phil (2010-06-17). "Internet-Draft. ZRTP: Media Path Key Agreement for Unicast Secure RTP". Retrieved 2010-06-17.
  3. ^ "Twinkle - SIP softphone for Linux". Twinklephone.com. 25 February 2009. Retrieved 4 March 2016.
  4. ^ "Zrtp FAQ". jitsi.org. Retrieved 4 March 2016.
  5. ^ "oRTP, a Real-time Transport Protocol (RTP, RFC3550) library | Linphone, an open-source video sip phone". Linphone.org. Archived from the original on 2013-12-09. Retrieved 2014-06-07.
  6. ^ "ZRTP - FreeSWITCH Wiki". FreeSWITCH Wiki. 2009-05-21. Retrieved 2016-01-20.
  7. ^ "FreeSWITCH Now Supports ZRTP!". FreeSWITCH. 21 May 2009. Retrieved 4 March 2016.
  8. ^ Andy Greenberg (2014-07-29). "Your iPhone Can Finally Make Free, Encrypted Calls". Wired. Retrieved 2015-01-18.
  9. ^ Marlinspike, Moxie (14 February 2017). "Video calls for Signal now in public beta". Open Whisper Systems. Retrieved 15 February 2017.
  10. ^ Mott, Nathaniel (14 March 2017). "Signal's Encrypted Video Calling For iOS, Android Leaves Beta". Tom's Hardware. Purch Group, Inc. Retrieved 14 March 2017.
  11. ^ a b "Free SIP Providers with ZRTP support". The Guardian Project. 22 February 2012. Retrieved 4 March 2016.
  12. ^ "PhonerLite". Phonerlite.de. Retrieved 4 March 2016.
  13. ^ "RokaCom". RokaCom. 2014-11-29.
  14. ^ "PrivateWave". PrivateWave. 1999-02-22. Retrieved 2014-06-07.
  15. ^ Join us for a Live Webinar. "Silent Circle". Silent Circle. Retrieved 2014-06-07.
  16. ^ "Softphone". Acrobits. Retrieved 2015-01-21.
  17. ^ "Specification of Draytek 2820Vn ADSL modem/router/switch". Ipbusinessphones.co.uk. 2013-08-13. Retrieved 2014-06-07.
  18. ^ "Draytek Softphone (software) description". Draytek.co.uk. Retrieved 2014-06-07.
[edit]
  • RFC 6189 — ZRTP: Media Path Key Agreement for Unicast Secure RTP
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=ZRTP&oldid=1252342559"