Introduction to Practical Cryptography
description
Transcript of Introduction to Practical Cryptography
![Page 1: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/1.jpg)
Introduction to Practical Cryptography
Protocols
![Page 2: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/2.jpg)
Agenda• Authentication• Security Handshakes
– One-way– Two-way
• Mediated Authentication• Kerberos
![Page 3: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/3.jpg)
Authentication
Prove continuity in relationship– Basis of trust– Identification Who you are
(biometrics)
What you have (tokens)What you know
Password: snoopy1Mother’s maiden name: jonesPets name: snoopy
Physical authentication: where you are
![Page 4: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/4.jpg)
Network Authentication
• Password
• One-time Passwords (ex. tokens)
• Network address– Caller-id - credit card – IP address– MAC address – banks
• Cryptographic protocols
![Page 5: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/5.jpg)
Concerns
• Impersonation
• Malicious insiders
• Eavesdropping– Keyboard sniffers– Shoulder-surfing– Network sniffers– Trojan horses
![Page 6: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/6.jpg)
2-Way Authentication
• Authentication often needed in both directions
• Server trusting user is not only concern– User must trust server – Ex. User accessing online bank account
• Variety of “solutions” in user applications
![Page 7: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/7.jpg)
Password-based Authentication• Proof by sharing• Doesn’t prevent insider attacks (system admin)• What is an appropriate password
– length? snoopy, snoopy1, snoopy12– reusable ? snoppy1, snoopy2, …. snoopy10, snoopy1– timeframe?
• How to do initial password distribution? lastname123, employee#
• Simple approach, works with humans … until user has too many to remember
– reuse across systems– Variations of something common: dog’s name– post-it on monitor– inconvenient to update, varying rules on what is appropriately complex,
how often to change snoopy1, Snoopy1, snoopy-1
![Page 8: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/8.jpg)
Storing Passwords
• Per-node
• Central repository
• Hashed passwords
• Password encryption– Salted passwords
![Page 9: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/9.jpg)
Password Guessing
• Online– Limited tries, exponential delays, alarm– But attacker can temporarily disable a user’s account –
ex. 3 tries and account locked until user calls help desk
• Offline: “dictionary” attack– Must capture password file– Try "obvious" passwords: snoopy, snoopy1, 1snoopy– Significant dates, easy patterns, personal information– While most systems disallow “dictionary words”,
complexity rules still give information – know need a digit, punctuation character …
Snoopy-12
![Page 10: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/10.jpg)
Passwords as Keys
• Directly as the key
• Convert to secret key– Transient, one-way transformation (hash)– Increase work of attacker
• Seed to pseudo-random number generator
![Page 11: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/11.jpg)
One-Time Passwords
• List of passwords used once only
• Need to re-initialize periodically
![Page 12: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/12.jpg)
OTPs – List Based
• Example: – Hash password 1000 times, store result on server– Client hashes 999 times, sends to server– Server verifies hash of received value matches stored– result– Store received hash
• Must be re-initialized periodically - over secure channel
![Page 13: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/13.jpg)
Lamport’s Hash
• One-time passwords• Server stores n, hashn(password)• User sends x = hashn-1(password)• Server computes hash(x), if = stored value, replaces stored value
with n-1 , x
• Safe from eavesdropping, server compromise not a problem for user
• No public key cryptography• Authentication not mutual• Add salt to password before hashing
– In case Alice uses same password on multiple systems– Salt must be stored on Alice’s system– Server uses hashn(password | salt)
![Page 14: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/14.jpg)
• Examples– RSA– VASCO Digipass
• Use a block cipher– Repeatedly encrypt– Continuously update every x seconds– Update each time user presses button
• Some work in both directions– Customer enters OTP– Server returns OTP, customer (manually) compares it
to value on token
OTP Generators (Tokens)
![Page 15: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/15.jpg)
• Help desk required – Synchronization not perfect– Premature battery death
• Cost – $15-$25 – banks with million customers
• User still needs pin (something you know + something you have)
• “Necklace of Tokens” issue– Only recently integrated with cell phones– Still rare to have multiple tokens on single device
• Non-standard algorithms– OATH effort
Tokens - Issues
![Page 16: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/16.jpg)
Cryptographic Authentication
• Tokens, smart cards use crypto• Use a password (or key) in a
cryptographic protocol– Prove possession of key– Mutual authentication
• Usually coupled with encryption of data after authentication
• Certificates– PKI covered in another lecture
![Page 17: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/17.jpg)
Pairwise Keying
Bob:xyzAlice:abcFey: ghjGeorge: 123Emily: mklDave: klj
Bob:xyzAlice:whoFey: binCarol: 123Emily: dogDave: cat
![Page 18: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/18.jpg)
Trusted Intermediaries (KDC)
Key Distribution Center
George-Bob:xyzGeorge-Alice:whoGeorge-Fey: bin…
Bob:13Carol: 31Dave: 7….
![Page 19: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/19.jpg)
KDC
• Can impersonate any node
• Single point of failure
• Potential bottleneck
![Page 20: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/20.jpg)
Certificate Authority
• Central point for certificates
• Signs cert for Alice containing her public key
• Others need only CA’s public key
• Revocation? – Real time with online KDC– Offline CA –expiration date, certificate
revocation list
![Page 21: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/21.jpg)
Agenda• Authentication• Security Handshakes
– One-way– Two-way
• Mediated Authentication• Kerberos
![Page 22: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/22.jpg)
Security Handshakes
• Considerations when creating protocols– Attacks/Information leakage– One-way– Mutual Authentication
![Page 23: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/23.jpg)
One-way Challenge-Response
Problems?– Authentication not mutual– Connection hijacking after authentication – attacker spoofs Alice or
Bob’s source address and send packets if conversation not encrypted– Off-line password/key attack – depends on length of K– Compromise of database/disk if K is stored, or temporary memory
access
Alice BobI’m Alice
challenge R
f(K,R)K = shared key
f: – encryption function – Bob just decrypts and verifies time in within allowed skew– hash – Bob needs to hash all times in allowable interval or Alice sends time
![Page 24: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/24.jpg)
One-Way using Timestamp
• Problems?– Impersonate Alice if intercept and send message – race condition– Keep list of used time stamps to prevent quick replay, but if use same K
with multiple servers, could send message to another server and impersonate Alice
– Clock skew/synchronization
Alice BobI’m Alice, f(K,timestamp)
![Page 25: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/25.jpg)
One-way Using Public Key
Alice BobI’m Alice
R
[R]Apriv
[R]Ax = R signed with Alice’s x key, where x is private (priv) or public (pub) key
Alice BobI’m Alice
[R]Apub
R
Bob decrypts with Alice’s public key and verifies R was returned.
Alice proves to Bob she has her private key by returning R
![Page 26: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/26.jpg)
One-way Problems
• First case:– Can send anything to Alice as R and get Alice
to sign it
• Second case:– Intercepted an encrypted message for Alice,
send it and get Alice to decrypt it
![Page 27: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/27.jpg)
Mutual Authentication
![Page 28: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/28.jpg)
Mutual Authentication with Secret Key
Alice BobI’m Alice
R1
f(K,R1)
R2
f(K,R2)
![Page 29: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/29.jpg)
Mutual Authentication with Secret Key
Alice BobI’m Alice, R2
f(K,R1)
R1, f(K,R2)
More efficient version:
![Page 30: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/30.jpg)
Mutual Authentication with Secret Key
Trudy BobI’m Alice, R2
Doesn’t know K so can’t sendf(K,R1)
R1, f(K,R2)
Trudy BobI’m Alice, R1
Now use f(K,R1) in above attempt
R3, f(K,R1)
Reflection attack:
Solutions:•Separate keys for each direction•Requirements on R values: odd in one direction, even in the other, concatenate with senders’ name
![Page 31: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/31.jpg)
Password/Key Guessing
• Also note, Trudy can get Bob to encrypt a value (or a several of values) and then try an offline attack to guess K
• Have Bob return R1 value for Alice to encrypt
Alice BobI’m Alice
f(K,R2)
R2, f(K,R1)
R1
Now Bob would have to reuse R1 in order for Trudy, who eavesdrops, to be able to use f(K,R1)
![Page 32: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/32.jpg)
Timestamps
• Same issues as before plus clock skew• Any modification to timestamp will work
Alice BobI’m Alice, f(K,timestamp)
f(K,timestamp+1)
![Page 33: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/33.jpg)
Mutual Authentication with Public Keys
• how to obtains/store/validate Bob’s public key
Alice BobI’m Alice, [R2]Bpub
R1
[R1]Apub, R2
![Page 34: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/34.jpg)
Session Key
• Once authentication occurs, want to encrypt data exchanged
• Session key• If key to one session obtained, can’t decrypt all
sessions• Don’t want known/easy to derive relationship
among session keys
![Page 35: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/35.jpg)
Agenda• Authentication• Security Handshakes
– One-way– Two-way
• Mediated Authentication• Kerberos
![Page 36: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/36.jpg)
Mediated Authentication
• Needham-Schroeder• Otway-Rees
![Page 37: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/37.jpg)
Needham-Schroeder
• N1, N2, N3 are nonces ("number used once")
N1, Alice wants to talk to BobAlice KDC Bob
EKa(N1, "Bob", Kab, ticket)N1 authenticates KDC to Aliceticket = EKb(Kab, "Alice")
EKab(N2), ticket
EKab(N2 - 1, N3)
EKab(N3 - 1)
Bob decrypts ticket to get Kab
Nonces used to verify each end has Kab
![Page 38: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/38.jpg)
Expanded Needham-Schroeder• Issue - ticket doesn’t expire• If Trudy obtains Alice’s key and ticket, Trudy can connect to Bob
even if Alice changes key.
N1, Alice wants to talk to Bob, Ekb(Nb)
Alice
KDC
Bob
EKa(N1, "Bob", Kab, ticket)ticket = EKb(Kab, "Alice", Ekb(Nb))
EKab(N2), ticket
EKab(N2 - 1, N3)
EKab(N3 - 1)
Ekb(Nb)
I want to talk to you
Nb is unique per session so can’t reuse ticket
![Page 39: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/39.jpg)
Needham-Schroeder
• Reflection attack in last steps if ECB mode (and nonce size = block size)Trudy->Bob: EKab(N2), ticket
Bob->Trudy: EKab(N2 - 1, N4)
Trudy->Bob: EKab(N4), ticket
Bob->Trudy: EKab(N4 - 1, N5)
Extract EKab(N4 - 1) and use in response of first run
• CBC solves this
Trudy doesn’t have Kab to obtain N4, needs N4-1 in next step, so get Bob to encrypt N4-1Extract 1st block of ciphertext
![Page 40: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/40.jpg)
Otway-Rees
Suspicious party should generate challenge
Alice
KDC
Bob
EKa(Na, Kab)
EKab(something recognizable)
Nc, "Alice", "Bob", EKa(Na, Nc, "Alice", "Bob")
EKa(Na, Nc, "Alice", "Bob"), EKb(Nb, Nc, "Alice", "Bob")
Nc, EKa(Na, Kab), EKb(Nb, Kab)
•Bob can’t decipher most of first message – forwards it to KDC•KDC verifies Nc matches in messages from Alice and Bob•KDC gives Bob message to forward to Alice•Alice trusts KDC and Bob are real - KDC would not have continued process if Bob did not have Kb to encrypt Nc and KDC was able to encrypt Na in message containing Kab•Bob trusts KDC – was able to encrypt Nb in message containing Kab•Last message proves to Bob that Alice knows Kab
![Page 41: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/41.jpg)
Encrypted Key Exchange (EKE)
Alice
BobShared weak secret W = hash(Alice’s password)
“Alice”, EW(ga mod p)
EW(gb mod p, C1)
EK(C1,C2)
EK(C2)
Both compute K = gab mod p
Diffie-Hellman key exchange with exchange encrypted – removes man in middleMutual authenticationIf try offline password attack, can’t determine correct plaintext – what is valid plaintext of ga mod p, gb mod p ?
Stores Alice, W
Both compute K = gab mod p
![Page 42: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/42.jpg)
Kerberos
• Based on Needham-Schroeder
• Uses time and includes ticket expiration
• Later in lecture
![Page 43: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/43.jpg)
Nonces
• Random number– 128-bit value negligible chance of being
repeated
• Timestamp – Synchronization– Predictable
• Sequence number– Maintain state– Predictable?
![Page 44: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/44.jpg)
Random Numbers
• Be careful with seed
• Size
• Easily known value: timestamp
• Divulging seed – don’t use some value included unencrypted in message
![Page 45: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/45.jpg)
Performance
• Number of messages exchanged
• Number of operations – using secret key algorithm– using public key algorithm– using hash
• And number of bytes involved
![Page 46: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/46.jpg)
Checklist
• Eavesdropping
• Initiation of conversation/partial conversations
• Impersonation by accepting a connection
• Access to disk/database at either end
• Man-in-middle
![Page 47: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/47.jpg)
Agenda• Authentication• Security Handshakes
– One-way– Two-way
• Mediated Authentication• Kerberos
![Page 48: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/48.jpg)
Needham-Schroeder
• N1, N2, N3 are nonces ("number used once")
N1, Alice wants to talk to BobAlice KDC Bob
EKa(N1, "Bob", Kab, ticket)N1 authenticates KDC to Aliceticket = EKb(Kab, "Alice")
EKab(N2), ticket
EKab(N2 - 1, N3)
EKab(N3 - 1)
Bob decrypts ticket to get Kab
Nonces used to verify each end has Kab
![Page 49: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/49.jpg)
Overview
• Originally developed at MIT• An essential part of Windows servers• Authentication infrastructure
– Designed to authenticate users to servers– Users must use their password as their initial
key and must not be forced to retype it constantly
• Based on Needham-Schroeder, with timestamps to limit key lifetime
![Page 50: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/50.jpg)
Versions
• MIT support: version 4 end-of-life in 2006– DES– Protocol flaw
• Original Needham-Schroeder protocol implicitly requires nonmalleable encryption: prevent an attacker, given a ciphertext, from producing a different ciphertext whose plaintext is meaningfully related to the plaintext of the original ciphertext.
• Kerberos version 4 fails to provide by inadequately authenticating its messages. Nonmalleability concept was not well-developed at the time.
– nonstandard propagating cipher block chaining (PCBC) mode. ciphertext block swaps being undetectable without additional integrity checking.
– Implementation flaws• Version 5
– Fixes/improvements (delegation, ticket lifetime, key versions …)– Encoding changes– Optional, variable-length fields, types
• Adds flexibility, but increases number of bytes per message and processing overhead
![Page 51: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/51.jpg)
Design Goals
• Users only have passwords to authenticate themselves
• The network is completely insecure
• It’s possible to protect the Kerberos server
• The workstations have not been tampered with (not a safe assumption)
![Page 52: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/52.jpg)
Resources Protected
• Network access to home directory
• Printer
• IM system
• Remote login
• Anything else that requires authentication
![Page 53: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/53.jpg)
Principals
• A Kerberos entity is known as a principal
• Could be a user or a system service
• Principal names are tuples: V4: <primary name, instance, realm>
V5: <primary name + variable fields, realm>
• The realm identifies the Kerberos server
![Page 54: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/54.jpg)
How Kerberos Works
• Users present tickets — cryptographically sealed messages with session keys and identities — to obtain a service.
• Use Needham-Schroeder (with password as Alice’s key) to get a Ticket-Granting Ticket (TGT); this ticket (and the associated key) are retained for future use during its lifetime.
• Use the TGT (and TGT’s key) in a Needham-Schroeder dialog to obtain keys for each actual service
![Page 55: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/55.jpg)
Shared Secret
• Each principal (user, device) shares a secret (master key) with the Kerberos KDC
• For users, this is their password (actually, a key derived from the password)
• The KDC is assumed to be secure and trustworthy; anything it says can be believed
![Page 56: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/56.jpg)
Kerberos Data Flow
TGT is ticket granting ticket
![Page 57: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/57.jpg)
Obtaining TGT
Alice Workstation KDCAS_REQAlice needs a TGT
AS_REQ: authentication server requestAS_REP: authentication server replyTGT: ticket granting ticketK_KDC is KDC’s master key
AS_REPEKA(SA,TGT)
Creates session key SALooks up Alice’s master key KACreate TGT EK_KDC(Alice,SA,expire time)
Alice, password
KDC stateless – sends ticket, does not need to save a copy
Workstation sends TGT when Alice needs to access remote resource
![Page 58: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/58.jpg)
Ticket Request
AliceWorkstation
KDC
TGS_REQAlice wants to talk to BobTGT Authenticator = ESA(timestamp)
TGS_REPESA(Bob, KAB, ticket to Bob)
Creates key KABDecrypts TGT to get SADecrypts authenticator to verify timestampLooks up Bob’s key KBCreates ticket EKB(Alice, KAB)
Login to Bob
![Page 59: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/59.jpg)
Access Remote Resource
Workstation(Alice)
Bob
AP_REQTicket to Bob = EKB(Alice, KAB)Authenticator = EKAB(timestamp)
AP_REPEKAB(timestamp+1)
![Page 60: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/60.jpg)
Messages
• Message fields listed in text
• Part of assigned readings
• Know what they mean/are for
• Don’t need to memorize list of fields for midterm
![Page 61: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/61.jpg)
Service Tickets
• Service tickets are almost identical to ticket-granting tickets
• The differences is that they have the name of a different service — say, “email” — rather than the ticket-granting service
• They’re encrypted in a key shared by the KDC and the service
![Page 62: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/62.jpg)
Using Service Tickets
• The client sends the service ticket and an authenticator to the service
• The service decrypts the ticket, using its own key• The service knows it’s genuine, because only the KDC
knows the key used to produce it• The service verifies that the ticket is for it and not some
other service• It uses the enclosed key to decrypt and verify the
authenticator• The net result is that the service knows the client’s
principal name, extracted from the ticket
![Page 63: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/63.jpg)
Authentication, Not Authorization
• Kerberos is an authentication service
• It does not (usually) provide authorization
• The services know a genuine name for the client, vouched for by the KDC
• They then make their own authorization decision based on this name
![Page 64: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/64.jpg)
Bidirectional Authentication
• Sometimes, the client wants to be sure of the server’s identity
• It asks the server to prove that it, too, knows the session key
• The server replies with EKAB(timestamp+1) using the same timestamp as was in the authenticator
![Page 65: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/65.jpg)
Ticket Lifetime
• TGTs typically last about 8–12 hours — the length of a login session
• Service tickets can be long- or short-lived, but don’t outlive the TGT
• Live tickets are cached by the client
• When service tickets expire, they’re automatically and transparently renewed
![Page 66: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/66.jpg)
Inter-Realm Tickets
• A ticket from one realm can’t be used in another, since a KDC in one realm doesn’t share secrets with services in another realm
• Realms can issue tickets to each other• A client can ask its KDC for a TGT to another
realm’s KDC• The remote realm trusts the user’s KDC to
vouch for the user’s identity• It then issues service tickets with the original
realm’s name for the principal, not its own realm name
![Page 67: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/67.jpg)
Putting Authorization in Tickets
• Under certain circumstances, tickets can contain authorization information known or supplied to the KDC
• Windows KDCs use this, to centralize authorization data
• As a result, Windows and open source Kerberos KDCs don’t interoperate well.
• Users can supply some authorization data, too, to restrict what other services do with proxy tickets
![Page 68: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/68.jpg)
Proxy Tickets
• Suppose a client wants to print a file
• The print spooler doesn’t want to copy the user’s file; that’s expensive
• The user obtains a proxy ticket granting the print spooler access to its files
• The print spooler uses that ticket to read the user’s file
![Page 69: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/69.jpg)
Restricting the Print Spooler
• The client doesn’t want the spooler to have access to all of its files
• It lists the appropriate file names in the proxy ticket request; the KDC puts that list of names into the proxy ticket
• When the print spooler presents the proxy ticket to a file server, it will only be given those files
• Note: the file server must verify that the client has access to those files.
![Page 70: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/70.jpg)
Limitations of Kerberos
• Ticket cache security
• Password-guessing
• Subverted login command
![Page 71: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/71.jpg)
Ticket Cache Security
• Where are cached tickets stored?
• Often in /tmp — is the OS protection good enough?
• Less of an issue on single-user workstations; often a threat on multi-user machines
• Note: /tmp needs to be a local disk, and not something mounted via NFS. . .
![Page 72: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/72.jpg)
Subverting Login
• No great solutions.
• Keystroke loggers are a real threat today
• Some theoretical work on secure network booting
![Page 73: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/73.jpg)
Version 5 Changes
![Page 74: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/74.jpg)
Delegation
• Delegation of rights– Alice wants Bob to access resource X on behalf of
Alice for time t.• Example: Alice logs into host Bob then wants to log into host
X from Bob
– Alice can request ticket with Bob’s address or a list of addresses
– Ticket can include application specific data – not used by Kerberos but used by host
• Can set to not allow delegation
![Page 75: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/75.jpg)
Ticket Lifetime
• V4: 21 hours max• V5: up to Dec. 31, 9999• Lifetime in seconds• Not revocable – be careful• Time ticket granted, start time and stop time• Renew until – instead of long lifetime, give option to keep
renewing– If stop using/needing ticket, won’t remain open
• Postdating• Grant ticket to run some process in future
– Batch job at end of week but requested ticket at beginning of week
![Page 76: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/76.jpg)
Key Version
• Suppose Alice has ticket to Bob
• Bob changes his key with KDC
• KDC keeps versions both versions of Bob’s key (key, version)
• Alice’s ticket keeps working until it expires
• Any other renewable or post-dated ticket will work with old key
![Page 77: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/77.jpg)
Master Keys and Realms
• Master keys – key between entity (such as Alice) and KDC
• Alice registered to realms R1, R2– Uses same password
• Hash password with realm name to get master key
• If attacker gets Alice’s password, still can compute both master keys
• But R1 and R2 don’t have the other’s master key for Alice. If attacker breaks into one, won’t get both keys.
![Page 78: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/78.jpg)
Repairs
• Insert new cipher (AES) to replace DES
• Checksum fix for integrity – replaced by choice of algorithm
• PCBC – replaced by choice (AES-CBC common)
![Page 79: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/79.jpg)
Hierarchy of Realms
B C
D E
G H
F
JI
A
H to D, go through E then BList transited realms in ticket, don’t give transited realms power to impersonate othersIf don’t trust one realm, all realms visited after that one are suspect
![Page 80: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/80.jpg)
Hierarchy of Realms
B C
D E
G H
F
JI
A
May have short cut linksF talks directly to B instead of C then A then B
![Page 81: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/81.jpg)
Password Guessing
• V4: anyone can send ticket request to KDC
Alice wants to talk to Bob
Trudy KDC
• V5: include encrypted timestamp
Alice wants to talk to Bob, EKa(timestamp)
Alice KDC
![Page 82: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/82.jpg)
Password-Guessing
• Kerberos tickets have verifiable plaintext• An attacker can run password-guessing
programs on intercepted ticket-granting tickets (Merritt and Bellovin invented EKE while studying this problem with Kerberos.)
• Kerberos uses passphrases instead of passwords
• Does this make guessing harder? Not sure
![Page 83: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/83.jpg)
Password Guessing
• On many Kerberos systems, anyone can ask the KDC for a TGT
• There’s no need to eavesdrop to get them — you can get all the TGTs you want over the Internet.
• Solution: preauthentication• The initial request includes a timestamp
encrypted with Kc• It’s still verifiable plaintext, but collecting TGTs
becomes harder again
![Page 84: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/84.jpg)
Multiple Sessions – Added Security
• Alice opens two sessions to Bob
• Don’t want Trudy swapping messages between sessions
• Alice specifies different session key to use for each
![Page 85: Introduction to Practical Cryptography](https://reader036.fdocuments.in/reader036/viewer/2022062301/5681471b550346895db45043/html5/thumbnails/85.jpg)
Other Protocols in Practice
• SSH
• TLS
• IPsec
• Application aware – transport layer or above
• Application not aware - IP layer