Usability Analysis of TLS API Documentation

Total Page:16

File Type:pdf, Size:1020Kb

Usability Analysis of TLS API Documentation Masaryk University Faculty of Informatics Usability Analysis of TLS API Documentation Master’s Thesis Bc. Matěj Grabovský Brno, Spring 2020 Masaryk University Faculty of Informatics Usability Analysis of TLS API Documentation Master’s Thesis Bc. Matěj Grabovský Brno, Spring 2020 This is where a copy of the official signed thesis assignment and acopyofthe Statement of an Author is located in the printed version of the document. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Bc. Matěj Grabovský Advisor: RNDr. Martin Ukrop i Acknowledgements I thank my dearest Kateřina for her fair gaiety, affectionate assiduities, firm support and constant sense of belonging. This work would not be presented here as is without her presence and input. I thank my advisor Martin for his boundless patience, invaluable advice, wise guidance and support in all phases of our work. My thanks also goes to Lydia for her priceless help and advice on writing and data analysis. Though many of my friends and family remain unnamed here, mygrat- itude goes to them undiluted for they supported me selflessly throughout the time and provided a much needed relief and distraction innumerable times. ii Abstract This thesis deals with the usability of selected TLS libraries, their documen- tation, code samples and related resources. We describe the design and re- sults of our initial exploratory study and a follow-up study, both performed with students of the Faculty of Informatics. The results show that the selected libraries’ documentation suffers from many usability problems. Although these issues are not specific to TLS libraries, their consequences might be more serious. Quantitative rating of the severity of selected problems suggests that the libraries are comparable. Further research is necessary in order to determine what kind of exam- ples are most useful to developers and, especially, how to compel library developers to heed the research community’s recommendations. Keywords developer experience, documentation, human factors, usability, usable se- curity, user study, TLS iii Contents 1 Introduction 1 2 Exploratory Study 4 2.1 Design and Methods 4 2.2 Data Analysis 5 2.3 Setting and Participants 6 2.4 Results 6 3 Methodology 10 3.1 Research Questions 10 3.2 Study Design 10 3.3 Task Design 11 3.4 Setting 15 3.5 Participants 15 3.6 Data Collection, Processing and Analysis 17 3.7 Limitations 19 4 Results 22 4.1 Identified Issues 22 4.2 Severity of Obstacles 33 4.3 Other Sources of Information 35 4.4 Supplementary Analyses 40 5 Discussion 42 5.1 Obstacles 42 5.2 Other Sources 44 6 Related Work 45 7 Conclusion 47 7.1 Future Work 47 Bibliography 49 iv A Pre-Task Questionnaire 54 B Post-Task Questionnaire 57 C Assignment Microsite Snapshot 60 v 1 Introduction TLS and Usability. Transport Layer Security (TLS) is a family of security protocols for secure, encrypted and authenticated communication in com- puter networks. It is most widely deployed in the HTTPS (HTTP over TLS) protocol, which serves hunders of millions of websites over the world with the numbers growing steadily. The Let’s Encrypt (2020) initiative claims to have provided TLS certifi- cates to 225 million websites. According to Google (2020), more than 90% of all pages loaded in the Google Chrome browser are served over HTTPS. NetMarketShare (2020) estimates 87% of all web traffic is encrypted. The importance of TLS for the modern Internet is undisputable. How- ever, several studies have shown that the protocol implementations are misused and misunderstood by developers, risking their users’ data and privacy (Egele et al. 2013; Georgiev et al. 2012; Krüger et al. 2018). Moreover, it has been shown that security and cryptographic inter- faces in general are hard to use and too easy to misuse (Acar, Backes, Fahl, Garfinkel, et al. 2017; Iacono and Gorski 2017; Nadi et al. 2016). Even pro- fessionals developers tend to struggle with writing code that is both secure and functionally correct (Acar, Stransky, et al. 2017; Georgiev et al. 2012; Krombholz et al. 2017). Exploratory Study. To this end, it is clear that the usability of security interfaces, their documentation and other resources is essential for their pratical security. In order to generate new reserarch questions at the in- terscetion of TLS and developer experience (DX) research, we performed a small qualitative exploratory study with in 2018. Nine IT students partic- ipated in the study, tasked to create a small application with three estab- lished C-language TLS libraries. The results revealed and confirmed a few usability factors considered by developers when working with the APIs. They have also hinted at the indispensability of the availability of quality documentation and code sam- ples, in line with previous research (Acar, Backes, Fahl, Garfinkel, et al. 2017; Nadi et al. 2016). Follow-up Study. We therefore decided to narrow down on this partic- ular aspect of library usability in a larger, more focused follow-up study. 1 1. Introduction We designed a mixed-methods user study, again with IT students at our university as participants. We aimed to identify common issues in docu- mentation, quantify the severity of some issues, and observe patterns in use of external sources of information. This time, we selected two popular libraries for two programming lan- guages each, diversifying the field of possibilities. We also opted for a more realistic task of modifying an existing application rather than creating a new one. We then analysed the results of our follow-up study, identify the causes and implications of various issues, and situate our findings within the ex- isting body of research. Thesis Outline. The thesis is laid out as follows. At the beginning, Chap- ter 2 lays out the design, execution and results of our initial exploratory study on the usability of TLS programming interfaces. In Chapter 3, we set the research questions for our follow-up study and detail the methods we chose to answer them with. Chapter 4 then lists the results from our analyses of the qualitative and quantitative data we collected. In Chapter 5, we situate the results within a wider context, interpret them and speculate on possible implica- tions. Chapter 6 surveys the the related research grounds and where our work fits in. And finally, Chapter 7 sums up our findings, their possible limitations and potential directions for further research. Acknowledgement of Contributions It bears mentioning that the work presented here is in part the result of a collaboration with my advisor, RNDr. Martin Ukrop, and a consultant, Dr.-Ing. Lydia Kraus. They were both advising me and providing feedback in all stages ofthe research process – designing the studies, analysing and understanding data, and presenting results. It would be too difficult to list their contributions precisely, so I present here merely a short summary of the key moments. Martin Ukrop helped design both studies and the tasks, administered the assignments in both experiments, anonymised the collected data and preprocessed them before the analysis phase. He also served as the second coder in coding qualitative data. 2 1. Introduction Lydia Kraus assisted with the analysis of qualitative data, creating the codebook and calculating interrater agreement in the exploratory study. She also advised me in various stages of analysing the data in the follow- up study. Moreover, we wrote the work-in-progress short paper presenting our exploratory study collaboratively. Unless otherwise noted, all the remaining work presented on the fol- lowing pages is my own with all due responsibility. 3 2 Exploratory Study While the usability of lower-level cryptographic libraries has been under active scrutiny by the usable security and DX research community (Acar, Backes, Fahl, Garfinkel, et al. 2017; Arzt et al. 2015; Egele et al. 2013; Nadi et al. 2016), the issues specific to TLS-related APIs and the usability ofcon- crete TLS libraries have not yet been thoroughly investigated to our knowl- edge. Therefore, following the agenda set forth by Acar, Fahl and Mazurek (2016), we designed and performed a small exploratory user study with the aim to to uncover potential TLS-specific usability issues. We defined our scope to TLS libraries, their APIs, their documentation and other related resources. 2.1 Design and Methods Since we were aiming to generate new research questions and hypothe- ses in this area, we opted for a purely qualitative study with open-ended data. Qualitative research methods had been used successfully in several studies before (Iacono and Gorski 2017; Krombholz et al. 2017; Naiakshina, Danilova, Tiefenau, Herzog, et al. 2017; Naiakshina, Danilova, Tiefenau and Smith 2018), which reinforced our choice of methodology. Due to the exploratory nature of our endeavour, we established no re- search questions a priori. Instead, we designed a programming task to be completed by the participants in three different libraries with a subsequent written report focusing on elements of the usability of theAPI. We chose three C libraries with TLS support for our experiment: Open- SSL, GnuTLS and mbed TLS (formerly PolarSSL). At the time of writing, OpenSSL is arguably the most popular cryptographic library (per Internet- wide scans; Nemec et al. 2017). GnuTLS aims to be a full-featured GPL- compatible alternative, although with a substantially different API. The API of mbed TLS is also distinct and we expected interesting data could be generated from comparisons with the two mainstream libraries. The programming task consisted of implementing a simple HTTPS client, starting from a basic code skeleton with library initialisation and clean up code using each of the libraries.
Recommended publications
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019
    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
    [Show full text]
  • Crypto Projects That Might Not Suck
    Crypto Projects that Might not Suck Steve Weis PrivateCore ! http://bit.ly/CryptoMightNotSuck #CryptoMightNotSuck Today’s Talk ! • Goal was to learn about new projects and who is working on them. ! • Projects marked with ☢ are experimental or are relatively new. ! • Tried to cite project owners or main contributors; sorry for omissions. ! Methodology • Unscientific survey of projects from Twitter and mailing lists ! • Excluded closed source projects & crypto currencies ! • Stats: • 1300 pageviews on submission form • 110 total nominations • 89 unique nominations • 32 mentioned today The People’s Choice • Open Whisper Systems: https://whispersystems.org/ • Moxie Marlinspike (@moxie) & open source community • Acquired by Twitter 2011 ! • TextSecure: Encrypt your texts and chat messages for Android • OTP-like forward security & Axolotl key racheting by @trevp__ • https://github.com/whispersystems/textsecure/ • RedPhone: Secure calling app for Android • ZRTP for key agreement, SRTP for call encryption • https://github.com/whispersystems/redphone/ Honorable Mention • ☢ Networking and Crypto Library (NaCl): http://nacl.cr.yp.to/ • Easy to use, high speed XSalsa20, Poly1305, Curve25519, etc • No dynamic memory allocation or data-dependent branches • DJ Bernstein (@hashbreaker), Tanja Lange (@hyperelliptic), Peter Schwabe (@cryptojedi) ! • ☢ libsodium: https://github.com/jedisct1/libsodium • Portable, cross-compatible NaCL • OpenDNS & Frank Denis (@jedisct1) The Old Standbys • Gnu Privacy Guard (GPG): https://www.gnupg.org/ • OpenSSH: http://www.openssh.com/
    [Show full text]
  • Post-Quantum Authentication in Openssl with Hash-Based Signatures
    Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Post-Quantum Authentication in OpenSSL with Hash-Based Signatures Denis Butin, Julian Wälde, and Johannes Buchmann TU Darmstadt, Germany 1 / 26 I Quantum computers are not available yet, but deployment of new crypto takes time, so transition must start now I Well established post-quantum signature schemes: hash-based cryptography (XMSS and variants) I Our goal: make post-quantum signatures available in a popular security software library: OpenSSL Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key cryptography (RSA, DSA, ECDSA) breaks once large quantum computers exist I Post-quantum cryptography: public-key algorithms thought to be secure against quantum computer attacks 2 / 26 Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key
    [Show full text]
  • Black-Box Security Analysis of State Machine Implementations Joeri De Ruiter
    Black-box security analysis of state machine implementations Joeri de Ruiter 18-03-2019 Agenda 1. Why are state machines interesting? 2. How do we know that the state machine is implemented correctly? 3. What can go wrong if the implementation is incorrect? What are state machines? • Almost every protocol includes some kind of state • State machine is a model of the different states and the transitions between them • When receiving a messages, given the current state: • Decide what action to perform • Which message to respond with • Which state to go the next Why are state machines interesting? • State machines play a very important role in security protocols • For example: • Is the user authenticated? • Did we agree on keys? And if so, which keys? • Are we encrypting our traffic? • Every implementation of a protocol has to include the corresponding state machine • Mistakes can lead to serious security issues! State machine example Confirm transaction Verify PIN 0000 Failed Init Failed Verify PIN 1234 OK Verified Confirm transaction OK State machines in specifications • Often specifications do not explicitly contain a state machine • Mainly explained in lots of prose • Focus usually on happy flow • What to do if protocol flow deviates from this? Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
    [Show full text]
  • No.Ntnu:Inspera:2546742.Pdf (10.61Mb)
    Krishna Shingala An alternative to the Public Key Krishna Shingala Infrastructure for the Internet of Things Master’s thesis in Communication Technology Supervisor: Danilo Gligoroski, Katina Kralevska, Torstein Heggebø Master’s thesis Master’s June 2019 An alternative to PKI for IoT PKI for to An alternative 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 An alternative to the Public Key Infras- tructure for the Internet of Things Krishna Shingala Submission date: June 2019 Responsible professor: Danilo Gligoroski, IIK, NTNU Supervisor: Danilo Gligoroski, IIK, NTNU Co-Supervisor: Katina Kralevska, IIK, NTNU Co-Supervisor: Torstein Heggebø, Nordic Semiconductor ASA Norwegian University of Science and Technology Department of Information Technology and Electrical Engineering Title: An alternative to the Public Key Infrastructure for the Internet of Things Student: Krishna Shingala Problem description: Internet of Things(IoT) enables participation of constrained devices on the Internet. Limited resources, bandwidth, and power on the devices have led to new protocols. Some examples of IoT driven and driving protocols are: – MQTT, CoAP that are application protocols for IoT; – 6LoWPAN enables efficient support of IPv6 on low power lossy networks; – CBOR enables concise data formatting; and – DTLS enables secure channel establishment over unreliable transport like the UDP. Security is one of the key factors for the success of IoT. TLS/DTLS secures the channel between the servers and the devices. Confidentiality is an important aspect of such a secure channel. Establishing the identity of an entity another.
    [Show full text]
  • Vetting SSL Usage in Applications with SSLINT
    2015 IEEE Symposium on Security and Privacy Vetting SSL Usage in Applications with SSLINT Boyuan He1, Vaibhav Rastogi2, Yinzhi Cao3, Yan Chen2, V.N. Venkatakrishnan4, Runqing Yang1, and Zhenrui Zhang1 1Zhejiang University 2Northwestern University 3Columbia University 4University of Illinois, Chicago [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Abstract—Secure Sockets Layer (SSL) and Transport Layer In particular, we ask the following research question: Is it Security (TLS) protocols have become the security backbone of possible to design scalable techniques that detect incorrect use the Web and Internet today. Many systems including mobile of APIs in applications using SSL/TLS libraries? This question and desktop applications are protected by SSL/TLS protocols against network attacks. However, many vulnerabilities caused poses the following challenges: by incorrect use of SSL/TLS APIs have been uncovered in recent • Defining and representing correct use. Given an SSL years. Such vulnerabilities, many of which are caused due to poor library, how do we model correct use of the API to API design and inexperience of application developers, often lead to confidential data leakage or man-in-the-middle attacks. In this facilitate detection? paper, to guarantee code quality and logic correctness of SSL/TLS • Analysis techniques for incorrect usage in software. applications, we design and implement SSLINT, a scalable, Given a representation of correct usage, how do we de- automated, static analysis system for detecting incorrect use sign techniques for analyzing programs to detect incorrect of SSL/TLS APIs.
    [Show full text]
  • You Really Shouldn't Roll Your Own Crypto: an Empirical Study of Vulnerabilities in Cryptographic Libraries
    You Really Shouldn’t Roll Your Own Crypto: An Empirical Study of Vulnerabilities in Cryptographic Libraries Jenny Blessing Michael A. Specter Daniel J. Weitzner MIT MIT MIT Abstract A common aphorism in applied cryptography is that cryp- The security of the Internet rests on a small number of open- tographic code is inherently difficult to secure due to its com- source cryptographic libraries: a vulnerability in any one of plexity; that one should not “roll your own crypto.” In par- them threatens to compromise a significant percentage of web ticular, the maxim that complexity is the enemy of security traffic. Despite this potential for security impact, the character- is a common refrain within the security community. Since istics and causes of vulnerabilities in cryptographic software the phrase was first popularized in 1999 [52], it has been in- are not well understood. In this work, we conduct the first voked in general discussions about software security [32] and comprehensive analysis of cryptographic libraries and the vul- cited repeatedly as part of the encryption debate [26]. Conven- nerabilities affecting them. We collect data from the National tional wisdom holds that the greater the number of features Vulnerability Database, individual project repositories and in a system, the greater the risk that these features and their mailing lists, and other relevant sources for eight widely used interactions with other components contain vulnerabilities. cryptographic libraries. Unfortunately, the security community lacks empirical ev- Among our most interesting findings is that only 27.2% of idence supporting the “complexity is the enemy of security” vulnerabilities in cryptographic libraries are cryptographic argument with respect to cryptographic software.
    [Show full text]
  • Xerox® Igen™ 150 Press 3 Party Software License Disclosure
    Xerox® iGen™ 150 Press 3rd Party Software License Disclosure October 2013 The following software packages are copyrighted for use in this product according to the license stated. Full terms and conditions of all 3rd party software licenses are available from the About screen under the Help menu on the Press Interface or by accessing the Support & Drivers page located on the http://www.xerox.com website. Adobe Icons and Web Logos, license: Adobe Icons and Web Logos License Apache log4j 1.2.8, Apache log4j 1.2.9, Apache Web Services XML-RPC 1.2.b1, Apache Lucene Java 1.3, Apache Tomcat 4.1.27, license: Apache License 1.1 Apache Axis 1.x 1.4, Apache Jakarta Commons HttpClient 3.0.alpha1, Apache Jakarta Commons Logging 1.0.4, Apache Jakarta Lucene 1.9.1, Apache XML Security Java 1.3.0, saxpath 1.0 FCS, Skin Look And Feel (skinlf) 1.2.8, Spring Framework Utilities 0.7, Apache Web Services Axis 1.2rc3, Apache Xerces Java XML Parser 2.7.1, Apache XML Xalan-Java 2.7.0, Jetty - Java HTTP Servlet Server 4.0.D0, Lucene Snowball, Streaming API for XML (StAX) - JSR-173 20040819, license: Apache License 2.0 Perl 5.8.5, Perl 5.10.0, AppConfig-1.66, Archive-Tar-1.58, Compress::Zlib-2.020, Expect.pm- 1.21, File-NCopy-0.36, File-NFSLock-1.20, Filesys-Df-0.92, Filesys-DiskFree-0.06, HTML- Parser-3.69, HTML-Tagset-3.20, HTML-Template-2.9, IO-Stty-0.02, IO-Tty-1.08, IO-Zlib- 1.09, libxml-perl-0.08, Net-Netmask-1.9015, Net-Telnet-3.03, perl-5.8.3, perlindex-1.605, Pod- Escapes-1.04, Pod-POM-0.25, Pod-Simple-3.13, Proc-ProcessTable-0.45, Socket6-0.23, Stat-
    [Show full text]
  • Cloudtransport: Using Cloud Storage for Censorship-Resistant Networking
    CloudTransport: Using Cloud Storage for Censorship-Resistant Networking Chad Brubaker1,2, Amir Houmansadr2, and Vitaly Shmatikov2 1 Google 2 The University of Texas at Austin Abstract. Censorship circumvention systems such as Tor are highly vulnerable to network-level filtering. Because the traffic generated by these systems is disjoint from normal network traffic, it is easy to recog- nize and block, and once the censors identify network servers (e.g., Tor bridges) assisting in circumvention, they can locate all of their users. CloudTransport is a new censorship-resistant communication system that hides users’ network traffic by tunneling it through a cloud storage ser- vice such as Amazon S3. The goal of CloudTransport is to increase the censors’ economic and social costs by forcing them to use more expen- sive forms of network filtering, such as large-scale traffic analysis, or else risk disrupting normal cloud-based services and thus causing collateral damage even to the users who are not engaging in circumvention. Cloud- Transport’s novel passive-rendezvous protocol ensures that there are no direct connections between a CloudTransport client and a CloudTrans- port bridge. Therefore, even if the censors identify a CloudTransport connection or the IP address of a CloudTransport bridge, this does not help them block the bridge or identify other connections. CloudTransport can be used as a standalone service, a gateway to an anonymity network like Tor, or a pluggable transport for Tor. It does not require any modifications to the existing cloud storage, is compatible with multiple cloud providers, and hides the user’s Internet destinations even if the provider is compromised.
    [Show full text]
  • 7) Internet of Things a Survey on the Security of Iot Frameworks
    Journal of Information Security and Applications 38 (2018) 8–27 Contents lists available at ScienceDirect Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa Internet of Things: A survey on the security of IoT frameworks ∗ Mahmoud Ammar a, , Giovanni Russello b, Bruno Crispo a a Department of Computer Science, KU Leuven University, Heverlee, 3001, Belgium b Department of Computer Science, University of Auckland, Private Bag 92019, Auckland 1142, New Zealand a r t i c l e i n f o a b s t r a c t Article history: The Internet of Things (IoT) is heavily affecting our daily lives in many domains, ranging from tiny wear- able devices to large industrial systems. Consequently, a wide variety of IoT applications have been devel- Keywords: oped and deployed using different IoT frameworks. An IoT framework is a set of guiding rules, protocols, Internet of Things and standards which simplify the implementation of IoT applications. The success of these applications IoT mainly depends on the ecosystem characteristics of the IoT framework, with the emphasis on the security Framework mechanisms employed in it, where issues related to security and privacy are pivotal. In this paper, we sur- Platform vey the security of the main IoT frameworks, a total of 8 frameworks are considered. For each framework, Security we clarify the proposed architecture, the essentials of developing third-party smart apps, the compati- ble hardware, and the security features. Comparing security architectures shows that the same standards used for securing communications, whereas different methodologies followed for providing other security properties.
    [Show full text]