Formal Verification of a Security Protocol for Financial Services
-
Upload
kyla-stevens -
Category
Documents
-
view
22 -
download
0
description
Transcript of Formal Verification of a Security Protocol for Financial Services
Formal Verification of a Security Formal Verification of a Security Protocol for Financial ServicesProtocol for Financial Services
Shizra Sultan MS-CCS [5]
Supervisor: Dr. Abdul Ghafoor
Committee Members: Dr. Awais Shibli
Dr. Osman Hassan Ms. Rahat Masood
Introduction Security Protocols Formal methods in practice
Literature Review Problem Statement Proposed architecture Proposed Methodology :Verifying a simple protocol
1. Threat Model2. Security Goals3. Formal Specification4. Automated Proof
Road map References
OutlineOutline
Historically, one keeps finding simple attacks against protocols even carefully-written, widely-deployed protocols,
even a long time after their design & deployment simple = no need to break cryptographic primitives
Why is it so difficult? concurrency + distribution + cryptography
Little control on the runtime environment active attackers
Hard to test implicit assumptions and goals
Authenticity, secrecy
4
Security protocols go wrong
A B
The Needham-Schroeder public-key authentication protocol (CACM 1978)
S
{| msg3(A,NA) |}KB
{| msg6(NA,NB) |}KA
{| msg7(NB) |}KB
A,B
{| B,KB |}KS-1
B,A
{| A,KB |}KS-1
Principal A initiates a session with principal BS is a trusted server returning public-key certificates eg {| A,KA |}KS-1NA,NB serve as nonces to prove freshness of messages 6 and 7
5
The
Nee
dham
-Sch
roed
er
prob
lem
In Using encryption for authentication in large networks of computers (CACM 1978), Needham and Schroeder didn’t just initiate a field that led to widely deployed protocols like Kerberos, SSL, SSH, IPSec, etc.
They threw down a gauntlet.
“Protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation.
The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area.”
6
Informal methods
“Principle 1: Every message should say what it means: the interpretation of the message should depend only on its content.It should be possible to write down a straightforward English sentence describing the content—though if there is a suitable formalism available that is good too.”Abadi and Needham, Prudent engineering practice for cryptographic protocols 1994
Informal lists of practical practices enumerate common patterns in the extensive record of flawed protocols, and formulate positive advice for avoiding each pattern.
For instance, Lowe’s famous fix of the Needham-Schroeder PK protocol makes explicit that message 6, {|NA,B,NB|}KA, is sent by B, who is not mentioned in the original version of the message.
Formal methods refers to a variety of mathematical modeling techniques that are applicable to computer system design.
They include activities such as system specification, specification analysis and proof, transformational development, and program verification.
What Are Formal Methods
“ Formal methods are mathematical approaches to software and system development which support the rigorous
specification, design and verification of computer systems, they exploit the power of mathematical notation and
mathematical proofs ”
Definition
Automated program verification under computational security assumptions (rather than automated symbolic verification or hand written proofs of models)
Method: Refinement types & type parametricity Application: TLS 1.2 Verification by computational security of sample cryptographic
functionalities using ideal refinement-typed interfaces.1. The cryptographic proofs of these functionalities are independent and
relatively simple; they mostly rely on programming and type checking.2. The security proofs for protocols using these cryptographic
functionalities entirely rely on automated type checking, much as in prior work on symbolic verification.
3. Their verified security properties are directly expressed as (asymptotic variants of) safety and perfect secrecy on the protocol code.
Literature Survey 1
Cédric Fournet,Markulf Kohlweiss,Pierre-Yves Strub “Modular Code-Based Cryptographic Verification” "18th ACM Conference on Computer and Communications Security (2011)
This paper presents an architecture and tool for verifying implementations of security protocols. Implementation can run with both concrete and symbolic implementations of cryptographic algorithms.
To obtain a reference implementation, it executes application code against concrete libraries. Experimental testing is essential to confirm that the protocol code is functionally correct, and complete for at least a few basic scenarios.
To obtain a symbolic prototype, it executes the same application code against symbolic libraries. This allows basic testing and debugging, especially for the expected message formats.
To perform formal verification, it runs a model extraction tool, called fs2pv, to derive a detailed formal model from the application code and symbolic libraries.
Literature Survey 2
Verified Interoperable Implementations of Security Protocols, “ACM Transactions on Programming Languages and Systems, Vol. 31, No. 1, Article 5, Pub. date: December 2008”
Model extraction v/s code generationSymbolic model v/s computational modelAuthentication and secrecy properties for crypto protocols have been formalized and thoroughly studied
After intense effort on symbolic reasoning, several techniques and tools are available for automatically proving these properties
e.g. Athena, TAPS, ProVerif, FDR, AVISPA, etc.
We can now automatically verify most security properties for detailed models of crypto protocols
e.g. SSL, IPSEC, Kerberos, Web Services
On-going work Fancy protocols and properties Relation between Dolev Yao abstractions and concrete crypto Extend results on formal models to fully-fledged application code
Literature Survey 3
Matteo Avalle,Alfredo Pironti, Riccardo Sisto, ”Formal Verification of Security Protocol Implementations: A Survey”
Abstract: Single mode to confirm the claimed identity of the remote user over Web or the Mobile channelApproach based on Transaction Identification Code and SMS to enforce extra security level
Pros:•application-layer security solution for wireless payment system to provide:•End-to-end authentication •Data confidentiality between wireless J2ME based clients and J2EE based servers•Two-way authentication protocol to authenticate both the parties. •Server side TIC maintenance and management mechanism
Cons:•Platform Dependent i.e. J2ME•Encryption operations according to the content and sensitivity of network data rather than encrypting everything •Communication over http•Leaves data in an unencrypted form at the gateway during the protocol switching process, which increases the risks to the confidentiality of data in the gateway
Literature survey 4
Ayu Tiwari, Sudip Sanyal, Ajith Abraham, “A Multi-Factor Security Protocol for Wireless Payment - Secure Web Authentication using Mobile Devices”, IADIS International Conference on Applied Computing Proceedings of the IADIS International Conference on Applied Computing, Salamanca, Spain, 18-20 February 2007
Proposed a multifactor authentication framework that extends the cryptographic link, binding an entity to a physical node device.
• Pros:
• A framework for multi-factor identification and authentication, which allows
mobile nodes in MANET to identify and authenticate each other by examining a wide range of characteristics.
• Combines well-known cryptographic mechanisms (such as digital certificates and signatures), with different sources of
identification information.
• The link between the entity and the physical device is not implicitly assumed; it is authenticated by two independent
factors
• Cons
• Authentication between neighboring nodes is performed in several steps.
• The combination of various weighted attributes will output the identity of a node in the network with a certain
level of confidence.
• An implementation of the proposed multifactor authentication framework requires special-purpose hardware, for
both node attribute certification (during the setup phase) and measurement (during the authentication phase).
Literature survey 5
Glynos, D. ,Kotzanikolaou, P. ; Douligeris, C., “Preventing impersonation attacks in MANET with multi-factor authentication”, Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, 2005. WIOPT 2005. Third International Symposium on 3-7 April 2005
The evaluation is performed according to the following criteria: Strength & vulnerabilities Cost User friendliness
Different authentication solutions have the vulnerability points which can be subject to attacks in as follows:
1. On the mobile phone 2. Across the Bluetooth connection 3. On the computer 4. Across the Internet connection 5. Across the connection between service provider and authentication server 6. On and between GSM network components and connectionsProposed Solutions Session ID OTP SIM
Evaluation of the financial solutions
Need of a secure protocol for financial transaction that can cater the vulnerabilities of existing protocols
Secure exchange of session keys
Solution based on multifactor authentication
Secure sessions to minimize all kind of security threats against information leakage and authentication
Proposed protocol should be formally verified
Problem Statement
A simple, one-message authentication protocol
Two roles client (A) sends some text, along with a MAC server (B) checks authenticity of the text the MAC is keyed using a nonce and a shared password the password is protected from dictionary attacks
by encrypting the nonce with the server’s public key
25
Password-based authentication
26
1. Threat Model
Alice’s Laptop
Pay Charlie $50 -Alice
“The network is the opponent.”
1. Interception2. Replay3. Redirection
Alice’s Bank II
Alice’s Bank I Internet Internet
27
1. Threat Model
Alice’s Laptop Alice’s Bank
Pay Charlie $50 -Alice
Internet Internet
“The network is the opponent.”
4. Insertion5. Impersonation
Pay Eve $500-Alice
28
1. Threat Model
Alice’s LaptopAlice’s Bank I
Internet Internet
Insiders may be compromised.
Eve’s Laptop
Alice’s Bank II
“Perfect Cryptography” assumption HMAC-SHA1 is a one-way hash function RSA-Encrypt is unbreakable
Opponent can encrypt, decrypt, sign, verify But only if it has the keys
The opponent knows pkB The opponent cannot guess
nonce (128 pseudorandom bits) skB (2048 bit RSA key) pwdA (8 character string)
(Hmm, perhaps not that unguessable)29
1. Threat Model
Message and Sender Authentication If B accepts text seemingly from A,
then A must have sent text to B Secrecy of skB and pwdA
The opponent cannot learn these values from the protocol
Message Secrecy The opponent cannot learn text
Session Authentication All messages in a session are authentic & correlated
30
2. Security Goals
Choice of formalism depends on desired expressiveness and verification technology Isabelle/HOL: Higher-order functional language, human-
assisted theorem prover ProVerif: Concurrent process calculus, automated
theorem prover, FDR/Casper: Communicating sequential processes, model
checker for fixed number of sessions,
31
3. Formal Specification
• Message Authentication
• Protocol Completion
• Password Secrecy
• Private Key Secrecy
• Resistance to Dictionary attacks on Password
If a property is false, ProVerif exhibits the counter-example as an attack E.g. Suppose A does not include text in the HMACSHA1
32
Protocol Goals in ProVerif
To verify similar security properties for protocol implementations, we need a formal semantics of the programming language a symbolic model of cryptography a verification tool that can analyze source code
We can verify code written in F#, a dialect of ML ML has well-understood formal semantics We provide symbolic modules for cryptography The fs2pv tool translates F# programs to ProVerif models; then
we can use ProVerif for verification.
33
4.Verifying Code