No abstract

TLS is the most important cryptographic protocol in use today. However, up to now there is no complete cryptographic security proof in the standard model, nor in any other model. We give the first such proof for the core cryptographic protocol of TLS ciphersuites based on ephemeral Diffie-Hellman key exchange (TLS-DHE), which include the cipher suite TLS DHE DSS WITH 3DES EDE CBC SHA mandatory in TLS 1.0 and TLS 1.1.It is impossible to prove security of the TLS Handshake in any classical key-indistinguishabilitybased security model (like e.g. the Bellare-Rogaway or the Canetti-Krawczyk model), due to subtle issues with the encryption of the final Finished messages of the TLS Handshake. Therefore we start with proving the security of a truncated version of the TLS Handshake protocol, which has also been considered in previous work on TLS.Then we define the notion of authenticated and confidential channel establishment (ACCE) as a new security model which captures precisely the security properties expected from TLS in practice, and show that the combination of the TLS Handshake protocol with the TLS Record Layer can be proven secure in this model.

Abstract. One-round authenticated key exchange (ORKE) is an established research area, with many prominent protocol constructions like HMQV (Krawczyk, CRYPTO 2005) and Naxos (La Macchia et al., ProvSec 2007), and many slightly different, strong security models. Most constructions combine ephemeral and static Diffie-Hellman Key Exchange (DHKE), in a manner often closely tied to the underlying security model. We give a generic construction of ORKE protocols from general assumptions, with security in the standard model, and in a strong security model where the attacker is even allowed to learn the randomness or the longterm secret of either party in the target session. The only restriction is that the attacker must not learn both the randomness and the long-term secret of one party of the target session, since this would allow him to recompute all internal states of this party, including the session key. This is the first such construction that does not rely on random oracles. The construction is intuitive, relatively simple, and efficient. It uses only standard primitives, namely non-interactive key exchange, a digital signature scheme, and a pseudorandom function, with standard security properties, as building blocks.

No abstract

Due to their high practical impact, Cross-Site Scripting (XSS) attacks have attracted a lot of attention from the members of security community worldwide. In the same way, a plethora of more or less effective defense techniques have been proposed, addressing both causes and effects of XSS vulnerabilities. As a result, an adversary often can no longer inject or even execute arbitrary scripting code in several reallife scenarios. In this article, we examine an attack surface that remains after XSS and similar scripting attacks are supposedly mitigated by preventing an attacker from executing JavaScript code. We address the question of whether an attacker really needs to execute JavaScript or similar functionality to perform attacks aiming for information theft. The surprising result is that an attacker can abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images, or font files. Having employed several case studies, we discuss so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well-protected websites. More precisely, we show that an attacker can use seemingly benign features to build side-channel attacks that measure and exfiltrate almost arbitrary data displayed on a given webpage. We conclude this article with a discussion of potential mitigation techniques against this class of attacks. In addition, we have implemented a browser patch that enables a website to make a vital determination as to being loaded in a detached view or a pop-up window. This approach proves useful for prevention of certain types of attacks we here discuss.

Abstract. The standard solution for user authentication on the Web is to establish a TLS-based secure channel in server authenticated mode and run a protocol on top of TLS where the user enters a password in an HTML form. However, as many studies point out, the average Internet user is unable to identify the server based on a X.509 certificate so that impersonation attacks (e.g., phishing) are feasible. We tackle this problem by proposing a protocol that allows the user to identify the server based on human perceptible authenticators (e.g., picture, voice). We prove the security of this protocol by refining the game-based security model of Bellare and Rogaway and present a proof of concept implementation.

Encrypted key transport with RSA-PKCS#1 v1.5 is the most commonly deployed key exchange method in all current versions of the Transport Layer Security (TLS) protocol, including the most recent version 1.2. However, it has several well-known issues, most importantly that it does not provide forward secrecy, and that it is prone to side channel attacks that may enable an attacker to learn the session key used for a TLS session. A long history of attacks shows that RSA-PKCS#1 v1.5 is extremely difficult to implement securely. The current draft of TLS version 1.3 dispenses with this encrypted key transport method. But is this sufficient to protect against weaknesses in RSA-PKCS#1 v1.5? We describe attacks which transfer the potential weakness of prior TLS versions to two recently proposed protocols that do not even support PKCS#1 v1.5 encryption, namely Google's QUIC protocol and TLS 1.3. These attacks enable an attacker to impersonate a server by using a vulnerable TLS-RSA server implementation as a "signing oracle" to compute valid signatures for messages chosen by the attacker. The first attack (on TLS 1.3) requires a very fast "Bleichenbacheroracle" to create the TLS CertificateVerify message before the client drops the connection. Even though this limits the practical impact of this attack, it demonstrates that simply removing a legacy algorithm from a standard is not necessarily sufficient to protect against its weaknesses. The second attack on Google's QUIC protocol is much more practical. It can also be applied in settings where forging a signature with the help of a "Bleichenbacher-oracle" may take an extremely long time. This is because signed values in QUIC are independent of the client's connection request. Therefore the attacker is able to pre-compute the signature long before the client starts a connection. This makes the attack practical. Moreover, the impact on QUIC is much more dramatic, because creating a single forged signature is essentially equivalent to retrieving the long-term secret key of the server.

No abstract