DOCSLIB.ORG

Skype and the Flux-Capacitor

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Contents Skype and the Skype Overview .................. 4 Flux-Capacitor VoIP Introduction .................. 5 VoIP Signalling Protocols ............. 6 Dr. Ralf Schlatterbeck VoIP: Bunch of Firewall Problems ......... 7 Open Source Consulting Standards for Encrypted Telephony ....... 8 Security with Encrypted Telephony ........ 9 Excursus: Man in the Middle ........... 10 Email: offi[email protected] Existing Implementations ............. 11 Web: http://www.runtux.com Alternatives to Skype ............... 12 Tel. +43/650/621 40 17 History of Publications about Skype ....... 13 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 1 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 2 Contents Skype Overview Skype Security Considerations .......... 14 • „It just works“: no problems with firewalls Skype Network Obfuscation: Flux Capacitor . 16 • Skype makers known for Spyware-contaminated Excursus: CRC32 ................. 18 filesharing software (KazaA) Skype Network Obfuscation: Compression . 20 • built-in software-update function in Skype Skype and Cryptography ............. 21 • Doesn’t adhere to any standards – no third-party Skype Communication Security .......... 22 offers Debugging Skype ................. 23 • Closed source – Open Source Skype would be Skype Task-Force? ................. 24 nice and this may be within reach now Bibliography ..................... 25 → Whom to entrust with your phone calls? → Encryption: Who owns the keys??? © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 3 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 4 VoIP Introduction VoIP Signalling Protocols • Voice over Internet Protocol (and often also Video) • IAX: Inter Asterisk Exchange: use same path for • Distinction: call signalling and content (voice/video) signalling and content – firewall-friendly • Signalling Protocols e. g. SIP, H.323, . • SIP: Session Initiation Protocol • Content transmission e. g. RTP (Realtime Transfer • Jabber/Jingle (Google Talk) Protocol) • H.323: ITU-T Standard • Quality: Low latency, low Jitter, low packet loss • MGCP: Media Gateway Control Protocol • Open: Success of VoIP depends on standards: we • SCCP/Skinny (proprietary CISCO) want interconnection of different vendor solutions • UNISTIM (proprietary Nortel) • If signalling and content are sent via different path • Skype (proprietary): optionally one signalling path we may get problems with firewalls → „Asterisk is first PBX in history to natively support proprietary IP terminals from the two biggest players in VoIP“ [MSM05] © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 5 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 6 VoIP: Bunch of Firewall Problems Standards for Encrypted Telephony • SIP, Jingle, H.323 are signalling protocols • encryption option for IAX with pre-shared keys → only for call-management • VoIP can be routed via a VPN, e. g. OpenVPN • For Content: RTP (Realtime Transfer Protocol) • SRTP/SRTCP: needs a key management scheme RTP-Port is dynamically negotiated Master-Key: call parties need to agree on a key → Firewall (NAT!) problems • Phil Zimmermanns ZRTP: SRTP + Diffie-Hellman • Remedy (or workaround): NAT-Traversal protocols, → call parties need not know each other! or intelligent firewall → uses existing SIP infrastructure • For Linux/Netfilter: SIP+H.323 connection tracking → approved as informational RFC and NAT modules • IETF DTLS based on certificates for negotiating • or use IAX! SRTP key – will become Standards-Track RFC (!) © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 7 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 8 Security with Encrypted Telephony Excursus: Man in the Middle • Traffic Analysis: „Who with whom“ → nearly conforming to EU Data Retention :-) encrypt encrypt • IAX transmits session information in clear AE EB • Even when using a VPN we can determine that Alice Eve Bob there is VoIP-content due to packet frequencies • Eve – the woman in the middle – does and -sizes key exchange with Alice and Bob • SRTP without ZRTP, IAX or VPN: • There are two keys, AE und EB needs prior agreement of calling/called parties • But: Alice and Bob can compare key checksums • ZRTP MITM-Protection: call partners can read key- by reading them to each other over the phone hash to each other – hard to fake by man in the → Authentification via speech! middle © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 9 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 10 Existing Implementations Alternatives to Skype General: • SIP-Phones (Ekiga, Twinkle, Linphone) • IAX encryption: no personal experience • Chat: multiprotocol-client Pidgin • OpenVPN + Asterisk IAX (or SIP/RTP) works well • Chat + telephony: Google Talk (Jabber extension „Jingle“ for Voice/Video) ZRTP: • Open Source telephony: Asterisk: SIP,Jabber/Jingle, • SRTP/ZRTP not yet in Asterisk but ZFone can be and lots of other protocols . used • Encryption: Phil Zimmermann’s ZRTP + SRTP • Phil Zimmermanns ZFone as add-on to existing or IETF’s DTLS (certificate-based) + SRTP RTP-based software • GNU ccRTP supports ZRTP • GPL-Client Twinkle with ZRTP © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 11 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 12 History of Publications about Skype Skype Security Considerations • Biondi, Desclaux: Silver Needle in the Skype, Black- • Writeable text-segment: hat Europe 2006 [BD06] Decrypts itself when called • Desclaux, Kortchinsky: Vanilla Skype [DK06a, DK06b], • could load code over the network into memory Recon 2006 • when asking for updates Skype sends its Skype-ID • Biondi, Desclaux, Kortchinsky analyzed the net- → maybe this is used for sending you your own work obfuscation and compression algorithms of personalized (trojan?) update? Skype but didn’t publish their work • Skype can find out IPs of other Skype clients [BD06, • they called the network obfuscation function „Flux p. 61] – there is already a service announced to Capacitor“ discover Skype IPs by username • 2010-07-07 Sean O’Neil: → imagine the possibilities when coupled with Geo- Skype’s Biggest Secret Revealed location © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 13 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 14 Skype Security Considerations Skype Network Obfuscation: Flux Capacitor • Remote Scan: We can make another node connect • A big obfuscated function first described by to a specified IP-Adress – even in the network Desclaux/Kortchinsky: „it is not an improvement of perimeter (inside Firewall) of that host [BD06, p. 82] the flux capacitor“ [DK06a, p. 52] • Censor API for chat activated for chinese Skype • they even describe a method how to generate C- calls ContentFilter.exe – API present in all code from the binary [DK06a, p. 55–65] Skype versions [DK06b, p. 40] • obfuscation function takes a 32-bit seed • AP2AP protocol for communication of non-Skype and computes an RC-4 key applications via Skype [DK06b, p. 42] • the RC4-key is used to encrypt the UDP-packet or • Information Exfiltration (file transfer) TCP-stream • remote control • for TCP the seed is sent in clear as the first bytes ⇒ that’s why I chose not to use Skype of the stream © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 15 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 16 Skype Network Obfuscation: Flux Capacitor Excursus: CRC32 • for UDP the CRC32 of source-IP, dest-IP and per • Silver Needle suggests UDP uses CRC32 – there packet ID XOR an initialisation vector (IV) is used is example code from Vanilla which has a CRC32 as the seed • The well-known crc32 from Ethernet, ZIP,etc. uses • The packet ID and IV are in clear in every packet the same polynomial but a different finalisation: • . so everything is known about the RC-4 key def zlib_crc (s, seed = 0) : • It’s just an obfuscation layer, no real encryption state = seed ^ 0xFFFFFFFF because the key is known (security by obscurity) state = do_crc (s, state) • But the obfuscation is so “good” that it hasn’t been return state ^ 0xFFFFFFFF published until now • I’ve been able to verify this for TCP, and now also def skype_crc (s, seed = 0xFFFFFFFF) : for UDP return do_crc (s, seed) © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 17 © 2010 Dr. Ralf Schlatterbeck Open Source Consulting · www.runtux.com · offi[email protected] 18 Excursus: CRC32 Skype Network Obfuscation: Compression • zlib crc32 uses initial value 0, skype uses 0xFFFFFFFF • Before encryption Skype uses an undocumented → effect is the same internal state arithmetic compression algorithm [DK06b, p.7–8] ⇒ So we can use crc32 from zlib for skype crc: • Arithmetic compression close to Huffman but using def skype_crc (s, seed = 0xFFFFFFFF) : reals mask = 0xFFFFFFFF • Sean O’Neil promises to publish the compression, return (crc32 (s, seed ^ mask)) ^ mask too: “The compression algorithm required to • this implementation allows part-wise computation: complete the decoding of Skype packets will be x = skype_crc ('abcd') published in December this
Recommended publications
  • Uila Supported Apps

    Uila Supported Apps

    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
  • Webrtc and XMPP

    Webrtc and XMPP

    webRTC and XMPP Philipp Hancke, XMPP Summit 2013 What is this webRTC thing … …and why should XMPP developers care? . I assume you know what XMPP is… . … you might have heard of Jingle . the XMPP framework for establishing P2P sessions . used for VoIP, filesharing, … . … you might have also heard about this webRTC thing . doing VoIP in the browser . without plugins . „no more flash“ . Do you want to know how it relates to XMPP ? Philipp Hancke © ESTOS GmbH 2013 2 What is webRTC? . P2P sessions between browsers . no servers involved in media transfer . using open standards . Javascript API in the browser . also an BSD-licensed C++ library from Google . Want to know more? . Listen to the evangelists! . Justin Uberti http://www.youtube.com/watch?v=E8C8ouiXHHk . Jose de Castro http://vimeo.com/52510068 . Cullen Jennings http://vimeo.com/cullenfluffyjennings/rtcwebexplained Philipp Hancke © ESTOS GmbH 2013 3 Initiating P2P sessions . initiate a P2P session between two browsers . negotiate media codecs, NAT traversal, etc . media is sent P2P . you need a session initiation protocol . SIP? . JSEP? . H.323? . Jingle! . webRTC does not mandate a signalling protocol . WG decision Philipp Hancke © ESTOS GmbH 2013 4 Call Flow - JSEP Philipp Hancke © ESTOS GmbH 2013 5 Jingle . You can use Jingle as signalling protocol . together with BOSH or XMPP over websockets in the browser . Demo later . But… . webRTC uses the Session Description Protocol as an API . Jingle does not use SDP . You need a mapping SDP -> Jingle -> SDP . Complicated, but doable . Topic for breakout Philipp Hancke © ESTOS GmbH 2013 6 Call Flow - Jingle Philipp Hancke © ESTOS GmbH 2013 7 webRTC-Jingle usecases .
  • The Handshake - Establishing Secure Connections Over Insecure Channels

    The Handshake - Establishing Secure Connections Over Insecure Channels

    Lecture 13: The handshake - establishing secure connections over insecure channels Boaz Barak We’ve now compiled all the tools that are needed for the basic goal of cryptography (which is still being subverted quite often) allowing Alice and Bob to exchange messages assuring their integrity and confidentiality over a channel that is observed or controlled by an adversary. Our tools for achieving this goal are: • Public key (aka assymetric) encryption schemes. • Public key (aka assymetric) digital signatures schemes. • Private key (aka symmetric) encryption schemes - block ciphers and stream ciphers. • Private key (aka symmetric) message authentication codes and psedoran- dom functions. • Hash functions that are used both as ways to compress messages for authentication as well as key derivation and other tasks. The notions of security we require from these building blocks can vary as well. For encryption schemes we talk about CPA (chosen plaintext attack) and CCA (chosen ciphertext attacks), for hash functions we talk about collision-resistance, being used (combined with keys) as pseudorandom functions, and then sometimes we simply model those as random oracles. Also, all of those tools require access to a source of randomness, and here we use hash functions as well for entropy extraction. Cryptography’s obsession with adjectives. As we learn more and more cryptography we see more and more adjectives, every notion seems to have modifiers such as “non malleable”, “leakage-resilient”, “identity based”, “concurrently secure”, “adaptive”, “non-interactive”, etc.. etc. Indeed, this motivated a parody web page of an automatic crypto paper title generator. Unlike algorithms, where typically there are straightforward quantitative tradeoffs (e.g., faster is better), in cryptography there are many qualitative ways protocols can vary based on the assumptions they operate under and the notions of security they provide.
  • Wiretapping End-To-End Encrypted Voip Calls Real-World Attacks on ZRTP

    Wiretapping End-To-End Encrypted Voip Calls Real-World Attacks on ZRTP

    Institute of Operating Systems and Computer Networks Wiretapping End-to-End Encrypted VoIP Calls Real-World Attacks on ZRTP Dominik Schürmann, Fabian Kabus, Gregor Hildermeier, Lars Wolf, 2017-07-18 wiretapping difficulty End-to-End Encryption SIP + DTLS-SRTP (SIP + Datagram Transport Layer Security-SRTP) End-to-End Encryption & Authentication SIP + SRTP + ZRTP Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time Transport Protocol) 2017-07-18 Dominik Schürmann Wiretapping End-to-End Encrypted VoIP Calls Page 2 of 13 wiretapping difficulty End-to-End Encryption & Authentication SIP + SRTP + ZRTP Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time Transport Protocol) End-to-End Encryption SIP + DTLS-SRTP (SIP + Datagram Transport Layer Security-SRTP) 2017-07-18 Dominik Schürmann Wiretapping End-to-End Encrypted VoIP Calls Page 2 of 13 wiretapping difficulty Introduction Man-in-the-Middle ZRTP Attacks Conclusion End-to-End Security for Voice Calls Institute of Operating Systems and Computer Networks No End-to-End Security PSTN (Public Switched Telephone Network) SIP + (S)RTP (Session Initiation Protocol + Secure Real-Time
  • AUTHENTICATION TECHNIQUES for HETEROGENEOUS TELEPHONE NETWORKS by BRADLEY GALLOWAY REAVES a DISSERTATION PRESENTED to the GRADUA

    AUTHENTICATION TECHNIQUES for HETEROGENEOUS TELEPHONE NETWORKS by BRADLEY GALLOWAY REAVES a DISSERTATION PRESENTED to the GRADUA

    AUTHENTICATION TECHNIQUES FOR HETEROGENEOUS TELEPHONE NETWORKS By BRADLEY GALLOWAY REAVES A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2017 © 2017 Bradley Galloway Reaves For Sarah ACKNOWLEDGMENTS Iamonlywritingthistodaybecauseofthemultitudeoffamily,friends,teachers,and colleagues who helped get me here. This journey began in high school, when Mrs. Reid, my English teacher, suggested that I would make a good college professor. I wasn’t sure about the idea until my second programming class in college. I loved programming, so I would do the lab assignments at home, then show up in the lab to demonstrate the project to the TA. My work for the week was done, but I didn’t leave the lab. Instead, I stayed for the next few hours helping other students when they needed help with the programming assignments. It became the best part of my week, and I realized that there was no career I wanted more than to be a professor of computing. Having a goal and knowing what it takes to achieve it are two very di↵erent things. At the time I knew I needed a PhD, but nothing of what it took to get one. Luckily, I had wonderfully supportive professors and advisors who told me what it took, and one in particular helped me take the first steps toward a research career. Tommy Morris was a new professor at Mississippi State, and after teaching my digital design class o↵ered me a (paid!) position in his research lab.
  • Analysis of Effect of Zfone Security on Video Call Service in Wireless Local Area Network

    Analysis of Effect of Zfone Security on Video Call Service in Wireless Local Area Network

    International Journal of Computer Techniques -– Volume 6 Issue 6,November 2019 ANALYSIS OF EFFECT OF ZFONE SECURITY ON VIDEO CALL SERVICE IN WIRELESS LOCAL AREA NETWORK Arip Solehudin 1 Bayu Priyatna 2 Nono Heryana 3 Teknik Informatika Fakultas Ilmu Komputer School of Engineering and Computer Science Sistem Informasi Fakultas Ilmu Komputer Universitas Singaperbangsa Karawang Universitas Buana Perjuangan Karawang Universitas Singaperbangsa Karawang Karawang, Indonesia Karawang, Indonesia Karawang, Indonesia [email protected] [email protected] [email protected] Abstract—Along with the development of WLAN (Wireless VoIP LAN that uses cable began to move using wireless Local Area Network) network technology, many services that network technology, namely wireless. The use of wireless used cable networks began to migrate to wireless networks. networks as a medium for the flow of data makes VoIP VoIP (Voice over Internet Protocol) is one service implemented services can be used in several communication technology in wireless local area networks. However, VoIP that uses tools such as personal computers, laptops, and smartphones. wireless technology as a data stream media Video Call service has a high risk of tapping pictures. To avoid tapping pictures, The use of VoIP technology that is implemented on you can add a security system to the service, one of which is to WLAN networks with video call services found in VoIP use Zfone security. With him adding a security system that will facilities is an excellent solution for conducting influence the work of Video Call services on the quality of conversations at affordable costs compared to the VoIP service.
  • Zfone: a New Approach for Securing Voip Communication

    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.
  • Copyrighted Material

    Copyrighted Material

    Stichwortverzeichnis A B Abstreitbarkeit 167 Bequemlichkeit 30 Adblocker 96 Bitcoin 110 – Adblock Plus 96 Blackberry 215 – Disconnect 96 Bookmarks siehe Favoriten – Ghostery 96 Browser 68, 75 – Privacy Badger 96 – Add-on 87, 90 – uBlock 97 – Apple Safari 77 Add-on – Cache 88 – Browser 87, 90 – Chromium 78 – E-Mail-Client 126 – Chronik 87 – Enigmail siehe Enigmail – Fingerprinting 85, 98 – GpgOL 137 – Google Chrome 77 – Mailvelope 130, 132 – HTML-Engine 80 – Thunderbird 139 – Hygiene 88 Adium 170 – Iceweasel 78 Advanced Programming Interface (API) 90, – Inkognito-Modus 86 182 – integrierte Suche 84 Android – Internet Explorer 77 – Android Privacy Guard (App) 156 – Konqueror 78 – K9 Mail (E-Mail-Client) 156 – Microsoft Edge 92 – OpenKeychain (App) 156 – Midori 78 – PGP 156 – Mosaic 68 – R2Mail2 (E-Mail-Client) 158 – Mozilla Firefox 68, 76 – S/MIME 156 – Netscape Navigator 68 Anonymität 206 COPYRIGHTED– Opera 77MATERIAL AOL Instant Messenger (AIM) 164 – Plug-in 87 Apple Mail – Prole (Identitäten) 87 – PGP 145 – Synchronisation von Einstellungen – S/MIME 155 86 Authentizierung 167, 169, 176, 179 – Web (Epiphany) 78 – Adium 172 Buffer Overow 82 – Multifaktor- 201 Bugs 82 – Pidgin 169 Bundesamt für Sicherheit in der Informations- Authentizität 29, 54, 56 technik (BSI) 215 233 Stichwortverzeichnis C – E-Mail-Adresse 119 Caesar-Chiffre 36 – Header 121 Certicate Authority siehe Zertizierungsstelle – Provider 129, 131, 139 Chain of Trust siehe Web of Trust – Server 122 Chaos Computer Club (CCC) 133 Eingangsverschüsselung 125 Chat 161 Electronic
  • PENGAMANAN PAYLOAD Voip BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE

    PENGAMANAN PAYLOAD Voip BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE

    PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE Oleh: MUHARTANTO E 103091029610 PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAIS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2010 M/1431 H i PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE Skripsi Diajukan untuk Memenuhi Persyaratan Memperoleh Gelar Sarjana Komputer Pada Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta Oleh: MUHARTANTO E 103091029610 PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAIS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2010 M/1431 H ii PENGAMANAN PAYLOAD VoIP BERBASIS ASTERISK DENGAN PROTOKOL SRTP MENGGUNAKAN TWINKLE Skripsi Sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta Oleh: MUHARTANTO E 103091029610 Menyetujui, Pembimbing I, Pembimbing II, Arini, MT Zulfiandri, MMSI NIP. 197601312009012001 NIP. 197001302005011003 Mengetahui, Ketua Program Studi Teknik Informatika Yusuf Durrachman, MIT NIP. 197105222006041002 iii PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKONOLOGI UIN SYARIF HIDAYATULLAH JAKARTA Dengan ini menyatakan bahwa skripsi yang ditulis oleh : Nama : Muhartanto E NIM : 103091029610 Fakultas : Sains dan Teknologi Program Studi : Teknik Informatika Judul Skripsi : Pengamanan Payload VoIP Berbasis Asterisk Dengan Protokol SRTP Menggunakan Twinkle. Dapat diterima sebagai syarat kelulusan untuk memperoleh gelar Sarjana Komputer pada Program Studi Teknik Informatika, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif Hidayatullah Jakarta. Jakarta, Agustus 2010 Menyetujui, Dosen Pembimbing Dosen Pembimbing I Dosen Pembimbing II Arini, MT Zulfiandri, MMSI NIP. 19760131 200901 2 001 NIP. 19700130 200501 1 003 Mengetahui, Dekan Fakultas Sains & Teknologi Ketua Prodi Teknik Informatika DR. Syopiansyah Jaya Putra, M.Sis Yusuf Durrachman, MIT NIP.
  • Google Talk: Is It Ready for the Enterprise?

    Google Talk: Is It Ready for the Enterprise?

    Research Publication Date: 16 April 2009 ID Number: G00166834 Google Talk: Is It Ready for the Enterprise? David Mario Smith, James Lundy This report discusses the Google Talk instant messaging product and its suitability for enterprises. This is important for companies which are looking at alternatives to IBM and Microsoft for messaging and collaboration. Key Findings • Google Talk IM is based on the Extensible Messaging and Presence Protocol (XMPP) and Jingle protocols. • To get enterprise-level support for Google Talk, companies have to purchase the full Google Apps Premier Edition (GAPE) suite. • Enterprise users are already using the Google Talk and Gmail free services. Recommendations • Enterprises making collaboration decisions should include the Google Apps portfolio as part of an effort to compare the economics of their current incumbent provider vs. similar services provisioned in the cloud. © 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. WHAT YOU NEED TO KNOW Enterprise instant messaging (IM) has emerged to become an infrastructure component in enterprises.
  • A Comparison Between Inter-Asterisk Exchange Protocol and Jingle Protocol: Session Time

    A Comparison Between Inter-Asterisk Exchange Protocol and Jingle Protocol: Session Time

    Engineering, Technology & Applied Science Research Vol. 6, No. 4, 2016, 1050-1055 1050 A Comparison Between Inter-Asterisk eXchange Protocol and Jingle Protocol: Session Time H. S. Haj Aliwi N. K. A. Alajmi P. Sumari K. Alieyan School of Computer Sciences Saad Al-Abdullah Academy School of Computer Sciences National Advanced IPv6 Center Universiti Sains Malaysia for Security Sciences, Kuwait Universiti Sains Malaysia Universiti Sains Malaysia [email protected] [email protected] [email protected] [email protected] Abstract—Over the last few years, many multimedia conferencing sessions. Such applications are Gtalk, Talkonaut, and Hangouts and Voice over Internet Protocol (VoIP) applications have been [7]. developed due to the use of signaling protocols in providing video, audio and text chatting services between at least two participants. II. BACKGROUND This paper compares between two widely common signaling protocols: InterAsterisk eXchange Protocol (IAX) and the extension of the eXtensible Messaging and Presence Protocol A. IAX Protocol (Jingle) in terms of delay time during call setup, call teardown, In 2004, Mark Spencer created the Inter-Asterisk eXchange and media sessions. (IAX) protocol for asterisk that performs VoIP signaling [22]. IAX is supported by a few other softswitches, (Asterisk Private Keywords-multimedia conferencing; VoIP; signaling protocols; Branch eXchange) PBX systems [23], and softphones [18]. Jingle; IAX Any type of media (Video, audio, and document conferencing) can be managed, controlled and transmitted through the I. INTRODUCTION Internet Protocol (IP) networks based on IAX protocol [25]. With the appearance of numerous multimedia conferencing IAX2 is considered to be the current version of IAX.
  • XEP-0234: Jingle File Transfer

    XEP-0234: Jingle File Transfer

    XEP-0234: Jingle File Transfer Peter Saint-Andre Lance Stout mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2019-06-19 Version 0.19.1 Status Type Short Name Deferred Standards Track jingle-ft This specification defines a Jingle application type for transferring a file from one entity to another. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.