System Security

1. System Security

2. Verifying the identity of another entity Two interesting cases (for this class): Computer authenticating to another computer Person authenticating to a computer Two issues: How authentication information is stored (at both ends) Authentication protocol itself Authentication

3. Any password-based protocol is vulnerable to an off-line dictionary attack if server is compromised Goal: password-based protocol should be secure against off-line attacks when server is not compromised Unfortunately, this has not been the case in practice (e.g., telnet, cell phones, etc.) Password-based protocols

4. User selection of passwords is typically very weak Lower entropy password makes dictionary attacks easier Typical passwords: Derived from account names or usernames Dictionary words, reversed dictionary words, or small modifications of dictionary words Etc. Password selection

5. Non-alphanumeric characters Longer phrases Can try to enforce good password selection… …but these types of passwords are difficult for people to memorize and type! Better password selection

6. In the clear… Hash of password “Salt”-ed hash of password Makes bulk dictionary attacks harder, but no harder to attack a particular password Centralized server stores password Threshold storage of password Password storage

7. Authentication storage node Central server stores password; servers request the password to authenticate user Auth. facilitator node Central server stores password; servers send information from user to be authenticated by the central server Note that central server must be authenticated! Centralized password storage

8. Server stores H(pw); user sends pw Secure against server compromise, but not eavesdropping (or replay attacks) Server stores pw, sends R; user sends H(pw,R) Secure against eavesdropping, but not server compromise (or dictionary attack) Can we achieve security against both? Basic authentication protocols…

9. What you know (passwords) What you have (keys) What you are (biometric devices) Where you are (physical) Authentication of People

10. A faked login prompt to capture passwords Counter measures: Make it hard to have the appearance of login prompt Use interrupts Prevent login by user programs Trojan Horses

11. What you have Smart cards: Challenge/response Cryptographic calculator: Interaction through a user (typing ...) Authentication Tokens

12. Accuracy: False acceptance rate. False rejection rate. Can adversary select imposters? Identical twins, family members, etc. Retinal scanner, fingerprint reader, handprint reader, voiceprint, keystroke timing, signature. Biometrics

13. Vulnerability: Dummy fingers and dead fingers Suitability and stability: Not for people with high probability of damaged fingerprints Not for kids growing up Fingerprints

14. Single phrase: Can use tape recorder to fake Stability: Background noise Colds Use with public phones Voice Recognition

15. State of a system Includes, e.g., current memory contents, all secondary storage, contents of all registers, etc. Secure states States in which the system is allowed to reside Security policy defines the set of secure states Security mechanism ensures that system never leaves secure state Access control

16. Access control matrix Characterizes rights of each active entity (“subject”) with respect to every other entity In any secure state, only transitions to other secure states are allowed Often concerned with transitions that affect the protection state of the system I.e., actions which alter the actions a subject is authorized to take Access control

17. Protected entities: “objects” O Active objects: “subjects” S (i.e., users/processes) Note that subjects are also objects Matrix A contains an entry for every pair (s, o) The entry contains the rights for s on o Examples: read/write/execute/etc. Protection states represented by (S, O, A) Access control matrix

18. In general, “rights” may be functions “Actual” rights depend on the system state Equivalently, may depend on system history May be more convenient to express in non-matrix form E.g., boolean expression evaluation More complex access control

19. Copy right Ability to transfer your rights to someone else Copier may have to surrender the right Own right Ability to grant rights on the object to others Attenuation of privilege “A subject may not give rights it does not possess” Attenuation of privilege

20. Drawbacks of access control matrices… In practice, number of subjects/objects is large Most entries blank/default Matrix is modified every time subjects/objects are created/deleted The problem

21. Instead of storing central matrix, store each column with the object it represents Stored as pairs (s, r) Subjects not in list have no rights Can use wildcards to give default rights Access control lists (ACLs)

22. Unix divides users into three classes: Owner of the file Group owner of the file All other users Note that this leaves little flexibility… Some systems have been extended to allow for more flexibility Abbrev. ACLs overridden by explicit ACLs Example: Unix

23. Only processes which “own” the object can modify the ACL of the object Sometimes, there is a special “grant” right (possibly per right) Modifying ACLs

24. Conflicts may arise if two entries give different permissions to a subject Multiple ways of resolving this; e.g.: Allow access if any entry gives rights Allow access only if no entry denies rights Apply first applicable entry Handling conflicts

25. Two approaches Apply ACL entry, if it exists; otherwise, apply default rule I.e., ACL entries override default permissions Augment the default permissions with those in the appropriate ACL entry Example: what if default allows “read” and ACL entry states “write”? Default permissions?

26. How to handle revocation? Easy to revoke all access with ACLs But…what if two different users granted the same right to the same person? E.g., both A and B give rights to C. Now A wants to revoke C’s rights. But B still wants to allow rights… Can store a history of ACL modifications Revocation

27. How to revoke access to a file? Would potentially require revoking all capabilities associated with that file One solution: indirection Capabilities name an entry in a table, rather than an object itself To revoke access to object, invalidate entry in table Or, change random number associated with object Difficult to revoke access by a single subject Revocation

28. What if one process gives capabilities to another? (Possibly indirectly) Can lead to security violation One solution: assign security classifications to capabilities E.g., when capability created, its classification is the same as the requesting process Capability contains rights depending on the object to which it refers Potential problems

29. Cryptographic key used to encrypt a file A file cannot be “read” unless the subject has the encryption key Can also enforce that requests from n users are required in order to read data (and-access), or that any of n users are able to read data (or-access) Example

30. (t, n)-threshold scheme to share a “key” Using this to achieve (t, n)-threshold encryption Shamir secret sharing Cryptographic secret sharing

31. Type checking E.g., label memory locations as either “data” or “instructions” Do not allow execution of type “data” Can potentially be used to limit buffer overflows Another example

32. Associated with data, not the object holding the data Prevents one user from copying data in a file to a new file, thereby giving access to the data When a subject reads from an object, the subject’s PACL is updated When an object is created, the object takes on the PACL of the creator Propagated ACLs

33. A creates file f, and allows B, D to access it After B reads f, PACLnew(B) = PACLold(B)  PACL(A) If B creates new file f’, this file is assigned PACLnew(B) User U can access f’ only if U is in both PACLold(B) and PACL(A) Example…

34. Access control matrices can express any (reasonable) security policy In practice, such matrices may not be used because of complexity, space requirements, etc. Final points (for now…)