A Roadmap for High Assurance Cryptography Harry Halpin harry.halpin@inria.fr @harryhalpin (Twitter) NEXTLEAP (nextleap.eu) Harry Halpin Prosecco Thanks to Peter Schwabe (Radboud University) Harry.halpin@inria.fr @harryhalpin
High Assurance is Needed More than Ever - 2
Traditional Security Methodology Defining security goals Identifying trusted code base needed to achieve those goals Isolating the TCB from the rest of the code Implementing a well-defined interface (API) between TCB and rest of the code Assuring that the API's usag meets the security goals.
Low vs. TCB has grown organically and mixed with non-tcb code low assurance. TCB goes beyond crypto : kernels, drivers, etc. Crypto TCB implements security goals as primary function. So crypto should always be inside TCB API must maintain security goals
How to Achieve High Assurance? 1) Testing : Cheap but no guaranteed absence of vulnerabilities. 2) Auditing : Better, but requires many experts and also has no guarantees. Issues with scaling and expense. 3) Formal Verification : Guarantee of security properties via formal proofs of correctness and security.
Do you really trust experts? - 6
Goal : Replace OpenSSL - 7
Formal Verification is slow OpenSSL has hand-optimized assembly per microarchitecture. Multiple carry bugs in big-integer arithmetic! (Brumley et al., CT RSA 2012) Formal verification does not usually translate to running code, so we are proving only a model of the code (often in Coq, DeepSpec, etc.), not the running code itself.
Fstar : Creates Running Code Formal verification done via lemmas via a dependent type system. https://www.fstar-lang.org/ Uses Kremlin to compile (with verification) from F* to Ocaml to CompCert C (and eventually Javascript). HACL* Library : Initially focussed on Curve25519 DH and EdDSA, now includes stream ciphers (Chacha20, Salsa20, XSalsa20), MACs (Poly1305, HMAC) Used in Mozilla's NSS now (2017).
Mozilla and Fstar - 10
Challenge : Speed and Verification Hand-optimized code almost always faster and amount of annotations dwarfs code Solution : Formally verify a LLVM (low-level virtual machine) that can create optimized micro-code per architecture See Jasmin (descendant of Qhasm): https://github.com/jasmin-lang/jasmin Proofs of equivalence between optimized Jasmin and Compert C GVerif : https://gfverif.cryptojedi.org/
Developer-Resistant API : Cryptographic API : is used by programmers to access cryptographic primitives and control cryptographic key material as needed in their applications and higher level protocols. Security API : Set of functions that maintain security properties regardless of usage of API. 88 % of errors caused by API usage in Android (Egele et. al., 2013)
Common API Errors : Cross API : Google's Project Wycheproof collects common errors https://github.com/google/wycheproof Formal modelling of APIs discovered errors in both use of crypto (re-use of IVs, deterministic «RNGs», low amount of iterations in key derivation) as well as key management : 1) PKCS#11 (Delaune et al., 2010) 2) WebCrypto (Halpin et al., 2016) 3) YubiKeys (Kunneman and Steel, 2012)
API Problems: APIs are designed by standards committee, usually results in errors. OpenSSL has many competitors : BoringSSL, WolfSSL, PolarSSL, GNUTLS, etc. Situation gets even worse with IPSec and VPN libraries. See composable libraries such as Noise Protocol (used in WhatsApp Signal implementation) http://noiseprotocol.org/
What is the ideal API? Flexible : Can be drop-in replacement for OpenSSL if possible for legacy software Problem : Deprecating broken primitives (MD5, etc.) How to force move from RSA to ECC? Safe Defaults : If defaults are not specified, use safe defaults (box/unbox in NaCL/libsodium) with key sizes and parameters. Who decides the defaults? Issues with E-CRYPT report, NIST, CFRG updates random, etc.
Next Steps and Discussion HACL* seems most mature, but lots of other tools Trying to tackle full TLS 1.3 (including X.509) : https://project-everest.github.io/ Advanced functions needed, such as constant time verification. Note dependency on hardware.