CS 111 Spring 2012 Scribe Notes, Lecture 18

Confidentiality, Authorization, and Protocols (06/05/2012)

Written by Joseph Noor, Lecture by Paul Eggert

Authentication + Encryption

Kerchoff's Design Principle

This principle is important when designing cryptographic systems. The general idea is that a good cryptosystem minimizes what needs to be kept secret from the public. Ultimately, this comes down to only having a small private key, such that the rest is not needed to be kept secret to preserve authentication. The examples of authentication that upholds Kerchoff's Design Principle which we will study are SSH and IPSEC.

Figure 1: Kerchoff's Ideal System

SSH

From user's viewpoint: (list of clients)
- Client
  - ~/.ssh/id_rsa.pub (public key)
  - ~/.ssh/id_rsa (private key)
  - ~/.ssh/known_hosts (catch imposters)
- Server
  - ~/.ssh/authorized-keys
SSH Transport Layer
- Initial key exchange, typically RSA (public key + server authentication)
- Establishes a private key
- Reoccurs every hour
User Authentication Layer
- Public key OR password
- Problems with password:
  - Password guessing
  - Exposed whenever entered into computer
  - Solution: Use password in order to access private key
Problems with SSH as a protocol/software system
- Tempting to just use passwords (less secure)
- Heavyweight operations to get a connection
  
  -Solution: Use tunneling (port forwarding)
- Has trouble scaling (like, for example, in a corporate environment)
  
  -Solution: IPSEC

Figure 2: Tunneling Example

IPSEC

Much bigger and grander than SSH
Focus on key distribution and management
Tunneling is common and crucial: build Virtual Private Network (VPN) out of tunnels

Authorization (Access Control)

After authentication has been completed successfully, the next step in designing a system is to properly coordinate who has access to what. This is known as authorization, or access control. Authorization assumes that authentication has worked as planned, but somehow an "evil" attacker (usually an insider) has found their way into the system. Authorization then tries to mitigate the damage that a bad peer could cause by limiting the access that peer has to certain data. By limiting the permissions that each client has, we can limit the harm an insider could cause. The goals of authorization are as follow:

Keep privacy intact (prevent information leakage)
Keepy integrity intact (prevent information corruption)
Maintain trust (program assumptions on data integrity are maintained)

The basic questions that outline the definition of authorization are:

What is your security model (objects, principals, rights)?
What are the threats (mostly worried about insiders)?

------An aside on the classification of an insider--------

During the 2008 presidential campaign, a Republican obtained access to the DNC system by observing a Democratic leader enter his information. He discovered private member info and emails. Question: is the Republican attacker considered an insider? Answer: Yes. An insider is an attacker that has gained access to the system without compromising authentication. Even though the system's authentication system worked exactly as planned, the insider was still able to gain access to the system. The goal of authorization is to limit the privileges that any client holds to mitigate the potential damage that client might commit if it was actually an insider.

-----------------------------------------------------------------

We are working with a big machine. This means that we are handling many resources, many users (who might not all be inter-connected), and many operations. We want to find an efficient way to answer: can user x write to file y?

The general solution to something like this can be seen in the figure below. Each position on the 3D cube represents a bool for whether or not a user (y) can perform an operation (z) on a specified file (x). This can easily be represented with one bit each, but as you scale this cube (such as for Facebook), you would have something like:

900 million users * 4 billion files on FB * 10 operations = massive storage overhead.

Figure 3: Authorization Cube

The solutions range from simple, such as the Unix model, to much more complex, such as role-based access control.

Simple Model: Unix Model

Uses grouping to limit permissions. rwx: read, write, execute/search

Owner - one guy
Group - one group
Other - everyone else

Example: UCLA webserver, files for CS111

Owner: Eggert
Group: CS111 TAs
Other: Everyone else

Issues:

Group info stored in /etc/groups. Only root can change it.
Doesn't scale well

Next Level Model: ACL Model

Uses access control lists (ACL)
Associated with each file is an access control list that designated permissions for that file
The owner may manipulate the ACL
ACL is in file metadata, change using syscall

ACL Example:

cd /.u/class/spring12/cs111

setfact -r -m user:kobe:rwx

+ More Flexible
+ Easier to Administrate
+ Some overhead.
- Users don't give up rights

Problem: Once you gain a right, you don't give them up. Certain users can gain too many rights and have access to too much. Programs and files should be continuously limited.

Fancy Model: Role-Based Access Control (RBAC)

Examples of usage: Active Dir, FreeBSD, Solaris, SELinux

Adds the concept of user-attained roles.
Example roles: professor, sys admin, student
You may assume a role, but you may lose rights from giving up your old role. This can be extrapolated over multiple sessions with many different roles.

The key idea here is the difference between an ACL and a Capability (used in roles):
ACLs: Guardians of data, resides next to the data. (e.g. Unix' access rights for files (3-entry ACL))
Capabilities: Guardians of data, resides next to the process. Handle that gives you the right to access an object

Example 1: simple read

fd = open("/etc/passwd", O_RDONLY, 0000); //This has an ACL Check based on flags

read(fd, buf, 4); //This is a capability check. OS looks at bit in file description. Faster, cachable, and WILL WORK!

+ Faster (rights/capabilities can be cached)
- Revoking is harder

Example 2: network & server

Server has ACL
Capabilities over a network are typically an encrypted hash
Server gives new object unsigned int. Client must keep int secret
Upon client access, ask: does request have the secret int?

This allows clients to delegate access and capabilities of certain files to other clients.