Introduction to Security

UCL Course COMP0133: Distributed Systems and Security LEC-11

---

Perfect Security: An Unattainable Goal

Security is

• A question of how motivated adversary is, and how much money he has

• No individual technique perfect

  e.g., People can be a serious problem in each real-world system

• Could meet a stated goal, but the goal could be inappropriate

Weakest item will determine the system security

---

Definitions

• Security

  techniques to controal who can access/modify systems

• Principal

  unit of accountability in a system (e.g., users)

• Access Control

  technqiues to restrict operations to particular principals

  (e.g., authentication, authorization …)

• Authentication

  verification of identity of principal making request

• Authorization

  granting of request to principal

---

Attacks

• Violation of Confidentiality

  Confidentiality: attackers read data without authorization

• Vilation of Integrity

  Integrity: attackers modify data without authorization

• Vilation of Availability (Denial of service)

  Availability: attackers make system unavaliable to legitimate users

---

General Approach

Figure out what to protect & what it is worth (Asset)

Figure out which attacks you want to defend against (Threat Model)

State goals and desired properties clearly (specifically)

e.g., Attack \( X \) on resource \( Y \) should cost \( Z \)

Structure with two types of components

• Trusted: must operate as designer expected, or breach (minimize this components)

• Untrusted: subverted operation does not lead to breach

Analyze resulting system (self-testing and testing by expected team), monitor success

---

Policy

Security is a Negative Goal

Ensure that nothing happens without authorization (hard to control something not do)

First step: specify who authorized to do what by policy

Definition: Goal that security must achieve

• Human Intent: originates from outside system

Concepts

• Subject: principal

• Object: abstraction to which access requested (e.g., file, memory page, serial port)

  Each object supports different kinds of access (e.g., read or write file, change permissions, …)

Access control

determine that which operation should be allowed

• What principal making request? (Authentication)

• Is operation permitted to principal? (Authorization)

---

Local User Authentication

Goal

Only the owner of the file can access it

UNIX Authentication Policy

• Each file has an owner principal: an integer user ID

• Each file has associated owner permissions (read, write, execute, &c.)

• Each process runs with integer user ID

  only can access file as owner if matches file’s owner user ID

• OS assigns user ID to user’s shell process at login time, authenticated by username and password

  <username, user id, password>

• Shell process creates new child processes with same user ID when typing commands

Bad Approach: Plaintext Password Database

Keep password database in a file

Passwords stored in file in plaintext

Protection

Make file readable only by privileged superuser (root)

/bin/login program prompts for usernames and passwords on console

runs as root, so can read password database

Attacks

• Shut down the computer, pull out the disk, read the disk in some other computer as root

• If attackers can play a role as root, they can attack successfully

Better Approach: Hashed Password Database

Hash Function

\( H \) is a cryptographic hash function \( H(x) = y \) where

• Preimage-Resistant

  Given \( y \) and \( H() \), it is computationally infeasible to recover \( x \)

• Second-Preimage-Resistant

  Given \( y \), it is computationally infeasible to find \( x’ \neq x \) such that \( H(x) = H(x’) = y \)

Idea

Instead of password in plaintext, store the hashed password \( H(password) \)

Make file readable by anyone (since hash functions cannot be inverted)

Dictionary Attack

1. Obtain copy of password file (until recently, world-readable on UNIX)

2. Compute hash results for all possible common word —– only done once and work for all

3. String compare resulting hashed words against passwords in file

Improved Approach: Salted & Hashed Password Database

Generate a random string of bytes \( r \) —– Salt

Store the pair \( (H(password,r), r) \) in password file

Benefits

• Same password produces different result on every machine

• Must see password file before can hash dictionary

• Single hashed dictionary not work for multiple hosts

Application

In Modern UNIX:

• Use salted & hashed password database

• The database is readable only by root

However, dictionary attacks are still possible after seeing password file

---

Remote User Authentication

Requirements

Confidentiality

• defend eavesdropping

• transfering username and plaintext password is not accepted

Integrity

• defend inserting, deleting, modifying, and replaying

• transfering username and hased password is not accepted (attack by recording and replaying)

such that

• message must change unpredictably at each login

• message must be verifiable at server as matching the user-known secret value

Possible Approach (only use Hash Functions)

Steps

1. Store the following information in server password database:

   \( Alice:99:H^{99}(password) \)

   The number is announced by server to client

2. At first login, Alice sends:

   \( {Alice, H^{98}(password)} \)

3. After verifying and logging, server then updates its database to contain:

   \( Alice:98:H^{98}(password) \)

4. At next login, Alice sends:

   \( {Alice, H^{97}(password)} \)

5. and so on ……

Limitations

• Alice must store her secret on the server securely (best if physically at server’s console)

• Alice must choose total number of logins at time of storing secret

• When logins all “used”, must store new secret on server securely again

Common Approach (use Encryption)