Keeping Connected When the Mobile Social Network Goes Offline

Keeping Connected When the Mobile Social Network Goes Offline

Øystein Løkken Sigholt Keeping Connected When the Mobile Social Network Goes Offline Master’s thesis in Communication Technology Supervisor: Besmir Tola June 2019 Master’s thesis Master’s NTNU Engineering Communication Technology Communication Department of Information Security and Department of Information Faculty of Information Technology and Electrical Technology of Information Faculty Norwegian University of Science and Technology of Science University Norwegian Øystein Løkken Sigholt Keeping Connected When the Mobile Social Network Goes Offline Master’s thesis in Communication Technology Supervisor: Besmir Tola June 2019 Norwegian University of Science and Technology Faculty of Information Technology and Electrical Engineering Department of Information Security and Communication Technology Title: Keeping Connected When the Mobile Social Network Goes Offline Student: Øystein Løkken Sigholt Problem description: Smartphone users today are used to being connected at all times. At the same time, there are vast amounts of remote areas that are without cell coverage. In addition, natural disasters may cause Internet connectivity outages. As a user moves out off cellular coverage, or is unable to reach the central server for any reason, connectivity is lost. As a consequence, Internet-based mobile social applications will not be able to provide their services and the end-users will become isolated until Internet connectivity is restored, even if the users that are exploiting the service are within a few meters of each other. Modern smartphones are equipped with a number of radio interfaces that enable wireless communication among devices in close proximity. Leveraging these capabili- ties could be used to establish connectivity between neighboring devices even in the most remote out-of-coverage locations. Important challenges concerning this approach are the security issues that arise when the centralized mutually trusted entity becomes unavailable. How can end users make sure that they are not communicating with an impostor, and how to protect the confidentiality and integrity of each message? The goal of this work is to propose, implement and experimentally validate a simple system that can be used to securely and easily enable communication in existing social applications in situations with no Internet connectivity. The proposed system will use WiFi Direct to connect neighboring devices, and apply mutual TLS to facilitate fast, reliable and secure identification of connected parties based on identity certificates issued by the central server before connection loss. Responsible professor: Yuming Jiang, IIK Supervisor: Besmir Tola, IIK Abstract The objective of this project is to propose, implement and test a technique that social smartphone applications can use to keep their users connected in situations where they are unable to connect to the application server, but close enough to each other to support device-to-device communication. The proposed idea and key contribution of this project are as follows: Each client is issued a certificate by a central authorization entity that they can use to identify themselves at any time. If a client is unable to connect to the application server, it will start looking for nearby peers using WiFi Direct, and attempt to form a group with them. Once a WiFi Direct group is formed, the group owner will temporarily assume the role of application server. Each group member and the group owner will then verify each others identity and connect using mutual Transport Layer Security (mTLS), facilitating secure communication. Sammendrag Dette prosjektets mål er å foreslå, implementere og teste en teknikk som sosiale smarttelefonapplikasjoner kan bruke for å koble sammen brukere i situasjoner der de ikke er i stand til å nå applikasjonsserveren, men nær nok hverandre til å støtte peer-til-peer-kommunikasjon. Den foreslåtte ideen og hovedbidraget fra prosjektet er som følger: Hver bruker får utstedt et sertifikat fra en sentral autorisasjonsenhet som de kan bruke til å identifisere seg. Hvis en klient ikke er i stand til å nå applikasjonsserveren, vil den begynne å lete etter andre enheter i samme situasjon i nærheten ved å bruke WiFi Direct og forsøke å danne en gruppe med dem. Når en slik gruppe har blitt dannet, vil gruppeeieren midlertidig overta rollen som applikasjonsserver. Hvert gruppemedlem og gruppens eier vil så verifisere hverandres identitet og koble til hverandre ved hjelp av gjensidig Transport Layer Security (mTLS), og dermed muliggjøre sikker kommunikasjon. Preface This thesis is being submitted as part of a master’s degree at the De- partment of Information Security and Communication Technology at the Norwegian University of Science and Technology (NTNU). As a result of the current work, a scientific paper has been produced which is soon to be submitted to WiMob 2019, The 15th International Conference on Wireless and Mobile Computing, Networking and Commu- nications. I would like to thank my supervisor Besmir Tola for his invaluable advice and continuous feedback, and professor Yuming Jiang for his encouragement and guidance. Trondheim, Thursday 6th June, 2019 Øystein Løkken Sigholt Contents List of Figures ix List of Tables xi List of Acronyms xiii 1 Introduction1 1.1 Background and Motivation....................... 1 1.2 Related Work............................... 2 1.3 Open Challenges............................. 4 1.4 Scope ................................... 4 1.5 Methodology and Tools ......................... 5 1.5.1 The Design Phase ........................ 5 1.5.2 The Implementation Phase ................... 5 1.5.3 The Validation Phase ...................... 6 2 Proposed Approach7 2.1 System Architecture........................... 7 2.1.1 The Authentication Component................. 7 2.1.2 The Server Component ..................... 9 2.1.3 The Client Component...................... 11 2.2 Exploited Technologies.......................... 12 2.2.1 WiFi Direct............................ 13 2.2.2 Mutual Transport Layer Security (mTLS)........... 16 2.2.3 Cryptography........................... 16 3 Implementation 23 3.1 The Dedicated Server .......................... 23 3.1.1 Certificate Generation...................... 23 3.2 The Client Application.......................... 24 3.2.1 The Main Activity........................ 24 3.2.2 The Chat Activity........................ 24 3.2.3 The Debug Activity ....................... 25 vii 3.2.4 Technical Details......................... 26 3.3 Cross Platform Code Reuse....................... 27 3.3.1 API Variation........................... 28 3.3.2 Serialization............................ 28 3.4 Cryptography............................... 29 3.4.1 Rivest Shamir Adleman (RSA)................. 29 3.4.2 Elliptic Curve Cryptography .................. 29 3.5 User Experience ............................. 31 4 Experimental Results 33 4.1 Security Validation............................ 33 4.1.1 Data Link Layer Security .................... 33 4.1.2 Transport Layer Security .................... 34 4.1.3 Application Layer Security ................... 35 4.2 Overhead ................................. 37 4.2.1 Connection............................ 37 4.2.2 Messaging............................. 39 4.2.3 Other Messaging Applications.................. 42 5 Discussion 47 5.1 Connectivity ............................... 47 5.2 Security.................................. 47 5.3 Overhead ................................. 48 5.4 User Experience ............................. 49 6 Conclusion 51 6.1 Future Work ............................... 52 6.1.1 Messaging Protocol........................ 52 6.1.2 Data Transport.......................... 53 6.1.3 Denial of Service Resilience................... 54 References 55 Appendices A Scientific Paper 59 List of Figures 2.1 System Architecture: Sign up and Online Operation........... 9 2.2 Message Packet................................ 11 2.3 System Architecture: Offline Operation .................. 12 2.4 WiFi Probe Request and Response..................... 14 2.5 WiFi Direct Topology ............................ 16 2.6 Legacy Client Connection Sequence Diagram ............... 17 2.7 TLS Handshake Protocol Message Flow.................. 18 2.8 Symmetric Cryptography Encryption and Decryption .......... 18 2.9 Public Key Cryptography Key Generation................. 19 2.10 Public Key Cryptography Signature .................... 20 2.11 Public Key Cryptography Encryption and Decryption.......... 20 3.1 Client Application Main Activity...................... 25 3.2 Client Application Chat Activity...................... 26 3.3 Connectivity Behavior State Machine ................... 27 3.4 WiFi Direct Connection Prompt ...................... 31 3.5 WiFi Connected, No Internet........................ 32 4.1 IEEE 802.11 Data Frame .......................... 34 4.2 WiFi PSK Transmitted Using NSD..................... 35 4.3 TLS Handshake Failure ........................... 35 4.4 Message Flow as Seen by theGO...................... 36 4.5 Message Signature Validation........................ 36 4.6 Automatic WiFi Direct Group Authentication and Connection Delay CDF 38 4.7 Message Packet Instantiation Time..................... 40 4.8 Message Packet Decryption Time...................... 40 4.9 Signal Protocol Message Data Structure.................. 43 4.10 Signal Message Example........................... 44 4.11 Bramble Transport Protocol Frames.................... 45 5.1 WhatsApp Security Code.......................... 50 ix

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    88 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us