Presentation is loading. Please wait.

Presentation is loading. Please wait.

NS-H0503-02/11041 System Security. NS-H0503-02/11042 Authentication Verifying the identity of another entity Two interesting cases (for this class): –Computer.

Similar presentations

Presentation on theme: "NS-H0503-02/11041 System Security. NS-H0503-02/11042 Authentication Verifying the identity of another entity Two interesting cases (for this class): –Computer."— Presentation transcript:

1 NS-H0503-02/11041 System Security

2 NS-H0503-02/11042 Authentication 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

3 NS-H0503-02/11043 Password-based protocols 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.)

4 NS-H0503-02/11044 Password selection 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.

5 NS-H0503-02/11045 Better password selection 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!

6 NS-H0503-02/11046 Password storage 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

7 NS-H0503-02/11047 Centralized password storage 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!

8 NS-H0503-02/11048 Basic authentication protocols… 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?

9 NS-H0503-02/11049 Authentication of People What you know (passwords) What you have (keys) What you are (biometric devices) Where you are (physical)

10 NS-H0503-02/110410 Trojan Horses 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

11 NS-H0503-02/110411 Authentication Tokens What you have Smart cards: –Challenge/response Cryptographic calculator: –Interaction through a user (typing...)

12 NS-H0503-02/110412 Biometrics 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.

13 NS-H0503-02/110413 Fingerprints Vulnerability: –Dummy fingers and dead fingers Suitability and stability: –Not for people with high probability of damaged fingerprints –Not for kids growing up

14 NS-H0503-02/110414 Voice Recognition Single phrase: –Can use tape recorder to fake Stability: –Background noise –Colds –Use with public phones

15 NS-H0503-02/110415 Access control 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

16 NS-H0503-02/110416 Access control 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

17 NS-H0503-02/110417 Access control matrix 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)

18 NS-H0503-02/110418 More complex access control 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

19 NS-H0503-02/110419 Attenuation of privilege 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”

20 NS-H0503-02/110420 The problem 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

21 NS-H0503-02/110421 Access control lists (ACLs) 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

22 NS-H0503-02/110422 Example: Unix 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

23 NS-H0503-02/110423 Modifying ACLs Only processes which “own” the object can modify the ACL of the object –Sometimes, there is a special “grant” right (possibly per right)

24 NS-H0503-02/110424 Handling conflicts 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

25 NS-H0503-02/110425 Default permissions? 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”?

26 NS-H0503-02/110426 Revocation 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

27 NS-H0503-02/110427 Revocation 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

28 NS-H0503-02/110428 Potential problems 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

29 NS-H0503-02/110429 Example 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)

30 NS-H0503-02/110430 Cryptographic secret sharing (t, n)-threshold scheme to share a “key” Using this to achieve (t, n)-threshold encryption Shamir secret sharing

31 NS-H0503-02/110431 Another example 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

32 NS-H0503-02/110432 Propagated ACLs 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

33 NS-H0503-02/110433 Example… 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)

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

Download ppt "NS-H0503-02/11041 System Security. NS-H0503-02/11042 Authentication Verifying the identity of another entity Two interesting cases (for this class): –Computer."

Similar presentations

Ads by Google