Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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)
Web Browser (Firefox+JS)
Secure Connec)on
Insecure Network
Networking (Linux)
Cryptographic Protocol
(HTTPS/TLS)
Web Server (Apache+SQL)
Online Banking Procedure
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
Networking (Windows)
Cryptographic Protocol
(HTTPS/TLS)
Web Browser (Firefox+JS)
Secure Connec)on
Insecure Network
Networking (Linux)
Cryptographic Protocol
(HTTPS/TLS)
Web Server (Apache+SQL)
Online Banking Procedure
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
Networking (Windows)
Cryptographic Protocol
(HTTPS/TLS)
Web Browser (Firefox+JS)
Secure Connec)on
Insecure Network
Networking (Linux)
Cryptographic Protocol
(HTTPS/TLS)
Web Server (Apache+SQL)
Online Banking Procedure
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
Networking (Windows)
Cryptographic Protocol
(Windows TLS)
Web Browser (Firefox+JS)
TLS Connec)on
Insecure Network
Networking (Linux)
Cryptographic Protocol (OpenSSL)
Web Server (Apache+SQL)
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?