DOCSLIB.ORG

How Secure Is Textsecure?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
How Secure Is Textsecure? How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time. In this setting, existing solutions, such messaging and has attracted a lot of attention is TEXTSECURE. as OTR, are only applicable in a limited fashion. Besides numerous direct installations, its protocol is part of Secure Messaging and TextSecure. In the light of the Android’s most popular aftermarket firmware CYANOGEN- recent revelations of mass surveillance actions performed MOD.TEXTSECURE’s successor Signal continues to use the by intelligence services such as NSA and GCHQ, several underlying protocol for text messaging. In this paper, we secure text messaging (TM) solutions that claim not to be present the first complete description of TEXTSECURE’s com- prone to surveillance and to offer a certain level of security plex cryptographic protocol, provide a security analysis of have appeared on the market [5]. its three main components (key exchange, key derivation and One of the most popular apps for secure TM is TEXT- 1 authenticated encryption), and discuss the main security claims SECURE , an app developed by Open WhisperSystems that of TEXTSECURE. Furthermore, we formally prove that—if key claims to support end-to-end security of text messages. registration is assumed to be secure—TEXTSECURE’s push While previously focusing on encrypted short message ser- messaging can indeed achieve most of the claimed security vice (SMS) communication, Open WhisperSystems intro- goals. duced data channel-based push messaging in February 2014. Thus, the app offers both an iMessage- and WhatsApp-like communication mode, providing SMS+data channel or data 1. Introduction channel-only communications [6]. Following Facebook’s ac- quisition of WHATSAPP,TEXTSECURE gained in popular- Since more than a decade, Instant Messaging (IM) is ity among the group of privacy-conscious users and has cur- an alternative to classical e-mail communication, for both rently more than 500,000 installations via Google Play. Its private and business communication. IM has different fea- encrypted messaging protocol has also been integrated into tures; most importantly, messages are delivered in real-time, the OS-level SMS-provider of CyanogenMod [7], a popular but only if both parties are online. However, in contrast to open-source aftermarket Android firmware that has been security mechanisms available for e-mail such as PGP [1] installed on about 10 million Android devices [8]. According and S/MIME [2], instant messages were sent unprotected: to media reports [9], TextSecure’s protocol has additionally In the early days, many popular IM solutions like MSN been implemented in WhatsApp’s Android client. While we MESSENGER and YAHOO MESSENGER did not provide any did not verify this claim, in consequence the protocol’s secu- security mechanisms at all. AOL only added a protection mechanism similar to S/MIME to their IM service later 1. The name of the App has been changed to SIGNAL in November 2015 on and Trillian’s SECUREIM messenger encrypted the data to be consistant with the iOS App. rity would affect several hundred million users. Despite this OTR’s focus differed significantly from previous message popularity, the messaging protocol behind TEXTSECURE prKGotection mechanisms like OpenPGP and S/MIME by has not been rigorously reviewed so far. While the develop- introducing two novel properties: Perfect Forward Secrecy ers behind TEXTSECURE have a long history of research and Deniability. in computer security, a security assessment is needed to Figure 1 shows how the OTR protocol version 1 works: carefully review the approach. After an initial signed Diffie-Hellman (DH) key exchange, Contribution. In summary, we make the following contri- novel DH shares are exchanged with every message, and the butions: resulting DH key is constantly changed. OTR uses malleable We are the first to completely and precisely docu- encryption [12] in combination with MACs (instead of digi- • ment and analyze TEXTSECURE’s secure push mes- tal signatures). The OTR protocol reveals the MAC keys one saging protocol. Our description was confirmed by round later to the public. This is essential for the deniability the developers of TEXTSECURE. property of the protocol: anyone can change the value of the We show that the main protocol of TEXTSECURE plaintext message, as inverting bits of the ciphertext will • consists of three building blocks: A cached One- result in an inversion of the same bits at the same positions Round Key Exchange (cORKE) protocol, a secure in the plaintext. Thus, the received messages are authentic key derivation function, and authenticated encryp- at the time of reception only (given a party verifies the first tion. We give formal security definitions and security signature and the following MACs). Since the MAC keys proofs for these blocks. are derived as hash values of the encryption keys, revealing We found subtle, but avoidable flaws in the protocol MAC keys does not compromise the security of the former, • that allows for an Unknown Key-Share attack. We and the exchanged messages remain confidential. Private have documented the issues and show how they DH shares xi and yj are deleted as soon as the key kij can be mitigated. They have been communicated to has been computed. This guarantees perfect forward secrecy the developers of TEXTSECURE. We show that our since without these private shares the encryption keys cannot proposed method of mitigation actually solves the be recomputed from the public shares Xi;Yj later. issues. Di Raimondo et al. [13] showed that OTR v1 is vul- We discuss how and to which extent deniability, • nerable to an unknown key-share (UKS) attack (also called perfect forward secrecy (PFS) and future security identity misbinding attack) [14]. We will discuss this kind (FS) are realized. While TEXTSECURE meets PFS of attack in Section 4.2. OTR version 2 did address this and FS, deniability is only achieved partially in issue by introducing a four message handshake that follows practice. the SIGMA protocol paradigm [15], effectively mitigating the UKS attack. Moreover, the protocol achieves deniability: 2. High-level Overview of TextSecure and re- public keys and signatures are exchanged within a con- lated protocols fidential channel, leaving no trace of participation for an eavesdropper. However, these strong capabilities come at the TEXTSECURE was previously compared [10] to the Off- cost of a four-message handshake. the-Record Protocol (OTR) and the Silent Circle Instant Messaging Protocol (SCIMP) [11]. In the following, we OTR and Mobile Messaging. Instant Messaging connec- discuss common elements and differences. tions are typically short-lived and online, whereas text mes- saging conversation may last for prolonged spans of time, a P Pb and parties may be offline temporarily. Additionally, text choose x0 messaging may be asynchronous, such that a sender sends x0 X0 := g (1) X0, σA σA := sign(skA,X0) choose y0 several messages before receiving an answer. y0 Y0 := g (2) Y0, σB choose x1 σB := sign(skB,Y0) The first adaption needed to derive a secure text mes- x1 X1 := g e x0 saging protocol from OTR is to make OTR work in offline k00 := H ((Y0) ) m e k00 := H(k00) e scenarios. The basic idea here is due to ElGamal [16]. Thus c00 := Enc(k00, m00) m (3) X1, c00, mac00 mac00 := MAC(k00, (X1, c00)) choose y1 OTR can be adapted to an offline scenario by storing many y1 Y1 := g e y0 ephemeral DH shares of each party on a server. k10 := H ((X1) ) m e k10 := H(k10) e c10 := Enc(k10, m10) The second adaption concerns key bookkeeping: In (4) Y1, c10, mac10 mac := MAC(km , (Y , c )) choose x2 10 10 1 10 OTR, an ephemeral DH share must be protected by a MAC x2 X2 := g e x1 k11 := H ((Y1) ) computed with a previous key, and must be acknowledged m e k11 := H(k11) c := Enc(ke , m ) by the recipient B before being used by the sender A. 11 11 11 m m (5) X2, c11, mac11, k00 mac11 := MAC(k11, (X2, c11)) . .. This secure chaining of keys through MACs needs a lot of bookkeeping, as well as the acknowledgment. Here, Figure 1: The Off-the-Record protocol. TEXTSECURE adapts to the scenario by replacing MAC chaining by a secret value derived from long-lived (ga; gb) Off-the-Record Protocol.
Load more

Recommended publications
  • Effective Cryptography What’S Wrong with All These Crypto Apis?
    Effective Cryptography What’s Wrong With All These Crypto APIs? Thorsten Groetker, CTO Utimaco, Inc. Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 1 Outline § What I mean by Effective Cryptography § Crypto APIs § Security § Ease of Use § Runtime Performance § Predictions § CryptoScript in a Nutshell § Outlook Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 2 Effective Cryptography Definition in a Nutshell Cryptography is effective if it is Li lingues es membres del sam familie. Lor separat existentie es 1. Secure unJCE/JCA myth. Por scientie, musica , sport etc, litot li sam vocabular. Li lingues differe solmen in li grammaticaOpenSSL, li pronunciation e li pluEVP commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi 2. Efficient far uniform grammaticaPKCS#11, pronunciation e plu sommun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu CAPIsimplic e regulari quam ti del coalescent lingues. Li nov lingua CNG a. Time to Result franca va esser plu simplic e regulari quam li existent Bouncy linguesCastle. I b. Performance What’s wrong with all these crypto APIs? (Focused on Hardware Security Modules) Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 3 Problem #1: Security PKCS#11 § Numerous key extraction attacks known § Jolyon Clulow “On the Security of PKCS#11” § Tookan project (e.g., “Attacking and Fixing PKCS#11 Security Tokens”) § CVE entries (not necessarily sporting “PKCS#11” in the text)
    [Show full text]
  • MASTERCLASS GNUPG MASTERCLASS You Wouldn’T Want Other People Opening Your Letters and BEN EVERARD Your Data Is No Different
    MASTERCLASS GNUPG MASTERCLASS You wouldn’t want other people opening your letters and BEN EVERARD your data is no different. Encrypt it today! SECURE EMAIL WITH GNUPG AND ENIGMAIL Send encrypted emails from your favourite email client. our typical email is about as secure as a The first thing that you need to do is create a key to JOHN LANE postcard, which is good news if you’re a represent your identity in the OpenPGP world. You’d Ygovernment agency. But you wouldn’t use a typically create one key per identity that you have. postcard for most things sent in the post; you’d use a Most people would have one identity, being sealed envelope. Email is no different; you just need themselves as a person. However, some may find an envelope – and it’s called “Encryption”. having separate personal and professional identities Since the early 1990s, the main way to encrypt useful. It’s a personal choice, but starting with a single email has been PGP, which stands for “Pretty Good key will help while you’re learning. Privacy”. It’s a protocol for the secure encryption of Launch Seahorse and click on the large plus-sign email that has since evolved into an open standard icon that’s just below the menu. Select ‘PGP Key’ and called OpenPGP. work your way through the screens that follow to supply your name and email address and then My lovely horse generate the key. The GNU Privacy Guard (GnuPG), is a free, GPL-licensed You can, optionally, use the Advanced Key Options implementation of the OpenPGP standard (there are to add a comment that can help others identify your other implementations, both free and commercial – key and to select the cipher, its strength and set when the PGP name now refers to a commercial product the key should expire.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Symmetric Asynchronous Ratcheted Communication with Associated Data
    Symmetric Asynchronous Ratcheted Communication with Associated Data B Hailun Yan( ) and Serge Vaudenay Ecole´ Polytechnique F´ed´erale de Lausanne (EPFL), Lausanne, Switzerland {hailun.yan,serge.vaudenay}@epfl.ch Abstract. Following up mass surveillance and privacy issues, modern secure communication protocols now seek strong security, such as forward secrecy and post-compromise security, in the face of state exposures. To address this problem, ratcheting was thereby introduced, widely used in real-world messaging protocols like Signal. However, ratcheting comes with a high cost. Recently, Caforio et al. proposed pragmatic construc- tions which compose a weakly secure “light” protocol and a strongly secure “heavy” protocol, in order to achieve the so-called ratcheting on demand. The light protocol they proposed has still a high complexity. In this paper, we prove the security of the lightest possible proto- col we could imagine, which essentially encrypts then hashes the secret key. We prove it without any random oracle by introducing a new secu- rity notion in the standard model. Our protocol composes well with the generic transformation techniques by Caforio et al. to offer high security and performance at the same time. 1 Introduction A classic communication model usually assumes that the endpoints are secure while the adversary is on the communication channel. However, protocols in recent messaging applications are secured with end-to-end encryption due to the prevalence of malware and system vulnerabilities. They attempt to enable secure communication services by regularly updating (ratcheting) the encryption key. One notable example of ratcheting is the Signal protocol [14] by Open Whisper Systems with its double-ratchet algorithm.
    [Show full text]
  • 2012 07 26 Letter to Skype
    ! Privacy International 46 Bedford Row London WC1R 4LR United Kingdom +44 (0) 20 7242 2836 @privacyint UK Charity No. 1147471 Friday, 27 July 2012 Dear Mr Bates, I am writing to request further information about the privacy implications of recent developments at Skype, as reported in the Washington Post.1 We were delighted to read that you believe these reports are “inaccurate” and“could mislead the Skype community”, and that you want to “clear this up”. 2 The growth of Skype since its launch in 2003 to become the world's leading VoIP provider has been driven by service that is affordable, high quality and, above all, secure. From an early stage in its development, Skype has assured its customers of the security of their communications. Press releases and product descriptions from 2005 boast of "end-to-end encryption for superior privacy" that "nobody can intercept".3 In 2008, a spokesperson reassured users that “[w]e have not received any subpoenas or court orders asking us to perform a live interception or wiretap of Skype-to-Skype communications” and “[i]n any event, because of Skype's peer-to-peer architecture and encryption techniques, Skype would not be able to comply with such a request”.4 In short, a promise was made to Skype customers that the privacy of their conversations and file transfers would be protected. As I'm sure you know, among Skype's 663 million registered users across the world are human rights defenders and pro-democracy activists living under autocratic regimes. In an environment where most channels of communication
    [Show full text]
  • Biting Into Forbidden Fruit
    Biting into the forbidden fruit Lessons from trusting Javascript crypto Krzysztof Kotowicz, OWASP Appsec EU, June 2014 About me • Web security researcher • HTML5 • UI redressing • browser extensions • crypto • I was a Penetration Tester @ Cure53 • Information Security Engineer @ Google Disclaimer: “My opinions are mine. Not Google’s”. Disclaimer: All the vulns are fixed or have been publicly disclosed in the past. Introduction JS crypto history • Javascript Cryptography Considered Harmful http://matasano.com/articles/javascript- cryptography/ • Final post on Javascript crypto http://rdist.root.org/2010/11/29/final-post-on- javascript-crypto/ JS crypto history • Implicit trust in the server to deliver the code • SSL/TLS is needed anyway • Any XSS can circumvent the code • Poor library quality • Poor crypto support • No secure keystore • JS crypto is doomed to fail Doomed to fail? Multiple crypto primitives libraries, symmetric & asymmetric encryption, TLS implementation, a few OpenPGP implementations, and a lot of user applications built upon them. Plus custom crypto protocols. https://crypto.cat/ https://www.mailvelope.com/ http://openpgpjs.org/ JS crypto is a fact • Understand it • Look at the code • Find the vulnerabilities • Analyze them • Understand the limitations and workarounds • Answer the question: can it be safe? JS crypto vulns in the wild • Language issues • Caused by a flaw of the language • Web platform issues • Cased by the web • Other standard bugs • out of scope for this presentation Language issues Language issues matter
    [Show full text]
  • Microsoft Skype for Business Deployment Guide
    Microsoft Skype for Business Deployment Guide Multimedia Connector for Skype for Business 8.5.0 3/8/2020 Table of Contents Multimedia Connector for Skype for Business Deployment Guide 4 Architecture 6 Paired Front End Pools 9 Federation Platform with Microsoft Office 365 Cloud 12 Managing T-Server and UCMA Connectors 14 Prerequisites 16 Provisioning for UCMA Connectors 22 Using Telephony Objects 24 Managing UCMA Connectors 28 Managing T-Server 33 Upgrading Multimedia Connector for Skype For Business 36 Configuring Skype for Business Application Endpoints 37 Configuring Skype for Business User Endpoints 38 High-Availability Deployment 39 Performance 45 Managing Workspace Plugin for Skype for Business 46 Using Workspace Plugin for Skype for Business 51 Handling IM Transcripts 60 Supported Features 61 Alternate Routing 62 Call Monitoring 63 Call Supervision 64 Calling using Back-to-Back User Agent 70 Conference Resource Pools 77 Disable Lobby Bypass 80 Emulated Agents 82 Emulated Ringing 85 Handling Direct Calls 86 Handling Pass-Through Calls 89 Hiding Sensitive Data 91 IM Treatments 93 IM Suppression 94 Music On Hold 97 No-Answer Supervision 98 Presence 99 Remote Recording 103 Remote Treatments 110 Transport Layer Security 112 UTF-8 Encoding 114 Supported Media Types 116 T-Library Functionality 120 Attribute Extensions 124 Hardware Sizing Guidelines and Capacity Planning 130 Error Messages 132 Known Limitations and Workarounds 134 Multimedia Connector for Skype for Business Deployment Guide Multimedia Connector for Skype for Business Deployment Guide Welcome to the Multimedia Connector for Skype for Business Deployment Guide. This Deployment Guide provides deployment procedures and detailed reference information about the Multimedia Connector for Skype for Business as a product, and its components: T-Server, UCMA Connector, and Workspace Plugin.
    [Show full text]
  • Horizontal PDF Slides
    1 2 The first 10 years of Curve25519 Abstract: “This paper explains the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done. free key compression, free key validation, and state-of-the-art 2005.09.15: Software online. timing-attack protection), 2005.09.20: Invited talk at ECC. more than twice as fast as other authors’ results at the same 2005.11.15: Paper online; conjectured security level (with submitted to PKC 2006. or without the side benefits).” 1 2 3 The first 10 years of Curve25519 Abstract: “This paper explains Elliptic-curve computations the design and implementation Daniel J. Bernstein of a high-security elliptic-curve- University of Illinois at Chicago & Diffie-Hellman function Technische Universiteit Eindhoven achieving record-setting speeds: e.g., 832457 Pentium III cycles 2005.05.19: Seminar talk; (with several side benefits: design+software close to done.
    [Show full text]
  • A History of End-To-End Encryption and the Death of PGP
    25/05/2020 A history of end-to-end encryption and the death of PGP Hey! I'm David, a security engineer at the Blockchain team of Facebook (https://facebook.com/), previously a security consultant for the Cryptography Services of NCC Group (https://www.nccgroup.com). I'm also the author of the Real World Cryptography book (https://www.manning.com/books/real-world- cryptography?a_aid=Realworldcrypto&a_bid=ad500e09). This is my blog about cryptography and security and other related topics that I Ûnd interesting. A history of end-to-end encryption and If you don't know where to start, you might want to check these popular the death of PGP articles: posted January 2020 - How did length extension attacks made it 1981 - RFC 788 - Simple Mail Transfer Protocol into SHA-2? (/article/417/how-did-length- extension-attacks-made-it-into-sha-2/) (https://tools.ietf.org/html/rfc788) (SMTP) is published, - Speed and Cryptography the standard for email is born. (/article/468/speed-and-cryptography/) - What is the BLS signature scheme? (/article/472/what-is-the-bls-signature- This is were everything starts, we now have an open peer-to-peer scheme/) protocol that everyone on the internet can use to communicate. - Zero'ing memory, compiler optimizations and memset_s (/article/419/zeroing-memory- compiler-optimizations-and-memset_s/) 1991 - The 9 Lives of Bleichenbacher's CAT: New Cache ATtacks on TLS Implementations The US government introduces the 1991 Senate Bill 266, (/article/461/the-9-lives-of-bleichenbachers- which attempts to allow "the Government to obtain the cat-new-cache-attacks-on-tls- plain text contents of voice, data, and other implementations/) - How to Backdoor Di¸e-Hellman: quick communications when appropriately authorized by law" explanation (/article/360/how-to-backdoor- from "providers of electronic communications services di¸e-hellman-quick-explanation/) and manufacturers of electronic communications - Tamarin Prover Introduction (/article/404/tamarin-prover-introduction/) service equipment".
    [Show full text]
  • Ipv6-Ipsec And
    IPSec and SSL Virtual Private Networks ITU/APNIC/MICT IPv6 Security Workshop 23rd – 27th May 2016 Bangkok Last updated 29 June 2014 1 Acknowledgment p Content sourced from n Merike Kaeo of Double Shot Security n Contact: [email protected] Virtual Private Networks p Creates a secure tunnel over a public network p Any VPN is not automagically secure n You need to add security functionality to create secure VPNs n That means using firewalls for access control n And probably IPsec or SSL/TLS for confidentiality and data origin authentication 3 VPN Protocols p IPsec (Internet Protocol Security) n Open standard for VPN implementation n Operates on the network layer Other VPN Implementations p MPLS VPN n Used for large and small enterprises n Pseudowire, VPLS, VPRN p GRE Tunnel n Packet encapsulation protocol developed by Cisco n Not encrypted n Implemented with IPsec p L2TP IPsec n Uses L2TP protocol n Usually implemented along with IPsec n IPsec provides the secure channel, while L2TP provides the tunnel What is IPSec? Internet IPSec p IETF standard that enables encrypted communication between peers: n Consists of open standards for securing private communications n Network layer encryption ensuring data confidentiality, integrity, and authentication n Scales from small to very large networks What Does IPsec Provide ? p Confidentiality….many algorithms to choose from p Data integrity and source authentication n Data “signed” by sender and “signature” verified by the recipient n Modification of data can be detected by signature “verification”
    [Show full text]
  • IM Security Documentation on Page Vi
    Trend Micro Incorporated reserves the right to make changes to this document and to the product described herein without notice. Before installing and using the product, review the readme files, release notes, and/or the latest version of the applicable documentation, which are available from the Trend Micro website at: http://docs.trendmicro.com/en-us/enterprise/trend-micro-im-security.aspx Trend Micro, the Trend Micro t-ball logo, Control Manager, MacroTrap, and TrendLabs are trademarks or registered trademarks of Trend Micro Incorporated. All other product or company names may be trademarks or registered trademarks of their owners. Copyright © 2016. Trend Micro Incorporated. All rights reserved. Document Part No.: TIEM16347/140311 Release Date: September 2016 Protected by U.S. Patent No.: Pending This documentation introduces the main features of the product and/or provides installation instructions for a production environment. Read through the documentation before installing or using the product. Detailed information about how to use specific features within the product may be available at the Trend Micro Online Help Center and/or the Trend Micro Knowledge Base. Trend Micro always seeks to improve its documentation. If you have questions, comments, or suggestions about this or any Trend Micro document, please contact us at [email protected]. Evaluate this documentation on the following site: http://www.trendmicro.com/download/documentation/rating.asp Privacy and Personal Data Collection Disclosure Certain features available in Trend Micro products collect and send feedback regarding product usage and detection information to Trend Micro. Some of this data is considered personal in certain jurisdictions and under certain regulations.
    [Show full text]
  • 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
    [Show full text]