Protection and Security
Definitions

Security: policy of authorizing
accesses


Prevents intentional misuses of a system
Protection: the actual mechanisms
implemented to enforce the
specialized policy

Prevents either accidental or intentional
misuses
Security Goals



Data confidentiality: secret data
remains secret
Data integrity: unauthorized users
should not be able to modify data
System availability: nobody can
make a system unusable
Security Components



Authentication determines who the
user is
Authorization determines who is
allowed to do what
Enforcement makes it so people can
do only what they are allowed to do
Authentication

The most common approach:
passwords


If I know the secret, the machine can
assume that I’m the user
Problems:
1. Password storage
2. Poor passwords
Password Storage

Encryption



Uses a key to transform the data
Difficult to reverse without the key
UNIX stores encrypted passwords in
/etc/passwd


Uses one-way transformations
Encrypts a typed password and
compares encrypted passwords
Poor Passwords

Short passwords


Easy to crack
Long passwords

Tend to be written down somewhere
Original UNIX


Required only lower-case, 5-lettered
passwords
265 or 1 million combinations


In 1975, it would take one day to crack
one password
Today, we can go through all those
combinations < 1 second
Partial Solutions


Extend password with a unique
number
Require more complex passwords



6 letters of upper, lower cases,
numbers, and special characters
706 or 100 billion combinations
Unfortunately, people still pick common
words
Partial Solutions


Delay every login by 1 second
Assign very long passwords


Give everyone a calculator (ATM card)
Requires a physical theft to steal the
password
Authentication in Distributed
Systems

Private key encryption of data





Encrypt(Key, Plaintext) = Cipher text
Decrypt(Key, Cipher text) = Plaintext
Hard to reverse without the key
With the plaintext and the cipher text,
one cannot derive the key
Provides secrecy and authentication,
as long as the key stays secret
How to distribute the keys?

Authentication server

Keeps a list of keys
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Encrypt(KeyAS, “I want KeyAB”)
Client A
Client B
KeyAS
KeyBS
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Encrypt(KeyAS,“Here is KeyAB and
a message to B”)
Client A
Client B
KeyAS
KeyBS
Kerberos Protocol
Keyxy is needed to talk between x and y
Server S
Client A
Client B
KeyAS
KeyBS
message
Encrypt(KeyBS, “use KeyAB to talk to A”)
Additional Details

Expiration timestamp for a key


Checksum for an encrypted message


Prevents a machine from replaying
messages (e.g., “deposit $100”)
Prevents modifications to a message
(e.g., “deposit $1000”)
KeyAS and KeyBS are renewed
periodically to reduce their exposures
Public Key Encryption


Separates authentication from secrecy
Involves a public key and private key




Encrypt(Keypublic, plaintext) = cipher text
Decrypt(Keyprivate, cipher text) = plaintext
Encrypt(Keyprivate, plaintext) = cipher text
Decrypt(Keypublic, cipher text) = plaintext
Public Key Encryption

Idea:


Private key is kept secret
Public key is advertised
Public Key Encryption

Encrypt(Keymy_public, “Hi, Andy”)


Anyone can create it, but only I can read
it (secrecy)
Encrypt(Keymy_private, “I’m Andy”)

Everyone can read it, but only I can
create it (authentication)
Public Key Encryption

Encrypt(Keyyour_public,
Encrypt(Keymy_private,
“I know your secret”))

Only I can create it, and only you can
read it
Authorization

Access matrix describes who can do
what
Bart
Lisa
File 1
Lisa’s diary File3
read,write
read
read, write
Maggie
-The matrix tends to be sparse
Access Control List


Stores all permissions for all users with
each object
Analogy: a guard in front of a door


Checks for a list of people allowed to
enter
UNIX: permission of each file is
specified according to its owner,
group, and the world
Capability List


Stores all objects a process can touch
Analogy: Keys

A key owner has the right of entry
Access Control List vs.
Capability List

Access control list (commonly used)



Easy to know who can access the object
Hard to know which objects a user can
access
Capability list


A user knows the list of objects to access
Hard to know who can access an object

More difficult to revoke capabilities
Enforcement



Enforcer programs check passwords,
access control lists, and so on…
In UNIX, enforcers are run as
superuser
If there is a bug, you are hosed!
The State of the World in
Security

Authentication



Authorization



Poor passwords
Nobody encrypts emails
Coarse-grained access control list
Often turned off for sharing
Enforcement

Buggy operating systems
Classes of Security Problems

Eavesdropping is the listener
approach



Tap into the Ethernet and see everything
Countermeasure: pressurized cabled
Abuse of privilege

If the superuser is evil, there is nothing
you can do
Classes of Security Problems

Imposter breaks into the system by
pretending to be someone else


Recorded voice and facial image
Countermeasure: behavioral
monitoring to look for suspicious
activities

Overwriting the boot block
Classes of Security Problems

A Trojan horse is a seemingly
innocent program that performs an
unexpected function

Countermeasure: integrity checking

Periodically, check binaries against their
checksums
Classes of Security Problems

Salami attack builds up an attack,
one-bit at a time


Example: send partial pennies to a bank
account
Countermeasure: code reviews
Classes of Security Problems

Logic bombs: a programmer may
secretly insert a piece of code into the
production system



A programmer feeds the system
password periodically
If the programmer is fired, the logic bomb
goes off
Countermeasure: code reviews
Classes of Security Problems

Denial-of-service attacks aim to
reduce system availability


A handful of machines can flood a victim
machine to disrupt its normal use
Countermeasure: open
Tenex


Used to be the most popular system at
universities before UNIX
Thought to be very secure
Tenex

Source code for the password check:
for (j = 0; j < 8; j++) {
if (input[j] != pw[j]) {
// go to error;
}
}

Need to go through 2568 combinations
Tenex

Unfortunately, Tenex used virtual
memory
password
in memory


on disk
A fast password check means that the
first character is wrong (error)
A slow check means that the first
character is correct (page fault)
Tenex

2568 checks to crack a password is
reduced down to 256 * 8 checks
The Internet Worm


In 1988, a Cornell graduate student,
RTM, released a worm into the
Internet (Robert Tappan Morris).
The worm used three attacks



rsh
fingerd
sendmail
The Internet Worm

Some machines trust other machines,
the use of rsh was sufficient to get
into a remote machine without
authentication
The Internet Worm

finger command did not check the
input buffer size

finger name@location

Overflow the buffer
Overwrite the return address of a
procedure
Jump and execute a shell (under root
privilege)


The Internet Worm

sendmail allowed the worm to mail a
copy of the code and get it executed

The worm was caught due to multiple
infections

People noticed the high CPU load