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

Prosecco Harry.halpin@inria.fr @harryhalpin

High Assurance is Needed More than Ever

High Assurance Cryptography

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

High Assurance Cryptography

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

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

Do you really trust experts ?

High Assurance Cryptography

• 6

Goal : Replace OpenSSL

High Assurance Cryptography

• 7

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

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

Mozilla and Fstar

High Assurance Cryptography

• 10

Challenge : Speed and Verification

Hand-optimized code almost always faster and amount

• f 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

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

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

• f 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

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

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

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