Proving the TLS Handshake Secure (As It Is)

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

Content delivery over TLS: a cryptographic analysis of keyless SSL

The Transport Layer Security (TLS) protocol is designed to allow two parties, a client and a server, to communicate securely over an insecure network. However, when TLS connections are proxied through an intermediate middlebox, like a Content Delivery Network (CDN), the standard endto- end security guarantees of the protocol no longer apply. In this paper, we investigate the security guarantees provided by Keyless SSL, a CDN architecture currently deployed by CloudFlare that composes two TLS 1.2 handshakes to obtain a proxied TLS connection. We demonstrate new attacks that show that Keyless SSL does not meet its intended security goals. These attacks have been reported to CloudFlare and we are in the process of discussing fixes. We argue that proxied TLS handshakes require a new, stronger, 3-party security definition. We present 3(S)ACCEsecurity, a generalization of the 2-party ACCE security definition that has been used in several previous proofs for TLS. We modify Keyless SSL and prove that our modifications guarantee 3(S)ACCE-security, assuming ACCE-security for the individual TLS 1.2 connections. We also propose a new design for Keyless TLS 1.3 and prove that it achieves 3(S)ACCEsecurity, assuming that the TLS 1.3 handshake implements an authenticated 2-party key exchange. Notably, we show that secure proxying in Keyless TLS 1.3 is computationally lighter and requires simpler assumptions on the certificate infrastructure than our proposed fix for Keyless SSL. Our results indicate that proxied TLS architectures, as currently used by a number of CDNs, may be vulnerable to subtle attacks and deserve close attention

A Messy State of the Union: Taming the Composite State Machines of TLS

To appearInternational audienceImplementations of the Transport Layer Security (TLS) protocol must handle a variety of protocol versions and extensions, authentication modes, and key exchange methods. Confusingly, each combination may prescribe a different message sequence between the client and the server. We address the problem of designing a robust composite state machine that correctly multiplexes between these different protocol modes. We systematically test popular open-source TLS implementations for state machine bugs and discover several critical security vulnerabilities that have lain hidden in these libraries for years, and have now finally been patched due to our disclosures. Several of these vulnerabilities, including the recently publicized FREAK flaw, enable a network attacker to break into TLS connections between authenticated clients and servers. We argue that state machine bugs stem from incorrect compositions of individually correct state machines. We present the first verified implementation of a composite TLS state machine in C that can be embedded into OpenSSL and accounts for all its supported ciphersuites. Our attacks expose the need for the formal verifica- tion of core components in cryptographic protocol libraries; our implementation demonstrates that such mechanized proofs are within reach, even for mainstream TLS implementations

A Multi-User, Single-Authentication Protocol for Smart Grid Architectures

open access articleIn a smart grid system, the utility server collects data from various smart grid devices. These data play an important role in the energy distribution and balancing between the energy providers and energy consumers. However, these data are prone to tampering attacks by an attacker, while traversing from the smart grid devices to the utility servers, which may result in energy disruption or imbalance. Thus, an authentication is mandatory to efficiently authenticate the devices and the utility servers and avoid tampering attacks. To this end, a group authentication algorithm is proposed for preserving demand–response security in a smart grid. The proposed mechanism also provides a fine-grained access control feature where the utility server can only access a limited number of smart grid devices. The initial authentication between the utility server and smart grid device in a group involves a single public key operation, while the subsequent authentications with the same device or other devices in the same group do not need a public key operation. This reduces the overall computation and communication overheads and takes less time to successfully establish a secret session key, which is used to exchange sensitive information over an unsecured wireless channel. The resilience of the proposed algorithm is tested against various attacks using formal and informal security analysis

A new construction for linkable secret handshake

National Research Foundation (NRF) Singapore; AXA Research Fun

Internet security for mobile computing

Mobile devices are now the most dominant computer platform. Every time a mobile web application accesses the internet, the end user’s data is susceptible to malicious attacks. For instance, when paying a bill at a store with NFC mobile payment, navigating through a city operating GPS on a smartphone, or dictating the temperature at a household with a home automation device. These activities seem routine, yet, when vulnerabilities are present they can leave holes for hackers to access bank accounts, pinpoint a user’s recent location, or tell when someone is not at home. The awareness of the end user cannot be trusted. Device vendors and developers must provide safeguards. An ongoing issue is that the present security standards are outdated and were never envisioned with mobile devices in mind. It can be suggested that security is only idling the progress of mobile computing. Still, many application developers and IT professionals do not adopt security standards fast enough to keep up-to-date with known vulnerabilities. The main goals of the next generation of security standards, TLS, will provide developers with greater security efficiency and improved mobile throughput. These proposed capabilities of the TLS protocol will streamline mobile computing into the forefront of security practices. The analysis of this report demonstrates concepts on the direction mobile security, usability, and performance from a development standpoint.Electrical and Computer Engineerin

Towards Forward Secure Internet Traffic

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

Denial-of-Service Resistance in Key Establishment

Denial of Service (DoS) attacks are an increasing problem for network connected systems. Key establishment protocols are applications that are particularly vulnerable to DoS attack as they are typically required to perform computationally expensive cryptographic operations in order to authenticate the protocol initiator and to generate the cryptographic keying material that will subsequently be used to secure the communications between initiator and responder. The goal of DoS resistance in key establishment protocols is to ensure that attackers cannot prevent a legitimate initiator and responder deriving cryptographic keys without expending resources beyond a responder-determined threshold. In this work we review the strategies and techniques used to improve resistance to DoS attacks. Three key establishment protocols implementing DoS resistance techniques are critically reviewed and the impact of misapplication of the techniques on DoS resistance is discussed. Recommendations on effectively applying resistance techniques to key establishment protocols are made

Private Handshakes

Private handshaking allows pairs of users to determine which (secret) groups they are both a member of. Group membership is kept secret to everybody else. Private handshaking is a more private form of secret handshaking, because it does not allow the group administrator to trace users. We extend the original definition of a handshaking protocol to allow and test for membership of multiple groups simultaneously. We present simple and efficient protocols for both the single group and multiple group membership case. Private handshaking is a useful tool for mutual authentication, demanded by many pervasive applications (including RFID) for privacy. Our implementations are efficient enough to support such usually resource constrained scenarios