Web-based Attacks on Host-Proof Encrypted Storage

International audienceCloud-based storage services, such as Wuala, and pass- word managers, such as LastPass, are examples of so- called host-proof web applications that aim to protect users from attacks on the servers that host their data. To this end, user data is encrypted on the client and the server is used only as a backup data store. Authorized users may access their data through client-side software, but for ease of use, many commercial applications also offer browser-based interfaces that enable features such as remote access, form-filling, and secure sharing.We describe a series of web-based attacks on popular host-proof applications that completely circumvent their cryptographic protections. Our attacks exploit standard web application vulnerabilities to expose flaws in the encryption mechanisms, authorization policies, and key management implemented by these applications. Our analysis suggests that host-proofing by itself is not enough to protect users from web attackers, who will simply shift their focus to flaws in client-side interfaces

Formal Modeling and Verification for Domain Validation and ACME

Web traffic encryption has shifted from applying only to highly sensitive websites (such as banks) to a majority of all Web requests. Until recently, one of the main limiting factors for enabling HTTPS is the requirement to obtain a valid certificate from a trusted certification authority, a tedious process that typically involves fees and ad-hoc key generation, certificate request and domain validation procedures. To remove this barrier of entry, the Internet Security Research Group created Let's Encrypt, a new non-profit certificate authority which uses a new protocol called Automatic Certificate Management Environment (ACME) to automate certificate management at all levels (request, validation , issuance, renewal, and revocation) between clients (website operators) and servers (certificate authority nodes). Let's Encrypt's success is measured by its issuance of over 12 million free certificates since its launch in April 2016. In this paper, we survey the existing process for issuing domain-validated certificates in major certification authorities to build a security model of domain-validated certificate issuance. We then model the ACME protocol in the applied pi-calculus and verify its stated security goals against our threat model of domain validation. We compare the effective security of different domain validation methods and show that ACME can be secure under a stronger threat model than that of traditional CAs. We also uncover weaknesses in some flows of ACME 1.0 and propose verified improvements that have been adopted in the latest protocol draft submitted to the IETF

Embedding of Security Components in Untrusted Third-Party Websites

Security-sensitive components, such as single sign-on APIs, need to be safely deployed on untrusted webpages. We present several new attacks on security components used in popular web applications that demonstrate how failing to isolate such components leaves them vulnerable to attacks both from the hosting website and other components loaded on the same page. These attacks are not prevented by browser security mechanisms alone, because they are caused by code interacting within the same origin. To mitigate these attacks, we propose to combine fine-grained component isolation at the JavaScript level with cryptographic mechanisms. We present Defensive JavaScript (DJS), a subset of the language that guarantees the behavioral integrity of trusted scripts loaded in an untrusted page. We give a sound type system, type inference tool and build defensive libraries for cryptography and data encodings. We show the effectiveness of our solution by implementing several isolation patterns that fix some of our original attacks. We use a translation of a fragment of DJS to to applied pi-calculus to verify concrete security policies of critical components against various classes of web attackers.Certaines librairies critiques pour la sécurité, par exemple pour l'authentification unique (single sign-on), nécéssitent d'être chargées dans des sites tiers non sûrs. Nous montrons comment le manque d'isolation entre ces librairies et leur page hôte les rendent vulnérables aux scripts tiers qui partagent le même environnement, y compris pour des services très largements utilisés. Les mécanismes de sécurité des navigateurs sont impuissants face à ces attaques car elles interviennent en dessous de la granularité des politiques de sécurité, fixée par origine (protocole, nom de domaine et numéro de port). Afin de mitiger ces attaques, nous proposons de combiner une isolation fine de ces librairies au niveau du langage avec des protections cryptographiques. À cette fin, nous introduisons DJS, un fragment de JavaScript qui protège l'intégrité de l'exécution d'un script dans un environnement JavaScript hostile. Nous nous appuyons sur un système de types inférables et sur un ensemble de librairies (elles-même bien typées) pour implémenter des solutions génériques aux attaques que nous avons découvertes. Nous vérifions la validité de ces schémas à l'aide d'une traduction d'un sous-ensemble de DJS vers le pi-calcul appliqué contre différent types d'attaques

Cinderella: Turning Shabby X.509 Certificates into Elegant Anonymous Credentials with the Magic of Verifiable Computation

Abstract-Despite advances in security engineering, authentication in applications such as email and the Web still primarily relies on the X.509 public key infrastructure introduced in 1988. This PKI has many issues but is nearly impossible to replace. Leveraging recent progress in verifiable computation, we propose a novel use of existing X.509 certificates and infrastructure. Instead of receiving & validating chains of certificates, our applications receive & verify proofs of their knowledge, their validity, and their compliance with application policies. This yields smaller messages (by omitting certificates), stronger privacy (by hiding certificate contents), and stronger integrity (by embedding additional checks, e.g. for revocation). X.509 certificate validation is famously complex and errorprone, as it involves parsing ASN.1 data structures and interpreting them against diverse application policies. To manage this diversity, we propose a new format for writing application policies by composing X.509 templates, and we provide a template compiler that generates C code for validating certificates within a given policy. We then use the Geppetto cryptographic compiler to produce a zero-knowledge verifiable computation scheme for that policy. To optimize the resulting scheme, we develop new C libraries for RSA-PKCS#1 signatures and ASN.1 parsing, carefully tailored for cryptographic verifiability. We evaluate our approach by providing two real-world applications of verifiable computation: a drop-in replacement for certificates within TLS; and access control for the Helios voting protocol. For TLS, we support fine-grained validation policies, with revocation checking and selective disclosure of certificate contents, effectively turning X.509 certificates into anonymous credentials. For Helios, we obtain additional privacy and verifiability guarantees for voters equipped with X.509 certificates, such as those readily available from some national ID cards

State Separation for Code-Based Game-Playing Proofs

The security analysis of real-world protocols involves reduction steps that are conceptually simple but still have to account for many protocol complications found in standards and implementations. Taking inspiration from universal composability, abstract cryptography, process algebras, and type-based verification frameworks, we propose a method to simplify large reductions, avoid mistakes in carrying them out, and obtain concise security statements. Our method decomposes monolithic games into collections of stateful *packages* representing collections of oracles that call one another using well-defined interfaces. Every component scheme yields a pair of a real and an ideal package. In security proofs, we then successively replace each real package with its ideal counterpart, treating the other packages as the reduction. We build this reduction by applying a number of algebraic operations on packages justified by their state separation. Our method handles reductions that emulate the game perfectly, and leaves more complex arguments to existing game-based proof techniques such as the code-based analysis suggested by Bellare and Rogaway. It also facilitates computer-aided proofs, inasmuch as the perfect reductions steps can be automatically discharged by proof assistants. We illustrate our method on two generic composition proofs: (1) a proof of self-composition using a hybrid argument; and (2) the composition of keying and keyed components. For concreteness, we apply them to the KEM-DEM proof of hybrid-encryption by Cramer and Shoup and to the composition of forward-secure game-based key exchange protocols with symmetric-key protocols

Key-schedule Security for the TLS 1.3 Standard

We analyze the security of the TLS 1.3 key establishment protocol, as specified at the end of its rigorous standardization process. We define a core key-schedule and reduce its security to concrete assumptions against an adversary that controls client and server configurations and adaptively chooses some of their keys. Our model supports all key derivations featured in the standard, including its negotiated modes and algorithms that combine an optional Diffie-Hellman exchange for forward secrecy with optional pre-shared keys supplied by the application or recursively established in prior sessions. We show that the output keys are secure as soon as any of their input key materials are. Our compositional, code-based proof makes use of state separation to yield concrete reductions despite the complexity of the key schedule. We also discuss (late) changes to the standard that would improve its robustness and simplify its analysis

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 Security Model and Fully Verified Implementation for the IETF QUIC Record Layer

We investigate the security of the QUIC record layer, as standardized by the IETF in draft version 30. This version features major differences compared to Google\u27s original protocol and prior IETF drafts. We model packet and header encryption, which uses a custom construction for privacy. To capture its goals, we propose a security definition for authenticated encryption with semi-implicit nonces. We show that QUIC uses an instance of a generic construction parameterized by a standard AEAD-secure scheme and a PRF-secure cipher. We formalize and verify the security of this construction in F*. The proof uncovers interesting limitations of nonce confidentiality, due to the malleability of short headers and the ability to choose the number of least significant bits included in the packet counter. We propose improvements that simplify the proof and increase robustness against strong attacker models. In addition to the verified security model, we also give concrete functional specification for the record layer, and prove that it satisfies important functionality properties (such as successful decryption of encrypted packets) after fixing more errors in the draft. We then provide a high-performance implementation of the record layer that we prove to be memory safe, correct with respect to our concrete specification (inheriting its functional correctness properties), and secure with respect to our verified model. To evaluate this component, we develop a provably-safe implementation of the rest of the QUIC protocol. Our record layer achieves nearly 2 GB/s throughput, and our QUIC implementation\u27s performance is within 21% of an unverified baseline

Implementing and Proving the TLS 1.3 Record Layer

International audienceThe record layer is the main bridge between TLS applications and internal sub-protocols. Its corefunctionality is an elaborate form of authenticated encryption: streams of messages for each sub-protocol(handshake, alert, and application data) are fragmented, multiplexed, and encrypted with optionalpadding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal streamtermination to the record layer.Compared to prior versions, TLS 1.3 discards obsolete schemes in favor of a common construction forAuthenticated Encryption with Associated Data (AEAD), instantiated with algorithms such as AESGCMand ChaCha20-Poly1305. It differs from TLS 1.2 in its use of padding, associated data and nonces.It also encrypts the content-type used to multiplex between sub-protocols. New protocol features suchas early application data (0-RTT and 0.5-RTT) and late handshake messages require additional keysand a more general model of stateful encryption.We build and verify a reference implementation of the TLS record layer and its cryptographic algorithmsin F?, a dependently typed language where security and functional guarantees can be specifiedas pre- and post-conditions. We reduce the high-level security of the record layer to cryptographic assumptionson its ciphers. Each step in the reduction is verified by typing an F? module; for each stepthat involves a cryptographic assumption, this module precisely captures the corresponding game.We first verify the functional correctness and injectivity properties of our implementations of onetimeMAC algorithms (Poly1305 and GHASH) and provide a generic proof of their security given thesetwo properties. We show the security of a generic AEAD construction built from any secure onetimeMAC and PRF. We extend AEAD, first to stream encryption, then to length-hiding, multiplexedencryption. Finally, we build a security model of the record layer against an adversary that controls theTLS sub-protocols. We compute concrete security bounds for the AES_128_GCM, AES_256_GCM,and CHACHA20_POLY1305 ciphersuites, and derive recommended limits on sent data before re-keying.We plug our implementation of the record layer into the miTLS library, confirm that they interoperatewith Chrome and Firefox, and report initial performance results. Combining our functional correctness,security, and experimental results, we conclude that the new TLS record layer (as described in RFCsand cryptographic standards) is provably secure, and we provide its first verified implementation

Confidential Consortium Framework: Secure Multiparty Applications with Confidentiality, Integrity, and High Availability

Confidentiality, integrity protection, and high availability, abbreviated to CIA, are essential properties for trustworthy data systems. The rise of cloud computing and the growing demand for multiparty applications however means that building modern CIA systems is more challenging than ever. In response, we present the Confidential Consortium Framework (CCF), a general-purpose foundation for developing secure stateful CIA applications. CCF combines centralized compute with decentralized trust, supporting deployment on untrusted cloud infrastructure and transparent governance by mutually untrusted parties. CCF leverages hardware-based trusted execution environments for remotely verifiable confidentiality and code integrity. This is coupled with state machine replication backed by an auditable immutable ledger for data integrity and high availability. CCF enables each service to bring its own application logic, custom multiparty governance model, and deployment scenario, decoupling the operators of nodes from the consortium that governs them. CCF is open-source and available now at https://github.com/microsoft/CCF.Comment: 16 pages, 9 figures. To appear in the Proceedings of the VLDB Endowment, Volume 1