Formal verification of a security protocol for financial services
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

Formal Verification of a Security Protocol for Financial Services PowerPoint PPT Presentation


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

Formal Verification of a Security Protocol for Financial Services. Supervisor : Dr . Abdul Ghafoor Committee Members : Dr . Awais Shibli Dr . Osman Hassan Ms. Rahat Masood. Shizra SultanMS-CCS [5]. Outline. Introduction Security Protocols Formal methods in practice

Download Presentation

Formal Verification of a Security Protocol for Financial Services

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Formal verification of a security protocol for financial services

Formal Verification of a Security Protocol for Financial Services

Supervisor:

Dr. Abdul Ghafoor

Committee Members:

Dr.AwaisShibli

Dr.Osman Hassan

Ms.RahatMasood

Shizra SultanMS-CCS [5]


Outline

Outline

  • Introduction

    • Security Protocols

    • Formal methods in practice

  • Literature Review

  • Problem Statement

  • Proposed architecture

  • Proposed Methodology :Verifying a simple protocol

    • Threat Model

    • Security Goals

    • Formal Specification

    • Automated Proof

  • Road map

  • References


Formal methods for security protocols

Formal Methods for Security Protocols

What’s so difficult about protocols?


Security protocols go wrong

Security protocols go wrong

  • 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


The needham schroeder problem

The Needham-Schroeder problem

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.”


Informal methods

Informal methods

Informal lists of practical practices enumerate common patterns in the extensive record of flawed protocols, and formulate positive advice for avoiding each pattern.

“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

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.


What are formal methods

What Are Formal Methods

  • 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.


Definition

Definition

“ 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 ”


Literature review

Literature Review


Literature survey 1

Literature Survey 1

CédricFournet,MarkulfKohlweiss,Pierre-Yves Strub“Modular Code-Based Cryptographic Verification” "18th ACM Conference on Computer and Communications Security (2011)

  • 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.

    • The cryptographic proofs of these functionalities are independent and relatively simple; they mostly rely on programming and type checking.

    • The security proofs for protocols using these cryptographic functionalities entirely rely on automated type checking, much as in prior work on symbolic verification.

    • Their verified security properties are directly expressed as (asymptotic variants of) safety and perfect secrecy on the protocol code.


Literature survey 2

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”

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 3

Literature Survey 3

Matteo Avalle,Alfredo Pironti, Riccardo Sisto, ”Formal Verification of Security Protocol Implementations: A Survey”

Model extraction v/s code generation

  • Symbolic model v/s computational model

  • Authentication 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


Financial transactions over a network

Financial transactions over a network

Literature survey


Literature survey 4

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

Abstract:

  • Single mode to confirm the claimed identity of the remote user over Web or the Mobile channel

  • Approach 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


Formal verification of a security protocol for financial services

J2ME is the preferred development platform due to the following reasons: the portability of Java code, the ability to reduce the network traffic by making use of the processing power of the Java phone to process data locally, and the ability to establish a differential security policy on the client that will perform the encryption operations according to the content and sensitivity of network data rather than encrypting everything. This helps us utilize the embedded device processing power very efficiently. Also, J2ME mobile information device applications (MIDlets) can operate over and make use of, the WAP stack to perform HTTP network interaction, without requiring TCP/IP. A side-effect of devising a general application-layer security solution using J2ME is that it provides a feasible solution to the traditional security gap in the WAP gateway [11].

This security gap is due to the security protocol conversion mechanism taking place in the WAP gateway between the secure sockets layer (SSL) encryption and the WAP wireless transport layer security (WTLS) encryption protocols. This protocol conversion 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 [12].

HTTP is a stateless protocol. Each HTTP request is independent of the other requests and the protocol specification does not devise any mechanism that can group a series of requests as belonging to one user or another. Over time, several strategies have evolved to address session tracking; the most practical of these are the use of cookies and URL rewriting. The Java Servlet API provides the HttpSession object, which represents each user's interaction with the web server. The Servlet API specification requires that web “containers” implement session tracking using the cookie mechanism. The cookie interchange mechanism is similar to that taking place between a web browser and a web server with one difference – in our proposed protocol, the client MIDlet program has to explicitly send the session cookie back to the server for every request.

CONCLUSION

In this paper, we have presented an application-layer security solution for wireless payment system to provide end-to-end authentication and data confidentiality between wireless J2ME based clients and J2EE based servers. This paper suggests a new protocol for web user authentication based on multifactor authentication approach which is completely secure and easy to implement. We also suggest an approach for two-way authentication protocol to authenticate both the parties. This solution can be implemented within the limited resources of a Java MIDP device, without any modification to the underlying protocols or wireless network infrastructure. Future work will focus on developing a new and efficient way to get TIC codes from the financial institutions. TIC code installation on the user’s cell phone must also be an easy task to avoid repeated visit by user to the bank or financial institution. Server side TIC maintenance and management mechanism to satisfy the demand from a large number of users is also part of future work.


Literature survey 5

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 on3-7 April 2005

  • 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).


Evaluation of the financial solutions

Evaluation of the financial solutions

  • 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 connections

      Proposed Solutions

    • Session ID

    • OTP

    • SIM


Problem statement

Problem Statement

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


Proposed architecture

Proposed Architecture


Architecture diagram

Architecture Diagram


Proposed methodology

Verifying a simple protocol

Proposed Methodology


Password based authentication

Password-based authentication

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 attacksby encrypting the nonce with the server’s public key


1 threat model

1. Threat Model

“The network is the opponent.”

Pay Charlie $50 -Alice

Internet

Alice’s Bank I

Alice’s Laptop

  • Interception

  • Replay

  • Redirection

Alice’s Bank II


1 threat model1

1. Threat Model

“The network is the opponent.”

Pay Charlie $50 -Alice

Internet

Pay Eve $500

-Alice

Alice’s Bank

Alice’s Laptop

4. Insertion

5. Impersonation


1 threat model2

1. Threat Model

Insiders may be compromised.

Internet

Alice’s Bank I

Alice’s Laptop

Alice’s Bank II

Eve’s Laptop


1 threat model3

1. Threat Model

  • “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)


2 security goals

2. Security Goals

  • Message and Sender Authentication

    • If B accepts text seemingly from A, then A must have sent text to B

  • Secrecy of skBand 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


3 formal specification

3. Formal Specification

  • 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,


Protocol goals in proverif

Protocol Goals in ProVerif

  • 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


4 verifying code

4.Verifying Code

  • 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.


Road map

Road Map


References

references


Thank you

Thank you


  • Login