1 / 34

Protection and Security

Protection and Security. Sarah Diesburg Operating Systems CS 3430. Definitions. Security : policy of authorizing accesses Prevents intentional misuses of a system Protection : the actual mechanisms implemented to enforce the specialized policy

igilstrap
Télécharger la présentation

Protection and Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protection and Security Sarah Diesburg Operating Systems CS 3430

  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 • Hashing • Uses a one-way hashing function to transform the data • Difficult to reverse • UNIX stores hashed passwords in /etc/shadow • Uses one-way transformations • Hashes a typed password and compares password hashes

  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 • 8 letters of upper, lower cases, numbers, and special characters • 708 or 576 trillion combinations • Unfortunately, people still pick common words

  10. Partial Solutions • Delay every login by significant amount of time to slow brute-force attacks • Assign very long passwords • 2-factor authentication • Login requires passphrase and code sent to your phone • Requires a physical theft to steal the password • 3-factor authentication is best • What are the 3 factors?

  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 • Kerberos is a network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to each other

  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, Sarah”) • Anyone can create it, but only I can read it (secrecy) • Encrypt(Keymy_private, “I’m Sarah”) • 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 • Example: page tables • Each process has a list of pages that it can access

  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… • E.g. pam (pluggable authentication modules) • In UNIX, enforcers are run as superuser • If there is a bug (or misconfiguration), 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 or encryption • 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. time Pentagon Traffic Analysis • Before the 1991 Persian Gulf War • Foreign intelligence tried to predict the starting date of the war

  34. Pentagon Traffic Analysis • So much for the element of surprise…

More Related