Key Management. Shared Key Exchange Problem How do Alice and Bob exchange a shared secret? Offline – Doesn’t scale Using public key cryptography (possible)

Key Management

Shared Key Exchange Problem• How do Alice and Bob exchange a shared secret?• Offline

– Doesn’t scale• Using public key cryptography (possible)• Using specially crafted messages (Diffie Hellman)• Using a trusted third party (KDC)

– Secrets should never be sent in clear– We should prevent replay attacks– We should prevent reuse of old keys

• Exchange a secret with someone you never met while shouting in a room full of people

• Alice and Bob agree on g and large n

• Alice chooses random a, sends

• Bob chooses random b, sends

• Alice takes Bob’s message and calculates

• Bob does the same; now they both know shared secret

nga mod

ngb mod

ngab mod

ngab mod

Diffie Hellman Key Exchange

• Building up to Needham Schroeder/Kerberos• User sends req. to KDC (key distrib. center)• KDC generates a shared key: Kc,s

• Keys KKDC,C and KKDC,S are preconfigured• No keys ever traverse net in the clear• Why are identities in tickets?

KDC Based Key Distribution

C KDC S3. EKKDC,S{C, Kc,s}

2. EKKDC,C{S, Kc,s}

1. C, S

ticket

• KDC does not have to talk both to C and S

• Messages 2 or 3 can be replayed by M– Force C and S to use same secret for a long time– Cause S to have an old ticket, break comm. w C

KDC Based Key Distribution

CKDC

S

ticketS = EKKDC,S{C, Kc,s}

2. EKKDC,C{S, Kc,s}, ticketS

1. C, S

3. ticketS

• Use nonces to prevent replay attacks

Needham-Shroeder Key Exchange

C

KDC

S

ticketS = EKKDC,S{C, Kc,s}

2. EKKDC,C{N1, S, Kc,s, ticketS}

1. N1, C, S

3. EKC,S{N2}, ticketS

4. EKC,S{N2-1, N3}

5. EKC,S{N3-1}

• What happens if attacker gets session key?– Can reuse old session key to answer challenge-

response, generate new requests, etc– Need timestamps to ensure freshness = tickets

expire after some time

Problem

Public Key Exchange Problem

• How do we verify an identity:– Alice sends to Bob her public key Pub(A)– Bob sends to Alice his public key Pub(B)– How do we ensure that those keys really belong to

Alice and Bob? Need a trusted third party

Man-in-the-Middle Attack On Key Exchange

• Alice sends to Bob her public key Pub(A)• Mallory captures this and sends to Bob Pub(M)• Bob sends to Alice his public key Pub(B)• Mallory captures this and sends to Alice Pub(M)• Now Alice and Bob correspond through Mallory

who can read/change all their messages

• Public key is public but …– How does either side know who and what the key is

for? • Does this solve key distribution problem?– No – while confidentiality is not required, integrity is

• Still need trusted third party– Digital certificates – certificate authority (CA) signs

identity+public key tuple with its private key– Problem is finding a CA that both client and server

trust

Public Key Exchange

Digital Certificates

• Everyone has Trent’s public key• Trent signs both Alice’s and Bob’s public keys – he

generates public-key certificate• When they receive keys, verify the signature• Mallory cannot impersonate Alice or Bob because

her key is signed as Mallory’s• Certificate usually contains more than the public

key – Name, network address, organization

• Trent is known as Certificate Authority (CA)

• Authentication steps– Alice provides nonce, or a timestamp is used

instead, along with her certificate.– Bob selects session key and sends it to Alice with

nonce, encrypted with Alice’s public key, and signed with Bob’s private key. He sends his certificate too

– Alice validates certificate – it is really Bob’s key inside

– Alice checks signature and nonce – Bob really generated the message and it is fresh

Certificate-Based Key Exchange

• Pretty Good Privacy– “Web of Trust”– Public key, identity association is signed by

many entities– Receiver hopefully can locate several signatures

that he can trust– Like an endorsement scheme

PGP

• User keys installed on server out of band– User logs in with a password– Copies her public key onto server

• Weak assurance of server keys– User machine remembers server keys on first

contact– Checks if this is still the same host on

subsequent contact– But no check on first contact

SSH

• Revocation lists (CRL’s)– Long lists– Hard to propagate

• Lifetime / Expiration– Short life allows assurance of validity at time of

issue• Real time validation– Receiver of a certificate asks the CA who signed it

if corresponding private key was compromised– Can cache replies

Recovery From Stolen Private Keys

Authentication andIdentity Management

• Ideally– Who you are

• Practically– Something you know (e.g., password)– Something you have (e.g., badge)– Something about you (e.g., fingerprint)

Basis for Authentication

Password Authentication• Alice inputs her password, computer verifies

this against list of passwords• If computer is broken into, hackers can learn

everybody’s passwords–Use one-way functions, store the result for

every valid password– Perform one-way function on input,

compare result against the list

Password Authentication• Hackers can compile a list of frequently used

passwords, apply one-way function to each and store them in a table – dictionary attack

• Host adds random salt to password, applies one-way function to that and stores result and salt value– Randomly generated, unique and long enough

Password Authentication• Someone sniffing on the network can learn the

password• Lamport hash or S-KEY – time-varying password– To set-up the system, Alice enters random number R–Host calculates

x0=h(R), x1=h(h(R)), x2=h(h(h(R))),..., x100

– Alice keeps this list, host sets her password to x101

– Alice logs on with x100, host verifies h(x100)=x101, resets password to x100

–Next time Alice logs on with x99

Password Authentication• Someone sniffing on the network can learn the

password–Host keeps a file of every user’s public key–Users keep their private keys–When Alice attempts to log on,

host sends her a random number R– Alice encrypts R with her private key

and sends to host–Host can now verify her identity by

decrypting the message and retrieving R

• Key Distribution– Confidentiality not needed for public key– Can be obtained ahead of time

• Performance– Slower than conventional cryptography– Implementations used for key distribution, then use

conventional crypto for data encryption• Trusted third party still needed– To certify public key– To manage revocation

Public Key Authentication

• Passport• Shibboleth

Single Sign-On

• Goal is single sign-on– Solves problem of weak or repeated user/pass

combinations• Implemented via redirections– Users authenticate themselves to a common server,

which gives them tickets• Widely deployed by Microsoft– Designed to use existing technologies in

servers/browsers (HTTP redirect, SSL, cookies, Javascript)

Passport

• Client (browser), merchant (Web server), Passport login server

• Passport server maintains authentication info for client – Gives merchant access when permitted by client

How Passport Works

David P. Kormann and Aviel D. Rubin,Risks of the Passport Single Signon Protocol,Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.

How Passport Works

David P. Kormann and Aviel D. Rubin,Risks of the Passport Single Signon Protocol,Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.

SSL

Token = encrypted authentication infousing key merchant shares with passport serverAlso set cookie at browser (passport)

• Placed into browser cache by servers to store state about this particular user– Contain any information that server wants to remember

about the user as name/value pairs– May contain expiration time– May persist across browser instances• Returned to server in clear on new access• Only those cookies created for the server’s domain

are sent to the server– May not be created by this server• Usually used for persistent sign in, shopping cart,

user preferences

How Cookies Work

• User logs in using her user/pass– Server sets a cookie with some info – username,

password, session ID …– Any future accesses return this info to the server who

uses it for authentication (equivalent to user/pass)– Once user signs out the cookie is deleted and the session

closed at the server• Problems– Cookies can be sniffed, remain on the browser because

user did not sign out, be stolen by cross-site scripting or via DNS poisoning

• Solutions: – Send cookies over SSL, use timed cookies, secure code,

bind cookies to IP address of the client, encrypt cookies …

Cookies for Authentication

Learn more at: http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

• Service Provider– Browser goes to Resource Manager who uses

WAYF, and user’s Attribute Requester, and decides whether to grant access.

• “Where are you from” (WAYF) service– Redirects to correct servers

• Federation to form trusted relationships between providers

Federated Identity - Shibboleth

6. I know you now. Redirect to SP, with a

handle for user

8. Based on attribute values, allow access to

resource

Identity Provider(IdP)

Web Site

Service Provider (SP)Web Site

1. User requests resource

2. I don’t know you, or where you are from

LDAP

WAYF

3. Where are you from?

4. Redirect to IdP for your org

5. I don’t know you. Authenticate using your

org’s web login1

2

3

4

5

7

7. I don’t know your attributes. Ask the IdP (peer to peer)

6

ClientWeb Browser

8

Source: Kathryn Huxtable [email protected] 10 June 2005

Shibboleth - Protocol

• Cards– Mag stripe (= password)– Smart card, USB key– Time-varying password

• Issues– How to validate– How to read (i.e. infrastructure)

Something You Have

• Biometrics– Measures some physical attribute• Iris scan• Fingerprint• Picture• Voice

• Issues– How to prevent spoofing– What if spoofing is possible? No way to obtain new

credentials

Something About You

• Require at least two of the classes we mentioned, e.g.– Smart card plus PIN– RSA SecurID plus password– Biometric and password

Multi-factor Authentication

Authorization and Policy

• Is principal P permitted to perform action A on object O?– Authorization system will provide yes/no answer

Authorization

• Who is permitted to perform which actions on what objects?

• Access Control Matrix (ACM)– Columns indexed by principal– Rows indexed by objects– Elements are arrays of permissions indexed by

action• In practice, ACMs are abstract objects– Huge and sparse– Possibly distributed

Access Control

Example ACMFile/User Tom Dick Harry

Readme.txt read read read, write

passwords write

Term.exe read, write, execute

• Access Control Lists (ACLs)– For each object, list principals and actions

permitted on that object– Corresponds to rows of ACM

Instantiations of ACMs

File

Readme.txt Tom: read, Dick: read, Harry: read, write

passwords Harry: write

Term.exe Tom: read, write, execute

• Capabilities– For each principal, list objects and actions

permitted for that principal– Corresponds to columns of ACM

• The Unix file system is an example of…?

Instantiations of ACMs

User

Tom Readme.txt: read, Term.exe: read, write, execute

Dick Readme.txt: read

Harry Readme.txt: read, write; passwords: write

• Discretionary• Mandatory • Role-based

Types of Access Control

• Owners control access to objects• Access permissions based on identity of

subject/object• E.g., access to health information

Discretionary Access Control

• Rules set by the system, cannot be overriden by owners• Each object has a classification and each

subject has a clearance (unclassified, classified, secret, top-secret)• Rules speak about how to match categories

and classifications– Access is granted on a match

Mandatory Access Control

• Ability to access objects depends on one’s role in the organization

• Roles of a user can change– Restrictions may limit holding multiple roles

simultaneously or within a session, or over longer periods.

– Supports separation of roles• Maps to organization structure

Role-Based Access Control

• Final goal of security– Determine whether to allow an operation

• Depends upon– Policy– Authentication

Authorization

• Policy defines what is allowed and how the system and security mechanisms should act

• Policy is enforced by mechanism which interprets it, e.g.– Firewalls– IDS– Access control lists

• Implemented as– Software (which must be implemented correctly and

without vulnerabilities)

Policy

• Focuses on controlled access to classified information and on confidentiality– No concern about integrity

• The model is a formal state transition model of computer security policy – Describes a set of access control rules which use

security classification on objects and clearances for subjects

• To determine if a subject can access an object– Combine mandatory and discretionary AC (ACM)– Compare object’s classification with subject’s

clearance (Top Secret, Secret, Confid., Unclass.)– Allow access if ACM and level check say it’s OK

Policy models: Bell-LaPadula

• Mandatory access control rules:– a subject at a given clearance may not read an object

at a higher classification (no read-up)– a subject at a given clearance must not write to any

object at a lower classification (no write-down). • Trusted subjects – the “no write-down” rule does

not apply to them– Transfer info from high clearance to low clearance

Policy models: Bell-LaPadula

Life-Experience Passwords (LEPs)

• Strong passwords are easily forgotten• Weak passwords are easily broken• Users reuse passwords at different sites• This holds for non-textual passwords too, plus they

are more difficult to use

Problem with passwords

memorabilityguessability

• Use memories from a user’s past – At least 2 years in the past

• Collect factoids – time, locations, people, activities, conversations– No preferences, no opinions

• Turn this into Q & A pairs– Questions become prompts– Answers become LEP

Life-experience Passwords

Life-experience Passwords

• How to collect memories, needs to be user-friendly– “Tell me a story” vs Q & A

• How to mine for useful data– Using natural language processing, hard in general

• How to detect weak factoids– E.g. relationships vs names, empty stories

• How to avoid use of sensitive info in LEPs• How to deal with synonyms, misspellings, etc.• How to store these passwords using one-way hashes

Challenges

User study

Users are asked to create 3 LEPs and 3 3class8 pass.Authenticate 1 week later – one attempt•Measure memorability, strength, diversity of pass•Ask a friend to try to guess passwords (Friend Free)

LEPs are strong

Most LEPs 3+ factoids. Up to 10 in free-formUp to 20 in guidedform

LEPs are memorable

LEP 3class8

LEPs are not easy to guessLEP

3class8 passwords were guessed 4.5% of time, even by acquaintances

Guessed only by close friends and spouses

Issues

• LEPs took 10x longer to create and input• How do we store LEPs?– Hash per answer • Easy to break by guessing most likely answers first

– Hash per LEP• User must recall all factoids

– Several hashes of strong combinations of factoids• No feedback to user what they missed

Try LEPs out

• Earn 2 participation points, have fun and help us collect more data

• http://leps.isi.edu/single_class