Formal Verification of a Security Protocol for Financial Services

1. Formal Verification of a Security Protocol for Financial Services Supervisor: Dr. Abdul Ghafoor Committee Members: Dr.AwaisShibli Dr.Osman Hassan Ms.RahatMasood Shizra Sultan MS-CCS [5]

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

3. Formal Methods for Security Protocols What’s so difficult about protocols?

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

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

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

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

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

9. Literature Review

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

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

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

15. Financial transactions over a network Literature survey

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

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

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

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

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

21. Proposed Architecture

22. Architecture Diagram

24. Verifying a simple protocol Proposed Methodology

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

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

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

28. 1. Threat Model Insiders may be compromised. Internet Alice’s Bank I Alice’s Laptop Alice’s Bank II Eve’s Laptop

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

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

31. 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,

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

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

34. Road Map

35. references

36. Thank you