Protection and Security

The distinction between security and protection, at least in this note

	Security: broad sense to refer all concerns about controlled access to facilities
	Protection: mechanism to support security

Policy and mechanism issues: Security policy should be established first and mechanism to enforce the policy

Categories of threats

	Unauthorized disclosure
	Unauthorized updates
	Denial of service: generally dealt by other parts of OS rather than security and protection. Three types: Deleting a good guy's file by a bad guy: overlaps with the unauthorized updates Physical attack by hand grenade Unauthorized consumption of resources

Unauthorized disclosure and updates are the threats we are concerned here

Threats are generally introduced by breaking-in by such as Trojan horse

Public Design rather than secret design. Reason:

	Secret design is all-or-nothing approach. Very difficult to keep it secret
	Not to hard to figure out the algorithm: decompile, ...
	Good guys will let you know the security holes

Default = No access

Minimum privilige: give just enough power to get the job done

Timely check

	Too long a timeout to change a password -> more chance to be stolen
	Too short -> lead users to use bad password and devise ways not to use password

Simple, uniform mechanism

	Simple design to reduce the chance of errors which bad guys use to break
	Clear, easy to understand, and uniform interface to reduce the chance of wrong use

Appropriate level of security

Excessive security mechanism leads: to unnecessary cost and performance degredation more importantly, users not to use it due to the complex of the system

Attacks on password and protections

	Direct attack on the password: try every possible password Random password: difficult to remember Run password checker to reject password which can be guessed easily: lead battle between cracker and checker Artificially slow down the password check
	Eavesdropping Looking over the shoulder: turn off echoing while accepting password Reading password file: store hash_ftn (password) Wire tapping: encryption
	Spoofing: authentication - generally challenge-response Client sends req. for authentication Server sends a challenge with a random value x Client responses with g (password, x) Server decripts g (password, x) and compares with the stored password -> Client authenticated

The protection state of a machine is conceptually defined by an access matrix

	Row: principal
	Column: object
	Cell: access rights, for example {read, write}, for the principal to the objects

Because the matrix tends to be very sparse, access information is represented by access control lists or capability lists

A list of rights associated with an object

Ex: AFS

	ACL for each directory. All files in a directory share the same ACL
	ACL for a directory: group-of-principals list of access rights
	Access rights: r: read l: list the directory and read the attributes of files i: create files d: delete files w: write files k: lock files a: administer ACL attributes
	"pts membership group-name" shows the list of principals in the group

Ex: Unix

	User is assigned with a uid, primary gid, and auxilary gids
	When a file is created, it: gets uid of the creator(= process) and gid of the containing directory access mode = logical AND of argument of create (or open) system call and one's complement of umask
	Access check algorithm check if root -> everything is OK check if owner -> owner field of the file compared check if group -> group field of the file compared otherwise -> other field of the file compared => owner could have less privilege than others, but owner has the right to chmod
	Permission of directory Read: ? Execute: permission to read attributes of files in the directory Write: permission to create or delete files in the directory -> can effectively modify a file that you don't have write permission by: delete the file and then create a new file with the same name!
	setuid: the euid of the process executing the file is set to the uid of the file

Capability is a "protected pointer" to an object: pointer + access permission

Each process has capabilities to work on as a Unix process has file descriptors of open files

Process passes capability to system call instead of passing fd

Ensuring the integrity of capability is important. Mechanisms:

	Tagged architecture: tag each word as a capability or a data word
	Separate capability segment
	Encryption: append each capability with checksum and encrypt capability and checksum using a secret key

Capability in Unix?

	fd is a sort of capability: access permission is somehow incorporated in
	Separate segment capability mechanism is used: process can't modify fd table which is stored in kernel space

HYDRA - a capability based protection

Encryption & decryption algorithm are known to public: remember design principles

Only keys make things secret

Key should not be too long -> inefficient

Goal: minimize out-of-band transmission while keeping the key secret as much as possible

Procedure

	Out-of-band transmission: each party has its own private key KDC (Key Distribution Center) has the private of every entity
	A -> KDC: (B, x)
	KDC -> A: [B, x, Kc, [A, Kc]Kb] Ka B - to ensure that the request has not been modified by a bad guy x - to authenticate KDC
	A -> B: [A, Kc]Kb
	B -> A: [y]Kc
	A -> B: [y + 1]Kc y & y+1: to prevent a bad guy from copying the messsage from A to B and sending later

Kerberos - private key (DES) based authentication

General

	Asymmetric public and private keys
	Encryption and decryption algorithms are usually identical. So f ( f ( msg, private_key ), public_key ) = f ( f ( msg, public_key ), private_key ) = msg
	RSA is the most common en(de)cryption algorithm

Digital signature using PK

	Sender sends: Msg + [ hash(Msg) ]private-key of sender hash(Msg) can be a checksum of Msg
	Receiver: computes hash(Msg) decrypt [ hash(Msg) ]private-key of sender using sender's public key compare the computed hash(Msg) with the decrypted hash value, if both agree, receiver assures that Msg really came from the sender

Public key distribution

	Problem: how can I trust that this public key really came from Alice?
	Solution: Certificate of CA (Certificate Authority) [ Alice, public-key of Alice ]secrete-key of CA

Netscape

	Public keys of CAs, for example VeriSign, are hardcoded
	Secure web-site -> browser: [web-site, public-key of web-site]secrete-key of CA
	browser -> web-site: [ brand new private-key ]public-key of web-site
	web-site <-> brower: [ Msg ]private-key

Encryption and Secure Computer Network - about encryption and key distribution