A Verified Extensible Library of Elliptic Curves Jean Karim Zinzindohoue, Evmorfia-Iro Bartzia, Karthikeyan Bhargavan To cite this version: Jean Karim Zinzindohoue, Evmorfia-Iro Bartzia, Karthikeyan Bhargavan. A Verified Extensible Li- brary of Elliptic Curves. 29th IEEE Computer Security Foundations Symposium (CSF), Jun 2016, Lisboa, Portugal. 10.1109/CSF.2016.28. hal-01425957 HAL Id: hal-01425957 https://hal.inria.fr/hal-01425957 Submitted on 8 Dec 2018 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. A Verified Extensible Library of Elliptic Curves Jean Karim Zinzindohoue´ Evmorfia-Iro Bartzia Karthikeyan Bhargavan ENPC/INRIA INRIA INRIA [email protected] [email protected] [email protected] Abstract—In response to increasing demand for elliptic curve ification and code can be significantly large. Abstractly, such cryptography, and specifically for curves that are free from the primitives compute well-defined mathematical functions in suspicion of influence by the NSA, new elliptic curves such as some finite field, whereas concretely, their implementations Curve25519 and Curve448 are currently being standardized, manipulate arrays of bytes that represent arbitrary precision in- implemented, and deployed in major protocols such as Transport tegers (called bignums). Furthermore, since asymmetric primi- Layer Security. As with all new cryptographic code, the correct- tives are typically much slower and can form the bottleneck in ness of these curve implementations is of concern, because any bug or backdoor in this code can potentially compromise the a cryptographic protocol, most implementations incorporate a security of important Internet protocols. We present a principled range of subtle performance optimizations that further distance approach towards the verification of elliptic curve implementa- the code from the mathematical specification. Consequently, tions by writing them in the dependently-typed programming even for small prime fields, comprehensive testing is ineffec- language F* and proving them functionally correct against a tive for guaranteeing the correctness of asymmetric primitive readable mathematical specification derived from a previous Coq implementations, leading to bugs in even well-vetted crypto- development. A key technical innovation in our work is the use graphic libraries [8], [9]. Even worse, asymmetric primitives of templates to write and verify arbitrary precision arithmetic are often used with long-term keys, hence any bug that leaks once and for all for a variety of Bignum representations used the underlying key material can be disastrous. in different curves. We also show how to use abstract types to enforce a coding discipline that mitigates side-channels at the Recent trends in protocol design indicate a shift towards source level. We present a verified F* library that implements the use of elliptic curves in preference to older asymmetric the popular curves Curve25519, Curve448, and NIST-P256, and primitives. This is partly due to concerns about mass surveil- we show how developers can add new curves to this library with lance, which means that non-forward-secret primitives such as minimal programming and verification effort. RSA encryption are no longer considered sufficient. Moreover, finite-field Diffie-Hellman computations are both slow and I. VERIFYING CRYPTOGRAPHIC LIBRARIES vulnerable to precomputation [10], two limitations that do not apply to elliptic curves, as far as currently known. The security of important Internet protocols, such as Trans- port Layer Security (TLS), crucially relies on cryptographic Cryptographic libraries such as OpenSSL already imple- constructions implemented in software and hardware. Any bug ment dozens of standardized elliptic curves. However, concerns or backdoor in these implementations can be catastrophic for about backdoors in NIST standards [11] have led to the security. Yet, although the precise computational security of standardization of new elliptic curves such as Curve25519 composite constructions and protocols has been widely studied and Curve448 [12], and implementations of these relatively using formal tools [1]–[3], the correctness of implementations new curves are currently being developed and widely de- of the underlying cryptographic primitives have received far ployed. The verification of these fresh implementations of less attention from the formal verification community. new elliptic curves was presented as an open challenge from practitioners to academics at the Real World Cryptography For symmetric primitives, such as block ciphers and hash workshop in 2015 [13]. Verifying libraries with multiple curves functions, the algorithm is the specification. Hence, verifying is particularly difficult because each curve implements its own a block cipher implementation amounts to proving the equiv- optimized field arithmetic code, and so two elliptic curves do alence between a concrete program written for some platform not share much code between them. This is in direct contrast and an abstract program given in the standard specification. to RSA and finite-field Diffie-Hellman libraries that are written Practitioners commonly believe that a combination of careful once and for all and remain stable thereafter. code inspection and comprehensive testing is enough to ensure functional correctness for such primitives, but that the greater In this paper, we take up this challenge and show how challenge is preventing side-channels such as timing leaks to write a library of elliptic curves that can be mechanically that have led to many recent attacks (e.g. see [4]). However, verified using a dependent type system. To better explain separating these concerns is not always possible or desirable, our approach and the design of our verified library, we first and researchers have shown that formal approaches can be consider a motivating example. effective both for verifying subtle performance optimizations in source programs [5], and for detecting side-channels in as- A. Example: Elliptic Curve Diffie-Hellman Key Exchange sembly code [6]. Furthermore, such code-based guarantees can also be formally linked to high-level cryptographic proofs [7]. One of the main applications of elliptic curves in cryp- tographic protocols is to implement a Diffie-Hellman key- For asymmetric primitives, such as RSA encryption, finite- exchange. Figure 1 illustrates a simple elliptic curve Diffie- field Diffie-Hellman, or elliptic curves, the gap between spec- Hellman protocol inspired by the QUIC transport protocol [14] Client Server let send sPub msg = let cPriv,cPubBytes = ECDH.keygen () in Knows S = sG Knows s let k = ECDH.shared secret cPriv sPub in (cPub, AEAD.encrypt k msg) Generates key-pair (c; C = cG) let receive sPriv (cPubBytes,encmsg) = Computes shared key k = cS if ECDH.is on curve cPubBytes then let cPub = ECDH.to spoint cPubBytes in C; enc(k; msg) let k = ECDH.shared secret sPriv cPub in AEAD.decrypt k msg else failwith "error" Computes shared key k = sC Fig. 1. An ephemeral-static elliptic curve Diffie-Hellman (ECDH) key exchange sending a single encrypted message (msg). The client and server are assumed to have agreed upon a curve with generator G. The server’s static public key S is known to everyone. The client is anonymous. Scalar multiplication (e.g. sG) can be read as a classic Diffie-Hellman modular exponentiation (Gx). Sample F* code for the client and server is shown on the right. and the 0-RTT mode of TLS 1.3 [15]. The right side of the leak its secret inputs via side-channels, and that its security figure displays example client-server code for this protocol in guarantees are preserved by the application code. an ML-like language called F* (e.g. the miTLS library [16] implements all of the TLS protocol in this style.) B. Towards a Verified Elliptic Curve Library An anonymous client wishes to send a secret message msg The most relevant prior work on verifying an elliptic curve to a public server. We assume that both have agreed upon implementation appears in [18], which shows how an imple- a curve (e.g. Curve25519) with public generator G, and we mentation of Curve25519 in the qhasm language [19] can be assume that the client has previously retrieved the server’s formally verified to be functionally correct using a combination static public key S from some trusted source. In the elliptic- of an SMT solver and the Coq theorem prover. This result is curve setting S is computed as the scalar multiplication sG, particularly impressive because it applies to highly optimized where s is the server’s private key. code written in a low-level assembly language. To send the message, the client generates an ephemeral Inspired by [18], we propose to build a verified library private-public key-pair (c; C), where C = cG, computes a that consists of multiple elliptic curves that maximally share Diffie-Hellman shared secret k = cS, uses it to encrypt the code, so that the verification effort of adding a new curve message, and sends the encrypted message along with its can be minimized. However, the approach used in [18] is public key C. The server first verifies that C is a valid point not particularly well-suited for this purpose. As a low-level on the curve, then computes k = sC, decrypts the message, programming language, qhasm does not lend itself to modular, and returns an (unencrypted) error message if it fails. incremental, proof-friendly development. The qhasm code for The main goal of the protocol is that the message msg must each curve is completely different, so the proof effort would remain a secret between the client and the server. This property have to be repeated from scratch for a new curve.