A Framework for the Cryptographic Verification of Java-Like Programs

Küsters, Ralf; Truderung, Tomasz; Graf, Jürgen

doi:10.1109/csf.2012.9

Cited by 34 publications

(65 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The F* programming language [78] has been used to verify small protocols and cryptographic libraries [82]. Similar techniques have been applied to the cryptographic verification of Java programs [59].…”

Section: Inriamentioning

confidence: 99%

Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate

Bhargavan

Blanchet

Kobeissi

2017

2017 IEEE Symposium on Security and Privacy (SP)

139

View full text Add to dashboard Cite

TLS 1.3 is the next version of the Transport Layer Security (TLS) protocol. Its clean-slate design is a reaction both to the increasing demand for low-latency HTTPS connections and to a series of recent high-profile attacks on TLS. The hope is that a fresh protocol with modern cryptography will prevent legacy problems; the danger is that it will expose new kinds of attacks, or reintroduce old flaws that were fixed in previous versions of TLS. After 18 drafts, the protocol is nearing completion, and the working group has appealed to researchers to analyze the protocol before publication. This paper responds by presenting a comprehensive analysis of the TLS 1.3 Draft-18 protocol. We seek to answer three questions that have not been fully addressed in previous work on TLS 1.3: (1) Does TLS 1.3 prevent well-known attacks on TLS 1.2, such as Logjam or the Triple Handshake, even if it is run in parallel with TLS 1.2? (2) Can we mechanically verify the computational security of TLS 1.3 under standard (strong) assumptions on its cryptographic primitives? (3) How can we extend the guarantees of the TLS 1.3 protocol to the details of its implementations? To answer these questions, we propose a methodology for developing verified symbolic and computational models of TLS 1.3 hand-in-hand with a high-assurance reference implementation of the protocol. We present symbolic ProVerif models for various intermediate versions of TLS 1.3 and evaluate them against a rich class of attacks to reconstruct both known and previously unpublished vulnerabilities that influenced the current design of the protocol. We present a computational CryptoVerif model for TLS 1.3 Draft-18 and prove its security. We present RefTLS, an interoperable implementation of TLS 1.0-1.3 and automatically analyze its protocol core by extracting a ProVerif model from its typed JavaScript code. Résumé : TLS 1.3 est la prochaine version du protocole TLS (Transport Layer Security). Sa conception à partir de zéro est une réaction à la fois à la demande croissante de connexions HTTPS à faible latence et à une série d'attaques récentes de haut niveau sur TLS. L'espoir est qu'un nouveau protocole avec de la cryptographie moderne éviterait d'hériter des problèmes des versions précédentes; le danger est que cela pourrait exposer à de nouveaux types d'attaques ou réintroduire d'anciens défauts corrigés dans les versions précédentes de TLS. Après 18 versions préliminaires, le protocole est presque terminé, et le groupe de travail a appelé les chercheurs à analyser le protocole avant publication. Cet article répond en présentant une analyse globale du protocole TLS 1.3 Draft-18.Nous cherchons à répondre à trois questions qui n'ont pas été entièrement traitées dans les travaux antérieurs sur TLS 1.3: (1) TLS 1.3 empêche-t-il les attaques connues sur TLS 1.2, comme Logjam ou Triple Handshake, même s'il est exécuté en parallèle avec TLS 1.2 ? (2) Peuton vérifier mécaniquement la sécurité calculatoire de TLS 1.3 sous des hypothèses standard (fortes) sur ses primitives...

show abstract

Section: Inriamentioning

confidence: 99%

Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate

Bhargavan

Blanchet

Kobeissi

2017

2017 IEEE Symposium on Security and Privacy (SP)

139

View full text Add to dashboard Cite

show abstract

“…We refer the reader to [19] for a full description of the framework. The CVJ framework is formulated for the language Jinja+ which comprises a rich fragment of Java.…”

Section: The Cvj Frameworkmentioning

confidence: 99%

“…To achieve this, we add oblivious transfer as a cryptographic building block to the framework for Cryptographic Verification of Javalike programs by Küsters et al [19,21]. That is, we provide an ideal interface in Java for oblivious transfer following the ideal OT functionality of [7] for Canetti's UC-framework [5].…”

Section: Introductionmentioning

confidence: 99%

“…In the next section we introduce some preliminaries, in particular we introduce the framework for the Cryptographic Verification of Java Programs by Küsters et al [19]. Furthermore, we briefly introduce cryptographic building blocks used in this paper, the specification language Java Modelling Language and the interactive theorem prover KeY.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Proving Correctness and Security of Two-Party Computation Implemented in Java in Presence of a Semi-honest Sender

Böhl

Greiner

Scheidecker

2014

Cryptology and Network Security

View full text Add to dashboard Cite

Abstract. We provide a proof of correctness and security of a two-party-computation protocol based on garbled circuits and oblivious transfer in the presence of a semi-honest sender. To achieve this we are the first to combine a machine-assisted proof of correctness with advanced cryptographic primitives to prove security properties of Java code. The machine-assisted part of the proof is conducted with KeY, an interactive theorem prover. The proof includes a correctness result for the construction and evaluation of garbled circuits. This is particularly interesting since checking such an implementation by hand would be very tedious and error-prone. Although we stick to the secure two-party-computation of an n-bit AND in this paper, our approach is modular, and we explain how our techniques can be applied to other functions. To prove the security of the protocol for an honest-but-curious sender and an honest receiver, we use the framework presented by Küsters et al. for the cryptographic verification of Java programs. As part of our work, we add oblivious transfer to the set of cryptographic primitives supported by the framework. This is a general contribution beyond our results for concrete Java code.

show abstract

“…While this solution is far from proving correctness of the actual implementation, as it assumes correctness of big parts of code, it is very manageable and amenable for implementation onto the firmware of real hardware tokens. Some recent work has focused on strong information flow guarantees for generalpurpose programs with cryptographic primitives [15,20]. These techniques have been applied to a different setting, an interesting future work would be to study whether they could be applied to the problem of type-based analysis of key management APIs.…”

Section: Introductionmentioning

confidence: 99%

Type-based analysis of key management in PKCS#11 cryptographic devices

Centenaro

Focardi

Luccio

2013

JCS

View full text Add to dashboard Cite

PKCS#11, is a security API for cryptographic tokens. It is known to be vulnerable to attacks which can directly extract, as cleartext, the value of sensitive keys. In particular, the API does not impose any limitation on the different roles a key can assume, and it permits to perform conflicting operations such as asking the token to wrap a key with another one and then to decrypt it. Fixes proposed in the literature, or implemented in real devices, impose policies restricting key roles and token functionalities. In this paper we define a simple imperative programming language, suitable to code PKCS#11 symmetric key management, and we develop a type-based analysis to prove that the secrecy of sensitive keys is preserved under a certain policy. We formally analyse existing fixes for PKCS#11 and we propose a new one, which is type-checkable and prevents conflicting roles by deriving different keys for different roles. We develop a prototype type-checker for a software token emulator written in C and we experiment on various working configurations.

show abstract

A Framework for the Cryptographic Verification of Java-Like Programs

Cited by 34 publications

References 37 publications

Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate

Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate

Proving Correctness and Security of Two-Party Computation Implemented in Java in Presence of a Semi-honest Sender

Type-based analysis of key management in PKCS#11 cryptographic devices

Contact Info

Product

Resources

About