DOCSLIB.ORG

Attacks to the Ssl Protocol Authors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Attacks to the Ssl Protocol Authors VIDEO Intypedia010en LESSON 10: ATTACKS TO THE SSL PROTOCOL AUTHORS: D. Luciano Bello and PhD. Alfonso Muñoz R&D Security Researcher (Chalmers University) R&D Security Researcher. T>SIC Group – UPM ALICE Hello and welcome to Intypedia. In previous lessons we learned the basics of the SSL protocol. Today we will delve into this protocol and see some real attacks to it and how to mitigate them. Join us! SCENE 1. IS SSL SECURE? ALICE Hello, Bob. In previous lessons we learned the basics of cryptography. We also learned how cryptography is implemented in algorithms and widely used protocols, like the SSL protocol we studied in lesson 9. However, sometimes there are news of attacks to such protocols and since SSL is a protocol widely used on the Internet, it's particularly interesting to study it. BOB Alice, don't trust everything that is published, I think that SSL is very secure and reliable. ALICE I agree with you. SSL is inherently secure because the protocols it uses are based on strong and mature theories. But even so, there are still many things that might become a problem. First of all, there’s complexity which is usually detrimental to usability. In addition, there might be programming bugs in the implementations. Furthermore, new techniques of cryptanalysis can be developed, making some protocols less secure than expected. This, added to the fact that Script Intypedia010en 1 the computing power of attackers is increasing according to Moore's Law, makes older versions of SSL insecure, stressing the need to review the protocols. BOB Wait... So you're telling me that SSL isn’t that secure? ALICE Don't stress out, Bob. SSL is secure in its theoretical design. But this is a necessary, although insufficient condition. Nowadays, the use of this protocol is crucial in e-commerce between clients (users) and suppliers of products. Its use is common in many transactions, such as buying a book on a Web store or in online banking. Although SSL has other uses, as we saw in the previous lesson, it is widely known for its use on the Web. Using SSL adequately will minimize attacks: not only classic ones like the man-in-the-middle attack against exchanged information, but also spoofing attacks in the access to social networks. Nonetheless, we must give an exact account of the "real security" of the SSL protocol. For example, its use on the Web goes far beyond the misconception that a page is secure if, and only if, it shows the famous "yellow padlock". To get an idea of what we're talking about, we will analyse some of the attacks this protocol has suffered in recent years and finish with some practical advice for a proper use. BOB Sounds like a great idea. Please continue, Alice. SCENE 2. PROGRAMMING ERRORS IN IMPLEMENTATIONS. CRYPTANALYSIS AND DOWNGRADE. ALICE Programming errors often cause really severe problems. One of the most famous attacks on SSL was the vulnerability announced in May 2008. The Argentinean researcher Luciano Bello discovered that random functions used in OpenSSL/Debian had been implemented incorrectly. This produced predictable "random" material that made it easier to reverse cryptographic processes. As a result, X.509 certificates, SSH keys and even encrypted material were exposed. BOB Yes... I remember vaguely. One implication was that private keys could be reconstructed from the distributed public keys. Without random cryptographic functions, cryptosystems were defenceless. ALICE Indeed, it was a specific problem that in the end got solved. However, to those implementation issues we must add the increasing computing capacity of attackers and the development of Script Intypedia010en 2 cryptanalysis. These factors could simplify the creation of false custom-made digital certificates. An example of this can be found in the results published by the 25th edition of the Chaos Communication Congress held in Berlin in December 2008. Researchers created a "valid" SSL certificate taking advantage of the emission particularities of certain certification authorities, a collision attack to the MD5 cryptographic algorithm and the huge computing capacity of one hundred PlayStations. It is true that MD5 is no longer used by certification authorities to calculate the hash of a certificate signed with a private key, but the current standard SHA-1 is also starting to encounter similar problems to those of its counterpart. This is a great example to justify why the cryptographic algorithms used in SSL are reviewed and updated by the scientific community. The use of older versions of the protocol should be avoided wherever possible, especially protocol downgrades forced by attackers. BOB Do you know of any other type of attack? ALICE Yes, another interesting attack was discovered by the researcher Moxie Marlinspike. When creating an SSL certificate and sending it to a certification authority to get it signed, the field that often gets more attention is CN (Common Name) which specifies the server name, like www.example.org. Moxie Marlinspike discovered that the standards for SSL and the X.509 certificate define the CN string as a PASCAL string (the length of the string is declared in position 0 and the chain is inserted in the other positions). Interestingly, most certificate processing software is written in C. Such software usually handles the string as a C string, inserting a NULL (\0) at the end of the string to indicate where it ends. The problem comes when someone obtains a certificate using www.realbank.com\0www.atacker.org. When processed by a browser, only the first part will be read (www.realbank.com), making it easy to falsify the bank. The easiest solution to this problem is for certification authorities to reject all certificates containing the NULL character. When fraudulent certificates are detected, they are usually revoked by the serial number included and, for this, the OCSP (Online Certificate Status Protocol) is usually used. Again, an incorrect configuration of the OCSP would allow attacks to the SSL protocol. BOB Excuse me, Alice; I think it would be interesting to define how to attack the OCSP. ALICE You're right. The Online Certificate Status Protocol is used to check online if a particular digital certificate has been revoked or not. For this, the client sends the request to the address of the Certificate Revocation List (CRL), which is included in the digital certificate. If an attacker is Script Intypedia010en 3 performing the man-in-the-middle attack to use one of these digital certificates, then they can intercept the OCSP requests and use them to their advantage. In a normal operation, a server using this protocol could send a Try Later response telling the client that it can't answer a request. The attacker could simulate this response, which has code 3 assigned, to tell the client that it is unable to attend its request at that moment. Given this situation, many Web clients will accept the digital certificate since they can't verify its validity. This is an obvious failure. BOB Alice, are you saying that it's easy to fool a system when the user accesses via https? ALICE Not only that. While many problems can be mitigated by updating our software, there is an element of the system that is very difficult to upgrade: the user. SCENE 3. TRICKING THE USER. SSL VULNERABILITY ON THE WEB. ALICE In practice, the easiest way to breach the security provided by SSL/TLS is to trick users into thinking they are using it when they actually aren't. BOB I would say that isn't possible, Alice. When I connect to my bank safely, I can see the yellow padlock in my browser, which tells me that the access to the site is secure and that the digital certificate that authenticates my bank has been properly validated. ALICE Unfortunately, Bob, that was a bad way to educate non-technical personnel on how to corroborate if a SSL protocol was being used. The truth is that many other conditions, which I will let you know shortly, must be considered. BOB Wait a minute. I know that if my computer has been compromised by a Trojan, for instance, it could be hoaxed to show a yellow padlock in the web browser implying that SSL encryption is being used when in fact it isn’t. ALICE Well, Bob, if you really have a Trojan in your computer, it could have total control and be able, not only to trick you, but to capture your passwords, redirect your data or authentication traffic and so on. But, possibly, the most interesting attacks are those that don't have internal access Script Intypedia010en 4 to your computer, like man-in-the-middle attacks whose main objective is to intercept a communication between client and server and view or alter the information in transit. BOB What if I connect to a page via https, is that possible? ALICE It depends on the complexity of the attack. Some may be solved with minimal training of the user; while other much more sophisticated attacks would be hardly detectable. The simplest example of a man-in-the-middle attack is to create a false digital certificate. That is, when a user connects via https to their online bank, the attacker connects between the two of them and sends their certificate to the client posing as the bank. The web browser detects that the digital certificate isn’t recognized and prompts the user whether they want to accept the connection. Most users with no security training will accept, so the attacker will be in the middle and will be able to do as they please with the data in transit, as well as the captured keys.
Load more

Recommended publications
  • The Double Ratchet Algorithm
    The Double Ratchet Algorithm Trevor Perrin (editor) Moxie Marlinspike Revision 1, 2016-11-20 Contents 1. Introduction 3 2. Overview 3 2.1. KDF chains . 3 2.2. Symmetric-key ratchet . 5 2.3. Diffie-Hellman ratchet . 6 2.4. Double Ratchet . 13 2.6. Out-of-order messages . 17 3. Double Ratchet 18 3.1. External functions . 18 3.2. State variables . 19 3.3. Initialization . 19 3.4. Encrypting messages . 20 3.5. Decrypting messages . 20 4. Double Ratchet with header encryption 22 4.1. Overview . 22 4.2. External functions . 26 4.3. State variables . 26 4.4. Initialization . 26 4.5. Encrypting messages . 27 4.6. Decrypting messages . 28 5. Implementation considerations 29 5.1. Integration with X3DH . 29 5.2. Recommended cryptographic algorithms . 30 6. Security considerations 31 6.1. Secure deletion . 31 6.2. Recovery from compromise . 31 6.3. Cryptanalysis and ratchet public keys . 31 1 6.4. Deletion of skipped message keys . 32 6.5. Deferring new ratchet key generation . 32 6.6. Truncating authentication tags . 32 6.7. Implementation fingerprinting . 32 7. IPR 33 8. Acknowledgements 33 9. References 33 2 1. Introduction The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key. Typically the parties will use some key agreement protocol (such as X3DH [1]) to agree on the shared secret key. Following this, the parties will use the Double Ratchet to send and receive encrypted messages. The parties derive new keys for every Double Ratchet message so that earlier keys cannot be calculated from later ones.
    [Show full text]
  • Security Analysis of the Signal Protocol Student: Bc
    ASSIGNMENT OF MASTER’S THESIS Title: Security Analysis of the Signal Protocol Student: Bc. Jan Rubín Supervisor: Ing. Josef Kokeš Study Programme: Informatics Study Branch: Computer Security Department: Department of Computer Systems Validity: Until the end of summer semester 2018/19 Instructions 1) Research the current instant messaging protocols, describe their properties, with a particular focus on security. 2) Describe the Signal protocol in detail, its usage, structure, and functionality. 3) Select parts of the protocol with a potential for security vulnerabilities. 4) Analyze these parts, particularly the adherence of their code to their documentation. 5) Discuss your findings. Formulate recommendations for the users. References Will be provided by the supervisor. prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague January 27, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Computer Systems Master’s thesis Security Analysis of the Signal Protocol Bc. Jan Rub´ın Supervisor: Ing. Josef Kokeˇs 1st May 2018 Acknowledgements First and foremost, I would like to express my sincere gratitude to my thesis supervisor, Ing. Josef Kokeˇs,for his guidance, engagement, extensive know- ledge, and willingness to meet at our countless consultations. I would also like to thank my brother, Tom´aˇsRub´ın,for proofreading my thesis. I cannot express enough gratitude towards my parents, Lenka and Jaroslav Rub´ınovi, who supported me both morally and financially through my whole studies. Last but not least, this thesis would not be possible without Anna who re- lentlessly supported me when I needed it most. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis.
    [Show full text]
  • SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell Secureworks Counter Threat Unit℠ Threat Intelligence
    SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell SecureWorks Counter Threat Unit℠ Threat Intelligence Presented at Black Hat Europe – March 14, 2012. Introduction Secure Sockets Layer (SSL) [1] and its successor Transport Layer Security (TLS) [2] have become key components of the modern Internet. The privacy, integrity, and authenticity [3] [4] provided by these protocols are critical to allowing sensitive communications to occur. Without these systems, e- commerce, online banking, and business-to-business exchange of information would likely be far less frequent. Threat actors have also recognized the benefits of transport security, and they are increasingly turning to SSL to hide their activities. Advanced Persistent Threat (APT) attackers [5], botnets [6], and even commodity web attacks can leverage SSL encryption to evade detection. To counter these tactics, organizations are increasingly deploying security controls that intercept end- to-end encrypted channels. Web proxies, data loss prevention (DLP) systems, specialized threat detection solutions, and network intrusion prevention systems (NIPS) offer functionality to intercept, inspect, and filter encrypted traffic. Similar functionality is present in lawful intercept systems and solutions enabling the broad surveillance of encrypted communications by governments. Broadly classified as “SSL/TLS interception proxies,” these solutions act as a “man in the middle,” violating the end-to-end security promises of SSL. This type of interception comes at a cost. Intercepting SSL-encrypted connections sacrifices a degree of privacy and integrity for the benefit of content inspection, often at the risk of authenticity and endpoint validation. Implementers and designers of SSL interception proxies should consider these risks and understand how their systems operate in unusual circumstances.
    [Show full text]
  • Is Bob Sending Mixed Signals?
    Is Bob Sending Mixed Signals? Michael Schliep Ian Kariniemi Nicholas Hopper University of Minnesota University of Minnesota University of Minnesota [email protected] [email protected] [email protected] ABSTRACT Demand for end-to-end secure messaging has been growing rapidly and companies have responded by releasing applications that imple- ment end-to-end secure messaging protocols. Signal and protocols based on Signal dominate the secure messaging applications. In this work we analyze conversational security properties provided by the Signal Android application against a variety of real world ad- versaries. We identify vulnerabilities that allow the Signal server to learn the contents of attachments, undetectably re-order and drop messages, and add and drop participants from group conversations. We then perform proof-of-concept attacks against the application to demonstrate the practicality of these vulnerabilities, and suggest mitigations that can detect our attacks. The main conclusion of our work is that we need to consider more than confidentiality and integrity of messages when designing future protocols. We also stress that protocols must protect against compromised servers and at a minimum implement a trust but verify model. 1 INTRODUCTION (a) Alice’s view of the conversa-(b) Bob’s view of the conversa- Recently many software developers and companies have been inte- tion. tion. grating end-to-end encrypted messaging protocols into their chat applications. Some applications implement a proprietary protocol, Figure 1: Speaker inconsistency in a conversation. such as Apple iMessage [1]; others, such as Cryptocat [7], imple- ment XMPP OMEMO [17]; but most implement the Signal protocol or a protocol based on Signal, including Open Whisper Systems’ caching.
    [Show full text]
  • The Most Dangerous Code in the World: Validating SSL Certificates In
    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software Martin Georgiev Subodh Iyengar Suman Jana The University of Texas Stanford University The University of Texas at Austin at Austin Rishita Anubhai Dan Boneh Vitaly Shmatikov Stanford University Stanford University The University of Texas at Austin ABSTRACT cations. The main purpose of SSL is to provide end-to-end security SSL (Secure Sockets Layer) is the de facto standard for secure In- against an active, man-in-the-middle attacker. Even if the network ternet communications. Security of SSL connections against an is completely compromised—DNS is poisoned, access points and active network attacker depends on correctly validating public-key routers are controlled by the adversary, etc.—SSL is intended to certificates presented when the connection is established. guarantee confidentiality, authenticity, and integrity for communi- We demonstrate that SSL certificate validation is completely bro- cations between the client and the server. Authenticating the server is a critical part of SSL connection es- ken in many security-critical applications and libraries. Vulnerable 1 software includes Amazon’s EC2 Java library and all cloud clients tablishment. This authentication takes place during the SSL hand- based on it; Amazon’s and PayPal’s merchant SDKs responsible shake, when the server presents its public-key certificate. In order for transmitting payment details from e-commerce sites to payment for the SSL connection to be secure, the client must carefully verify gateways; integrated shopping carts such as osCommerce, ZenCart, that the certificate has been issued by a valid certificate authority, Ubercart, and PrestaShop; AdMob code used by mobile websites; has not expired (or been revoked), the name(s) listed in the certifi- Chase mobile banking and several other Android apps and libraries; cate match(es) the name of the domain that the client is connecting Java Web-services middleware—including Apache Axis, Axis 2, to, and perform several other checks [14, 15].
    [Show full text]
  • The Bad-Attitude Guide to Computer Security
    The Bad-Attitude Guide to Computer Security Keith Winstein Stanford University https://cs.stanford.edu/~keithw Bad (-attitude?) advice 1. 2. 3. 4. 5. 6. 7. 8. Bad (-attitude?) advice 1. Do build your own cryptographic protocol. 2. 3. 4. 5. 6. 7. 8. Mosh (mobile shell) Mosh deployment I Impetus: SSH for bad Wi-Fi I + intermittent connectivity I + roaming I + local echo I + security against forged RST I First release: 2012 I Today: appx. 2{20 million users Mosh protocol I Every datagram wrapped with AES-OCB I Every datagram represents idempotent operation I No TLS, no DTLS, no public-key crypto I No timestamps, no replay cache, no daemon I No cipher negotiation, no file IO, no root I Roaming: server replies to source address of highest-numbered authentic incoming datagram Hacker News \One man band by the looks of it. Implements its own private crypto protocol (has it been vetted for replay attacks? padding attacks? [insert 20 years of perplexing bugs confounding the greatest minds in computer science]?)" Slashdot \Welcome to Yet Another Protocol Devised By Academics Who Have Not Been Near a Real Network in Twenty Years, If Ever." Twitter Dan Kaminsky: \Mosh being outside of SSH Transport makes academic perf code unauthenticated. Love MoSH, would love it much more if it operated inside SSH's channel" Q: \any particular reason? Since quick recovery from packetloss is one of its main goals, UDP+OCB is needed." Kaminsky: \It's *tricky* to build new secure channels. Look at DTLS's long and painful dev cycle." Twitter (cont.) Moxie Marlinspike: \I dunno, from a semantic sec perspective, it'd be hard to do worse than SSH.
    [Show full text]
  • Multi-Device Secure Instant Messaging
    SoK: Multi-Device Secure Instant Messaging Antonio Dimeo, Felix Gohla, Daniel Goßen, Niko Lockenvitz {antonio.dimeo, felix.gohla, daniel.gossen, niko.lockenvitz}@student.hpi.de Hasso Plattner Institute, University of Potsdam April 17, 2021 Abstract The secure multi-device instant messaging ecosystem is diverse, varied, and under- represented in academia. We create a systematization of knowledge which focuses on the challenges of multi-device messaging in a secure context and give an overview of the current situation in the multi-device setting. For that, we analyze messenger documentation, white papers, and research that deals with multi-device messaging. This includes a detailed description of different patterns for data transfer between devices as well as device management, i.e. how clients are cryptographically linked or unlinked to or from an account and how the initial setup can be implemented. We then evaluate different instant messengers with regard to relevant criteria, e.g. whether they achieve specific security, usability, and privacy goals. In the end, we outline interesting areas for future research. Contents 1 Introduction3 1.1 Group Messaging vs. Multi-Device Messaging............... 4 1.2 Methodology.................................. 4 2 Multi-Device Messaging7 2.1 Context...................................... 7 2.2 Transferring Data Between Different Devices of One User........ 7 2.2.1 Storing Data on a Server........................ 8 2.2.2 Using Messages to Exchange Data.................. 9 2.3 Transferring Data to a Different User..................... 11 2.3.1 Without End-to-end Encryption................... 11 2.3.2 End-to-end Encryption With Shared Group Key.......... 13 2.3.3 End-to-end Encryption Per Recipient...............
    [Show full text]
  • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
    Case 2:16-cv-02340-AB-PJW Document 1 Filed 04/06/16 Page 1 of 9 Page ID #:1 1 QUINN EMANUEL URQUHART & SULLIVAN, LLP Bruce E. Van Dalsem (Bar No. 124128) 2 ([email protected]) Daniel C. Posner (Bar No. 232009) 3 ([email protected]) Alex Bergjans (Bar No. 302830) 4 ([email protected]) 865 South Figueroa Street, 10th Floor 5 Los Angeles, California 90017-2543 Telephone: (213) 443-3000 6 Facsimile: (213) 443-3100 7 Attorneys for Plaintiff Wire Swiss GmbH 8 9 UNITED STATES DISTRICT COURT 10 CENTRAL DISTRICT OF CALIFORNIA 11 12 WIRE SWISS GmbH , a Swiss CASE NO. 2:16 -cv -2340 corporation; 13 Plaintiff, COMPLAINT FOR 14 DECLARATORY JUDGMENT OF v. NON -INFRINGEMENT; EXTORTION 15 QUIET RIDDLE VENTURES, LLC 16 d/b/a OPEN WHISPER SYSTEMS; DEMAND FOR JURY TRIAL and MOXIE MARLINSPIKE aka 17 MATTHEW ROSENFELD and/or MIKE BENHAM, an individual, 18 Defendants. 19 20 21 22 23 24 25 26 27 28 COMPLAINT Case 2:16-cv-02340-AB-PJW Document 1 Filed 04/06/16 Page 2 of 9 Page ID #:2 1 Plaintiff Wire Swiss GmbH (“Wire Swiss”) alleges against defendants Quiet 2 Riddle Ventures LLC dba Open Whisper Systems (“Open Whisper Systems”) and 3 Moxie Marlinspike, aka Matthew Rosenfield and/or Mike Benham (“Marlinspike,” 4 and collectively with Open Whisper Systems, “Defendants”), as follows: 5 NATURE OF THE ACTION 6 1. This is an action for a declaratory judgment of non-infringement of 7 copyright. As alleged in further detail below, Defendants claim copyright in certain 8 open-source software code used for encrypting data communications.
    [Show full text]
  • Clone Detection in Secure Messaging: Improving Post-Compromise Security in Practice
    Clone Detection in Secure Messaging: Improving Post-Compromise Security in Practice Cas Cremers Jaiden Fairoze CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Saarbrücken, Germany Saarbrücken, Germany [email protected] [email protected] Benjamin Kiesl Aurora Naska CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security Saarbrücken, Germany Saarbrücken, Germany [email protected] [email protected] ABSTRACT Practice . In Proceedings of the 2020 ACM SIGSAC Conference on Computer and We investigate whether modern messaging apps achieve the strong Communications Security (CCS ’20), November 9–13, 2020, Virtual Event, USA. post-compromise security guarantees offered by their underlying ACM, New York, NY, USA, 15 pages. https://doi.org/10.1145/3372297.3423354 protocols. In particular, we perform a black-box experiment in which a user becomes the victim of a clone attack; in this attack, the user’s full state (including identity keys) is compromised by 1 INTRODUCTION an attacker who clones their device and then later attempts to The advent of modern secure messaging, and the widespread de- impersonate them, using the app through its user interface. ployment of the Signal protocol library in particular, has brought Our attack should be prevented by protocols that offer post- modern security mechanisms to millions of users. Specifically, this compromise security, and thus, by all apps that are based on Signal’s includes the double-ratchet algorithm [23] and the security prop- double-ratchet algorithm (for instance, the Signal app, WhatsApp, erties it can provide, such as post-compromise security [6], which and Facebook Secret Conversations).
    [Show full text]
  • More Tricks for Defeating SSL in Practice
    More Tricks For Defeating SSL In Practice Moxie Marlinspike [email protected] Moxie Marlinspike Institute For Disruptive Studies Moxie Marlinspike Institute For Disruptive Studies Once Again, The Back Story... Moxie Marlinspike Institute For Disruptive Studies In the past, I've talked about BasicConstraints... Moxie Marlinspike Institute For Disruptive Studies Certificate Chaining VeriSign Intermediate CA paypal.com Moxie Marlinspike Institute For Disruptive Studies Certificate Chaining VeriSign Intermediate CA Intermediate CA paypal.com Moxie Marlinspike Institute For Disruptive Studies How do we verify these things? Moxie Marlinspike Institute For Disruptive Studies What they say: ● Verify that the name of the leaf node is the same as the site you're connecting to. ● Verify that the leaf certificate has not expired. ● Check the signature. ● If the signing CA is in our list of trusted root CAs, stop. Otherwise, move one up the chain and repeat. Moxie Marlinspike Institute For Disruptive Studies Here Be Dragons ● Very tempting to use a simple recursive function. ● Everyone focuses on the signature validation. ● The result of a naïve attempt at validation is a chain that is complete, but nothing more. Moxie Marlinspike Institute For Disruptive Studies What if... VeriSign Intermediate CA Intermediate CA thoughtcrime .org Moxie Marlinspike Institute For Disruptive Studies What if... VeriSign Intermediate CA Intermediate CA thoughtcrime .org paypal.com Moxie Marlinspike Institute For Disruptive Studies What they say: ● Verify that the name of the leaf node is the same as the site you're connecting to. ● Verify that the leaf certificate has not expired. ● Check the signature. ● If the signing CA is in our list of trusted root CAs, stop.
    [Show full text]
  • On the End-To-End Security of Group Chats in Instant Messaging Protocols
    On the End-to-End Security of Group Chats in In- stant Messaging Protocols Paul Rösler Master’s Thesis – December 6, 2018. Chair for Network and Data Security. 1st Supervisor: Prof. Dr. Jörg Schwenk 2nd Supervisor: Prof. Dr. Tibor Jager 1st Advisor: Prof. Dr. Jörg Schwenk 2nd Advisor: Dr. Christian Mainka Acknowledgments The reason for finishing my master thesis more than half a year later than it was planned, is my enthusiasms for doing (new) research. I am grateful to the ones who supported me in gaining the opportunity to do research. At first I want to thank my colleges Martin and Christian, who introduced me to my supervisor Jörg. Then I want to thank Jörg for providing a liberal environment of self-responsibility that allows me to explore many interesting areas of cryptography and IT security. I am also thankful to Christian and Jörg for starting my PhD studies with a collaboration that resulted in this thesis. Furthermore I want to thank my second supervisor Eike for introducing me to (other researchers but especially to) Bertram from whom I learned to be precise and formal in my work. Also I want to thank all my colleges (especially my office neighbor Robert) for jointly enabling a friendly and welcoming office atmosphere. Then I thank the best learning group one could think of for having wonderful six years of studies (and much more). I honestly hope that we maintain our friendship. Finally I thank my whole family and my girlfriend Nadine for always supporting me mentally and – if necessary – letting me work long hours.
    [Show full text]
  • HUNTING for VULNERABILITIES in SIGNAL JP Aumasson & Markus Vervier
    HUNTING FOR VULNERABILITIES IN SIGNAL JP Aumasson & Markus Vervier 1 WHOIS JP (@veorq) Principal researcher @ Kudelski Security Speaks French Crypto guy Markus (@marver) Head of research @ x41 D-Sec Speaks German Not CISSP 2 PROPS This BH US 2016 boring talk Open Whisper Systems Eric Sesterhenn Hanno Boeck 3 AGENDA Signal internals, security promises Attack surface and liabilities Bugs, alternative features, and demos Conclusions 4 SIGNAL 5 THE SIGNAL APPS Mobile apps for messaging & audio/video calls By Open Whisper Systems (Moxie Marlinspike et al.) Formerly known as "TextSecure", "RedPhone" Android, iOS, and Chrome Desktop app 6 TRUSTED TOOL Endorsed by Snowden and other opinion leaders Popular among activists in the US and abroad Minimal data collection from Signal servers 7 SECURITY PROMISES Solid end-to-end encryption, defending against Active network attackers Client and server compromises Traffic analysis (partially) High assurance software, with Code perceived as high-quality No major security issue ever Reproducible Android builds 8 SIGNAL IS MORE THAN SIGNAL Core crypto "libsignal" licensed to and integrated in Facebook Messenger's "Secret Conversations" mode Facebook WhatsApp default encryption Google Allo's "Incognito" mode 9 10 KEY AGREEMENT: X3DH Combines 4 key pairs: long-term and ephemeral One-time prekeys trick, to simulate online-ness Forward-secret, resilient to malicious servers Out-of-band identity verification necessary 11 SESSION KEYS: DOUBLE RATCHET Protocol to compute message-unique keys: New Diffie-Hellman for every first message from a party "Key := Hash(Key)" for consecutive messages Past and future messages safe if present key known Attachments have identical protection 12 THE "SIGNAL PROTOCOL" = X3DH and double ratchet as implemented in Signal (Moxie Marlinspike, [email protected] ML, 30.11.16) 13 WAIT – WAS THAT ALL? 14 UNSPECIFIED a.k.a.
    [Show full text]