Multi-ciphersuite security of the Secure Shell (SSH) protocol

The Secure Shell (SSH) protocol is widely used to provide secure remote access to servers, making it among the most important security protocols on the Internet. We show that the signed-Diffie--Hellman SSH ciphersuites of the SSH protocol are secure: each is a secure authenticated and confidential channel establishment (ACCE) protocol, the same security definition now used to describe the security of Transport Layer Security (TLS) ciphersuites. While the ACCE definition suffices to describe the security of individual ciphersuites, it does not cover the case where parties use the same long-term key with many different ciphersuites: it is common in practice for the server to use the same signing key with both finite field and elliptic curve Diffie--Hellman, for example. While TLS is vulnerable to attack in this case, we show that SSH is secure even when the same signing key is used across multiple ciphersuites. We introduce a new generic multi-ciphersuite composition framework to achieve this result in a black-box way

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

On the Practical (In-)Security of 64-bit Block Ciphers: Collision Attacks on HTTP over TLS and OpenVPN

International audienceWhile modern block ciphers, such as AES, have a block size of at least 128 bits, there are many 64-bit block ciphers, such as 3DES and Blowfish, that are still widely supported in Internet security protocols such as TLS, SSH, and IPsec. When used in CBC mode, these ciphers are known to be susceptible to collision attacks when they are used to encrypt around 2^32 blocks of data (the so-called birthday bound). This threat has traditionally been dismissed as impractical since it requires some prior knowledge of the plaintext and even then, it only leaks a few secret bits per gigabyte. Indeed, practical collision attacks have never been demonstrated against any mainstream security protocol, leading to the continued use of 64-bit ciphers on the Internet. In this work, we demonstrate two concrete attacks that exploit collisions on short block ciphers. First, we present an attack on the use of 3DES in HTTPS that can be used to recover a secret session cookie. Second, we show how a similar attack on Blowfish can be used to recover HTTP BasicAuth credentials sent over OpenVPN connections. In our proof-of-concept demos, the attacker needs to capture about 785GB of data, which takes between 19-38 hours in our setting. This complexity is comparable to the recent RC4 attacks on TLS: the only fully implemented attack takes 75 hours. We evaluate the impact of our attacks by measuring the use of 64-bit block ciphers in real-world protocols. We discuss mitigations, such as disabling all 64-bit block ciphers, and report on the response of various software vendors to our responsible disclosure of these attacks

Post-quantum key exchange for the TLS protocol from the ring learning with errors problem

Lattice-based cryptographic primitives are believed to offer resilience against attacks by quantum computers. We demonstrate the practicality of post-quantum key exchange by constructing ciphersuites for the Transport Layer Security (TLS) protocol that provide key exchange based on the ring learning with errors (R-LWE) problem; we accompany these ciphersuites with a rigorous proof of security. Our approach ties lattice-based key exchange together with traditional authentication using RSA or elliptic curve digital signatures: the post-quantum key exchange provides forward secrecy against future quantum attackers, while authentication can be provided using RSA keys that are issued by today\u27s commercial certificate authorities, smoothing the path to adoption. Our cryptographically secure implementation, aimed at the 128-bit security level, reveals that the performance price when switching from non-quantum-safe key exchange is not too high. With our R-LWE ciphersuites integrated into the OpenSSL library and using the Apache web server on a 2-core desktop computer, we could serve 506 RLWE-ECDSA-AES128-GCM-SHA256 HTTPS connections per second for a 10 KiB payload. Compared to elliptic curve Diffie--Hellman, this means an 8 KiB increased handshake size and a reduction in throughput of only 21%. This demonstrates that provably secure post-quantum key-exchange can already be considered practical

Segurança na arquitetura TCP/IP : de firewalls a canais seguros

Orientador: Paulo Licio de GeusArquivo incompleto - falta página 78Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de ComputaçãoResumo: O espectro de protocolos e aplicações TCP/IP é provavelmente tão amplo quanto é premente a necessidade de mecanismos de segurança nesta arquitetura. O alcance deste aspecto de segurança vai desde a segurança intrínseca de sistemas operacionais, passando por firewalls, criptografia e canais seguros, até aplicações especificas. De maneira geral, poucas referências tratam este problema de maneira completa, especialmente no que se refere à criptografia e sua relação com os protocolos TCP/IP seguros. Desta forma, o foco principal deste trabalho é enumerar os problemas inerentes à arquitetura TCP/IP, tratando as questões de segurança com especial ênfase na tecnologia de firewalls e nos algoritmos de criptografia, assim como na sua relação na construção de canais seguros de comunicação. Como aplicação deste estudo, obteve-se diretrizes para o desenvolvimento de aplicações críticas do ponto de vista de segurança em ambiente HTML/HTTPS, as quais serviram de base para a implementação do produto de Internet banking do BankBoston no Brasil.Abstract: The range of TCP/IP protocols and applications is probably as wide as is strong the need for security mechanisms in this architecture. The scope of the security aspects goes from the inherent security of operating systems, through firewalls, cryptography and secure channels, up to specific applications. As a general rule, little literature deals thoroughly with this issue, especially with regards to cryptography and its relation to secure TCP/IP protocols. As such, this work focuses on enumerating the intrinsic problems of the TCP/IP architecture, dealing with the security issues with special emphasis in firewall technology and in cryptographic algorithms, as well as in their relation with regards to building secure communication channels. As an application for this study, directions for the development of critical security applications in an HTML/HTTPS environment were obtained, which were the basis for the implementation of the Internet banking system for BankBoston in Brazil.MestradoMestre em Ciência da Computaçã

Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

International audienceWe investigate the security of Diffie-Hellman key exchange as used in popular Internet protocols and find it to be less secure than widely believed. First, we present Logjam, a novel flaw in TLS that lets a man-in-the-middle downgrade connections to " export-grade " Diffie-Hellman. To carry out this attack, we implement the number field sieve discrete log algorithm. After a week-long precomputation for a specified 512-bit group, we can compute arbitrary discrete logs in that group in about a minute. We find that 82% of vulnerable servers use a single 512-bit group, allowing us to compromise connections to 7% of Alexa Top Million HTTPS sites. In response, major browsers are being changed to reject short groups. We go on to consider Diffie-Hellman with 768-and 1024-bit groups. A small number of fixed or standardized groups are in use by millions of servers. Performing precomputations for just ten of these groups would allow a passive eavesdropper to decrypt traffic to up to 66% of IPsec VPN servers, 26% of SSH servers, 24% of popular HTTPS sites, or 16% of SMTP servers. In the 1024-bit case, we estimate that such computations are plausible given nation-state resources, and a close reading of published NSA leaks shows that the agency's attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community

Imperfect forward secrecy: How Diffie-Hellman fails in practice

International audienceWe investigate the security of Diffie-Hellman key exchange as used in popular Internet protocols and find it to be less secure than widely believed. First, we present Logjam, a novel flaw in TLS that lets a man-in-the-middle downgrade connections to "export-grade" Diffie-Hellman. To carry out this attack, we implement the number field sieve discrete logarithm algorithm. After a week-long precomputation for a specified 512-bit group, we can compute arbitrary discrete logarithms in that group in about a minute. We find that 82% of vulnerable servers use a single 512-bit group, and that 8.4% of Alexa Top Million HTTPS sites are vulnerable to the attack. a In response, major browsers have changed to reject short groups. We go on to consider Diffie-Hellman with 768-and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency's attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community

Safely Exporting Keys from Secure Channels: On the Security of EAP-TLS and TLS Key Exporters

We investigate how to safely export additional cryptographic keys from secure channel protocols, modeled with the authenticated and confidential channel establishment (ACCE) security notion. For example, the EAP-TLS protocol uses the Transport Layer Security (TLS) handshake to output an additional shared secret which can be used for purposes outside of TLS, and the RFC 5705 standard specifies a general mechanism for exporting keying material from TLS. We show that, for a class of ACCE protocols we call “TLS-like” protocols, the EAP-TLS transformation can be used to export an additional key, and that the result is a secure AKE protocol in the Bellare–Rogaway model. Interestingly, we are able to carry out the proof without looking at the specifics of the TLS protocol itself (beyond the notion that it is “TLS-like”), but rather are able to use the ACCE property in a semi black-box way. To facilitate our modular proof, we develop a novel technique, notably an encryption-based key checking mechanism that is used by the security reduction. Our results imply that EAP-TLS using secure TLS 1.2 cipher-suites is a secure authenticated key exchange protocol

Beyond Modes: Building a Secure Record Protocol from a Cryptographic Sponge Permutation

Abstract. BLINKER is a light-weight cryptographic suite and record protocol built from a single permutation. Its design is based on the Sponge construction used by the SHA-3 algorithm KECCAK. We examine the SpongeWrap authen-ticated encryption mode and expand its padding mechanism to offer explicit do-main separation and enhanced security for our specific requirements: shared se-cret half-duplex keying, encryption, and a MAC-and-continue mode. We motivate these enhancements by showing that unlike legacy protocols, the resulting record protocol is secure against a two-channel synchronization attack while also having a significantly smaller implementation footprint. The design facilitates security proofs directly from a single cryptographic primitive (a single security assump-tion) rather than via idealization of multitude of algorithms, paddings and modes of operation. The protocol is also uniquely suitable for an autonomous or semi-autonomous hardware implementation of protocols where the secrets never leave the module, making it attractive for smart card and HSM designs

Nation-State Attackers and their Effects on Computer Security

Nation-state intelligence agencies have long attempted to operate in secret, but recent revelations have drawn the attention of security researchers as well as the general public to their operations. The scale, aggressiveness, and untargeted nature of many of these now public operations were not only alarming, but also baffling as many were thought impossible or at best infeasible at scale. The security community has since made many efforts to protect end-users by identifying, analyzing, and mitigating these now known operations. While much-needed, the security community's response has largely been reactionary to the oracled existence of vulnerabilities and the disclosure of specific operations. Nation-State Attackers, however, are dynamic, forward-thinking, and surprisingly agile adversaries who do not rest on their laurels and are continually advancing their efforts to obtain information. Without the ability to conceptualize their actions, understand their perspective, or account for their presence, the security community's advances will become antiquated and unable to defend against the progress of Nation-State Attackers. In this work, we present and discuss a model of Nation-State Attackers that can be used to represent their attributes, behavior patterns, and world view. We use this representation of Nation-State Attackers to show that real-world threat models do not account for such highly privileged attackers, to identify and support technical explanations of known but ambiguous operations, and to identify and analyze vulnerabilities in current systems that are favorable to Nation-State Attackers.PHDComputer Science & EngineeringUniversity of Michigan, Horace H. Rackham School of Graduate Studieshttps://deepblue.lib.umich.edu/bitstream/2027.42/143907/1/aaspring_1.pd