CS111 Lecture 18: Security

The most common form of attack in real world security applications is computer fraud. These types of attacks generally fall into the following categories:

• Against Privacy
• Against Integrity
• Against Service (ie Denial of Service, Dos)

Our general goals are to allow authorized access (positive goal), and disallow unauthorized access (negative goal). Generally positive goals are easier to test than negative goals.

In order to protect against malicious attacks, potential security risks must first be identified. The most common types of attacks include but are not limited to: Insiders, Social Engineering (outsiders posing as insiders), Network Attacks (viruses, drive by downloads, DoS, buffer overruns, etc.) and Device Attacks (USB switchblades / viruses).

Protection against these attacks must enforce four main ideas: Authorization (prove who you are), Integrity, Authorization (keep track of what you can do) and Auditing (second line of defense, see what was done). In order for these mechanisms to be realistically used in everyday practice, they require a high level of correctness and efficiency.

The first step in protection from fraudulent access is Authentication; proving you are who you are, which prevents attackers from masquerading as their target. Authentication falls into two categories, either External or Internal.

External (relies on a "sentry") - Passwords / Biometrics / Secret Keys (computer managed) - Must not be forgeable - Watch out for password attacks (shoulder surfing, key logging, man in the middle, etc)

Internal - Typically recorded in process descriptor - General Idea: maintain authentication somewhere the user can't mess with

External authentication is slower, while internal authentication must be fast. These processes are based on what you know, what you have, and who I (the other party) am. A popular method that utilizes all three is Cryptography.

Cryptography allows the user to obfuscate data in such a way that only a user with the proper keys can unencrypt it. A cryptographic hash function looks something like: h(m) -> V, where m is your message, h is the hash function, and V is the resulting hash value. Cryptography has the interesting property that, given the hash value V, an attacker cannot easily derive the message m. One of the best cryptographic hash functions are the SHA hash functions, designed by the NSA, short for Secure Hash Algorithm. SHA1 produces a 160-bit hash value. The following illustrates the behavior of encryption via Symmetric Encryption (shared secret key)

Given:	Result:
P, K	-> {P}^K -> easy
{P}^K, K	-> P -> easy
{P}^K	-> P -> hard
P	-> {P}^K -> hard
P, {P}^K	-> K -> hard

So far we've been discussing Authentication, but we haven't taken into account Man-In-The-Middle attacks. If an eavesdropper intercepts a packet from A to B, there is a chance that the private key can be recovered. One weakness of SHA1 is that given SHA1(Q), it is relatively easy to calculate SHA1(Q | "random bits"), where | means concatenate.

One solution is Message Authentication Code (MAC). Using the HMAC algorithm (which assumes a shared secret key K), our message looks something like: SHA1( (K^pad1) | SHA1( (K^pad2) | Msg)) . The receiver can recompute the inner SHA1 to get the checksum, but since the attacker doesn't have the private key K, they can only penetrate one layer at most. A typical authentication exchange now looks something like this:

A -> B	{Nonce_A | Hi I'm Alice}^U_B
B -> A	{Nonce_A | Nonce_B}^U_A
A -> B	{Nonce_B | K^s}^U_B

Where Nonce_A is A's Nonce, Nonce_B is B's Nonce, U_A is A's public key, U_B is B's public key, and K^s is the session ID. This multiphase handshake, although secure, is also slow.

One popular method of secure data transfer is the SSH protocol, which stands for Secure Shell. Running an SSH client on your laptop, you may see the following in your home directory: ~/.ssh/id_rsa.pub , id_rsa, and known_hosts. The id_rsa.pub would be your public key, id_rsa is your private key, and known_hosts is a list off servers/public keys, a defense mechanism for catching spoofed sites. The private key is stored encrypted with the user's pass phrase, as an added defense mechanism. On the server side, you'll see something like this: ~/.ssh/authorized_keys , along with the hostname and public keys.

An alternative to SSH is the IPSec protocol. IPSec was made with a different goal in mind; instead of having Security sit on the Application Level, it should be placed on the Network Level. This is done by building a virtual network on top of the physical network. Applications see only unencrypted packets, and don't need to worry about authentication. Whereas SSH is designed for individual use, IPSec is designed for large networks, and is generally used in a large production environment.

Up until now, we've been covering defense mechanisms and how to implement them. Now we take a look at user Policy, that is, which user U has permission P on system object O. The Unix model, has 9 bits for permissions (rwx) for user, group and owner. One flaw here is that permissions cannot be set for individual users without creating a separate group. Access Control Lists (ACLs) are basically lists of permissions for each user linked together. However, long lists with too many writes are hard to manage. An alternative to this is Role Based Access (RBAC). Instead of granting access to users, we grant access to roles, ie DBA, Grader, etc. Each user is given a list of roles he/she can assume, and are given to individual sessions. Roles are also used for specific actions (ie unlink), and allows for more fine-grained control. Following this idea, Capabilities are basically "tickets" handed out for an object + action, and records for a process one thing it can do. These capabilities must be unforgeable, must be consulted before any access , and must have OS+hardware support.

- Trusted Software is expensive: auditing / testing / 3rd party checking / etc.
- How do you know software 'off-the-net' is good?
- Need reliable hamper proof certificate for software

For a client, you usually have a list of trusted programs you will run, backed by a MD5 checksum. To make them one step more secure, we instead use a list of program sources, backed by public keys.

- ACLs are wrong
- Wrong version of software installed
- Insider Attacks, ie deliberate misconfiguratiion
- Backup restore problems
- Password leaks

All of these are human errors, but other errors include OS bugs, bugs in trusted programs (microsoft programs!), or even trojan horses. Ultimately, on some level you must end up trusting someone! (refer to http://www.acm.org/classes/sep95 for Ken Thompson's trick)

- Appropriate levels of abstraction
Modularity, Encapsulation, hiding complexity
- Interface Specification
Contract between users and implementers, crucial for interoperability
Who's in charge??!??!
- Interface is not the same as Implementation
Interfaces with just 1 implementation may have problems, be suspicious (the map is not the territory)
- Policy vs Mechanism
What you want vs low level tools to build that
Keep separate