Enhancing System Security: Authentication, Encryption, and Access Control

1. Protection and Security

2. 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

3. 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

4. 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

5. 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

6. 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

7. Poor Passwords • Short passwords • Easy to crack • Long passwords • Tend to be written down somewhere

8. 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

9. 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

10. 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

11. 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

12. How to distribute the keys? • Authentication server • Keeps a list of keys

13. Encrypt(KeyAS, “I want KeyAB”) Kerberos Protocol Keyxy is needed to talk between x and y Server S Client B Client A KeyBS KeyAS

14. Encrypt(KeyAS,“Here is KeyAB and a message to B”) Kerberos Protocol Keyxy is needed to talk between x and y Server S Client B Client A KeyBS KeyAS

15. message Encrypt(KeyBS, “use KeyAB to talk to A”) Kerberos Protocol Keyxy is needed to talk between x and y Server S Client B Client A KeyBS KeyAS

16. Additional Details • Expiration timestamp for a key • Prevents a machine from replaying messages (e.g., “deposit $100”) • Checksum for an encrypted message • Prevents modifications to a message (e.g., “deposit $1000”) • KeyAS and KeyBS are renewed periodically to reduce their exposures

17. 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

18. Public Key Encryption • Idea: • Private key is kept secret • Public key is advertised

19. 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)

20. Public Key Encryption • Encrypt(Keyyour_public, Encrypt(Keymy_private, “I know your secret”)) • Only I can create it, and only you can read it

21. Authorization • Access matrix describes who can do what -The matrix tends to be sparse

22. 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

23. Capability List • Stores all objects a process can touch • Analogy: Keys • A key owner has the right of entry

24. 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

25. 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!

26. The State of the World in Security • Authentication • Poor passwords • Nobody encrypts emails • Authorization • Coarse-grained access control list • Often turned off for sharing • Enforcement • Buggy operating systems

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. Tenex • Used to be the most popular system at universities before UNIX • Thought to be very secure

34. 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

35. Tenex • Unfortunately, Tenex used virtual memory • A fast password check means that the first character is wrong (error) • A slow check means that the first character is correct (page fault) password in memory on disk

36. Tenex • 2568 checks to crack a password is reduced down to 256 * 8 checks

37. 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

38. The Internet Worm • Some machines trust other machines, the use of rsh was sufficient to get into a remote machine without authentication

39. 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)

40. 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