System Security
NS-H0503-02/1104
1
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
2
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
3
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
4
Better password selection
•
•
•
•
NS-H0503-02/1104
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!
5
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
6
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
7
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
8
Authentication of People
•
•
•
•
NS-H0503-02/1104
What you know (passwords)
What you have (keys)
What you are (biometric devices)
Where you are (physical)
9
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
10
Authentication Tokens
• What you have
• Smart cards:
– Challenge/response
• Cryptographic calculator:
– Interaction through a user (typing ...)
NS-H0503-02/1104
11
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
12
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
13
Voice Recognition
• Single phrase:
– Can use tape recorder to fake
• Stability:
– Background noise
– Colds
– Use with public phones
NS-H0503-02/1104
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
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 (oraccess)
NS-H0503-02/1104
29
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
30
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
31
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
32
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
33
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.
NS-H0503-02/1104
34