Identification and Authentication CSCE 790 Lecture 8

1
Identification and Authentication CSCE
790Lecture 8

2
Reading assignment

• Reading assignments for Febr. 7
• Required
• Oppliger Ch 6, Ch 16.2.1
• Maximum security Ch 14

3
Authentication

• Allows an entity (a user or a system) to prove
  its identity to another entity
• Typically, the entity whose identity is verified
  reveals knowledge of some secret S to the
  verifier
• Strong authentication the entity reveals
  knowledge of S to the verifier without revealing
  S to the verifier

4
Identification Techniques

• What the claimant knows
• Password, personal information
• What the claimant possesses
• Physical key, ticket, passport, token, smart card
• What the claimant is (biometrics)
• Fingerprints, voiceprint, signature dynamics
• Where the claimant is
• Network address, physical location

5
Passwords

• Commonly used method
• For each user, system stores (user name,
  F(password)), where F is some transformation
  (e.g., one-way cipher) in a password file
• F(password) is easy to compute
• From F(password), password is difficult to
  compute
• Password is not stored in the system
• When user enters the password, system computes
  F(password) match provides proof of identity

6
Vulnerabilities of Passwords

• Inherent vulnerabilities
• Easy to guess or snoop
• No control on sharing
• Practical vulnerabilities
• Visible in the clear in distributed and network
  environment
• Susceptible for replay attacks if encrypted
  naively

7
Weak Passwords

• Bell Labs study (Morris and Thompson, 1979), 3289
  passwords were examined
• 15 single ASCII characters, 72 two ASCII
  characters, 464 three ASCII characters, 477 four
  ASCII characters, 706 five letters (all lower
  case or all upper case), 605 six letters, all
  lower case, 492 week passwords (name, dictionary
  words, etc.)
• Summary 2831 passwords (86 of the sample) were
  weak, i.e., either too easy to predict or too
  short

8
Dictionary Attacks on Passwords

• Attack 1
• Create dictionary of common words and names and
  their simple transformations
• Use these to guess password
• Attack 2
• Usually F is public and so is the password file
  (encrypted)
• Compute F(word) for each word in dictionary
• Find match
• Attack 3
• Pre-compute dictionary
• Look up matches

9
Password Salt

• Used to make dictionary attack more difficult
• Salt is a 12 bit number between 0 and 4095
• It is derived from the system clock and the
  process identifier
• Compute F(passwordsalt) both salt and
  F(passwordsalt) are stored in the password table
• User gives password, system finds salt and
  computes F(passwordsalt) and check for match
• Note with salt, the same password is computed in
  4096 ways

10
Password Management Policy

• Educate users to make better choices
• Define rules for good password selection and ask
  users to follow them
• Ask or force users to change their password
  periodically
• Actively attempt to break users passwords and
  force users to change broken ones
• Screen password choices

11
One-time Password

• Use the password exactly once!

12
Lamports scheme

• Doesnt require any special hardware
• System computes F(x),F2(x),, F100(x) (this
  allows 100 logins before password change)
• System stores users name and F100(x)
• User supplies F99(x) the first time
• If the login is correct, system replaces F100(x)
  with F99(x)
• Next login user supplies F98(x) and so on
• User calculates Fn(x) using a hand-held
  calculator, a workstation, or other devices

13
Time Synchronized

• There is a hand-held authenticator
• It contains an internal clock, a secret key, and
  a display
• Display outputs a function of the current time
  and the key
• It changes about once per minute
• User supplies the user id and the display value
• Host uses the secret key, the function and its
  clock to calculate the expected output
• Login is valid if the values match

14
Time Synchronized
Secret key
Time
DES
One Time Password
15
Challenge Response

• Non-repeating challenges from the host is used
• The device requires a keypad

Network
Work station
Host
User ID
Challenge
Response
16
Challenge Response
Secret key
Challenge
DES
One Time Password
17
Devices with Personal Identification Number (PIN)

• Devices are subject to theft, some devices
  require PIN (something the user knows)
• PIN is used by the device to authenticate the
  user
• Problems with challenge/response schemes
• Key database is extremely sensitive
• This can be avoided if public key algorithms are
  used

18
Smart Cards

• Portable devices with a CPU, I/O ports, and some
  nonvolatile memory
• Can carry out computation required by public key
  algorithms and transmit directly to the host
• Some use biometrics data about the user instead
  of the PIN

19
Biometrics

• Fingerprint
• Retina scan
• Voice pattern
• Signature
• Typing style

20
Problems with Biometrics

• Expensive
• Retina scan (min. cost) about 2,200
• Voice (min. cost) about 1,500
• Signature (min. cost) about 1,000
• False readings
• Retina scan 1/10,000,000
• Signature 1/50
• Fingerprint 1/500

21
Authentication

• Network must ensure
• Data exchange is established with addressed peer
  entity
• Not with an entity masquerade or replay of
  previous establishment
• Network must ensure data source is the one
  claimed
• Authentication generally follows identification
• Establish validity of claimed identity
• Provide protection against fraudulent transactions

22
Authentication

• Identification, authentication and authorization
  information must be securely maintained by the
  network

23
Authentication

• Authentication Function provides means to
  authenticate a message
• Authentication Protocol enables the receiver to
  authenticate the message

24
Authentication Functions

• Encryption
• Cryptographic checksum
• Hash function

25
Conventional Encryption
Plaintext M
Ciphertext C
Plaintext M
Encryption
Decryption
Sender
Recipient
K
K
Secure channel

• R knows that
• Message was
• sent by S
• Message hasnt
• been altered

Key source
26
Conventional Encryption

• Provides confidentiality
• Provides authentication if recipient can check
  whether the deciphered message is legitimate or
  not

27
How to detect legitimate plaintext?

• Example binary object file, digitalized X-ray
• Solutions
• Easily recognizable structure of plaintext
• Append error detecting code, e.g., checksum F(M)

28
Internal Error Control
EKMF(M)
M
M
M
F
D
E

compare
F(M)
F(M)
F
Recipient
K
K
Sender
Authentication Attacker cant generate
ciphertext with valid error control
29
External Error Control
Sender
Recipient
EKM
M
D
M

F
E
compare
F
F(EKM)
K
K
Authentication Attacker can generate ciphertext
with valid error control But does not know the
corresponding plaintext
30
Digital Signatures

• Message authentication
• Protects two communicating parties against a
  third one
• Does not protect against each other
• NEED Digital signature

31
Digital signature

• Direct digital signature public-key cryptography
  based
• Arbitrated digital signature
• Conventional encryption
• Arbiter sees message
• Arbiter does not see message
• Public-key based
• Arbiter does not see message

32
Digital Signatures in RSA
Insecure channel
Sign
Verify
Plaintext
Signed plaintext
Plaintext
Encryption Alg.
Decryption Alg.
Recipient
Sender
Ss public key
Ss private key
(need reliable channel)
33
Authentication Protocols

• Mutual authentication
• Mutual validation of identity
• Agree on session key
• Example KDC, Kerberos
• One-way authentication
• Not synchronized
• Example e-mail

34
Kerberos Authentication Service

• Developed at MIT under project Athena in mid
  1980s
• Versions 1-3 were for internal use versions 4
  and 5 are being used externally
• Version 4 has a larger installed base, simpler
  and has better performance
• Version 5 corrects some of the security
  deficiencies of version 4
• Trusted third-party authentication protocol
  (based on the Needham and Schroeder
  authentication protocol)

35
Kerberos Objective

• To provide a trusted third-party service that can
  perform authentication between any pair of
  entities
• Authentication is two-way
• Not meant for high risk operations (e.g., bank
  transactions, classified govt. data, student
  grades)

36
Design Goals

• Impeccability
• No clear text on the network
• No client passwords on the server (servers must
  store secret server key)
• Minimum exposure of client key on workstation
  (smartcard solution eliminates this need)

37
Design Goals

• Containment
• Compromise affects only one client (or server)
• Limited authentication lifetime (8 hours, 24
  hours, more)
• Transparency
• Password required only at login
• Minimum modification to existing applications

38
Physical Security

• Public and private workstations none
• Servers moderate (locked rooms, known software)
• Kerberos - high

39
Encryption

• Uses DES-based secret key cryptography
• Each principal (service or user) agree on a
  secret key at the time of registration
• This is called master key
• Notes
• Each user has a password which is converted to a
  DES key
• Client and server do not initially share an
  encryption key

40
Clocks

• All machines that use Kerberos must be loosely
  synchronized
• (within few minutes)

41
Kerberos Components

• Kerberos database contains secret key for each
  principal (user or service)
• This is the only place where user passwords are
  stored on the network.
• Key Distribution Center (KDC) uses the Kerberos
  database to verify the identity of users
  requesting the use of services

42
Kerberos Components

• Ticket Granting Server (TGS) Issues tickets to
  clients for communicating with network servers
  after the KDC has verified the identity of the
  client

43
Kerberos Steps
Kerberos
1.Request ticket- granting ticket
Once per user logon session
2. Ticket session key
KDC
Client
3. Request service- granting ticket
TGS
Once per type of service
4. Ticket session key
6. Provide server authentication
5. Request service
Server
Once per service session
44
Notation

• c client
• s server
• Kx secret key of x (known to x and Kerberos)
• Kc,s session key for c and s (generated by
  Kerberos and sent to c)
• P Kq P encrypted with Kq
• Tc,s ticket for c to use s (generated by c and
  verified by s

45
Notation

• Ac,s authenticator for c to use s
• addr clients IP address
• time0 beginning time for ticket
• life lifetime of ticket
• timea timestamp

46
Credentials

• Tickets
• Tc,s s, c, addr, time0, life, Kc,s Ks
• Authenticator
• Ac,s c, timeaKc,s

47
Getting Initial Ticket

• B logs into the workstation (WS), WS sends Bs
  user id to KDC in the clear
• KDC returns to the WS, encrypted with Bs secret
  key
• Session key KB,KDC (secret key to be used during
  the current session)
• Ticket granting ticket (TGT) containing the
  session key, the user id, and an expiration time,
  encrypted by KKDC

48
Getting Initial Ticket

• After receiving the message from KDC, WS prompts
  B for his password, uses it to derive Bs secret
  key, that is used to decrypt the session key
  KB,KDC and TGT
• WS discards Bs password and his master key
• When B requires access to a service A, WS will
  need to send the TGT to TGS. Since TGT contains
  all the information TGS needs about the initial
  login session. Note, Kerberos can be stateless

49
Getting Server Ticket

• B wants to access service A, WS sends to TGS the
  name A and an authenticator which proves that WS
  knows the session key
• Authenticator consists of the time of day
  encrypted with session key (here with KB,KDC)
• TGS decrypts TGT to obtain KB,KDC and verifies
  timestamp

50
Getting Server Ticket

• If OK, TGS generates new session key KB,A, finds
  As master key and sends to WS a ticket to A and
  KB,A encrypted by KB,KDC
• The ticket to A consists of B, expiration time,
  and KB,A both encrypted using As master key

51
Requesting Service

• Upon receipt of the message from KDC, WS decrypts
  the message using KB,KDC
• WS sends the ticket to A and an authenticator to
  A
• A decrypts the ticket to obtain KB,A, decrypts
  the authenticator using KB,A to verify the
  timestamp
• If everything checks out, A knows the message is
  from B
• A and B can use KB,A to encrypt future messages
  if they wish

52
Replicated Kerberos Servers

• Avoid single point of failure and performance
  bottleneck
• Mutual consistency of replicated data is
  maintained as follows
• All updates are made to a primary copy
• Other copies are read only
• Database is transferred in the clear and
  cryptographic checksum and timestamp is used

53
Kerberos Realms

• A realm consists of
• Kerberos server
• Application servers
• Users
• All users and servers are registered with
  Kerberos
• Kerberos provides interrealm authentication
• Servers are registered with each other and share
  a secret key

54
Kerberos Limitations

• It is possible to cache and replay old
  authentications during the lifetime of the ticket
• If server can be fooled about correct time, old
  ticket can be reused
• Vulnerable to password guessing attacks