A Roadmap for High Assurance Cryptography

Transcription

1 A Roadmap for High Assurance Cryptography Harry (Twitter) NEXTLEAP (nextleap.eu) Harry Halpin Prosecco Thanks to Peter Schwabe (Radboud

2 High Assurance is Needed More than Ever - 2

3 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.

4 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

5 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.

6 Do you really trust experts? - 6

7 Goal : Replace OpenSSL - 7

8 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.

9 Fstar : Creates Running Code Formal verification done via lemmas via a dependent type system. 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).

10 Mozilla and Fstar - 10

11 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): Proofs of equivalence between optimized Jasmin and Compert C GVerif :

12 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)

13 Common API Errors : Cross API : Google's Project Wycheproof collects common errors 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)

14 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)

15 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.

16 Next Steps and Discussion HACL* seems most mature, but lots of other tools Trying to tackle full TLS 1.3 (including X.509) : Advanced functions needed, such as constant time verification. Note dependency on hardware.