Security - Authentication Protocols and Authorisation

1. Security - Authentication Protocols and Authorisation CS3517 Distributed Systems and Security Lecture 21

2. Last Lecture • SSL Handshake Phases • ‘Browser sends SSL version and cryptographic preferences (e.g. RSA for key exchange, DES for communication) to server’ • Correct version is on CS3517 website

3. Authentication • Verification of identity: • Authentication is the act of verifying someone’s identity • Users have to follow a particular procedure to prove their identity to a service • It doesn’t specify what a user is allowed or not allowed to do (that would be authorisation)

4. Authentication • Goal: Users want to prove their identity to a server “I am Alice” “Alice” “Bob” In a network, Bob cannot “see” Alice, so how can he be sure about the identity / origin of the received request?

5. Authentication - Problem • Goal: Users want to prove their identity to a server “Alice” “Bob” In a network, Bob cannot “see” Alice, an impostor can declare herself to be “Alice” “I am Alice” “Impostor”

6. Authentication • Goal: Users want to prove their identity to a server Alice’s IP address “I am Alice” “Alice” “Bob” Failure scenario?

7. Authentication • Goal: Users want to prove their identity to a server “Alice” “Bob” Failure scenario: Impostor can create a packet “spoofing” Alice’s IP address Alice’s IP address “I am Alice” “Impostor”

8. Authentication • Use Password: transmit password in the clear over network • Main Problem: eavesdropping / interception Alice’s IP address Alice’s Password “I am Alice” “Alice” “Bob” Failure scenario? Alice’s IP address “OK”

9. Authentication • Use Password: transmit password in the clear over network • “Playback Attack” Alice’s IP address Alice’s Password “I am Alice” “Alice” “Bob” Playback Attack: Impostor records the IP packets exchanged Alice’s IP address “OK” Records Interaction “Impostor”

10. Authentication • Use Password: transmit password in the clear over network • “Playback Attack” “Alice” “Bob” Playback Attack: Impostor records the IP packets exchanged and plays it back to receiver Alice’s IP address Alice’s Password “I am Alice” Alice’s IP address “OK” “Impostor”

11. Authentication • Use encrypted Password: sender sends an encrypted password (signature) to prove that this message is genuine Alice’s IP address Encrypted Password “I am Alice” “Alice” “Bob” Failure scenario? Alice’s IP address “OK”

12. Authentication • Problem: playback attack still works! “Alice” “Bob” Playback Attack: Impostor records the IP packets exchanged and plays it back to receiver Alice’s IP address Encrypted Password “I am Alice” Alice’s IP address “OK” “Impostor”

13. Cryptographic Authentication • No password is transmitted over the network • Users prove their identity to a service by performing a cryptographic operation, usually on some digital entity supplied by the server • Cryptographic operations are based on the user’s secret key

14. Authentication with Symmetric Keys • Goal: Avoid playback attacks • Use a “nonce” (a number used only once), issued by the receiver • Sender uses secret (private) key to encrypt nonce • Scenario: • “Alice” sends identification • To test/prove that “Alice” is the sender, “Bob” sends the nonce “R” back • “Alice” must return R, encrypted with the secret key “I am Alice” “Alice” “Bob” R Only “Alice” knows key to encrypt the nonce. Failures, drawbacks? KA-B(R)

15. Authentication with Symmetric Keys • Problems • Poor scaling properties • Generalising the model for m users and n services requires a priory distribution of m x n secret keys • Possible Improvement • Use a trusted 3rd party, with which each user and service shares a secret key • These are then “only” m + n secret keys to be shared

16. Key Distribution Center (KDC) • A Key Distribution Center is a trusted 3rd party that shares different secret keys with each registered user • The KDC introduces “Mediated Authentication” • Each user and service shares a secret key with the trusted KDC • KDC generates a session key and securely distributes it to the parties that wish to communicate • Communicating parties prove to each other that they know the session key

17. Mediated Authentication • Goal: two parties share a secret key for communication • KDC mediates this process • Two nonces, “R1” and “R2” are used Alice Bob “I am Alice, I want to speak to Bob” KDC KA-KDC(KA-B, Bob) KB-KDC(KA-B, Alice) Generates key KA-B Alice sends nonce R1 R1 KA-B(R1), R2 Bob sends nonce R2 KA-B(R2)

18. Mediated Authentication (2) • Goal: Avoid KDC having to communicate with Bob • Use “Tickets” (security tokens that expire) Alice Bob “I am Alice, I want to speak to Bob” KDC KA-KDC(KA-B, Bob), TicketB = KB-KDC(KA-B, Alice) Generates key KA-B Alice, TicketB = KB-KDC(KA-B, Alice) R1 KA-B(R1), R2 KA-B(R2)

19. Kerberos • Widely adopted and implemented in popular operating systems • See http://www.kerberos.org • Kerberos uses time stamps as “nonces” in the mutual authentication phase of the protocol • It uses mediated authentication with tickets • Very useful background reading – see hidden slides from PowerPoint version of this lecture on the CS3517 website

20. Security - Authorisation

21. Authorisation • Authentication - verifying who you are • Authorisation- verifying what you are allowed to do (what services to use, what actions to perform), after a server has authenticated you • Access Control is a mechanism to control (allow / deny) access to resources • Examples include files, services, machines on a network etc.

22. Access Control • Assign access rights to resources • What access rights should each user have? • Enforce access Rights • Fight security threats • Stop insiders from abusing access rights to a system (either accidentally or deliberately) • Limit damage from external hackers

23. Access Control: Examples • Possible restrictions in accessing resources • Customer - can only see own data, has limited modification rights • Staff – may only issue refunds for returned items below 1000 pounds, otherwise extra permission is required • Web applications - limited rights to access and manipulate a database • Limits damage from hackers who break in

24. Deciding on Access Rights • Classify users, resources, rights • Decide what rights each type of user has for each type of resource • Should these rights be permanent or temporary? • Should access be audited (logged in log files)? • Implement access rights using OS features • User / group rights in UNIX • Access control lists • Access rights in SQL databases • GPOs (Active Directory) • Etc.

25. Access Control Lists (ACL) • Specify the access permissions of each group for each resource (or resource type) • E.g.: Doctors have read-access to the blood-test database: (doctors, blood-test.db) – read • E.g.: Lab personnel have read / write access to the blood-test database: (lab, blood-test.db) – read, write • Program-specific permissions • Introduce application-specific restrictions

26. Temporary Rights • Instead of fixed access, give user a certificate allowing him to do X to R • He / she has a capability • Cryptography validates certificate • Capabilities can be temporarily delegated or assigned • Nurse has the “see patient data for ward W” capability, while assigned to this ward

27. Audit • Access can be logged • Write to a log file • E.g. Allow all doctors full access to blood tests, but audit each access • Demand extra explanation for unusual activities • E.g. Access to data of patient who lives 200 miles away • Auditing is useful to monitor behaviour of privileged staff (e.g. Sys Admin), who have full access privileges to everything • In such a case, we have to protect the audit files themselves on a separate log server!

28. Classic UNIX Access Control • Unix users are organised in groups • A user is identified by its user ID(uid) • A user can be in multiple groups • A group is identified by a group ID(gid) • Each UNIX resource / file has a particular owner (a UNIX user) • Each process (program) started by the user inherits the user ID (uid) and group ID(gid) of the user • These two ID’s are used to identify what files / resources these programs may access • Each file has access rights defined for the file owner and for groups

29. The UNIX File System • Consists of a hierarchical directory structure • Each directory is a list of pairs: • (filename, inodenumber) • Information contained in an inode: • Where the file is stored • File length • Last time file was read / written • Owner (the uid of the process that created the file) • Group (the gid of the process that created the file) • Protection privileges: 12 bits

30. UNIX Access Privileges • Nine of the 12 bits encode access rights • User: read, write, execute • Group: read, write, execute • Other: read, write, execute • Other bits • Set user ID: change user ID on execution • if this bit is set, then the current user executing this file (program) has the same rights as the owner of the file being executed • Set group ID: change group ID on execution • If this bit is set, then the group rights of the owner of the file are inherited by the currently executing user • For directories: a new file created in a directory will inherit the group of the directory and not the group of the user / process that created the file drwxrwsr-x 4 mkolling lecturer 4096 Jul 28 2011 public_html

31. Windows Access Control • Access Control Lists • Is a list of “access control entries” (ACE) • Each ACE is defined for a resource • “open a file” • “run a program” • Etc. • Each ACE specifies for a resource • A trustee (the individual, group or session) • The access rights (allowed, denied, audited) • There are two types of ACLs • A DACL (discretionary access control list) is used to check whether a trustee can access the resource • A SACL (system access control list) is used to specify what access actions (or attempts) are to be audited

32. Access Control In SQL • SQL • Access rights are granted to individual users • Access rights for resources such as tables, columns • Privileges • Select, insert, update, delete, grant, revoke, etc. • MySQL additions • More privileges • Drop, alter, create, index • Also admin privileges (e.g. Shutdown, file) • Can also limit number of queries per hour • Groups • Specify rights by host as well as by user • Specify rights by connection type (e.g. SSL) • Can also audit access through general logs

33. Example: Online Bookstore • What are the groups? • What are the resources? • What are the access rights? • What are the threats? • See hidden slides from PowerPoint version of this lecture on the CS3517 website

34. Inference Control • Can people with limited access rights use these to learn things we don’t want them to know? • Real danger with aggregate queries • E.g.: Exam: • Why is it wrong to make public the average marks grouped by UK, EU and International students, when there is only one UK student on the course? • Inference attack • Using information from one security level from a database to infer a fact that should be protected at a higher security level

35. Tracker Queries • Deduce information about individuals by querying census databases • Census contains anonymised information about a person: address, income, occupation, marital status, children etc. • If I know where a person lives and know other details except income, I can formulate a query that may give me a result set with one entry – I may be able to deduce the income of a person from anonymised data in a census database • This is called a “tracker” • Exploits extreme values (e.g. a very special occupation) and other background knowledge

36. Tracker Defence • Possible defence • Database doesn’t respond, if the number of entries in the result set is below a minimum value • Does not work • Use multiple separate queries and intersect the result sets manually • Defence is hard (see Anderson, chapter 8.3)

37. Key Points • Access control: • Define the rights different users have to data • It is essential to limit the damage that can be done by “insiders” • Use OS/DB features • Design of the right and effective policies may be hard • Inference control • Attacker can learn a lot from what is regarded as limited or non-critical data