a roadmap for high assurance cryptography
play

A Roadmap for High Assurance Cryptography Harry Halpin - PowerPoint PPT Presentation

A Roadmap for High Assurance Cryptography Harry Halpin harry.halpin@inria.fr @harryhalpin (Twitter) Thanks to Peter Schwabe (Radboud University) NEXTLEAP (nextleap.eu) Harry Halpin Harry.halpin@inria.fr Prosecco @harryhalpin High Assurance


  1. A Roadmap for High Assurance Cryptography Harry Halpin harry.halpin@inria.fr @harryhalpin (Twitter) Thanks to Peter Schwabe (Radboud University) NEXTLEAP (nextleap.eu) Harry Halpin Harry.halpin@inria.fr Prosecco @harryhalpin

  2. High Assurance is Needed More than Ever High Assurance Cryptography - 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. High Assurance Cryptography

  4. Low vs. High Assurance Cryptography ● 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 High Assurance Cryptography

  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. High Assurance Cryptography

  6. Do you really trust experts ? High Assurance Cryptography - 6

  7. Goal : Replace OpenSSL High Assurance Cryptography - 7

  8. Formal Verification is slow OpenSSL has hand-optimized assembly per micro- architecture. 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. High Assurance Cryptography

  9. 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). High Assurance Cryptography

  10. Mozilla and Fstar High Assurance Cryptography - 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): https://github.com/jasmin-lang/jasmin Proofs of equivalence between optimized Jasmin and Compert C – GVerif : https://gfverif.cryptojedi.org/ High Assurance Cryptography ●

  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) High Assurance Cryptography

  13. 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) High Assurance Cryptography

  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) http://noiseprotocol.org/ High Assurance Cryptography

  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. High Assurance Cryptography

  16. 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. High Assurance Cryptography

Recommend


More recommend