470 likes | 484 Views
This chapter explores authentication protocols such as Kerberos and Needham-Schroeder for secure workstation authentication and key distribution. It also discusses the vulnerabilities and challenges associated with these protocols.
E N D
Chapter–8.5Authentication And Key Distribution Anjum Reyaz-Ahmed
Outline Part I : Authentication Protocols Kerberos Protocol Needham-Schroder Protocol Part II: Current Literary Review “Elliptical Curve Cryptography How it Works" Sun Microsystems Laboratory 2005 “Security Challenges in Seamless Mobility – How to Handover The Keys”, WICON 2008 Part III: Future Research Initiatives
Kerberos • Provide authentication for a user that works on a workstation. • Uses secret key technology • Because public key technology still had patent projection. • Implements authentication by Needham & Schroeder. • On the market in versions 4 and 5. [Chow and Johnson 1997]
Kerberos • Kerberos consists of • Key Distribution Center (KDC) • Runs on a physically secure node • Library of Subroutines • Modifies known UNIX libraries such as telnet, rlogin, … [Chow and Johnson 1997]
Key Distribution Center • KDC: • Database of keys for all users • Invents and hands out keys for each transaction between clients. Alice KDC Bob Alice wants Bob KAlice{ KAB for Bob } KBob{KAB for Alice} [Chow and Johnson 1997]
Key Distribution Center • Message from KDC to Bob has some problems. • Timing problem: Alice needs to wait to make sure that Bob got the key. • Change the protocol so that Alice receives a ticket to talk to Bob. [Chow and Johnson 1997]
Key Distribution Center Alice KDC Bob KAlice{Use KAB for Bob} Ticket for Bob := KBob{Use KAB for Alice} Alice wants Bob I’m Alice, my ticket is KBob{Use KAB for Alice} [Chow and Johnson 1997]
Key Distribution Center • Needham Schroeder: • Combines KDC operation with authentication. • Uses nonces instead of timestamps to prevent replay attacks. • A (sequential / random) number used only once. [Chow and Johnson 1997]
Needham Schroeder N1, Alice, Bob Bob Alice KDC KAlice{N1, Bob, KAB, ticket to Bob} Ticket, KAB{N2} KAB{N2-1, N3} KAB{N3-1} Ticket = KBob{KAB, Alice} [Chow and Johnson 1997]
Needham Schroeder Alice, Bob Bob Alice Trudy (KDC) KDC Trudy as Bob Kalice{ Bob, KAB, ticket to Bob} Ticket = KBob{KAB, Alice}, … Trudy can now successfully authenticate herself to Alice as Bob. Trudy impersonates the KDC and replays the old captured message, which looks like a normal message. Trudy waits until Alice makes a request to the KDC. Trudy now incorporates Bob. Purpose of the nonce is the following scenario: Assume that Trudy has stolen an old key of Bob’s and stolen the message where Alice previously has requested a key. Bob has in the meantime changed his key. But the nonces make all messages unique! [Chow and Johnson 1997]
Needham Schroeder • Message 2: KAlice{N1, Bob, KAB, ticket} with ticket = KBob{KAB,Alice} • N1 prevents replay attacks. • “Bob” to prevent Trudy from trying to play Bob. • Ticket does not have to be sent encrypted with Alice’s key. [Chow and Johnson 1997]
Needham Schroeder • Message 3: ticket, KAB{N2} • Alice presents a challenge together with her ticket. • Bob decodes ticket to find KAB. • He decodes the latter part of the message to find the challenge. [Chow and Johnson 1997]
Needham Schroeder • Message 4: KAB{N2-1,N3} • Bob solves Alice’s challenge. • Bob sends Alice his own challenge. • Your turn: What is the vulnerability if message 4 were to read: KAB{N2-1}, KAB{N3} ? Answer on next two slides.
Needham Schroeder • Answer: • Trudy eavesdrops on an exchange and then splices her own messages to Bob: [Chow and Johnson 1997]
Needham Schroeder Bob Alice Ticket, KAB{N2} KAB{N2-1}, KAB{N3} Replays Ticket, KAB{N2} KAB{N2-1} KAB{N4} Trudy (later) Trudy now resumes her first connection: KAB{N4-1} and is authenticated Ticket, KAB{N4} KAB{N4-1} KAB{N5} Trudy (second connection) [Chow and Johnson 1997]
Needham Schroeder • Expanded Needham Schroeder • Prevents replay attacks after Alice’s master key was stolen and Alice changed her master key. [Chow and Johnson 1997]
Needham Schroeder • Vulnerability Scenario • Alice has a previous key JAlice that Trudy captured. • Alice has changed her key to KAlice. • Trudy has captured a previous login request from Alice to KDC: • KDC sent JAlice{N1,Bob,JAB,KBob{JAB,Alice}} [Chow and Johnson 1997]
Needham Schroeder • Vulnerability Scenario • Trudy has JAlice{N1,Bob,JAB,KBob{JAB,Alice}} • Trudy calculates JAB and KBob{JAB,Alice} with JAlice. • Trudy now impersonates Alice to Bob. She sends her round 3 message to Bob: N2, KBob{JAB,Alice} • She can complete the Needham Schroeder protocol with Bob. • Since the KDC no longer participates, informing the KDC of the change does not prevent Trudy from succeeding impersonating Alice to Bob. [Chow and Johnson 1997]
Needham Schroeder Vulnerability Scenario • Trudy has • JAlice{N1,Bob,JAB,KBob{JAB,Alice}}, JAB. KBob{JAB,Alice}. • Trudy to Bob: JAB{N2}, KBob{JAB,Alice} • Bob to Trudy: JAB{N2–1, N3} • Trudy to Bob: JAB{N3–1} • Trudy and Bob are mutually authenticated! [Chow and Johnson 1997]
Needham Schroeder • Solution: • Prevent replays after long duration: • Clock and date. • Certificate from Bob. • Extended Needham Schroeder picks the latter. [Chow and Johnson 1997]
Extended Needham Schroeder Alice to Bob: I want to talk to you. Bob to Alice: KBob{NB} Alice to KDC: N1, “Alice wants Bob”, KBob{NB} KDC to Alice: KAlice{N1,“Bob”,KAB, KBob{KAB, “Alice”, NB}} Alice to Bob: KBob{KAB, “Alice”, NB}, KAB{N2} Bob to Alice: KAB{N2-1,N3} Alice to Bob: KAB{N3-1}. NB prevents the previous attack. Bob can determine whether Alice is using the key that the KDC has. [Chow and Johnson 1997]
Extended Needham Schroeder • Alice now needs to receive a certificate from Bob before starting standard Needham Schroeder. [Chow and Johnson 1997]
Otway Rees • Replaces extended Needham Schroeder • Uses only 5 messages • Speed-up results from the “suspicious party” (Bob) going to the KDC. [Chow and Johnson 1997]
Otway Rees Alice to Bob: NC, Alice Bob KAlice{NA, NC, Alice, Bob} Bob to KDC: KAlice{NA,NC, Alice, Bob}, KBob{NB, NC, Alice, Bob} KDC to Bob NC, KAlice{NA,KAB}, KBob{NB,KAB} Bob to Alice: KAlice{NA, KAB} Alice to Bob: KAB{NC} [Chow and Johnson 1997]
Kerberos • Based on Needham Schroeder, but uses time instead of nonces. • Approximate time is easy in distributed systems. [Chow and Johnson 1997]
Kerberos • Kerberos Authentication Service: Alice to KDC N1 “Alice wants Bob” KDC to Alice KAlice{N1, “Bob”, KAB, KBob{KAB, Alice, expir. Time}} Alice to Bob KBob{KAB, “Alice”, expir. Time}, KAB{cur. Time} Bob to Alice KAB{cur. Time +1} [Chow and Johnson 1997]
Kerberos • Kerberos Setup • Master key shared by KDC with each principal. • When Alice logs into her machine, her station asks the KDC for a session key for Alice. The KDC also gives her a Ticket Granting Ticket. (TGT) • Alice’s workstation retains only the session key and the TGT. • Alice’s workstation uses the TGT to receive other tickets from the Ticket Granting Service (TGS). [Chow and Johnson 1997]
Kerberos • Two entities: • Key distribution center. • Authentication Server (AS) • Ticket granting server (TGS). • Both need the same database, so they are usually on the same machine. [Chow and Johnson 1997]
Elliptical Curve Cryptography- How it works-----Sheueling Chang, Hans Eberle, Vipul Gupta, Nils Gura----Sun Microsystem 2005 Summary: Elliptical curve cryptosystem (ECC) operates over points on an elliptical curve The best known algorithm to attack ECC runs more slowly than best known algorithm to other cryptosystems ECC can offer equivalent security with subsequently smaller size keys. [Chang & et al. 2005]
Elliptical Curve Crytography Public-key cryptosystem offering the highest security strength per bit. Uses smaller keys for equivalent security. Results in faster computations and savings in memory, power and bandwidth (especially important in constrained environments). Performance advantage increases as security needs increase over time Endorsed/standardized by NIST, ANSI, IEEE, IETF. [Chang & et al. 2005]
How it works • Parameters: Elliptic curve, base point G • Scalar point multiplication: Q = kP, e.g. 9P = 2(2(2P)) + P • Hard problem: Given kP (public-key) & P, find k (private-key). EC Discrete Logarithm Problem – no known subexponential solutions. [Chang & et al. 2005]
ECC ON Small Devices Large keys are a big problem for small devices [Chang & et al. 2005]
Securing the Next Generation Internet The Internet today is ... a global marketplace for goods and services enabled by security mechanisms that ensure authentication, confidentiality and integrity predominantly secured by the SSL protocol using a combination of symmetric- and public-key cryptography but ... many new devices connecting to the Internet have limited capabilities (e.g. sensors, appliances) new applications (e.g. patient monitoring, building automation) will increase the number of transactions requiring security the future will demand higher levels of security (e.g. 128-bit AES, 2048-bit RSA) [Chang & et al. 2005]
What makes ECC hard to crack? The security of ECC relies on the difficulty of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP), i.e. finding k, given P and Q = kP. The problem is computationally intractable for large values of k.
Key Exchange • Each node has a CPU and communication controller running independently • Time Triggered Communication Protocol
Summary ECC can offer equivalent security with substantially smaller key sizes. For example, a 160-bit ECC key provides the same level of security as a 1024-bit RSA key and 224-bit ECC is equivalent to 2048-bit RSA. Smaller keys result in faster computations, lower power consumption, as well as memory and bandwidth savings. While these characteristics make ECC especially appealing for small embedded devices , they can also alleviate the computational burden on secure web servers. [Chang & et al. 2005]
Security Challenges in Seamless Mobility – How to "Handover" the keys? --- K Hooper, L Chen, A Izquierdo, N Golmie --- WICON 2008 Synopsis Key management challenges for seamless handover across heterogeneous wireless networks. [Hoeper et al. 2008]
Key Distributor • The authentication server of the serving network • the lowest common key holder in serving and target network • the lowest key holder in the serving network with access to target network via a short cut
Summary Discussion on various security aspects of key management and seamless mobility in heterogeneous networks. Show that Handover security and performance depends on the method used to derive the HO key hierarchy the network position of the entity acting as key distributor the protocol used to distribute HO keys Present three HO key distribution protocols: a push protocol and two variant of pull protocols.
Future of User Authentication Passwords are the weakest link in any system We need new methods of authenticating users Password 2.0?
Belly-Button Ring Identifiers If your mobile phone is your future authenticator, how do you authenticate to your mobile phone? One possibility is based on MIT’s “beeper-based” signature concept (R. Rivest, A. Lysyanskaya) “Beeper” that you wear — maybe a belly button ring? — sends low-power signal to your phone Fresh signal required for phone to generate digital signatures — otherwise phone won’t sign Beeper can authenticate you to your phone, and/or you and your phone to the network
Knowledge-Based Authentication Users will authenticate based on what they know — and what they’re able to do— in new and sophisticated ways Life questions” are quite common already for password reset, as well as account enrollment Human-computer interfaces offer new possibilities for authentication, e.g., PassfaceTM
References: • Randy Chow & Theodore Johnson . “Distributed Operating Systems & Algorithms”. pp 156-163 Addison-Wesley 1997 • Sheueling Chang, Hans Eberle, Vipul Gupta & Nils Gura. “Elliptical Curve Cryptography- How it works”. Sun Microsystem http://research.sun.com/projects/crypto/ , 2005 • Katrin Hoeper, Lidong Chen, Antonio Izquierdo & Nada Golmie. “Security Challenges in Seamless Mobility – How to Handover the Keys”. WICON IEEE, 2008