AIT 682: Network and Systems Security

Slides:



Advertisements
Similar presentations
CMSC 414 Computer (and Network) Security Lecture 22 Jonathan Katz.
Advertisements

Lecture 10: Mediated Authentication
Key Management. Shared Key Exchange Problem How do Alice and Bob exchange a shared secret? Offline – Doesnt scale Using public key cryptography (possible)
Key distribution and certification In the case of public key encryption model the authenticity of the public key of each partner in the communication must.
Akshat Sharma Samarth Shah
CSC 474 Information Systems Security
Handshake Protocols COEN 350. Simple Protocol Alice: Hi, I am Alice. My password is “fiddlesticks”. Bob: Welcome, Alice.
ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011.
Last Class: The Problem BobAlice Eve Private Message Eavesdropping.
CIS 725 Key Exchange Protocols. Alice ( PB Bob (M, PR Alice (hash(M))) PB Alice Confidentiality, Integrity and Authenication PR Bob M, hash(M) M, PR Alice.
CS470, A.SelcukCryptographic Authentication1 Cryptographic Authentication Protocols CS 470 Introduction to Applied Cryptography Instructor: Ali Aydin Selcuk.
1 Security Handshake Pitfalls. 2 Authentication Handshakes Secure communication almost always includes an initial authentication handshake: –Authenticate.
CS470, A.SelcukNeedham-Schroeder1 Needham-Schroeder Protocol Authentication & Key Establishment CS 470 Introduction to Applied Cryptography Instructor:
CS555Spring 2012/Topic 161 Cryptography CS 555 Topic 16: Key Management and The Need for Public Key Cryptography.
CMSC 414 Computer and Network Security Lecture 16 Jonathan Katz.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering.
CMSC 414 Computer and Network Security Lecture 22 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz.
More on AuthenticationCS-4513 D-term More on Authentication CS-4513 Distributed Computing Systems (Slides include materials from Operating System.
EEC 688/788 Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
CMSC 414 Computer and Network Security Lecture 18 Jonathan Katz.
Slide 1 Vitaly Shmatikov CS 378 Key Establishment Pitfalls.
CMSC 414 Computer and Network Security Lecture 23 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 17 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.
Alexander Potapov.  Authentication definition  Protocol architectures  Cryptographic properties  Freshness  Types of attack on protocols  Two-way.
Strong Password Protocols
Lecture 11: Strong Passwords
Authentication (ch 9~12) IT443 – Network Security Administration 1.
Chapter 3: Basic Protocols Dulal C. Kar. Key Exchange with Symmetric Cryptography Session key –A separate key for one particular communication session.
Security protocols  Authentication protocols (this lecture)  Electronic voting protocols  Fair exchange protocols  Digital cash protocols.
Using Cryptography for Network Security Common problems: –Authentication - A and B want to prove their identities to one another –Key-distribution - A.
1 Lecture 9: Cryptographic Authentication objectives and classification one-way –secret key –public key mutual –secret key –public key establishing session.
1 Needham-Schroeder A --> S: A,B, N A S --> A: {N A,B,K AB,{K AB,A} KBS } KAS A --> B:{K AB,A} KBS B --> A:{N B } KAB A --> B:{N B -1} KAB.
Using Cryptography for Network Security Common problems: –Authentication - A and B want to prove their identities to one another –Key-distribution - A.
The School of Electrical Engineering and Computer Science (EECS) CS/ECE Network Security Dr. Attila Altay Yavuz Authentication Protocols (I): Secure Handshake.
Lesson Introduction ●Authentication protocols ●Key exchange protocols ●Kerberos Security Protocols.
Dr. Nermi hamza.  A user may gain access to a particular workstation and pretend to be another user operating from that workstation.  A user may eavesdrop.
Security Handshake Pitfalls. Client Server Hello (K)
Chapter 9. Key management
Key Management Session and Interchange Key Key Exchange
Computer Communication & Networks
Topics In a confidential communication the authenticity needs to be carefully established for:
CS480 Cryptography and Information Security
Chapter 15 Key Management
Chapter 8 Network Security.
Authentication Protocols
Tutorial on Creating Certificates SSH Kerberos
Handshake Protocols COEN 150.
or call for office visit.
Message Security, User Authentication, and Key Management
Chapter 11 Message Authentication and Hash Functions
刘振 上海交通大学 计算机科学与工程系 电信群楼3-509
9.2 SECURE CHANNELS Medisetty Swathy.
پروتكلهاي احرازاصالت Authentication protocols
Strong Password Protocols
IT IS 6200/8200.
CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9
Protocol ap1.0: Alice says “I am Alice”
Strong Password Protocols
KERBEROS.
CDK: Chapter 7 TvS: Chapter 9
Lecture 6.1: Protocols - Authentication and Key Exchange I
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Diffie/Hellman Key Exchange
Formal Methods for Security Protocols
COEN 351 Authentication.
刘振 上海交通大学 计算机科学与工程系 电信群楼3-509
Security: Public Key Cryptography
Key Exchange With Public Key Cryptography
Presentation transcript:

AIT 682: Network and Systems Security Topic 6.2 Authentication Protocols Instructor: Dr. Kun Sun

Authentication Handshakes Secure communication almost always includes an initial authentication handshake. Authenticate each other Establish session keys This process is not trivial; flaws in this process undermine secure communication

Authentication with Shared Secret I’m Alice Alice Bob A challenge R f(KAlice-Bob, R) Weaknesses Authentication is not mutual; Trudy can convince Alice that she is Bob Trudy can hijack the conversation after the initial exchange If the shared key is derived from a password, Trudy can mount an off-line password guessing attack Trudy may compromise Bob’s database and later impersonate Alice

Authentication with Shared Secret (Cont’d) I’m Alice Alice Bob KAlice-Bob{R} R A variation Requires reversible cryptography Other variations are possible Weaknesses All the previous weaknesses remain Trudy doesn’t have to see R to mount off-line password guessing if R has certain patterns (e.g., concatenated with a timestamp) Trudy sends a message to Bob, pretending to be Alice

Authentication with Public Key I’m Alice Alice Bob R SigAlice{R} Bob’s database is less risky Weaknesses Authentication is not mutual; Trudy can convince Alice that she is Bob Trudy can hijack the conversation after the initial exchange Trudy can trick Alice into signing something Use different private key for authentication

Authentication with Public Key (Cont’d) Alice Bob I’m Alice {R}Alice R A variation

Mutual Authentication Alice Bob I’m Alice R1 f(KAlice-Bob, R1) R2 f(KAlice-Bob, R2) Optimize Alice Bob I’m Alice, R2 R1, f(KAlice-Bob, R2) f(KAlice-Bob, R1)

Mutual Authentication (Cont’d) Reflection attack Trudy Bob I’m Alice, R2 R1, f(KAlice-Bob, R2) f(KAlice-Bob, R1) Trudy Bob I’m Alice, R1 R3, f(KAlice-Bob, R1)

Reflection Attacks (Con’td) Lesson: Don’t have Alice and Bob do exactly the same thing Different keys Totally different keys KAlice-Bob = KBob-Alice + 1 Different Challenges The initiator should be the first to prove its identity Assumption: initiator is more likely to be the bad guy

Mutual Authentication (Cont’d) Password guessing Alice Bob I’m Alice, R2 R1, f(KAlice-Bob, R2) f(KAlice-Bob, R1) Countermeasure Alice Bob I’m Alice R1 f(KAlice-Bob, R1), R2 f(KAlice-Bob, R2)

Mutual Authentication (Cont’d) Public keys Authentication of public keys is a critical issue Alice Bob I’m Alice, {R2}Bob R2, {R1}Alice R1

Mutual Authentication (Cont’d) Mutual authentication with timestamps Require synchronized clocks Alice and Bob have to encrypt different timestamps Alice Bob I’m Alice, f(KAlice-Bob, timestamp) f(KAlice-Bob, timestamp+1)

Integrity/Encryption for Data Communication after mutual authentication should be cryptographically protected as well Require a session key established during mutual authentication

Establishment of Session Keys Secret key based authentication Assume the following authentication happened. Can we use KAlice-Bob{R} as the session key? Can we use KAlice-Bob{R+1} as the session key? In general, modify KAlice-Bob and encrypt R. Use the result as the session key. No to both questions. In the second question, Trudy may impersonate Bob and use R+1 as a challenge. As a result, Trudy gets the session key. Alice Bob I’m Alice R KAlice-Bob{R}

Establishment of Session Keys (Cont’d) Two-way public key based authentication Alice chooses a random number R, encrypts it with Bob’s public key Trudy may hijack the conversation Alice encrypts and signs R Trudy may save all the traffic, and decrypt all the encrypted traffic when she is able to compromise Bob Less severe threat

Two-Way Public Key Based Authentication (Cont’d) A better approach Alice chooses and encrypts R1 with Bob’s public key Bob chooses and encrypts R2 with Alice’s public key Session key is R1R2 Trudy will have to compromise both Alice and Bob An even better approach Alice and Bob estatlish the session key with Diffie-Hellman key exchange Alice and Bob signs the quantity they send Trudy can’t learn anything about the session key even if she compromises both Alice and Bob

Establishment of Session Keys (Cont’d) One-way public key based authentication It’s only necessary to authenticate the server Example: SSL Encrypt R with Bob’s public key Diffie-Hellman key exchange Bob signs the D-H public key

Mediated Authentication (With KDC) KDC operation (in principle) Alice Bob KDC Generate KAB Alice wants Bob KBob{KAB} KAlice{KAB} Some concerns Trudy may claim to be Alice and talk to KDC Trudy cannot get anything useful Messages encrypted by Alice may get to Bob before KDC’s message It may be difficult for KDC to connect to Bob Use a trusted node named key distribution center (kdc) that knows keys for all the nodes.

Mediated Authentication (With KDC) KDC operation (in practice) Alice Bob KDC Generate KAB Alice wants Bob KBob{KAB} KAlice{KAB}, KBob{KAB} ticket Must be followed by a mutual authentication exchange To confirm that Alice and Bob have the same key

Needham-Schroeder Protocol Classic protocol for authentication with KDC Many others have been modeled after it (e.g., Kerberos) Nonce: A number that is used only once Deal with replay attacks Alice Bob KDC Generate KAB N1, Alice wants Bob ticket to Bob, KAB{N2} KAlice{N1, “Bob”, KAB, ticket to Bob}, where ticket to Bob = KBob{KAB, Alice} KAB{N21, N3} KAB{N31} N1 is to prevent replay attacks and assure Alice that she is really talking to the KDC, which assume a previous K_Bob, and the KAlice{N1, “Bob”, KAB, ticket to Bob} is known by Trudy. Not a practical threat, but remove the minor possibility in any circumstances.

Needham-Schroeder Protocol (Cont’d) A vulnerability When Trudy gets a previous key used by Alice, Trudy may reuse a previous ticket issued to Bob for Alice Essential reason The ticket to Bob stays valid even if Alice changes her key A previous K_Alice is compromised, well the current K_Alice is secure.

Expanded Needham-Schroeder Protocol Alice Bob KDC Generate KAB; extract NB N1, Alice wants Bob, KBob{NB} ticket to Bob, KAB{N2} KAlice{N1, “Bob”, KAB, ticket to Bob}, where ticket to Bob = KBob{KAB, Alice, NB} KAB{N21, N3} KAB{N31} I want to talk to you KBob{NB} The additional two messages assure Bob that the initiator has talked to KDC since Bob generates NB

Otway-Rees Protocol Only has five messages NC, “Alice”, “Bob”, KAlice{NA, NC, “Alice”, “Bob”} Alice Bob Generate KAB Extract NB KAlice{NA, NC, “Alice”, “Bob”}, KBob{NB, NC, “Alice”, “Bob”} KDC NC, KAlice{NA, KAB}, KBob{NB, KAB} KAlice{NA, KAB} KAB{anything recognizable} Only has five messages KDC checks if NC matches in both cipher-texts Make sure that Bob is really Bob