Concrete cryptographic security in F*

Transcription

1 Concrete cryptographic security in F*

2 crypto hash (SHA3) INT-CMA encrypt then-mac Auth. encryption Secure RPC some some some adversary attack attack symmetric encryption (AES). IND-CMA, CCA2 secure channels hybrid encryption another adversary public-key encryption (RSA) IND-CMA, CCA2 TLS 1.2 crypto primitives typed interfaces (game-based security assumption) crypto constructions typed interfaces (game-based security guarantees) security protocols typed interfaces (attacker model) active adversaries

3 Security programming example: Access Control Lists

4 Untrusted client code may call a trusted, defensive library for accessing files Trusted code sets up security policy as a typed API Typechecking client code enforces policy compliance Untrusted code deals with dynamic checks and errors - preconditions capture policy requirements - postconditions enable re-use of dynamic checks

5 This plain interface says nothing about the security of MACs!

6 This ideal interface uses a log to specify security Great for F* verification. Unrealistic: tags can be guessed

7 Our ideal interface reflects the security of a chosen-message game [Goldwasser 88] UF-CMA programmed in F* The MAC scheme is ε-uf-cma-secure against a class of probabilistic, computationally bounded attackers when the game returns true with probability at most ε.

8 UF-CMA adversary ideal system Mac real interface concrete system Mac real interface concrete algorithm assumed UF-CMA computationally Ideal filter Ideal MAC RPC protocol secure RPC ε RPC protocol log-based error correction making VERIFY returns false on forgeries sample protocol typed against ideal MAC interface Any p.p.t. adversary perfectly safe by typing Any p.p.t. adversary safe too, with probability 1 ε protocol adversary typed against RPC interface

9

10 Security programming example Authenticated RPC

11 request MAC Client response MAC Network adversary Service

12

13 Connecting to localhost:8080 Sending {BgAyICsgMj9mhJa7iDAcW3Rrk...} (28 bytes) Listening at ::1:8080 Received Request 2 + 2? Sending {AQA0NccjcuL/WOaYS0GGtOtPm...} (23 bytes) Received Response 4

14

15 Bytes, Network lib.fst system libraries cryptographic primitives typed interfaces (security assumptions) HMAC mac.fst INT-CMA Authenticated RPC rpc.fst Formatting format.fst security protocols typed interfaces (modular design) plain typed interfaces (attacker model) active adversaries adv.fst any typed F* program any typed F* program application code

16 Another sample crypto assumption Collision Resistance

17 For authentication, we often require hash algorithms to be computationally injective (x y: bytes). H x = H y x = y This is modelled by maintaining an inverse, monotonic table from hash tags to hashed bytestrings

18 For authentication, we often require hash algorithms to be computationally injective (x y: bytes hashed so far). H x = H y x = y This is modelled by maintaining an inverse, monotonic table from hash tags to hashed bytestrings

19 Authenticated Encryption

20 We rely on type abstraction: Ideal encryption never accesses the plaintext, is info-theoretically secure.

21 We program this game in F* parameterized by a real scheme AE and the flag b We capture its security using types to keep track of the content of the log

22 Plaintext Ideal flags Code follows the structure of the construction & its proof For each functionality, we have a separate module and an interface that captures its security Idealization is conditional, controlled by flags whose values are unknown at verification-time The top-level proof consists of gradually setting flags for all crypto assumptions active adversaries any typed F* program ε CPA Encrypt secrecy IDEAL IND-CPA Encrypt-then-MAC authenticated encryption ε CPA + ε MAC ε MAC MAC authentication IDEAL UF-CMA any typed F* protocol application code

23 EtM.Plain EtM.Ideal Code follows the structure of the construction & its proof For each functionality, we have a separate module and an interface that captures its security Idealization is conditional, controlled by flags whose values are unknown at verification-time The top-level proof consists of gradually setting flags for all crypto assumptions active adversaries any typed F* program ε CPA EtM.CPA secrecy IDEAL IND-CPA EtM.AE Encrypt-then-MAC authenticated encryption ε CPA + ε MAC ε MAC EtM.MAC authentication IDEAL UF-CMA any typed F* protocol application code