Lecture 18

Tuesday, December 01, 2009

By: Alexander Bonomo

Security:

Computer security techniques are designed to make the computer less useful.

--> making computers more secure comes at a cost

Start by Knowing Your Enemy,

Threat modeling + classification <== to come up with defense mechanisms

Example: Securing CourseWeb or maybe University Credit Union

Biggest Threats:

• attackers:
  • students (ordinary users) want to see each other's work to plagiarize
  • outsiders want to gain personal information about students
    • may want to get copies of assignments
• Mode of attack:
  • guessing passwords of legitimate users
  • exploit an Apache bug (or other infrastructure)
    • e.g. SQL injection
  • Denial of Service
  • Social Engineering (trick someone into giving you their password)
  • Take over a router to intercept packets (sniff packets) (steal a session)
  • Break into the machine room and steal a disk (or a backup disk)
  • video camera snooping
  • keylogger on terminal
  • ***insider attack***

General O.S. functions:

·Authentication - proving you are who you say you are

·Integrity - don’t let attackers muck with data or metadata (esp. security metadata)

·Authorization - are you allowed to do X? where X is whatever action you're trying to do

·Auditing - keep logs, so that you can figure out what bad guys did ---> need this for insider attacks

• undo bad guys' actions

Constraints:

·efficiency (esp. to avoid DoS problems)

• if we add too much security, system will become slow

·Correctness

• we need this system to work as advertised
• if a bug exists, there is a good chance someone will find it and try to exploit it
  • opponents are also motivated to find these bugs

Authentication:

3 ways:

1. based on who the principal (user in charge of the session) is (e.g. retinal scan)

2. based on what the principal knows (e.g. passwords)

3. based on what the principal has (e.g. physical keys)

·often, these forms of authentication are combined

·you can use one to bootstrap another (e.g. go present your student id for a seasnet account, then you get a password

·authentication prevents masquerading attack

Techniques:

·external

• e.g. by login program

• usually done w/ passwords
  • can be snooped and/or guessed
• can also be done with tokens/keys

·internal

• assume user has already gone through external authentication
• the O.S. must keep track of the user's identity
• cannot let a user muck with their own user id
  • integrity must be respected
• user id is consulted for authorization decisions
• logged during audits

Authentication building blocks:

·cryptographic hash functions

• h(message) = 160bitHashValue
• given the hash value, it is very difficult to guess the message

· symmetric encryption

• given a message M and key K, it is easy to get the encrypted message, {M}^K
• given encrypted message {M}^K and key K it is easy to get the message, M
• however given only the encrypted message, it is difficult to get key and/or message

· asymmetric encryption

• M = message
• U = public key
• K = private key
• U, K come in pairs
• M, U ---> {M}^U is easy
• {M}^U and also given K ----> M is easy
• U ---> K is hard
• {M}^U ----> M is hard
• this method tends to be more expensive

A typical conversation:

A wants to talk to B

• A → B
  • {Hello, I'm A. {Nonce}^K_A }^U_B
• B → A
  • {Hi, I got your message: {Nonce}^K_A {Nonce}^K_B}^U_A
• A → B
  • {Yep, it's me. {Nonce}^K_B {session key} }^U_B

Nonce is a random bit string that is different every time.

Here they are used to verify that A and B are really who the say they are and that they recieved each other's messages.

The session key is also a nonce used for symmetric encryption.

SSH does this!

• Client
  • .ssh/id_rsa.pub
    • public key you can publish
  • /id_rsa
    • private key
  • /known_hosts
    • server's name, IP address, public key ← used to foil masquerading servers
• Server
  • .ssh/authorized_keys
    • list of public keys

SSH transport layer

· initial key exchange: session key.

• These keys are renewed every so often.

·enclosing each packet with a cryptographic checksum to preserve integrity

• M ---> M^HMAC(M, K) <---- cryptographic checksum for M
• M, HMAC(M, K) ---> K is hard

·for privacy:

• M ---> M^K

·both privacy and integrity checks are typical

Authorization:

we know who the users are, but now we need to keep track of what they're allowed to do

Access Control:

• for each principal p:
  • for each resource r
    • for each access method m: //read, write, delete, etc.
      • you have a bit Okp, r, m

In practice, this model is too hard to administer.

It is possible to shorten the authorization metadata by making it easier to understand and maintain, but the cost for this is that the underlying model is more complicated.