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

Diffie-Hellman Key Exchange 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

KDC Based Key Distribution 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? 1. C, S 3. EKKDC,S{C, Kc,s} C KDC S ticket 2. EKKDC,C{S, Kc,s}

KDC Based Key Distribution KDC does not have to talk both to C and S Messages 2 or 3 can be replayed by Mallory Force C and S to use same secret for a long time Cause S to have an old ticket, break comm. w C ticketS = EKKDC,S{C, Kc,s} 1. C, S C KDC S 2. EKKDC,C{S, Kc,s}, ticketS 3. ticketS

Needham-Shroeder Key Exchange Use nonces to prevent replay attacks ticketS = EKKDC,S{C, Kc,s} 1. N1, C, S C KDC S 2. EKKDC,C{N1, S, Kc,s, ticketS} 3. EKC,S{N2}, ticketS 4. EKC,S{N2-1, N3} 5. EKC,S{N3-1}

Problem 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

Solution Introduce Ticket Granting Server (TGS) Daily ticket plus session keys Authentication server (AS) authenticates users TGS+AS = KDC This is modified Needham-Schroeder Basis for Kerberos

Kerberos C S Third-party authentication service Distributes session keys for authentication, confidentiality, and integrity TGS 4. TGSRep 3. TGSReq AS 2. ASRep 1. ASReq C S 5. SReq

Kerberos ASReq = userID, TGS, lifetime1 Kuser = f(passuser) ASReq = userID, TGS, lifetime1 TTGS = EKAS,TGS(TGS, C, KTGS,C, timestamp1, lifetime2) ASRep = EKuser(KTGS,C, TGS, timestamp2, lifetime2), TTGS TGSReq = TTGS, EKTGS,C(C, timestamp3), S, lifetime3 TS = EKS,TGS(S, C, KS,C, timestamp4, lifetime4) TGSRep = TS, EKC,TGS(KS,C, S, timestamp5, lifetime4) SReq = EKC,S{C, timestamp6}, TS

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

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)

Certificate-Based Key Exchange 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

PGP 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

SSH 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

Recovery From Stolen Private Keys 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

Authentication and Identity Management

Basis for Authentication Ideally Who you are Practically Something you know (e.g., password) Something you have (e.g., badge) Something about you (e.g., fingerprint)

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

Authentication With Symmetric Key Server sends random number R Client encrypts with symmetric key, sends back or Server sends random number R, encrypted with symmetric key Client decrypts, sends back Client decrypts, sends back R-1, encrypted with symmetric key

Authentication With Public Key Server sends random number R Client encrypts with private key, sends back or Server sends random number R, encrypted with public key of client Client decrypts, sends back

Authentication With Public Key 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

Single Sign-On Passport Shibboleth

Passport Goal is single sign-on Implemented via redirections 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)

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 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. SSL Token = encrypted authentication info using key merchant shares with passport server Also set cookie at browser (passport)

How Cookies Work 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

Cookies for Authentication 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 … Learn more at: http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

Federated Identity - Shibboleth 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

Shibboleth - Protocol 2. I don’t know you, or where you are from 3. Where are you from? Client Web Browser 4. Redirect to IdP for your org 1. User requests resource 5. I don’t know you. Authenticate using your org’s web login 8 1 3 5 Service Provider (SP) Web Site WAYF Identity Provider (IdP) Web Site 2 4 LDAP 6 7 6. I know you now. Redirect to SP, with a handle for user 8. Based on attribute values, allow access to resource 7. I don’t know your attributes. Ask the IdP (peer to peer) Source: Kathryn Huxtable khuxtable@ku.edu 10 June 2005

Something You Have Cards Issues Mag stripe (= password) Smart card, USB key Time-varying password Issues How to validate How to read (i.e. infrastructure)

Something About You Biometrics Issues 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

Multi-factor Authentication Require at least two of the classes we mentioned, e.g. Smart card plus PIN RSA SecurID plus password Biometric and password

Authorization and Policy

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

Access Control 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

Example ACM File/User Tom Dick Harry Readme.txt read read, write passwords write Term.exe read, write, execute

Instantiations of ACMs Access Control Lists (ACLs) For each object, list principals and actions permitted on that object Corresponds to rows of ACM File Readme.txt Tom: read, Dick: read, Harry: read, write passwords Harry: write Term.exe Tom: read, write, execute

Instantiations of ACMs 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…? User Tom Readme.txt: read, Term.exe: read, write, execute Dick Readme.txt: read Harry Readme.txt: read, write; passwords: write

Types of Access Control Discretionary Mandatory Role-based

Discretionary Access Control Owners control access to objects Access permissions based on identity of subject/object E.g., access to health information

Mandatory 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 19:59 19:59

Policy models: Bell-LaPadula 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

Role-Based 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

Attribute-Based Access Control Ability to access objects depends on attributes assigned to user and object, environment attributes, etc. Attributes can have single value (clearance) or multiple values (project membership) Example: students can view their grades only during weekdays and for courses that they took less than 3 years ago

Authorization Final goal of security Depends upon Determine whether to allow an operation Depends upon Policy Authentication

Policy 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)