“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.”
„Schlüsselaustauschprotokoll, welches während des Rufaufbaues einen Diffie-Hellman-Schlüsselaustausch innerhalb eines Real-time-Transport-Protocol-Datenstroms (RTP) ausführt, welcher mittels eines anderen Signalisierungs-Protokolles wie dem Session Initiation Protocol (SIP) aufgebaut wurde. Dieser erzeugt ein gemeinsames Geheimnis, welches dann zur Erzeugung von Schlüsseln und Salt für eine Secure-RTP-Sitzung (SRTP) verwendet wird.“
Eines der Merkmale von ZRTP ist, dass es sich für die Schlüsselverwaltung nicht auf SIP-Signalisierung oder irgendwelche Server stützt. Es unterstützt opportunistische Verschlüsselung durch automatische Erkennung von ZRTP-Unterstützung auf der Gegenseite.
Das Protokoll setzt keine gemeinsamen Geheimnisse oder Public-Key-Infrastruktur (PKI) oder Zertifizierungsstellen voraus, tatsächlich werden bei der Etablierung jeder Sitzung vergängliche Diffie-Hellman-Schlüssel erstellt: Dies ermöglicht den Verzicht auf die Umständlichkeit der Einrichtung und Unterhaltung einer vertrauenswürdigen Drittpartei.
Diese Schlüssel dienen der Erzeugung des Sitzungsgeheimnisses, von dem der Sitzungsschlüssel und Parameter für die SRTP-Sitzung abgeleitet werden, zusammen mit eventuell vorhandenen vorherigen gemeinsamen Geheimnissen: Dies bietet Schutz gegen Mittelsmannangriffe, solange der Angreifer nicht in der ersten Sitzung zwischen den beiden Endstellen anwesend war.
ZRTP kann mit jeglichen Signalisierungsprotokollen eingesetzt werden, einschließlich SIP, H.323, Jingle und Verteilte-Hashtabellen-Systeme. ZRTP ist unabhängig von der Signalisierungsschicht, da jegliche Schlüsselaushandlung über den RTP-Datenstrom geschieht.
ZRTP/S, eine ZRTP-Protokollerweiterung, kann auf jeglicher Art von bestehenden Telefonnetzwerken betrieben werden, einschließlich GSM, UMTS, ISDN, PSTN, SATCOM, UHF/VHF-Funk, weil es ein schmalbandiges Bitstrom-orientiertes Protokoll ist und vollzieht jegliche Schlüsselaushandlung innerhalb des Datenstroms zwischen zwei Endstellen.
Alan Johnston nannte das Protokoll „ZRTP“, weil es in seinen frühesten Internet-Drafts[3] auf zu RTP-Paketen hinzugefügten Kopfdaten-Erweiterungen basierte, welche ZRTP zu einer Variante von RTP machten. In späteren Entwürfen wurde das Paketformat geändert, um es syntaktisch von RTP unterscheidbar zu machen. Angesichts dieser Änderung ist ZRTP nunmehr ein Pseudoakronym.
Authentifizierung
Nonce
Der Diffie-Hellman-Schlüsselaustausch selbst bietet keinen Schutz gegen Mittelsmannangriffe. Um (ohne bestehendes gemeinsames Geheimnis) sicherzustellen, dass der Angreifer tatsächlich nicht in der ersten Sitzung anwesend ist, wird eine „Short Authentication String“ (SAS) genannte Nonce genutzt: Die kommunizierenden Parteien überprüfen verbal einen auf beiden Endgeräten angezeigten Wert auf Übereinstimmung. Wenn der Wert nicht übereinstimmt, deutet dies auf einen Mittelsmannangriff. (Ende 2006 entwickelte die US-amerikanische NSA ein experimentelles Stimmenanalyse und -synthese-System zur Überwindung dieser Schutzmaßnahme,[4] jedoch wurde von dieser Art Angriffe keine ernsthafte Gefahr für die Protokollsicherheit angenommen. Dies könnte sich durch die NSA-Affäre geändert haben.[3])
Der SAS wird zur Authentifizierung des Schlüsselaustausches genutzt, welcher im Grunde eine kryptologische Prüfsumme der zwei Diffie-Hellman-Werte ist. Der SAS-Wert wird auf beiden ZRTP-Endstellen angezeigt. Um eine Authentifizierung durchzuführen, wird dieser Wert dem Kommunikationspartner über die Sprachverbindung laut vorgelesen. Falls die Werte auf beiden Seiten nicht übereinstimmen, deutet dies auf einen Mittelsmannangriff; falls sie übereinstimmen, ist ein Mittelsmannangriff sehr unwahrscheinlich. Der Einsatz von Hash Commitment im DH-Austausch beschränkt den Angreifer beim Angriff auf nur einen Versuch beim Erzeugen des korrekten SAS, wodurch der SAS recht kurz sein kann. Beispielsweise lässt ein 16-Bit-SAS einem Angreifer nur eine von 65.536 Möglichkeiten, um nicht entdeckt zu werden.
Schlüsselkontinuität
ZRTP bietet eine zweite Authentifizierungsschicht gegen einen Mittelsmannangriff, basierend auf einer Form von Schlüsselkontinuität. Es gewährleistet dies durch das Zwischenspeichern einiger gehashter Informationen aus dem letzten Schlüssel für die Nutzung im nächsten Anruf, um beim nächsten Anruf in das gemeinsame Geheimnis für den DH-Austausch einzufließen, was ihm Schlüsselkontinuitätseigenschaften verleiht, analog zu SSH. Wenn der Mittelsmann nicht bereits in der ersten Sitzung anwesend ist, so ist er von folgenden Sitzungen ausgeschlossen. Daher werden die meisten Mittelsmannangriffe auch dann aufgehalten, wenn der SAS nie genutzt wird, da der Mittelsmann in der ersten Sitzung nicht zugegen war.
Geschichte
Das Verfahren entspringt der von Phil Zimmermann entwickelten VoIP-Software Zfone, für die es als zentraler Teil des Sicherheitskonzeptes entwickelt wurde. Zfone wurde im März 2006 erstmals der Öffentlichkeit vorgestellt. Am 5. März 2006 wurde von Phil Zimmermann, Jon Callas und Alan Johnston eine Protokollspezifikation an die Internet Engineering Task Force (IETF) übermittelt.[3] Zu der Zeit wurden auch wesentliche Teile des Verfahrens zum Patent angemeldet, das bei wunschgemäßer Implementierung automatisch kostenlos lizenziert wird.[5][6] Die IETF veröffentlichte die Protokollspezifikation am 11. April 2011 als RFC 6189.[1]
ZRTP wurde in GNU ZRTP implementiert,[7] welches in Twinkle und SFLphone eingesetzt wird, und in GNU ZRTP4J,[8] welches in Jitsi (früher „SIP Communicator“) eingesetzt wird. Es wurde für die Nutzung in Linphone[9] auch in ortp[10] implementiert. Kommerzielle Implementierungen von ZRTP liegen vor in PrivateGSM von PrivateWave[11] und neuerdings in Silent Phone von Silent Circle, einem von Phil Zimmermann gegründeten Unternehmen.[12] Ebenso unterstützen FreeSWITCH und PhonerLite das Protokoll.
ZORG zrtp.org – quelloffene Implementierung in C++ und Java optimiert für Mobiltelefone unter GNU Affero General Public License integriert im Telefonie-Framework PJSIP und MJSIP
RFC: 6189 – ZRTP: Media Path Key Agreement for Unicast Secure RTP. 11. April 2011 (englisch).
Open ZRTP – quelloffene Implementierung in C++ unter GNU Lesser General Public License integriert im PJSIP-Framework, betreut von iCall
Einzelnachweise
↑ abRFC: 6189 – ZRTP: Media Path Key Agreement for Unicast Secure RTP. 11. April 2011 (englisch).
