Lecture 19 - Security Part 2
December 4, 2008

Shared secret key (Symmetric encryption)
vs.
Public key (asymmetric encryption)  

In Asymmetric Encryption, the Public Key (U) and the Private Key (K) always come in pairs.  

• Slower
• Doesn't solve the key distribution problem, just changes it to make it easier

• HMAC(M) = SHA1((K^pad1)^ПSHA1((K^pad2)^ПM) )
• Why so paranoid?
• given SHA1(Q)
• easier to calculate SHA1(Q П (small suffix))

• {M^ПHMAC(M,K)}^K

• First three steps: public key handshake (slow)
• After we get the key, the key is used for data transfer (fast)

^ = exclusive OR

^{П = concatenation}

M = message  

Acutal Implementations of Security 

• SSH protocol/implementation
• from user's viewpoint
• client
• ~/.ssh/id_rsa.pub
• public key
• ~/.ssh/id_rsa
• private key
• stored encrypted with "K", the pass phrase
• ~/.ssh/known_hosts
• all previously connected server's public keys
• used to catch when server's key changes
• first time must be trusted
• server
• ~/.ssh/authorized_keys
• hostname + pubkeys
• IPSec
• Make network level secure, leave application level alone
• Pass a shared key across computers to be used in a virtual network
• Apps see only unencrpyted packets atop a virtual network
• Outside nodes only see encrypted data

• privacy
• integrity
• trust
• Access Control Lists (ACLs)
• which user U has permission P on object O?
• Unix model
• each object O, 9 bits (u, g, o)
• small and compact
• ACLs
• Linked list of permissions
• [me | rwx | *guy   ]       [guy | rwx | *guy2]
• $ getfacl
     user:: rwx
     group:: r-x
     other::r-x
• $setfacl -r -m user:ianku:rwx
• long lists, problem with too many rights
• hard to manage
• Role based Access Control (RBAC)
• ACL's contain roles not users: dba, grader, etc
• for each user:
• a list of roles that that user can assume
• roles are given to sessions
• also used for actions
• Capabilities
• ticket for an object + action
• records for a process, one thing to do
• must be unforgeable
• must be consulted before any access is done
• OS support + hw support
• Approaches:
• via "pointer" to a table in OS
• can't easily send it across network
• via hash that means you know you have access
• magic cookie, say 128 bits
• copy this to whoever you want (over network OK)

• Which software to trust?
• trusted software is expensive: auditing/testing/3rd party checking/etc
• how do you know software "off-the-net" is good?
• need reliable tamper-proof certificate for software
• client: list of programs you will run + md5 checksum?
• problem: list of programs constantly change (updtes)
• client list of programs program sources you will run + md5 checksum public keys
• What can go wrong?
• screwups in setup
• ACLs that are wrong
• wrong version of software installed
• deliberate misconfiguration
• backup/restore problems
• passwords given to bad guys
• bugs in OS
• bug in trusted program
• trojan horses

• Ken Thompson's trick
• change login.c
• if (strcmp(u,"ken") == 0)
     return 0; //0 is root access

• change gcc.c
• if (compiling"login.c")
     insert above code
• if (compiling"gcc.c")
     insert above code