Authloop: End-To-End Cryptographic Authentication for Telephony Over Voice Channels

Total Page:16

File Type:pdf, Size:1020Kb

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. perfect and still an area of active research, this infrastruc- We address this problem with AuthLoop, the first system ture helps to make a huge range of attacks substantially to provide cryptographic authentication solely within the more difficult. Unfortunately, the lack of similarly strong voice channel. We design, implement and characterize mechanisms in telephony means that not even trained se- the performance of an in-band modem for executing a curity experts can currently reason about the identity of TLS-inspired authentication protocol, and demonstrate other callers. its abilities to ensure that the explicit single-sided authen- In this paper, we address this problem with tication procedures pervading the web are also possible AuthLoop.1 AuthLoop provides a strong cryptographic on all phones. We show experimentally that this protocol authentication protocol inspired by TLS 1.2. However, can be executed with minimal computational overhead unlike other related solutions that assume Internet access and only a few seconds of user time ( 9 instead of 97 ≈ ≈ (e.g., Silent Circle, RedPhone, etc [24, 73, 25, 5, 3, 6, seconds for a na¨ıve implementation of TLS 1.2) over het- 1, 74, 7]), accessibility to a secondary and concurrent erogeneous networks. In so doing, we demonstrate that data channel is not a guarantee in many locations (e.g., strong end-to-end validation of Caller ID is indeed prac- high density cities, rural areas) nor for all devices, man- tical for all telephony networks. dating that a solution to this problem be network agnos- tic. Accordingly, AuthLoop is designed for and trans- 1 Introduction mitted over the only channel certain to be available to all phone systems — audio. The advantage to this approach Modern telephony systems include a wide array of end- is that it requires no changes to any network core, which user devices. From traditional rotary PSTN phones to would likely see limited adoption at best. Through the modern cellular and VoIP capable systems, these devices use of AuthLoop, users can quickly and strongly iden- remain the de facto trusted platform for conducting many tify callers who may fraudulently be claiming to be orga- of our most sensitive operations. Even more critically, nizations including their financial institutions and their these systems offer the sole reliable connection for the government [28]. majority of people in the world today. We make the following contributions: Such trust is not necessarily well placed. Caller ID is known to be a poor authenticator [59, 18, 67], and 1A name reminiscent of the “Local Loop” used to tie traditional yet is successfully exploited to enable over US$2 Bil- phone systems into the larger network, we seek to tie modern telephony systems into the global authentication infrastructure that has dramati- lion in fraud every year [28]. Many scammers simply cally improved transaction security over the web during the past two block their phone number and exploit trusting users by decades. 1 USENIX Association 25th USENIX Security Symposium 963 Intermediary Telco IP Networks Networks VOIP Cell Network Carrier Web Gateway Internet Services VOIP Proxy Gateway PSTN Figure 1: A high-level representation of modern telephony systems. In addition to voice being transcoded at each gateway, all identity mechanisms become asserted rather than attested as calls cross network borders. A strong end- to-end authentication must be designed aware of all such limitations. Design a Complete Transmission Layer: We de- work; Section 3 presents the details of our system includ- • sign the first codec-agnostic modem that allows for ing lower-layer considerations; Section 4 discusses our the transmission of data across audio channels. We security model; Section 5 formally defines the AuthLoop then create a supporting link layer protocol to en- protocol and parameterizes our system based on the mo- able the reliable delivery of data across the hetero- dem; Section 6 discusses our prototype and experimental geneous landscape of telephony networks. results; Section 7 provides additional discussion about our system; and Section 8 provides concluding remarks. Design AuthLoop Authentication Protocol: After • characterizing the bandwidth limitations of our data channel, we specify our security goals and design 2 Background and Related Work the AuthLoop protocol to provide explicit authenti- cation of one party (i.e., the “Prover”) and option- In this section, we provide an overview of modern tele- ally weak authentication of the second party (i.e., phony networks and review current and proposed prac- the “Verifier”). tices of authentication in those networks. Evaluate Performance of a Reference Implemen- • 2.1 Modern Telephony Networks tation: We implement AuthLoop and test it us- ing three representative codecs — G.711 (for PSTN The landscape of modern telephony is complex and het- networks), AMR (for cellular networks) and Speex erogeneous. Subscribers can receive service from mo- (for VoIP networks). We demonstrate the ability bile, PSTN and VoIP networks, and calls to those sub- to create a data channel with a goodput of 500 bps scribers may similarly originate from networks imple- and bit error rates averaging below 0.5%. We then menting any of the above technologies. Figure 1 pro- demonstrate that AuthLoop can be run over this vides a high-level overview of this ecosystem. channel in an average of 9 seconds (which can be While performing similar high-level functionality played below speaker audio), compared to running (i.e., enabling voice calls), each of these networks is a direct port of TLS 1.2 in an average of 97 seconds built on a range of often incompatible technologies. (a 90% reduction in running time). From circuit-switched intelligent network cores to packet switching over the public Internet, very little information The remainder of this paper is organized as follows: beyond the voice signal actually propagates across the Section 2 provides background information and related borders of these systems. In fact, because many of these 2 964 25th USENIX Security Symposium USENIX Association a) 1-second chirp sweep from 300 - 3300 Hz before AMR-NB encoding b) 1-second chirp sweep from 300 - 3300 Hz after AMR-NB encoding Figure 2: A comparison of a signal (a) before and (b) after being encoded with the AMR codec. Note that while the entirety of the signal is within the range of allowable frequencies for call audio, the received signal differs significantly from its original form. It is therefore critical that a high-fidelity mechanism for delivering data over a mobile audio channel be designed. networks rely on different codecs for encoding voice, user nature of wireless spectrum. Unfortunately, 1G au- one of the major duties of gateways between these sys- thentication relied solely on the plaintext assertion of tems is the transcoding of audio. Accordingly, voice en- each user’s identity and was therefore subject to signifi- coded at one end of a phone call is unlikely to have the cant fraud [53]. Second generation (2G) networks (e.g., same (or even similar) bitwise representation when it ar- GSM) designed cryptographic mechanisms for authen- rives at the client side of the call. As evidence, the top ticating users to the network. These protocols failed to plot of Figure 2 shows a sweep of an audio signal from authenticate the network to the user and lead to a range 300 to 3300 Hz (all within the acceptable band) across of attacks against subscribers [44, 26, 19, 68]. Third 1 second. The bottom plot shows the same signal af- and fourth generation (3G and 4G) systems correctly ter is has been encoded using the Adaptive Multi-Rate implement mutual authentication between the users and (AMR) audio codec used in cellular networks, resulting providers [11, 12, 13]. Unfortunately, all such mecha- in a dramatically different message. This massive differ- nisms are designed to allow accurate billing, and do little ence is a result of the voice-optimized audio codecs used to help users identify other callers. in different telephony networks. Accordingly, success- While a number of seemingly-cellular mechanisms fully performing end-to-end authentication will require have emerged to provide authentication between end careful design for this non-traditional data channel.
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]
  • 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).
    [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]
  • 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]