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

Formal Methods for Security Protocols

What’s so difficult about protocols?

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

Literature Review

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”

Financial transactions over a networkLiterature 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

Proposed ArchitectureProposed Architecture

Architecture Diagram

Proposed MethodologyProposed Methodology

Verifying a simple protocol

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

Road Map

references

Thank you