cs526: information security chris clifton october 16, 2003 authentication

34
CS526: Information Security Chris Clifton October 16, 2003 Authentication

Upload: elfrieda-hodges

Post on 26-Dec-2015

223 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CS526: Information Security Chris Clifton October 16, 2003 Authentication

CS526: Information SecurityChris Clifton

October 16, 2003

Authentication

Page 2: CS526: Information Security Chris Clifton October 16, 2003 Authentication

3

What we have so far:Access control

• Given subjects S, objects O– What subject is allowed– what type of access– to what object

• Enough for a realistic system?– How do we know a request really is from s?– And the object accessed really is o?

• Next Topic: Authentication and Identity

Page 3: CS526: Information Security Chris Clifton October 16, 2003 Authentication

4

What is Authentication?

• Authentication: Binding of identity to subject• How do we do it?

– Entity knows something• Passwords, id numbers

– Entity has something• Badge, smart card

– Entity is something• Biometrics

– Entity is someplace• Source IP, restricted area terminal

Page 4: CS526: Information Security Chris Clifton October 16, 2003 Authentication

CS526: Information SecurityChris Clifton

October 28, 2003

Authentication

Page 5: CS526: Information Security Chris Clifton October 16, 2003 Authentication

6

Authentication System:Formal Definition

• A: set of authentication information– used by entities

• C: set of complementary information– used by system to validate authentication information

• F: Set of complementation functions– f : A → C– Generate appropriate c C given a A

• L: set of authentication functions– l: A C → { true, false }– verify identity

• S: set of selection functions– s : ? → A– Generate/alter A and C

Page 6: CS526: Information Security Chris Clifton October 16, 2003 Authentication

7

Authentication System

• (A, C, F, L, S, (f, l)) such that f F, l L,

(f, l) in the system such that a A, c f(a) C:

– l(a, f(a)) → true– l(a, c) → false

• with high probability

• (Bad) example: plaintext passwords– A = C = alphabet*– f returns argument– l is string equivalence

Page 7: CS526: Information Security Chris Clifton October 16, 2003 Authentication

8

Background: Cryptography

• Encryption system Ek(s)– over all choices of k, should form uniform distribution– Thus “appears” independent of s

• Decryption: Dk(Ek(s)) = s

• Strength: Given Ek(s), finding k or s difficult

– Better: given s, E, Ek(s), learning k hard

– choosing k, computing Dk, Ek must be easy

• Public key: p, r such that Dr(Ep(s)) = s– Similar notions of strength

Page 8: CS526: Information Security Chris Clifton October 16, 2003 Authentication

9

Authentication Systems: Passwords

• Information known to subject

• Complementation Function– Identity – requires that c be protected– One-way hash – function such that

• f(a) easy to compute• f-1(c) difficult to compute

– Better ideas?

Page 9: CS526: Information Security Chris Clifton October 16, 2003 Authentication

10

Attacks on Passwords

• Dictionary attack: Trial and error guessing– Type 1: attacker knows A, f, c– Type 2: attacker knows A, l– Difficulty based on |A|, time g to compute f or l

• Probability P of breaking in time T: P ≥ Tg/|A|• Problem: often smaller in practice than in theory

• Password Selection– Random– Pronounceable nonsense– User selection

• Controls on allowable– Password checking, aging

Page 10: CS526: Information Security Chris Clifton October 16, 2003 Authentication

12

Authentication Systems: Challenge-Response

• Pass algorithm– authenticator sends message m– subject responds with a(m)

• a is an encryption function• In practice: key known only to subject

• What is the advantage over passwords?– Avoids “replay” attacks

• One-time password– a changes after use– Why is this challenge-response?

Page 11: CS526: Information Security Chris Clifton October 16, 2003 Authentication

13

Attacks onChallenge-Response

• Type 1 attack– Attacker knows (space of) encryption function– Captures challenge and response– Learns encryption function / key– Can now properly respond to new challenge

• Solution: encrypt challenge– Use shared key to share session key– Session key encrypts challenge– Challenge thus indistinguishable from random data

Page 12: CS526: Information Security Chris Clifton October 16, 2003 Authentication

14

Authentication Systems: Biometrics

• Used for human subject identification

• Based on physical characteristics that are tough to copy– fingerprint– voice patterns– iris/retina patterns– face recognition– keystroke interval/timing/pressure

Page 13: CS526: Information Security Chris Clifton October 16, 2003 Authentication

15

Attacks on Biometrics

• Fake biometrics– fingerprint “mask”– copy keystroke pattern

• Fake the interaction between device and system– Replay attack

• Authenticate the authenticator!

– Requires careful design of entire authentication system

Page 14: CS526: Information Security Chris Clifton October 16, 2003 Authentication

16

Authentication Systems: Location

• Based on knowing physical location of subject• Example: Secured area

– Assumes separate authentication for subject to enter area– In practice: early implementation of challenge/response and

biometrics

• What about generalizing this?– Assume subject allowed access from limited geographic area

• I can work from (near) home

– Issue GPS Smart-Card– Authentication tests if smart-card generated signature within

spatio/temporal constraints– Key: authorized locations known/approved in advance

• If I know I’ll be traveling, login from my office disabled!

Page 15: CS526: Information Security Chris Clifton October 16, 2003 Authentication

17

Authentication vs. Identity

• Authentication: Binding of identity to subject– We know how– We’ve discussed subjects– But what precisely is identity?

• Principal: Unique Entity– Subject– Object

• Identity: Specifies a principal

Page 16: CS526: Information Security Chris Clifton October 16, 2003 Authentication

18

Identity = Principal?

• Identity to Principal may be many-to-one– Given identity, know principal– Other direction unimportant?

• Examples: Unix– User identity– File identity

Identity Principal

Page 17: CS526: Information Security Chris Clifton October 16, 2003 Authentication

19

What is a Principal?

• Entity– Subject– Object

• Also a set of entities– Think of subject as “power user”, not individual

• Examples:– Groups: defined collection of users with common

privileges– Roles: membership tied to function

Page 18: CS526: Information Security Chris Clifton October 16, 2003 Authentication

20

Representing Identity

• Randomly chosen: not useful to humans• User-chosen: probably not unique

– At least globally

• Hierarchical: Disambiguate based on levels– File systems– X.500: Distinguished Names

• /O=Purdue University/OU=Computer Sciences/CN=clifton

– Aliases• /O=Purdue University/OU=ITaP/CN=cclifton

Page 19: CS526: Information Security Chris Clifton October 16, 2003 Authentication

21

Validating Identity

• Authentication: Does subject match purported identity?

• Problem: Does identity match principal?• Solution: certificates

– Certificate: Identity validated to belong to known principal

– Certification Authority: Certificate Issuer• Authentication Policy: describes authentication required to

ensure principal correct• Issuance policy: Who certificates will be issued to

– CA is trusted

Page 20: CS526: Information Security Chris Clifton October 16, 2003 Authentication

22

Certificate Implementation

• Is a certificate real?– Digital signatures– Certificate = Identity + EIssuerPrivateKey(Identity)

• Correct if Identity = DIssuerPublicKey(Signature)

• Can I trust it?– Hierarchy of issuers

• Certificate includes certificate of issuer chain

– Higher levels place (contractual) conditions on lower level issuance

• Common issuance, authentication policy

– Also solves uniqueness issue

Page 21: CS526: Information Security Chris Clifton October 16, 2003 Authentication

23

Certificate Examples

• Verisign– Independently verifies identity of principal– Levels of certification

• Email address verified• Name/address verified• Legal identity verified

– More common: corporate identity• Is this really PayTuition.EDU I’m giving my bank account

number to?

• PGP (Pretty Good Privacy): “Web of Trust”– Users verify/sign certificates of other users– Do I trust the signer?

• Or someone who signed their certificate?

Page 22: CS526: Information Security Chris Clifton October 16, 2003 Authentication

CS526: Information SecurityChris Clifton

October 30, 2003

Systems: Design Principles

Page 23: CS526: Information Security Chris Clifton October 16, 2003 Authentication

26

Internet Identity

• Host Identity: Who is this on the network?• Ethernet: MAC address

– Guarantees uniqueness

• IP address: aaa.bbb.ccc.ddd– Provides hierarchy to ease location

• Domain Name Service– Human-recognizable name to IP– aliasing

• Issues: Spoofing– At any level, change mapping if identity to principal

Page 24: CS526: Information Security Chris Clifton October 16, 2003 Authentication

27

Anonymity

• What if identity not needed?– Web browsing– Complaints about assignments

• Removing identity not as easy as it sounds– I can send email without my userid– But it still traces back to my machine

• Solution: anonymizer– Strips identity from message– Replaces with (generated) id– Send to original destination– Response: map generated id back to original identity

Page 25: CS526: Information Security Chris Clifton October 16, 2003 Authentication

28

Anonymity

• Problem: Anonymizer knows identity– Can it be trusted?– Courts say no!

• Solution: multiple anonymizers– Onion Routing– Crowds

AnonymizerA

AnonymizerB

Sender ReceiverEA(B)

EB(Receiver)ER(message)

EB(Receiver)ER(message)

ER(message)

Page 26: CS526: Information Security Chris Clifton October 16, 2003 Authentication

29

Building Real Systems

• Theory allows formal proof of known security policies– For components– And collections of components

• What should the security policies be?

• Design principles:– Guiding standards that are relatively

independent of policy

Page 27: CS526: Information Security Chris Clifton October 16, 2003 Authentication

30

Principle of Least Privilege

• A subject should be given only those privileges needed to complete its task

Page 28: CS526: Information Security Chris Clifton October 16, 2003 Authentication

31

Fail-Safe Defaults

• Unless a subject is given explicit access to an object, it should be denied access

Page 29: CS526: Information Security Chris Clifton October 16, 2003 Authentication

32

Economy of Mechanism

• Security mechanisms should be as simple as possible– But no simpler

Page 30: CS526: Information Security Chris Clifton October 16, 2003 Authentication

33

Complete Mediation

• All accesses to an object must be checked to ensure they are allowed

Page 31: CS526: Information Security Chris Clifton October 16, 2003 Authentication

34

Open Design

• Security of a mechanism should not depend on secrecy of the design/implementation

Page 32: CS526: Information Security Chris Clifton October 16, 2003 Authentication

35

Separation of Privilege

• A system should not grant permission based on a single condition

Page 33: CS526: Information Security Chris Clifton October 16, 2003 Authentication

36

Least Common Mechanism

• Mechanisms used to access resources should not be shared

Page 34: CS526: Information Security Chris Clifton October 16, 2003 Authentication

37

Psychological Acceptability

• Security mechanisms should not make the resource more difficult to access than if security mechanisms were not present