formal’security’analysis’of’ cryptographic ... course... ·...

Formal Security Analysis of Cryptographic Protocol Code

Karthikeyan Bhargavan INRIA

IIT Delhi, Fall 2010

Lecture 1: WriCng Secure Web ApplicaCons

IntroducCon

WriCng Secure Web ApplicaCons

•  An increasing number of security-‐criCcal services can now be accessed from the web

•  Online banking, Google Health, Electronic tax returns •  A parallel increase in aNacks on web applicaCons

•  Credit card fraud, IdenCty theO •  Cryptography, if used correctly, can help

•  Data encrypCon, Secure hardware, Access control •  MathemaCcally proven guarantees

•  But easy to get wrong, even for experts •  Need for training, verificaCon tools •  Many recent advances in provers, program analysis tools

3

Example: Secure Online Banking

xxxxxxx

Secure connec)on to bank’s website

Nobody other than the bank can read what I type (confidenCality)

My secret login Informa)on

Nobody other than me can access my account page (authenCcaCon)

Goal: Prevent unauthorized access to data even if an unknown aBacker controls the network and some other bank clients.

4

ApplicaCon-‐Level VulnerabiliCes

•  Bank holds records in a Database –  Is the database secure? And the passwords? – Can one bypass the password mechanism?

•  Client keeps copies of her bank records –  Is her computer secure? – Can social engineering reveal her password?

5

Banking Procedure

Client Bank

Network-‐level ANacks

•  An aNacker can hijack the web session •  ImpersonaEon: Pretend to be the client •  Replay: Resend an old client message •  RedirecEon: Divert a message meant for one server to another

6

Web Browser (Firefox+JS)

Web Server (Apache+SQL)

Online Banking Procedure

Client Bank

Web Session

Cryptographic ProtecCons

•  Secure password database

•  No access to secrets

•  Strong crypto primiCves

•  No side-‐channel informaCon leakage

7

Networking (Windows)

Cryptographic Protocol

(HTTPS/TLS)


Secure Connec)on

Insecure Network

Networking (Linux)


(HTTPS/TLS)



Client Bank

Web Session

Security VerificaCon Goal

Given a •  Web applica)on with strong security goals, protected using a

•  Cryptographic protocols and secure databases, against an

•  Arbitrary aDacker who controls the network and some clients and servers

Goal: MathemaEcal proof that the web applicaEon preserves its security goals in all runs.

PotenCal ANacks at All Levels



(HTTPS/TLS)


Secure Connec)on

Insecure Network

Networking (Linux)


(HTTPS/TLS)



Web applicaEon bugs Browser, Server bugs

Social engineering MisconfiguraEon

Crypto protocol errors Protocol soMware bugs

OperaEng system bugs

Client Bank

Web Session

9

40%

10%

20%

30%

Top 25 Bugs 2010*

* 2010 CWE/SANS Top 25 Most Dangerous SoMware Errors

A Problem of Scale



(HTTPS/TLS)


Secure Connec)on

Insecure Network

Networking (Linux)


(HTTPS/TLS)



A: Web applicaCon code 100,000 lines (in Java, Javascript)

D: Client and Bank share 100 lines of data

P: Security-‐related code 10,000 lines (in C, Java)

L: System libraries 1,000,000 lines (in C)

Client Bank

O: Unknown Opponent

Web Session

10

A Simpler VerificaCon Goal

Write and verify a •  Simple web applicaCon in F#, that uses a •  Cryptographic protocol wriNen in F#, on top of •  Libraries provided by the .NET Framework

Under the following trust assumpCons •  Fully Trusted: databases, cryptographic algorithms

–  Assume they are implemented correctly •  ParEally Trusted: operaCng systems, web browsers

–  Assume they do not leak secret data •  No Trust: network, compromised clients and servers

–  Assume they are under the control of the aNacker

Abstract

Abstract

A Simpler VerificaCon Goal



(Windows TLS)


TLS Connec)on

Insecure Network

Networking (Linux)

Cryptographic Protocol (OpenSSL)


Password-‐based Authen)ca)on

Client Bank

A: Web applicaCon code 100,000 lines

Client and Bank share 100 lines of data

P : Security-‐related code 10,000 lines

L: System libraries 1,000,000 lines

O: Opponent <unknown> lines

HTTPS Session

If you cannot verify, find an aNack

•  Protocols are designed by experienced cryptographers –  And implemented by skilled programmers

•  SCll, serious flaws both in designs and implementaCons –  Most standards got it wrong once or twice (SSL, SSH, IPSEC) –  Just in 2009, bugs in Google single-‐sign-‐on, MicrosoO Kerberos,

and OpenSSL cerCficate verificaCon Security tesCng does not help much

–  How to test for all aNack scenarios? Independent expert review may help

–  E.g. mandatory Crypto Board review for any non-‐standard crypto

–  SCll, more an art than a science, and a limited resource Do I need a new review before submikng any code change?

Course Outline

•  Write web applicaCons in F# –  Using simple libraries for Networking, Databases, Cryptography, and Key Management

•  Security analysis of F# programs –  Syntax and semanCcs of F, a core subset of F# –  Understand and implement aNacks –  Formalize security properCes of programs

•  Automated proofs of security for F# programs –  Syntax and semanCcs of applied pi calculus –  TranslaCon from F to applied pi –  Verify F# programs using the ProVerif theorem prover

•  Other security verificaCon techniques for progams

Course Keywords

•  FuncConal Programming (F#, lambda calculus) –  Ease of analysis, well-‐defined semanCcs

•  Models of concurrency (pi calculus) –  Precisely model web applicaCons, aNacker

•  Cryptographic PrimiCves (AES, HMAC, RSA) –  Provide strong security guarantees

•  AuthenCcaCon, Secrecy, AuthorizaCon –  Typical security goals

•  Formal VerificaCon Tools (Coq, ProVerif) –  Semi-‐automated proofs of correctness, security

Lecture 1: WriCng Secure Web ApplicaCons

A client-‐server applicaCon in F#

Data Encodings

•  Conversions between strings and bytestrings – bytes are byte arrays, string is Unicode

•  Implemented using .NET Framework libraries – System.Convert, System.Text.Encoding

A Simple Networking Library

•  Network operaCons in funcConal style (stateless) •  Sends and receives bytestrings

–  Can be extended to other messaging paNerns •  Implemented using .NET Framework (System.Net)

A “Hello, World!” Web ApplicaCon

An Echo Client-‐Server ApplicaCon

Running the Echo Client and Server

Network-‐based ANacker

•  We explicitly allow a network-‐based aNacker to modify each message that is sent or received

•  On every message, Net.send and Net.recv call ANack.send and ANack.recv, respecCvely

•  By default, they do not modify the message

An InjecCon ANack

•  Sent message is modified en route •  Client and server are unaware of modificaCon

C A

S Msg XXX

Network-‐based ANacks

Generally called Man-‐in-‐the-‐Middle aNacks •  InjecEon: Send a false message to server

•  Replay: Send an old message again

•  RedirecEon: Forward message to wrong server

Both client and server messages may be targeted, unpredictably over Cme

Exercises

•  Install F# (Windows, or Mono/Linux) •  Write a client-‐server applicaCon of your choice – Libraries will be available on the course web page – Choose an applicaCon with an interesCng security property, e.g. something that requires either providing or retrieving secret data

•  Exhibit injecCon, replay, and redirecCon aNacks – How do these aNacks violate the security property?

formal’security’analysis’of’ cryptographic ... course... ·...

Documents