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

a roadmap for high assurance cryptography
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 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

Prosecco Harry.halpin@inria.fr @harryhalpin

slide-2
SLIDE 2

High Assurance is Needed More than Ever

High Assurance Cryptography

  • 2
slide-3
SLIDE 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

slide-4
SLIDE 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

slide-5
SLIDE 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

slide-6
SLIDE 6

Do you really trust experts ?

High Assurance Cryptography

  • 6
slide-7
SLIDE 7

Goal : Replace OpenSSL

High Assurance Cryptography

  • 7
slide-8
SLIDE 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

slide-9
SLIDE 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

slide-10
SLIDE 10

Mozilla and Fstar

High Assurance Cryptography

  • 10
slide-11
SLIDE 11

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
slide-12
SLIDE 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

slide-13
SLIDE 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

  • 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

slide-14
SLIDE 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

slide-15
SLIDE 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

slide-16
SLIDE 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