DOCSLIB.ORG

ZRTP: Media Path Key Agreement for Unicast Secure RTP

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ZRTP: Media Path Key Agreement for Unicast Secure RTP Internet Engineering Task Force (IETF) P. Zimmermann RFC Request for Comments: 6189bis Zfone Project 6189bis Category: Informational A. Johnston, Ed. TOC ISSN: 2070-1721 Avaya J. Callas Apple, Inc. November 2012 ZRTP: Media Path Key Agreement for Unicast Secure RTP Abstract This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio- Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6189bis. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. RFC Table of Contents 6189bis TOC 1. Introduction 2. Terminology 3. Overview 3.1. Key Agreement Modes 3.1.1. Diffie-Hellman Mode Overview 3.1.2. Preshared Mode Overview 3.1.3. Multistream Mode Overview 4. Protocol Description 4.1. Discovery 4.1.1. Protocol Version Negotiation 4.1.2. Algorithm Negotiation 4.2. Commit Contention 4.3. Matching Shared Secret Determination 4.3.1. Calculation and Comparison of Hashes of Shared Secrets 4.3.2. Handling a Shared Secret Cache Mismatch 4.4. DH and Non-DH Key Agreements 4.4.1. Diffie-Hellman Mode 4.4.1.1. Hash Commitment in Diffie-Hellman Mode 4.4.1.2. Responder Behavior in Diffie-Hellman Mode 4.4.1.3. Initiator Behavior in Diffie-Hellman Mode 4.4.1.4. Shared Secret Calculation for DH Mode 4.4.2. Preshared Mode 4.4.2.1. Commitment in Preshared Mode 4.4.2.2. Initiator Behavior in Preshared Mode 4.4.2.3. Responder Behavior in Preshared Mode 4.4.2.4. Shared Secret Calculation for Preshared Mode 4.4.3. Multistream Mode 4.4.3.1. Commitment in Multistream Mode 4.4.3.2. Shared Secret Calculation for Multistream Mode 4.5. Key Derivations 4.5.1. The ZRTP Key Derivation Function 4.5.2. Deriving ZRTPSess Key and SAS in DH or Preshared Modes 4.5.3. Deriving the Rest of the Keys from s0 4.6. Confirmation 4.6.1. Updating the Cache of Shared Secrets 4.6.1.1. Cache Update Following a Cache Mismatch 4.6.1.2. Cache Update for a PBX Following a Cache Mismatch 4.7. Termination 4.7.1. Termination via Error Message 4.7.2. Termination via GoClear Message 4.7.2.1. Key Destruction for GoClear Message 4.7.3. Key Destruction at Termination 4.8. Random Number Generation 4.9. ZID and Cache Operation 4.9.1. Cacheless Implementations 5. ZRTP Messages 5.1. ZRTP Message Formats 5.1.1. Message Type Block 5.1.2. Hash Type Block 5.1.2.1. Negotiated Hash and MAC Algorithm 5.1.2.2. Implicit Hash and MAC Algorithm 5.1.3. Cipher Type Block 5.1.4. Auth Tag Type Block 5.1.5. Key Agreement Type Block 5.1.6. SAS Type Block 5.1.7. Signature Type Block 5.2. Hello Message 5.3. HelloACK Message 5.4. Commit Message 5.5. DHPart1 Message 5.6. DHPart2 Message 5.7. Confirm1 and Confirm2 Messages 5.8. Conf2ACK Message 5.9. Error Message 5.10. ErrorACK Message 5.11. GoClear Message 5.12. ClearACK Message 5.13. SASrelay Message 5.14. RelayACK Message 5.15. Ping Message 5.15.1. Rationale for Ping messages 5.16. PingACK Message 6. Retransmissions 7. Short Authentication String 7.1. SAS Verified Flag 7.2. Signing the SAS 7.2.1. OpenPGP Signatures 7.2.2. ECDSA Signatures with X.509v3 Certs 7.2.3. Signing the SAS without a PKI 7.3. Relaying the SAS through a PBX 7.3.1. PBX Enrollment and the PBX Enrollment Flag 7.4. Automated Methods of Authenticating the DH Exchange 8. Signaling Interactions 8.1. Binding the Media Stream to the Signaling Layer via the Hello Hash 8.1.1. Integrity-Protected Signaling Enables Integrity-Protected DH Exchange 8.2. Combining ZRTP With SDES 8.2.1. Deriving auxsecret from SDES Key Material 8.3. Codec Selection for Secure Media 9. False ZRTP Packet Rejection 10. Intermediary ZRTP Devices 10.1. On Reducing PBX MiTM Behavior 11. The ZRTP Disclosure Flag 11.1. Guidelines on Proper Implementation of the Disclosure Flag 12. Mapping between ZID and AOR (SIP URI) 13. IANA Considerations 14. Media Security Requirements 15. Security Considerations 15.1. Self-Healing Key Continuity Feature 16. Acknowledgments 17. References 17.1. Normative References 17.2. Informative References TOC 1. Introduction ZRTP is a key agreement protocol that performs a Diffie-Hellman key exchange during call setup in the media path and is transported over the same port as the Real-time Transport Protocol (RTP) [RFC3550] media stream which has been established using a signaling protocol such as Session Initiation Protocol (SIP) [RFC3261]. This generates a shared secret, which is then used to generate keys and salt for a Secure RTP (SRTP) [RFC3711] session. ZRTP borrows ideas from [PGPfone]. A reference implementation of ZRTP is available in [Zfone]. The ZRTP protocol has some nice cryptographic features lacking in many other approaches to media session encryption. Although it uses a public key algorithm, it does not rely on a public key infrastructure (PKI). In fact, it does not use persistent public keys at all. It uses ephemeral Diffie-Hellman (DH) with hash commitment and allows the detection of man-in- the-middle (MiTM) attacks by displaying a short authentication string (SAS) for the users to read and verbally compare over the phone. It has Perfect Forward Secrecy, meaning the keys are destroyed at the end of the call, which precludes retroactively compromising the call by future disclosures of key material. But even if the users are too lazy to bother with short authentication strings, we still get reasonable authentication against a MiTM attack, based on a form of key continuity. It does this by caching some 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 Secure SHell (SSH). All this is done without reliance on a PKI, key certification, trust models, certificate authorities, or key management complexity that bedevils the email encryption world. It also does not rely on SIP signaling for the key management, and in fact, it does not rely on any servers at all. It performs its key agreements and key management in a purely peer-to-peer manner over the RTP packet stream. ZRTP can be used and discovered without being declared or indicated in the signaling path. This provides a best effort SRTP capability. Also, this reduces the complexity of implementations and minimizes interdependency between the signaling and media layers. However, when ZRTP is indicated in the signaling via the zrtp-hash SDP attribute, ZRTP has additional useful properties. By sending a hash of the ZRTP Hello message in the signaling, ZRTP provides a useful binding between the signaling and media paths, which is explained in Section 8.1. When this is done through a signaling path that has end-to-end integrity protection, the DH exchange is automatically protected from a MiTM attack, which is explained in Section 8.1.1. ZRTP is designed for unicast media sessions in which there is a voice media stream. For multiparty secure conferencing, separate ZRTP sessions may be negotiated between each party and the conference bridge. For sessions lacking a voice media stream, MiTM protection may be provided by the mechanisms in Sections 8.1.1 or 7.2. In terms of the RTP topologies defined in [RFC5117], ZRTP is designed for Point-to-Point topologies only. TOC 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Load more

Recommended publications
  • Zfone: a New Approach for Securing Voip Communication
    Zfone: A New Approach for Securing VoIP Communication Samuel Sotillo [email protected] ICTN 4040 Spring 2006 Abstract This paper reviews some security challenges currently faced by VoIP systems as well as their potential solutions. Particularly, it focuses on Zfone, a vendor-neutral security solution developed by PGP’s creator, Phil Zimmermann. Zfone is based on the Z Real-time Transport Protocol (ZRTP), which is an extension of the Real-time Transport Protocol (RTP). ZRTP offers a very simple and robust approach to providing protection against the most common type of VoIP threats. Basically, the protocol offers a mechanism to guarantee high entropy in a Diffie- Hellman key exchange by using a session key that is computed through the hashing several secrets, including a short authentication string that is read aloud by callers. The common shared secret is calculated and used only for one session at a time. However, the protocol allows for a part of the shared secret to be cached for future sessions. The mechanism provides for protection for man-in-the-middle, call hijack, spoofing, and other common types of attacks. Also, this paper explores the fact that VoIP security is a very complicated issue and that the technology is far from being inherently insecure as many people usually claim. Introduction Voice over IP (VoIP) is transforming the telecommunication industry. It offers multiple opportunities such as lower call fees, convergence of voice and data networks, simplification of deployment, and greater integration with multiple applications that offer enhanced multimedia functionality [1]. However, notwithstanding all these technological and economic opportunities, VoIP also brings up new challenges.
    [Show full text]
  • Pgpfone Pretty Good Privacy Phone Owner’S Manual Version 1.0 Beta 7 -- 8 July 1996
    Phil’s Pretty Good Software Presents... PGPfone Pretty Good Privacy Phone Owner’s Manual Version 1.0 beta 7 -- 8 July 1996 Philip R. Zimmermann PGPfone Owner’s Manual PGPfone Owner’s Manual is written by Philip R. Zimmermann, and is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Pretty Good Privacy™, PGP®, Pretty Good Privacy Phone™, and PGPfone™ are all trademarks of Pretty Good Privacy Inc. Export of this software may be restricted by the U.S. government. PGPfone software is (c) Copyright 1995-1996 Pretty Good Privacy Inc. All rights reserved. Phil’s Pretty Good engineering team: PGPfone for the Apple Macintosh and Windows written mainly by Will Price. Phil Zimmermann: Overall application design, cryptographic and key management protocols, call setup negotiation, and, of course, the manual. Will Price: Overall application design. He persuaded the rest of the team to abandon the original DOS command-line approach and designed a multithreaded event-driven GUI architecture. Also greatly improved call setup protocols. Chris Hall: Did early work on call setup protocols and cryptographic and key management protocols, and did the first port to Windows. Colin Plumb: Cryptographic and key management protocols, call setup negotiation, and the fast multiprecision integer math package. Jeff Sorensen: Speech compression. Will Kinney: Optimization of GSM speech compression code. Kelly MacInnis: Early debugging of the Win95 version. Patrick Juola: Computational linguistic research for biometric word list. -2- PGPfone Owner’s
    [Show full text]
  • PGP® Desktop for Windows User's Guide
    October 2003 PGP® Desktop for Windows User’s Guide Version Information PGP Desktop for Windows User’s Guide, version 8.0.3. Released October, 2003. Copyright Information Copyright © 1991–2003 by PGP Corporation. All Rights Reserved. No part of this document can be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, with- out the express written permission of PGP Corporation. Trademark Information PGP and Pretty Good Privacy are registered trademarks, and the PGP logo is a trademark, of PGP Corpo- ration in the U.S. and other countries. IDEA is a trademark of Ascom Tech AG. All other registered and unregistered trademarks in this document are the sole property of their respective owners. Licensing and Patent Information The IDEA cryptographic cipher described in U.S. patent number 5,214,703 is licensed from Ascom Tech AG. The CAST encryption algorithm is licensed from Northern Telecom, Ltd. PGP Corporation may have patents and/or pending patent applications covering subject matter in this software or its documenta- tion; the furnishing of this software or documentation does not give you any license to these patents. Acknowledgments The compression code in PGP Desktop is by Mark Adler and Jean-Loup Gailly, used with permission from the free Info-ZIP implementation. Export Information Export of this software and documentation may be subject to compliance with the rules and regulations promulgated from time to time by the Bureau of Export Administration, United States Department of Commerce, which restrict the export and re-export of certain products and technical data.
    [Show full text]
  • Introducing a Verified Authenticated Key Exchange Protocol Over Voice
    Introducing a Verified Authenticated Key Exchange Protocol over Voice Channels for Secure Voice Communication Piotr Krasnowski1;2, Jerome Lebrun1 and Bruno Martin1 1Univ. Coteˆ d’Azur, I3S-CNRS, Sophia Antipolis, France 2BlackBoxSecu,´ Sophia Antipolis, France fkrasnowski, lebrun, [email protected] Keywords: Authenticated Key Exchange, Secure Voice Communications, Data over Voice, Vocal Verification, Crypto Phone, Tamarin Prover, Formal Protocol Verification. Abstract: Increasing need for secure voice communication is leading to new ideas for securing voice transmission. This work relates to a relatively new concept of sending encrypted speech as pseudo-speech in audio domain over existing civilian voice communication infrastructure, like 2G-4G networks and VoIP. Such a setting is more universal compared to military “Crypto Phones” and can be opened for public evaluation. Nevertheless, secure communication requires a prior exchange of cryptographic keys over voice channels, without reliance on any Public Key Infrastructure (PKI). This work presents the first formally verified and authenticated key exchange (AKE) over voice channels for secure military-grade voice communications. It describes the operational principles of the novel com- munication system and enlists its security requirements. The voice channel characteristics in the context of AKE protocol execution is thoroughly explained, with a strong emphasis on differences to classical store- and-forward data channels. Namely a robust protocol has been designed specifically for voice channels with double authentication based on signatures and Short Authentication Strings (SAS). The protocol is detailed and analyzed in terms of fundamental security properties and successfuly verified in a symbolic model using Tamarin Prover. 1 INTRODUCTION An increasing concern of privacy violation in voice communications has motivated the development of secure voice over IP (VoIP) communicators, with Telegram and Signal being the iconic examples12.
    [Show full text]
  • PGP Desktop Security for Windows 95, Windows 98, and Windows NT
    PGP Desktop Security for Windows 95, Windows 98, and Windows NT User’s Guide Version 6.5 Int. Copyright © 1990-1999 Network Associates, Inc. and its Affiliated Companies. All Rights Reserved. PGP*, Version 6.5.1 Int. 9-9-99. Printed in the EC. PGP, Pretty Good, and Pretty Good Privacy are registered trademarks of Network Associates, Inc. and/or its Affiliated Companies in the US and other countries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. Portions of this software may use public key algorithms described in U.S. Patent numbers 4,200,770, 4,218,582, 4,405,829, and 4,424,414, licensed exclusively by Public Key Partners; the IDEA(tm) cryptographic cipher described in U.S. patent number 5,214,703, licensed from Ascom Tech AG; and the Northern Telecom Ltd., CAST Encryption Algorithm, licensed from Northern Telecom, Ltd. IDEA is a trademark of Ascom Tech AG. Network Associates Inc. may have patents and/or pending patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents. The compression code in PGP is by Mark Adler and Jean-Loup Gailly, used with permission from the free Info-ZIP implementation. LDAP software provided courtesy University of Michigan at Ann Arbor, Copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/).
    [Show full text]
  • PGP 7.0 Mac Users Guide
    PGP Freeware for MacOS User’s Guide Version 7.0 Copyright©1990-2001NetworkAssociates,Inc.anditsAffiliatedCompanies.AllRights Reserved. PGP*,Version7.0.3 01-2001.PrintedintheUnitedStatesofAmerica. PGP,PrettyGood,andPrettyGoodPrivacyareregisteredtrademarksofNetworkAssociates, Inc.and/oritsAffiliatedCompaniesintheUSandothercountries.Allotherregisteredand unregisteredtrademarksinthisdocumentarethesolepropertyoftheirrespectiveowners. PortionsofthissoftwaremayusepublickeyalgorithmsdescribedinU.S.Patentnumbers 4,200,770,4,218,582,4,405,829,and4,424,414,licensedexclusivelybyPublicKeyPartners;the IDEA(tm)cryptographiccipherdescribedinU.S.patentnumber5,214,703,licensedfrom AscomTechAG;andtheNorthernTelecomLtd.,CASTEncryptionAlgorithm,licensedfrom NorthernTelecom,Ltd.IDEAisatrademarkofAscomTechAG.NetworkAssociatesInc.may havepatentsand/orpendingpatentapplicationscoveringsubjectmatterinthissoftwareor itsdocumentation;thefurnishingofthissoftwareordocumentationdoesnotgiveyouany licensetothesepatents.ThecompressioncodeinPGPisbyMarkAdlerandJean-LoupGailly, usedwithpermissionfromthefreeInfo-ZIPimplementation.LDAPsoftwareprovided courtesyUniversityofMichiganatAnnArbor,Copyright©1992-1996Regentsofthe UniversityofMichigan.Allrightsreserved.Thisproductincludessoftwaredevelopedbythe ApacheGroupforuseintheApacheHTTPserverproject(http://www.apache.org/).Balloon helpsupportcourtesyofJamesW.Walker.Copyright©1995-1999TheApacheGroup.All rightsreserved.SeetextfilesincludedwiththesoftwareorthePGPwebsiteforfurther information.ThissoftwareisbasedinpartontheworkoftheIndependentJPEGGroup.Soft
    [Show full text]
  • Wiretapping End-To-End Encrypted Voip Calls: Real-World Attacks on ZRTP
    Proceedings on Privacy Enhancing Technologies ; 2017 (3):1–17 Dominik Schürmann*, Fabian Kabus, Gregor Hildermeier, and Lars Wolf Wiretapping End-to-End Encrypted VoIP Calls: Real-World Attacks on ZRTP Abstract: Voice calls are still one of the most com- saging apps, such as WhatsApp and Facebook Messen- mon use cases for smartphones. Often, sensitive personal ger [10, 35]. As a result, mobile messaging, the most information but also confidential business information popular smartphone feature, finally includes end-to-end is shared. End-to-end security is required to protect encryption for average users. Comparing their security against wiretapping of voice calls. For such real-time features with that of voice calls shows a major imbal- communication, the ZRTP key-agreement protocol has ance. While making voice calls is the second most popu- been proposed. By verbally comparing a small number lar smartphone feature with 93% popularity [25], its se- of on-screen characters or words, called Short Authenti- curity is often neglected. It is difficult to retrofit the tra- cation Strings, the participants can be sure that no one ditional Public Switched Telephone Network with end- is wiretapping the call. Since 2011, ZRTP is an IETF to-end security, but it is feasible to protect users of mod- standard implemented in several VoIP clients. ern Voice over IP (VoIP) apps. In this paper, we analyzed attacks on real-world VoIP To protect real-time communication channels, the systems, in particular those implementing the ZRTP ZRTP key agreement protocol has been proposed. Based standard. We evaluate the protocol compliance, er- on the Diffie-Hellmann (DH) key exchange, it has been ror handling, and user interfaces of the most common standardized in 2011 as RFC 6189 [37].
    [Show full text]
  • Implementation of a Real-Time Voice Encryption System
    Implementation of a real-time voice encryption system Markus Albert Brandau Master Thesis Universitat Politècnica de Catalunya EUETIT Autor: Markus Brandau Tutor: Ignasi Esquerra Llucià Feb. 2008 1 Fachhochschule Köln University of Applied Sciences Cologne 07 Fakultät für Informations-, Medien- und Elektrotechnik, Studiengang Technische Informatik/ Information Engineering Institut für Nachrichtentechnik Labor für Technische Akustik Master Thesis Thema: Implementation of a real-time voice encryption system Student : Markus Brandau Matrikelnummer: 11031393 Referent : Prof. Dr.- Ing. Pörschmann Korreferent : Prof. Dr.- Ing. Elders- Boll Abgabedatum : 13. Feb. 2008 Hiermit versichere ich, dass ich die Diplomarbeit selbständig angefertigt und keine anderen als die angegebenen und bei Zitaten kenntlich gemachten Quellen und Hilfsmittel benutzt habe. Markus Albert Brandau 2 Abstract Abstract In this master thesis, a voice encryption system was programmed as a real-time software application. The idea was based on a previous graduation thesis and is meant to show an example of the possibilities of signal processing for educational use. The application uses a frequency scrambling technique on an audio signal taken from the computer microphone input and plays it scrambled back to the speakers, or other way around to descramble the signal. The basic idea is to use a frequency channel decomposition through digital signal filtering and down-sampling. Reassembling these sub-bands in a different order, a scrambled voice signal is the result. In addition, the scrambling process is embedded into a “software framework” which allows the use of an audio data stream from and to a sound card through different APIs so a computer platform real-time application can be accomplished.
    [Show full text]
  • Authloop: End-To-End Cryptographic Authentication for Telephony Over Voice Channels
    AuthLoop: End-to-End Cryptographic Authentication for Telephony over Voice Channels Bradley Reaves, Logan Blue, and Patrick Traynor, University of Florida https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/reaves This paper is included in the Proceedings of the 25th USENIX Security Symposium August 10–12, 2016 • Austin, TX ISBN 978-1-931971-32-4 Open access to the Proceedings of the 25th USENIX Security Symposium is sponsored by USENIX AuthLoop: Practical End-to-End Cryptographic Authentication for Telephony over Voice Channels Bradley Reaves Logan Blue Patrick Traynor University of Florida University of Florida University of Florida reaves@ufl.edu bluel@ufl.edu [email protected]fl.edu Abstract asserting an identity (e.g., a bank, law enforcement, etc.), taking advantage of a lack of reliable cues and mecha- Telephones remain a trusted platform for conducting nisms to dispute such claims. Addressing these prob- some of our most sensitive exchanges. From banking to lems will require the application of lessons from a related taxes, wide swathes of industry and government rely on space. The Web experienced very similar problems in the telephony as a secure fall-back when attempting to con- 1990s, and developed and deployed the Transport Layer firm the veracity of a transaction. In spite of this, authen- Security (TLS) protocol suite and necessary support in- tication is poorly managed between these systems, and in frastructure to assist with the integration of more veri- the general case it is impossible to be certain of the iden- fiable identity in communications. While by no means tity (i.e., Caller ID) of the entity at the other end of a call.
    [Show full text]
  • Alternate Encryption Scheme for Real-Time Traffic
    ALTERNATE ENCRYPTION SCHEME FOR REAL-TIME TRAFFIC A Thesis by Gopinath Gopalakrishnan M.S., Wichita State University, 2007 Submitted to the Department of Electrical and Computer Engineering and the faculty of the Graduate School of Wichita State University in partial fulfillment for the degree of Master of Science July 2007 © Copyright 2007 by Gopinath Gopalakrishnan All Rights Reserved ALTERNATE ENCRYPTION SCHEME FOR REAL-TIME TRAFFIC I have examined the final copy of this thesis for form and content, and recommend that it be accepted in partial fulfillment of the requirements for the degree of Master of Science with a major in Electrical and Computer Engineering. ______________________________ Ravi Pendse, Committee Chair We have read this thesis and recommend its acceptance: _______________________________ Kamesh Namuduri, Member _______________________________ Krishna K.Krishnan, Member iii DEDICATION This thesis is dedicated to my beloved parents, all my family members and friends who have supported and encouraged me throughout my life. Without their support and encouragement this thesis would not be a success. iv ACKNOWLEDGEMENTS I would like to thank my advisor, Dr. Ravi Pendse, for all his support and valuable guidance over the entire course of my academic career at WSU and for giving me an opportunity to do my Master’s thesis under his guidance in the field of VOIP Security. I am thankful to my committee for taking the time to work with me in this endeavor. I would also like to thank Mr. Nagaraja Thanthry, Mr. Amarnath Jasti, Mr. Manivannan Srinivasan and all my friends at the Advanced Networking Research Center (ANRC) at Wichita State University for their help during this time.
    [Show full text]
  • PGP Freeware for Windows 95, Windows 98, and Windows NT
    PGP Freeware for Windows 95, Windows 98, and Windows NT User’s Guide Version 6.5 Copyright © 1990-1999 Network Associates, Inc. and its Affiliated Companies. All Rights Reserved. PGP*, Version 6.5.1 06-99. Printed in the United States of America. PGP, Pretty Good, and Pretty Good Privacy are registered trademarks of Network Associates, Inc. and/or its Affiliated Companies in the US and other countries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. Portions of this software may use public key algorithms described in U.S. Patent numbers 4,200,770, 4,218,582, 4,405,829, and 4,424,414, licensed exclusively by Public Key Partners; the IDEA(tm) cryptographic cipher described in U.S. patent number 5,214,703, licensed from Ascom Tech AG; and the Northern Telecom Ltd., CAST Encryption Algorithm, licensed from Northern Telecom, Ltd. IDEA is a trademark of Ascom Tech AG. Network Associates Inc. may have patents and/or pending patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents. The compression code in PGP is by Mark Adler and Jean-Loup Gailly, used with permission from the free Info-ZIP implementation. LDAP software provided courtesy University of Michigan at Ann Arbor, Copyright © 1992-1996 Regents of the University of Michigan. All rights reserved. This product includes software developed by the Apache Group for use in the Apache HTTP server project (http://www.apache.org/).
    [Show full text]
  • Information Security Issues in Voice Over Internet Protocol
    Information Security Issues in Voice Over Internet Protocol Satya Bhan Jonathan Clark Joshua Cuneo Jorge Mejia-Ramirez CS 4235 Fall 2006 Table of Contents I. Introduction.…………………………………………………………………………1 II. An Overview of VoIP……………………………………………………….……..1 VoIP Protocols…………………………………………………………..……3 III. Common VoIP Security Threats…………………………………………...……..6 Denial of Service Attacks……………………………………………….…… 7 Eavesdropping………………………………………………………….….… 8 Spoofing…………………………………………………………………....…9 Theft of Service…………………………………………………………...…. 10 Spam over Internet Telephony (SPIT)………………………………….....….11 IV. VoIP Encryption Algorithms……………………………………………….…….12 PGPfone………………………………………………………………………12 Motivation………………………………………………………………....….12 Technical Details………………………………………………......… 15 Secure Real-time Transport Protocol………………………………..………..16 ZRTP and Zfone……………………………………………………...……….18 ZRTP………………………………………………………………….18 Zfone………………………………………………………………….20 Skype………………………………………………………………………… 20 V. Research and Development to Improve VoIP Security…………………...……… 23 Locating Users in a Secure and Reliable Way………………………..…...… 23 Current State and Motivation to Change…………………………….. 24 Proposed Scheme…………………………………………..……...….25 Monitoring VoIP Networks………………………………………………….. 26 Motivation………….………..……………………………….……… 26 Current State………………..………………………………….…….. 26 Proposed Idea………………………………………………………….27 Intrusion Detection and Prevention on SIP……………………………………28 The Prototype………………………………………………….………29 VI. Concluding Remarks………………………………………..…………………… 30 VII. Works Cited………………………………………………..……………………
    [Show full text]