The Future of Computing: Challenges and Opportunities

Download Report

Transcript The Future of Computing: Challenges and Opportunities

Lecture 18 Overview
Protected Objects
•
•
•
•
•
•
CPU
Memory
I/O devices (disks, printers, keyboards,...)
Programs
Data
Networks
CS 450/650 Lecture 18: Protection in Operating System
2
Separation
• Physical separation
– Use different physical resources for different users
• Temporal separation
– Execute users' programs at different times
• Logical separation
– Gives the impression that no other users exist
• Cryptographic separation
– Encrypt data and make it unintelligible to
outsiders
CS 450/650 Lecture 18: Protection in Operating System
3
Sharing
• Sometimes, users want to share resources
– Library routines (e.g., libc)
– Files or database records
• OS should allow flexible sharing, not “all or nothing”
–
–
–
–
Which files or records? Which part of a file/record?
Which other users?
Can other users share objects further?
What uses are permitted?
• Read but not write, view but not print (Feasibility?)
• Aggregate information only
– For how long?
CS 450/650 Lecture 18: Protection in Operating System
4
Protection Techniques
• Fence register
– Exception if memory access below address in fence register
– Protects operating system from user programs
– Single user only
CS 450/650 Lecture 18: Protection in Operating System
5
Protection Techniques
• Base/bounds register pair
– Exception if memory access below/above address in
base/bounds register
– Different values for each user program
– Maintained by operating system during context switch
– Limited flexibility
CS 450/650 Lecture 18: Protection in Operating System
6
Protection Techniques
• Tagged architecture
– Each memory word has one or more extra bits that identify
access rights to word
– Very flexible
– Large overhead
– Difficult to port OS from/to
other hardware architectures
CS 450/650 Lecture 18: Protection in Operating System
7
Segmentation
• use different segments for code, data, stack
– or maybe even more fine-grained
• Virtual addresses consist of two parts:
– <segment name, offset within segment>
• OS keeps mapping from segment name to its
base physical address in Segment Table
• Each segment has its own memory protection
attributes
CS 450/650 Lecture 18: Protection in Operating System
8
Logical and Physical Representation of Segments
CS 450/650 Lecture 18: Protection in Operating System
9
Translation of Segment Address
Segment Table also contains memory protection attributes
CS 450/650 Lecture 18: Protection in Operating System
10
Review of Segmentation
• Advantages:
– Each address reference is checked for protection
by hardware
– Many different classes of data items can be
assigned different levels of protection
– Users can share access to a segment
• with potentially different access rights
– Users cannot access an unpermitted segment
CS 450/650 Lecture 18: Protection in Operating System
11
Review of Segmentation
• Disadvantages:
– External fragmentation
– Dynamic length of segments requires costly outof-bounds check for generated physical addresses
– Segment names are difficult to implement
efficiently
CS 450/650 Lecture 18: Protection in Operating System
12
Paging
• Program is divided into equal-sized chunks
– pages
• Physical memory is divided into equal-sized
chunks
– frames
• Virtual addresses consist of two parts:
– <page #, offset within page>
– # bits for offset = log2(page size),
– no out-of-bounds possible for offset
CS 450/650 Lecture 18: Protection in Operating System
13
Page Address Translation
CS 450/650 Lecture 18: Protection in Operating System
14
Review of Paging
• Advantages:
– Each address reference is checked for protection
by hardware
– Users can share access to a page, with potentially
different access rights
– Users cannot access an unpermitted page
• Disadvantages:
– Internal fragmentation
– Assigning different levels of protection to different
classes of data items not feasible
CS 450/650 Lecture 18: Protection in Operating System
15
Paged Segmentation
CS 450/650 Lecture 18: Protection in Operating System
16
x86 Architecture
• x86 architecture provides both segmentation
and paging
• Memory protection bits indicate no access,
read/write access or read-only access
• Recent x86 processors also include NX (No
eXecute) bit, forbidding execution of
instructions stored in page
– Helps against some buffer overflows
CS 450/650 Lecture 18: Protection in Operating System
17
Lecture 19
Protection in Operating System (cont)
CS 450/650
Fundamentals of
Integrated Computer Security
Slides are modified from Ian Goldberg and Hesham El-Rewini
Access Control
Every object to be protected is within one or more protection domains
O2
O1
Domain 2
O2
CS 450/650 Lecture 19: Access Control
Domain 1
Domain 3
O4
O3
O1
19
Access Rights
<O2, {execute}>
<O1, {read,write}>
Domain 3
Domain 2
<O2, {write}>
CS 450/650 Lecture 19: Access Control
Domain 1
<O4, {print}>
<O1, {execute}>
<O3, {read}>
20
Access Control
• In general, access control has three goals:
– Check every access: Else OS might fail to notice
that access has been revoked
– Enforce least privilege: Grant program access only
to smallest number of objects required to perform
a task
• Access to additional objects might be harmless under
normal circumstances, but disastrous in special cases
– Verify acceptable use: Limit types of activity that
can be performed on an object
• e.g., for integrity reasons
CS 450/650 Lecture 19: Access Control
21
Directory
CS 450/650 Lecture 19: Access Control
22
Directory Issues
• List becomes too large if many shared objects
are accessible to all users
– Deletion must be reflected in all directories
• Revocation of access
– Must search all users to see access
– Large systems can easily have 5,000 to 10,000
active accounts
• Pseudonyms
– Multiple permissions
CS 450/650 Lecture 19: Access Control
23
Access Control Lists (ACLs)
• Each object has a list of subjects and access
rights
CS 450/650 Lecture 19: Access Control
24
Access Control Lists
• Which of the following can we do quickly for
ACLs?
– Determine set of allowed users per object
– Determine set of objects that a user can access
– Revoke a user’s access right to an object or all
objects
CS 450/650 Lecture 19: Access Control
25
Access Control Lists
• ACLs are implemented in NTFS file system,
– user entry can denote entire user group
• e.g., “Students”
• Classic UNIX file system has simple ACLs
– Each file lists its owner, a group and a third entry
representing all other users
• For each class, there is a separate set of rights
– Groups are system-wide defined in /etc/group
• use chmod/chown/chgrp for setting access rights
to your files
CS 450/650 Lecture 19: Access Control
26
Access Control Matrix
• Set of protected objects: O
– e.g., files or database records
• Set of subjects: S
– e.g., humans, processes acting on behalf of
humans or group of humans/processes
• Set of rights: R
– e.g., {read, write, execute, own}
• Access control matrix consists of entries a[s,o]
– where s  S, o  O and a[s,o]  R
CS 450/650 Lecture 19: Access Control
27
Example Access Control Matrix
File 1
File 2
File 3
Alice
orw
rx
o
Bob
r
orx
Carol
CS 450/650 Lecture 19: Access Control
rx
28
Implementing Access Control Matrix
• Access control matrix is hardly ever
implemented as a matrix
– Matrix would likely be sparse
• Instead, ordered triples
(Alice, File1, {o,r,w})
(Alice,
(Alice,
(Bob,
(Bob,
(Carol,
File2,
File3,
File1,
File2,
File2,
CS 450/650 Lecture 19: Access Control
{r,x})
{o})
{r})
{o,r,x})
{r,x})
29
Capabilities
• A capability is an unforgeable token that gives
its owner some access rights to an object
– e.g., Alice: {File 1:orw}, {File 2:rx}, {File 3:o}
• Unforgeability enforced
– by having OS store and maintain tokens
– by cryptographic mechanisms
• digital signatures,
– allows tokens to be handed out to processes/users
– OS will detect tampering when process/user tries to get
access with modified token
CS 450/650 Lecture 19: Access Control
30
Capabilities
• transfer or propagate right
– A subject having this right can pass copies of
capabilities to other subjects
• Domain
– collection of objects to which the process has
access
CS 450/650 Lecture 19: Access Control
31
Combining ACLs and Capabilities
• In some scenarios, it makes sense to use both
ACLs and capabilities
– e.g., for efficiency reasons
• In a UNIX file system, each file has an ACL,
– which is consulted when executing an open() call
• If approved, caller is given a capability listing
type of access allowed in ACL (read or write)
– Capability is stored in memory space of OS
– Upon read()/write() call, OS looks at capability
to determine whether type of access is allowed
CS 450/650 Lecture 19: Access Control
32
Kerberos
• requires two systems which are both part of the key
distribution center (KDC)
– authentication server (AS) and
– ticket-granting server (TGS)
• A user presents an authenticating credential (such as
a password) to the AS
– receives a ticket showing that the user has passed
authentication
• single sign-on: user signs on once
– from that point on all the user's (allowable) actions are
authorized without the user needing to sign on again
CS 450/650 Lecture 19: Access Control
33
Procedure-Oriented Access Control
• A procedure controls access to objects
– the procedure forms a capsule around the object
• permitting only certain specified accesses
– can ensure that accesses to an object be made
through a trusted interface
• implements the principle of information
hiding
– carries a penalty of inefficiency
CS 450/650 Lecture 19: Access Control
34
Role-based Access Control (RBAC)
• In general, objects that a user can access often
do not depend on the identity of the user, but
on the user’s role within the organization
– e.g., salesperson can access customers’ credit card
numbers, marketing person only customer names
• In RBAC, administrator assigns users to roles
and grants access rights to roles
• When a user takes over new role, need to
update only her role assignment
– not all her access rights
CS 450/650 Lecture 19: Access Control
35
Role Based Access Control
Role Hierarchies
ROLES
Permission-Role
Assignment
PERMISSIONS
...
USERS
Usrer-Role
Assignment
Sessions
•
•
•
•
A user can be a member of many roles
Each role can have many users as members
A permission can be assigned to many roles
Each role can have many permissions
– read, write, append, execute
CS 450/650 Lecture 19: Access Control
36
Task Based Access Control
Classical subject-object access control
TBAC view of access control
P

P

S x O x A
S x O x A x U x AS
TBAC extensions
P – Permission
S – Subject
O – Object
A – Actions
U – Usage and Validity Counts
AS – Authorization step
• No Roles Involved
• For each authorization step consumes permission, usage count
is incremented
• Usage Count reaches its limit, the associated permission is
deactivated
CS 450/650 Lecture 19: Access Control
37
Task Role Based Access Control
User-Role
Assignment
USERS
Role-Task
Assignment
ROLES
Task-Permission
Assignment
TASKS
PERMISSIONS
• Permissions are assigned to tasks rather than roles
• In Workflow Authorization Model,
– subjects gain access to the required objects only during
the execution of the task
CS 450/650 Lecture 19: Access Control
38
Access Control Policies
• Specification of how each user is authorized to
use each resource
• In practice, no computer applies a single
policy to manage all of its resources
• Scheduling algorithms for CPU  SJF, RR
• Storage  paging, segmentation
CS 450/650 Lecture 19: Access Control
39
User Authentication
CS 450/650 Lecture 19: Access Control
User Authentication
• Systems often have to identify and authenticate
users
– OS when a user logs in
– Web server before handing out confidential info
• Identification and authentication is easy among
people that know each other
– We identify our friends based on their face or voice
• More difficult for computers to authenticate people
sitting in front of them
• Even more difficult for computers to authenticate
people accessing them remotely
CS 450/650 Lecture 19: User Authentication
41
Authentication Factors
• Something the user knows
– User name and password, PIN, secret question
• Something the user has
– ATM card, badge, cookie, physical key, uniform
• Something the user is
– Biometrics (fingerprint, voice pattern, face,…)
• Have been used by humans forever, but only recently
by computers
• Something about the user’s context
– Location, time
CS 450/650 Lecture 19: User Authentication
42
Authentication Factors
• “Something you have” can become
“something you know”
– If token can be easily duplicated, such as magnetic
strip on ATM card
• That’s why ATM fraud is so wide spread
– Some banks distribute small devices displaying
numbers that change over time
• Current number needs to be input for online banking
• However, knowing number does not imply physical
possession of device
CS 450/650 Lecture 19: User Authentication
43
Combination of Auth. Factors
• Different classes of authentication factors can
be combined for more solid authentication
– Two- or multi-factor authentication
• Using multiple factors from the same class
might not provide better authentication
CS 450/650 Lecture 19: User Authentication
44
Passwords
• Probably oldest authentication mechanism
• User enters user ID and password
• Usability problems
– Entering passwords is inconvenient
– If password is disclosed to unauthorized
individual, the individual can immediately access
protected resource
• Unless we use multi-factor authentication
– If password is shared among many people,
password updates become difficult
CS 450/650 Lecture 19: User Authentication
45
Password Guessing Attacks
• Brute-force: Try all possible passwords using
exhaustive search
• It’s possible to test 350K Microsoft Word
passwords per second on a 3-GHz Pentium
• For passwords of length 8 consisting only of
letters, there are about 2*1011 possibilities
– It takes only 166 hours to test all of them
• Expected wait till success is 83 hours
• Easy to buy more hardware if payoff is worth it
CS 450/650 Lecture 19: User Authentication
46
Password Guessing Attacks
• Can make attack harder by including digits and
special characters in password
• However, exhaustive search assumes that
people choose passwords randomly, which is
often not the case
– Attacker can do much better by exploiting this
observation
CS 450/650 Lecture 19: User Authentication
47
Password Guessing Attacks
• Password Recovery Toolkit (PRTK) assumes
that a password consists of a root and a preor postfix appendage
– “password1”, “abc123”, “123abc”
• Root is taken from dictionaries
– names, English words,…
• Appendage is two-digit combination
– date, single symbol,…
CS 450/650 Lecture 19: User Authentication
48
Password Guessing Attacks
• Attack requires that attacker has encrypted
password file or encrypted document
– Offline attack
• Instead attacker might want to guess your
banking password
– Online attack
• Online guessing attacks are detectable
– Bank shuts down online access to your bank
account after n failed login attempts
• typically n ≤ 5
CS 450/650 Lecture 19: User Authentication
49
Choosing Good Passwords
• Use letters, numbers and special characters
• Choose long passwords
– At least eight characters
•
•
•
•
•
Avoid guessable roots
If supported, use pass phrase
Mix upper and lower case
introduce misspellings and special characters
Avoid common phrases
– e.g., advertisement slogans
CS 450/650 Lecture 19: User Authentication
50
Password Hygiene
• Writing down passwords is more secure than
– storing many passwords on a networked
computer or
– re-using same password across multiple sites
• Unreasonable to expect users to remember
long passwords,
– especially when changed often
– Requires physical security for password sheet,
don’t use sticky notes
CS 450/650 Lecture 19: User Authentication
51
Password Hygiene
• Change passwords regularly
– Especially if shorter than eight characters
– Should users be forced to change their password?
– Leads to password cycling and similar
• “myFavoritePwd” -> “dummy” -> “myFavoritePwd”
• goodPwd.”1” -> goodPwd.”2” -> goodPwd.”3”
CS 450/650 Lecture 19: User Authentication
52
Password Hygiene
• Don’t reveal passwords to others
– In email or over phone
• If your bank really wants your password over the
phone, switch banks
• Don’t enter password that gives access to
sensitive information on a public computer
– Don’t do online banking on them
CS 450/650 Lecture 19: User Authentication
53
Attacks on Password Files
• Systems need to store information about a
password in order to validate given password
• Storing passwords in plaintext is dangerous,
– even when file is read protected from users
– Password file might end up on backup tapes
– Intruder into OS might get access to password file
– System administrator has access to file and might
use passwords to impersonate users at other sites
• Many people re-use passwords across multiple sites
54
Defending against Attacks
• Store only a digital fingerprint of the password
in the password file
– using cryptographic hash
• When logging in, system computes fingerprint
of entered password and compares it with
user’s stored fingerprint
• Still allows guessing attacks when password
file leaks
CS 450/650 Lecture 19: User Authentication
55
Defending against Attacks
• UNIX makes these attacks harder by storing
user-specific salts in the password file
– Salt is derived from time of day and process ID of
/bin/passwd
– Salt is included when computing password
fingerprint
– Two users who happen to have the same
password will have different fingerprints
– Makes guessing attacks harder,
• can’t just build a single table of fingerprints and
passwords and use it for any password file
CS 450/650 Lecture 19: User Authentication
56
Defending against Attacks
• Store an encrypted version of the password in
the password file
• Need to keep encryption key away from
attackers
• As opposed to fingerprints, this approach
allows system to easily re-compute password
if necessary
– e.g., have system email password to predefined
email address when user forgets password
• Has become the norm for many websites
57
Interception Attacks
• Attacker intercepts password while it is being
transmitted to website
• One-time passwords make intercepted password
useless for later logins
– In a challenge-response protocol, the server sends a
random challenge to the client
– Client uses challenge and password as an input to a
function and computes a one-time password
– Client sends one-time password to server
– Server checks whether client’s response is valid
– Given intercepted challenge and response, attacker might
be able to brute-force password
CS 450/650 Lecture 19: User Authentication
58
Interception Attacks
• Proposed solutions are difficult to deploy
– Changes to HTTP protocol required
• i.e., every browser and many servers would have to be
changed
– Challenge-response functions need to be
irreversible, but also computable by humans for
easy deployment
• which makes them rare
CS 450/650 Lecture 19: User Authentication
59
Graphical Passwords
• Graphical passwords are an alternative to textbased passwords
• Multiple techniques, e.g.,
– User chooses a picture
• user has to re-identify this picture in a set of pictures
– User chooses set of places in a picture
• user has to click on each place
• Issues similar to text-based passwords arise
– e.g., choice of places is not necessarily random
• Shoulder surfing becomes a problem
CS 450/650 Lecture 19: User Authentication
60
Graphical Passwords
CS 450/650 Lecture 19: User Authentication
61
Server authentication
• With the help of a password, system
authenticates user (client)
• But user should also authenticate system
(server) so that password does not end up
with attacker instead!
CS 450/650 Lecture 19: User Authentication
62
Server authentication
• Classic attack:
– have a program display a fake login screen
– when user “logs in”, programs prints error
message, sends captured user ID and password to
attacker and ends current session
• which will start actual login screen
– That’s why Windows requires you to press <CTRLALT-DELETE> for login
• Always gives login window and cannot be overridden
• Today’s attack: Phishing
CS 450/650 Lecture 19: User Authentication
63
Biometrics
• Authenticate based on physical characteristics
– Fingerprints, iris scan, voice, handwriting, typing
pattern,…
• Biometrics have been hailed as a way to get
rid of the problems with password and tokenbased authentication
• Unfortunately, they have their own problems
CS 450/650 Lecture 19: User Authentication
64
Biometrics
• If observed trait is sufficiently close to
previously stored trait, accept user
– Observed fingerprint will never be completely
identical to a previously stored fingerprint of the
same user
• Biometrics work well for local authentication,
– but are less suited for remote authentication or
for identification
CS 450/650 Lecture 19: User Authentication
65
Local vs. Remote Authentication
• In local authentication, a guard can ensure
that:
– I put my own finger on a fingerprint scanner,
• not one made out of gelatin
– I stand in front of a camera
• don’t just hold up a picture of somebody else
• In remote authentication, this is much more
difficult
CS 450/650 Lecture 19: User Authentication
66
Authentication vs. Identification
• Authentication: Does a captured trait
correspond to a particular stored trait?
• Identification: Does a captured trait
correspond to any of the stored traits?
– a search problem, which is made worse by the fact
that in biometrics matches are based on closeness
– False positives can make biometrics-based
identification useless
• False positive: Alice is accepted as Bob
• False negative: Alice is incorrectly rejected as Alice
CS 450/650 Lecture 19: User Authentication
67
Biometrics-based Identification
• Example (from Bruce Schneier’s “Beyond Fear”)
– Face-recognition software with (unrealistic)
accuracy of 99.9% is used in a football stadium to
detect terrorists
• 1-in-1,000 chance that a terrorist is not detected
• 1-in-1,000 chance that innocent person is flagged as
terrorist
– If one in 10 million stadium attendees is a known
terrorist,
• there will be 10,000 false alarms for every real terrorist
CS 450/650 Lecture 19: User Authentication
68
Other Problems with Biometrics
• Privacy concerns
– Why should my employer (or a website) have
information about my fingerprints, iris,..?
• Aside: Why should a website know my date of birth, my
mother’s maiden name,… for “secret questions”?
– What if this information leaks?
• Getting a new password is easy, but much more difficult
for biometrics
• Accuracy: False negatives are annoying
– What if there is no other way to authenticate?
– What if I grow a beard, hurt my finger,…?
CS 450/650 Lecture 19: User Authentication
69