CS 111 Lecture 18 Scribe Notes – Spring 2013
by Jiawei Sun and Chenyang Wang

Lecture Topic: Confidentiality, Authorization, and Protocols


Intro: Why Confidentiality is important
On March 1, 2012, Supreme Council of Virtual Space, a body set up by Iranian authorities to oversee the Internet, launched a DoS(denial-of-service) attack on BBC by jamming two satellites feeds.


Defense Techniques
19th century techniques – Kerckhoffs’s Principles

    1. The system must be practically, if not mathematically, indecipherable;
    2. It must not be required to be secret, and it must be able to fall into the hands of the enemy without inconvenience;
    3. Its key must be communicable and retainable without the help of written notes, and changeable or modifiable at the will of the correspondents;
    4. It must be applicable to telegraphic correspondence;
    5. It must be portable, and its usage and function must not require the concourse of several people;
    6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe.

• The second principle suggests that we should minimize what needs to be kept secret for whole system to work. In another word, we should open our designs including algorithms, codes and networks to the public.
• However, this principle is controversial. One of the objections to this principle is that “If you kept everything secret, wouldn’t it be more secure?” (“security via obscurity”)
• DVD encryption is a real-life counter-example to the objection – the whole technology is secret, but it is not secure; the encryption method was officially published by a Norway hacker (possibly an insider job) and decryption becomes fairly easy.

Take Kerkhoffs’s Principle to “login to Unix”

The file “/etc/password” contains the passwords for every user.
For example: “eggert:1010:xyzzy82:/home/eggert” indicates the user “eggert” has user ID 1010, his password is xyzz82 and the home directory is /home/eggert.

For better protection, instead of including the password in the file, a cryptographic checksum is used for replacement: “eggert:1010:3482936:/home/eggert”.
The cryptographic checksum is generated by a very well designed hash function
                     H (password) = checksum
such that knowing the checksum gives you little info about password. In another word, reverse engineering shouldn’t work.

However, the cryptographic checksum method doesn’t prevent PW guessers because according to Kerckhoffs’s Principle, the hash function should be public to everyone. (An expensive hash function may discourage PW guessing.)

To improve the cryptographic checksum method, we add to the hash function a secret “salt” such that
                     H (password concatenates salt) = checksum

In original Unix, the salt is also concatenated after the checksum in the “/etc/password/” file: “eggert:1010:348293643x:/home/eggert”. Here the secret salt is “43x” but it will take the PW guesser every long time to guess the PW since the guesser does not know which part of the string is the checksum and which part of the string is the secret salt.

On seasnet, the cryptographic checksums are not included in the file “/etc/password” (with permission rw-r--r--). The cryptographic checksums are included in “/etc/shadow” and the file’ permission rw------- makes it not visible to any users.


Authentication
The purpose of authentication is to prevent masquerading, one of the most common way to break in system.
Authentication methods

• Authentication via passwords
• - Possible attacks:
      -password guessing (brute force) (think about this as trying 10,000 pin numbers on a ATM)
      -snoop the password (capture the bits through the network, similar to video camera at ATM)
      -server impression (similar to set up a fake ATM)
• Authentication via magnetic or optical card
• Authentication via IP addresses / MAC addresses
• Authentication via finger prints / biometric

External authentication vs. Internal authentication
External authentication: identify the user before granting access to the user.
Internal authentication: give the user badge and grants access to some parts of the system according the badge instead of granting the access to the whole system.

In Linux, the user ID in the process table entry is an example of internal authentication, the kernel constantly checks the user ID to determine whether or not to let that process to use some specific system calls.


Authentication over a network
We must assume the attacker can snoop, alter, delete message, etc. In another word, we must assume that the attacker may have the full control of the network.
Encryption with Key
A: Client.     B: Server.
To for B to identify A, A must send a message to B “I’m A and my password is ‘plugh’.”

Since the message could be seen by the attacker, we should encrypt the message.
If we encrypt the message with key K, we must keep K secret and the encryption should have the following property:
                     {Message}K + Key K -> Message                  <Decryption>
                     Message + Key K -> {Message}K                  <Encryption>

Here we have to assume that we can somehow hand the key K to the client secretly, otherwise the attacker can simply decrypt the message by “stealing” the key K.

However, even though we can somehow hand the key K to the client secretly, we are still vulnerable to replay attacks, in which the attack simply resend the encrypted message {message}K to B and prevent to be A.


Public Key System
Here we introduce an authentication method using two keys – a private key K and a public key U. The encryption using the two keys should have the following property:
                     {Message}U + Key K -> Message                 <Decryption>
                     Message + Key U -> {Message}U                 <Encryption>

In this system, the public key U is available to the public and the users will use it to encrypt their messages to the server B. Then the server B will use the private key K to decrypt the messages, and thus only server B can see the messages.

However, this is still vulnerable to a replay-attack. To make the system resist to replay-attack, two sets of keys are used by user A and server B, in which the messages transferred in both directions are securely encrypted.


HMAC Message Authentication
This authentication method is used to prevent message tampering and it assumes private key K.

A hash function SHA1 is used for encryption: (^ indicates exclusive or operation, -- indicates concatenation, and pad1, pad2 are two secret salts)
                     SHA1((K ^ pad1) -- SHA1 ((K ^ pad2) -- Message))
The SHA1 hash function takes a 512-bit input and produces a 160-bit checksum.

Why do we need to call SHA1 twice? Why not just SHA1(K ^ Message)? The reason for this is that SHA1 is not a very good function that handles concatenation, knowing SHA1(X) is easy to guess SHA1(X -- Y) when Y is a short string.


Two Sample Protocols
SSH (Secure Shell)

• Public keys are stored in “~/.ssh/id_rsa.pub”
• Private keys are stored in “~/.ssh/id_rsa”
• A list of ssh servers you have logged into is stored in “~/.ssh/known_hosts”

IPsec (Internet Protocol Security)
IPsec is a technology protocol suite for securing Internet Protocol (IP) communications by authenticating and/or encrypting each IP packet of a communication session. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session.



Authorization and Access Control
Authorization should be interpreted as a three dimension space, in which users, files and allowed-actions are the three “axis.” Every point in the three-dimension cube should answer a specific authorization question in the form of “is this user allowed to do this to this file?”
We want to represent the cube efficiently and make it understandable to both the user and admins, who are changing the entries in this cube.


Method 1: Access control lists
Attached to each file, is a list of users who are authorized to do what with that file.
There are two problems needed to be solved for ACLs:

• Who can change the ACL? In Unix, only owner can change it.
• Can you give away a file / give ownership to someone else? Unix – yes, because there is no security holes for doing so. BSD – no, because a user can give files to someone else so that the user can have larger quota.

Method 2: Capabilities
Attached to each principal (process), is a list of files that principal is authorized to access.
In Linux, file descriptors is an example of capabilities.

For both of the two methods, they must be unforgettable, consulted before access is allowed, and supported by hardware and OS.


Implementation

• Direct access – map into address space (eg. Process can directly access graphics registers for performance.) The advantage of direct access is that process can run at hardware speed after authorized.
• Indirect access – issue services requests via trusted handlers. The advantage of indirect access is that it is more flexible – it is easy to revoke access.

VMS-style Access-control-list
Used in Linux and characterized by associating other sets of user.

For example, the command “setfact –r –m group:tas:rwx” creates a new group “tas” and authorizes the group with the permissions to read, write and execute the file. Since new groups can be added in this way, ACLs do not have fixed size.

The problem with ACL is that it may give too many rights to a particular user/admin and paranoid groups may not trust someone with too many rights.
Eg. The chair of the department can edit Emacs source code, change CS111 grades or change homework.

One solution is to use Role-Based Access Control RBAC, in which a 4-dimention authorization structure is used instead of a cubic structure. In this 4-diemention structure, user, file, allowed-action along with role will be the “axis.” RBAC trades rights for security.