sistem security

NS-H0503-02/1104 1

System Security

NS-H0503-02/1104 2

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

NS-H0503-02/1104 3

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

NS-H0503-02/1104 4

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.

NS-H0503-02/1104 5

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!

NS-H0503-02/1104 6

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

NS-H0503-02/1104 7

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!

NS-H0503-02/1104 8

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?

NS-H0503-02/1104 9

Authentication of People

• What you know (passwords)• What you have (keys)• What you are (biometric devices)• Where you are (physical)

NS-H0503-02/1104 10

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

NS-H0503-02/1104 11

Authentication Tokens

• What you have• Smart cards:– Challenge/response

• Cryptographic calculator: – Interaction through a user (typing ...)

NS-H0503-02/1104 12

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.

NS-H0503-02/1104 13

Fingerprints

• Vulnerability:– Dummy fingers and dead fingers

• Suitability and stability:– Not for people with high probability of damaged

fingerprints– Not for kids growing up

NS-H0503-02/1104 14

Voice Recognition

• Single phrase:– Can use tape recorder to fake

• Stability:– Background noise– Colds– Use with public phones

NS-H0503-02/1104 15

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

NS-H0503-02/1104 16

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

NS-H0503-02/1104 17

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)

NS-H0503-02/1104 18

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

NS-H0503-02/1104 19

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”

NS-H0503-02/1104 20

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

NS-H0503-02/1104 21

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

NS-H0503-02/1104 22

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

NS-H0503-02/1104 23

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)

NS-H0503-02/1104 24

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

NS-H0503-02/1104 25

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”?

NS-H0503-02/1104 26

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

NS-H0503-02/1104 27

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

NS-H0503-02/1104 28

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

NS-H0503-02/1104 29

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)

NS-H0503-02/1104 30

Cryptographic secret sharing

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

NS-H0503-02/1104 31

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

NS-H0503-02/1104 32

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

NS-H0503-02/1104 33

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)

NS-H0503-02/1104 34

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.