144 research outputs found

    Proving the TLS Handshake Secure (As It Is)

    Get PDF
    International audienceThe TLS Internet Standard features a mixed bag of cryptographic algorithms and constructions, letting clients and servers negotiate their use for each run of the handshake. Although many ciphersuites are now well-understood in isolation, their composition remains problematic, and yet it is critical to obtain practical security guarantees for TLS, as all mainstream implementations support multiple related runs of the handshake and share keys between algorithms.We study the provable security of the TLS handshake, as it is implemented and deployed. To capture the details of the standard and its main extensions, we rely on miTLS, a verified reference implementation of the protocol. We propose new agile security definitions and assumptions for the signatures, key encapsulation mechanisms (KEM), and key derivation algorithms used by the TLS handshake. To validate our model of key encapsulation, we prove that both RSA and Diffie-Hellman ciphersuites satisfy our definition for the KEM. In particular, we formalize the use of PKCS#1v1.5 and build a 3,000-line EasyCrypt proof of the security of the resulting KEM against replayable chosen-ciphertext attacks under the assumption that ciphertexts are hard to re-randomize.Based on our new agile definitions, we construct a modular proof of security for the miTLS reference implementation of the handshake, including ciphersuite negotiation, key exchange, renegotiation, and resumption, treated as a detailed 3,600-line executable model. We present our main definitions, constructions, and proofs for an abstract model of the protocol, featuring series of related runs of the handshake with different ciphersuites. We also describe its refinement to account for the whole reference implementation, based on automated verification tools

    Vulnerability-Tolerant Transport Layer Security

    Get PDF
    SSL/TLS communication channels play a very important role in Internet security, including cloud computing and server infrastructures. There are often concerns about the strength of the encryption mechanisms used in TLS channels. Vulnerabilities can lead to some of the cipher suites once thought to be secure to become insecure and no longer recommended for use or in urgent need of a software update. However, the deprecation/update process is very slow and weeks or months can go by before most web servers and clients are protected, and some servers and clients may never be updated. In the meantime, the communications are at risk of being intercepted and tampered by attackers. In this paper we propose an alternative to TLS to mitigate the problem of secure commu- nication channels being susceptible to attacks due to unexpected vulnerabilities in its mechan- isms. Our solution, called Vulnerability-Tolerant Transport Layer Security (vtTLS), is based on diversity and redundancy of cryptographic mechanisms and certificates to ensure a secure communication even when one or more mechanisms are vulnerable. Our solution relies on a combination of k cipher suites which ensure that even if k ? 1 cipher suites are insecure or vul- nerable, the remaining cipher suite keeps the communication channel secure. The performance and cost of vtTLS were evaluated and compared with OpenSSL, one of the most widely used implementations of TLS

    Towards Forward Secure Internet Traffic

    Full text link
    Forward Secrecy (FS) is a security property in key-exchange algorithms which guarantees that a compromise in the secrecy of a long-term private-key does not compromise the secrecy of past session keys. With a growing awareness of long-term mass surveillance programs by governments and others, FS has become widely regarded as a highly desirable property. This is particularly true in the TLS protocol, which is used to secure Internet communication. In this paper, we investigate FS in pre-TLS 1.3 protocols, which do not mandate FS, but still widely used today. We conduct an empirical analysis of over 10 million TLS servers from three different datasets using a novel heuristic approach. Using a modern TLS client handshake algorithms, our results show 5.37% of top domains, 7.51% of random domains, and 26.16% of random IPs do not select FS key-exchange algorithms. Surprisingly, 39.20% of the top domains, 24.40% of the random domains, and 14.46% of the random IPs that do not select FS, do support FS. In light of this analysis, we discuss possible paths toward forward secure Internet traffic. As an improvement of the current state, we propose a new client-side mechanism that we call "Best Effort Forward Secrecy" (BEFS), and an extension of it that we call "Best Effort Forward Secrecy and Authenticated Encryption" (BESAFE), which aims to guide (force) misconfigured servers to FS using a best effort approach. Finally, within our analysis, we introduce a novel adversarial model that we call "discriminatory" adversary, which is applicable to the TLS protocol

    Cache-22: A Highly Deployable End-To-End Encrypted Cache System with Post-Quantum Security

    Get PDF
    Cache systems are crucial for reducing communication overhead on the Internet. The importance of communication privacy is being increasingly and widely recognized; therefore, we anticipate that nearly all end-to-end communication will be encrypted via secure sockets layer/transport layer security (SSL/TLS) in the near future. Herein we consider a catch-22 situation, wherein the cache server checks whether content has been cached or not, i.e., the cache server needs to observe it, thereby violating end-to-end encryption. We avoid this catch-22 situation by proposing an encrypted cache system which we call Cache-22. To maximize its deployability, we avoid heavy, advanced cryptographic tools, and instead base our Cache-22 system purely on traditional SSL/TLS communication. It employs tags for searching, and its design concept enables the service provider to decide, e.g., via an authentication process, whether or not a particular user should be allowed to access particular content. We provide a prototype implementation of the proposed system using the color-based cooperative cache proposed by Nakajima et al. (IEICE Trans. 2017) under several ciphersuites containing post-quantum key exchanges in addition to ECDHE (Elliptic Curve-based). We consider NIST Post-Quantum Cryptography round 3 finalists and alternate candidates: lattice-based (Kyber, SABER, NTRU), code-based (BIKE), and isogeny-based (SIKE). Compared to direct HTTPS communication between a service provider and a user, employing our Cache-22 system has a merit to drastically reduce communications between a cache server and the service provider (approximately 95%) which is effective in a hierarchical network with a cost disparity

    Postcards from the post-HTTP world: Amplification of HTTPS vulnerabilities in the web ecosystem

    Get PDF
    HTTPS aims at securing communication over the Web by providing a cryptographic protection layer that ensures the confidentiality and integrity of communication and enables client/server authentication. However, HTTPS is based on the SSL/TLS protocol suites that have been shown to be vulnerable to various attacks in the years. This has required fixes and mitigations both in the servers and in the browsers, producing a complicated mixture of protocol versions and implementations in the wild, which makes it unclear which attacks are still effective on the modern Web and what is their import on web application security. In this paper, we present the first systematic quantitative evaluation of web application insecurity due to cryptographic vulnerabilities. We specify attack conditions against TLS using attack trees and we crawl the Alexa Top 10k to assess the import of these issues on page integrity, authentication credentials and web tracking. Our results show that the security of a consistent number of websites is severely harmed by cryptographic weaknesses that, in many cases, are due to external or related-domain hosts. This empirically, yet systematically demonstrates how a relatively limited number of exploitable HTTPS vulnerabilities are amplified by the complexity of the web ecosystem

    Post-Quantum Key Exchange for the Internet and the Open Quantum Safe Project

    Get PDF
    Designing public key cryptosystems that resist attacks by quantum computers is an important area of current cryptographic research and standardization. To retain confidentiality of today\u27s communications against future quantum computers, applications and protocols must begin exploring the use of quantum-resistant key exchange and encryption. In this paper, we explore post-quantum cryptography in general and key exchange specifically. We review two protocols for quantum-resistant key exchange based on lattice problems: BCNS15, based on the ring learning with errors problem, and Frodo, based on the learning with errors problem. We discuss their security and performance characteristics, both on their own and in the context of the Transport Layer Security (TLS) protocol. We introduce the Open Quantum Safe project, an open-source software project for prototyping quantum-resistant cryptography, which includes liboqs, a C library of quantum-resistant algorithms, and our integrations of liboqs into popular open-source applications and protocols, including the widely used OpenSSL library

    Wireless LAN security.

    Get PDF
    Chan Pak To Patrick.Thesis (M.Phil.)--Chinese University of Hong Kong, 2005.Includes bibliographical references (leaves 82-86).Abstracts in English and Chinese.Abstract --- p.iAcknowledgement --- p.iiiContents --- p.ivList of Figures --- p.viiList of Tables --- p.viiiChapter 1 --- Introduction --- p.1Chapter 1.1 --- Motivation --- p.1Chapter 1.2 --- The Problems --- p.3Chapter 1.3 --- My Contribution --- p.4Chapter 1.4 --- Thesis Organization --- p.5Chapter 2 --- Wireless LAN Security Model --- p.6Chapter 2.1 --- Preliminary Definitions on WLAN --- p.6Chapter 2.2 --- Security Model --- p.7Chapter 2.2.1 --- Security Attributes --- p.7Chapter 2.2.2 --- Security Threats in WLAN --- p.8Chapter 2.2.3 --- Attacks on Authentication Scheme --- p.10Chapter 2.2.4 --- Attacks on Keys --- p.10Chapter 2.3 --- Desired Properties of WLAN Authentication --- p.11Chapter 2.3.1 --- Security Requirements of WLAN Authentication --- p.11Chapter 2.3.2 --- Security Requirements of Session Keys --- p.12Chapter 2.3.3 --- Other Desired Properties of WLAN Authentication --- p.12Chapter 3 --- Cryptography --- p.14Chapter 3.1 --- Overview on Cryptography --- p.14Chapter 3.2 --- Symmetric-key Encryption --- p.15Chapter 3.2.1 --- Data Encryption Standard (DES) --- p.15Chapter 3.2.2 --- Advanced Encryption Standard (AES) --- p.15Chapter 3.2.3 --- RC4 --- p.16Chapter 3.3 --- Public-key Cryptography --- p.16Chapter 3.3.1 --- RSA Problem and Related Encryption Schemes --- p.17Chapter 3.3.2 --- Discrete Logarithm Problem and Related Encryption Schemes --- p.18Chapter 3.3.3 --- Elliptic Curve Cryptosystems --- p.19Chapter 3.3.4 --- Digital Signature --- p.19Chapter 3.4 --- Public Key Infrastructure --- p.20Chapter 3.5 --- Hash Functions and Message Authentication Code --- p.21Chapter 3.5.1 --- SHA-256 --- p.22Chapter 3.5.2 --- Message Authentication Code --- p.22Chapter 3.6 --- Entity Authentication --- p.23Chapter 3.6.1 --- ISO/IEC 9798-4 Three-pass Mutual --- p.23Chapter 3.6.2 --- ISO/IEC 9798-4 One-pass Unilateral --- p.24Chapter 3.7 --- Key Establishment --- p.24Chapter 3.7.1 --- Diffie-Hellman Key Exchange --- p.24Chapter 3.7.2 --- Station-to-Station Protocol --- p.25Chapter 3.8 --- Identity-Based Cryptography --- p.25Chapter 3.8.1 --- The Boneh-Franklin Encryption Scheme --- p.26Chapter 3.8.2 --- Au and Wei's Identification Scheme and Signature Scheme --- p.27Chapter 4 --- Basics of WLAN Security and WEP --- p.29Chapter 4.1 --- Basics of WLAN Security --- p.29Chapter 4.1.1 --- "Overview on ""Old"" WLAN Security" --- p.29Chapter 4.1.2 --- Some Basic Security Measures --- p.29Chapter 4.1.3 --- Virtual Private Network (VPN) --- p.30Chapter 4.2 --- WEP --- p.31Chapter 4.2.1 --- Overview on Wired Equivalent Privacy (WEP) --- p.31Chapter 4.2.2 --- Security Analysis on WEP --- p.33Chapter 5 --- IEEE 802.11i --- p.38Chapter 5.1 --- Overview on IEEE 802.11i and RSN --- p.38Chapter 5.2 --- IEEE 802.1X Access Control in IEEE 802.11i --- p.39Chapter 5.2.1 --- Participants --- p.39Chapter 5.2.2 --- Port-based Access Control --- p.40Chapter 5.2.3 --- EAP and EAPOL --- p.40Chapter 5.2.4 --- RADIUS --- p.41Chapter 5.2.5 --- Authentication Message Exchange --- p.41Chapter 5.2.6 --- Security Analysis --- p.41Chapter 5.3 --- RSN Key Management --- p.43Chapter 5.3.1 --- RSN Pairwise Key Hierarchy --- p.43Chapter 5.3.2 --- RSN Group Key Hierarchy --- p.43Chapter 5.3.3 --- Four-way Handshake and Group Key Handshake --- p.44Chapter 5.4 --- RSN Encryption and Data Integrity --- p.45Chapter 5.4.1 --- TKIP --- p.45Chapter 5.4.2 --- CCMP --- p.46Chapter 5.5 --- Upper Layer Authentication Protocols --- p.47Chapter 5.5.1 --- Overview on the Upper Layer Authentication --- p.47Chapter 5.5.2 --- EAP-TLS --- p.48Chapter 5.5.3 --- Other Popular ULA Protocols --- p.50Chapter 6 --- Proposed IEEE 802.11i Authentication Scheme --- p.52Chapter 6.1 --- Proposed Protocol --- p.52Chapter 6.1.1 --- Overview --- p.52Chapter 6.1.2 --- The AUTHENTICATE Protocol --- p.56Chapter 6.1.3 --- The RECONNECT Protocol --- p.59Chapter 6.1.4 --- Packet Format --- p.61Chapter 6.1.5 --- Ciphersuites Negotiation --- p.64Chapter 6.1.6 --- Delegation --- p.64Chapter 6.1.7 --- Identity Privacy --- p.68Chapter 6.2 --- Security Considerations --- p.68Chapter 6.2.1 --- Security of the AUTHENTICATE protocol --- p.68Chapter 6.2.2 --- Security of the RECONNECT protocol --- p.69Chapter 6.2.3 --- Security of Key Derivation --- p.70Chapter 6.2.4 --- EAP Security Claims and EAP Methods Requirements --- p.72Chapter 6.3 --- Efficiency Analysis --- p.76Chapter 6.3.1 --- Overview --- p.76Chapter 6.3.2 --- Bandwidth Performance --- p.76Chapter 6.3.3 --- Computation Speed --- p.76Chapter 7 --- Conclusion --- p.79Chapter 7.1 --- Summary --- p.79Chapter 7.2 --- Future Work --- p.80Bibliography --- p.8

    Supporting NAT traversal and secure communications in a protocol implementation framework

    Get PDF
    Dissertação apresentada na Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa para obtenção do Grau de Mestre em Engenharia Electrotécnica e de ComputadoresThe DOORS framework is a versatile, lightweight message-based framework developed in ANSI C++. It builds upon research experience and subsequent knowledge garnered from the use and development of CVOPS and OVOPS, two well known protocol development frameworks that have obtained widespread acceptance and use in both the Finnish industry and academia. It conceptually resides between the operating system and the application, and provides a uniform development environment shielding the developer from operating system speci c issues. It can be used for developing network services, ranging from simple socket-based systems, to protocol implementations, to CORBA-based applications and object-based gateways. Originally, DOORS was conceived as a natural extension from the OVOPS framework to support generic event-based, distributed and client-server network applications. However, DOORS since then has evolved as a platform-level middleware solution for researching the provision of converged services to both packet-based and telecommunications networks, enterprise-level integration and interoperability in future networks, as well as studying application development, multi-casting and service discovery protocols in heterogeneous IPv6 networks. In this thesis, two aspects of development work with DOORS take place. The rst is the investigation of the Network Address Translation (NAT) traversal problem to give support to applications in the DOORS framework that are residing in private IP networks to interwork with those in public IP networks. For this matter this rst part focuses on the development of a client in the DOORS framework for the Session Traversal Utilities for NAT (STUN) protocol, to be used for IP communications behind a NAT. The second aspect involves secure communications. Application protocols in communication networks are easily intercepted and need security in various layers. For this matter the second part focuses on the investigation and development of a technique in the DOORS framework to support the Transport Layer Security (TLS) protocol, giving the ability to application protocols to rely on secure transport layer services

    Analysis and Implementation of the Messaging Layer Security Protocol

    Get PDF
    The use of messaging services on smartphones has increased considerably in recent years, due to the growth in the availability of mobile devices and the evolution of communication technologies via Internet, factors that have effectively replaced the use of text messages. This increase also concerned the use in the business environment, a context where the exchange of confidential information is more frequent and therefore the need to protect communication between two or more people. This is important not only on a security point of view, but also for personal privacy. The major global players have responded by implementing security measures within their services, such as end-to-end encryption and increasingly strict rules regarding the processing of personal data. In this thesis we will illustrate Messaging Layer Security, shortened as MLS, a new protocol under development that guarantees security and efficiency in group conversations. When in a conversation between two clients, security can be ensured through end-to-end encryption and key exchange. The problem arises when multiple actors participate in the conversation asynchronously: in this case the computational effort is considerable, even more so considering the use of mobile devices with reduced battery capacity that does not guarantee the continuous presence of the online device. The thesis will deal with both the architectural part, that is more general and traces the outline of the subject, and the protocol part, more technical and detailed. Finally, an implementation of MLS written in Rust and called Melissa will be illustrated, which provides all the basic functionalities indicated in the draft 05 version of the protocol
    • …
    corecore