|
 


  
 

| 
Fourth Edition
by William Stallings
 |    
   

ð















 











 



 














 















 




 




 








 

 


 


 








  



 











 






 



 
Æð








  
g have looked at message
authentication
~ but does not address issues of lack of
trust
g digital signatures provide the ability
to:
~ verify author, date & time of signature
~ authenticate message contents
~ be verified by third parties to resolve
disputes
g hence include authentication
function with additional capabilities
     
g must depend on the message signed
g must use information unique to sender
~ to prevent both forgery and denial
g must be relatively easy to produce
g must be relatively easy to recognize & verify
g be computationally infeasible to forge
~ with new message for existing digital signature
~ with fraudulent digital signature for given message
g be practical save digital signature in storage
   
g involve only sender & receiver
g assumed receiver has sender¶s
public-key
g digital signature made by sender
signing entire message or hash with
private-key
g can encrypt using receivers public-
key
g important that sign first then
encrypt message & signature
g security depends on sender¶s
private-key
  
  

g involves use of arbiter A

~ validates any signed message
~ then dated and sent to recipient
g requires suitable level of trust in
arbiter
g can be implemented with either
private or public-key algorithms
g arbiter may or may not see
message
   

g used to convince parties of each

others identity and to exchange
session keys
g may be one-way or mutual
g key issues are
~ confidentiality ± to protect session keys
~ timeliness ± to prevent replay attacks
g published protocols are often found
to have flaws and need to be
modified
ñ

g where a valid signed message is copied
and later resent
~ simple replay
~ repetition that can be logged
~ repetition that cannot be detected
~ backward replay without modification
g countermeasures include
~ use of sequence numbers (generally
impractical)
~ timestamps (needs synchronized clocks)
~ challenge/response (using unique nonce)
M 
  


g as discussed previously can use a

two-level hierarchy of keys
g usually with a trusted Key
Distribution Center (KDC)
~ each party shares own master key with
KDC
~ KDC generates session keys used for
connections between parties
~ master keys used to distribute these to
them

 
  

g original third-party key distribution

protocol
g for session between A B mediated
by KDC
g protocol overview is:
R
A->KDC: ’
©© ’  ©© 
ÀÄ KDC -> A: EKa[Ks ©© ’  ©©  ©©
E [ ©©’

i
A -> B: ! [ ©©’


B -> A: ! [

A -> B: ! [f()

 
  
g used to securely distribute a new
session key for communications
between A & B
g but is vulnerable to a replay attack
if an old session key has been
compromised
~ then message 3 can be resent
convincing B that is communicating
with A
g modifications to address this
require:
~ timestamps (Denning 81)
using an extra nonce (Neuman 93)
M  
 


g have a range of approaches based

on the use of public-key encryption
g need to ensure have correct public
keys for other parties
g using a central Authentication
Server (AS)
g various protocols exist using
timestamps or nonces
   
g Denning 81 presented the following:
R
A -> AS: ’
©© ’ 
À
AS -> A: EPRas[’
©©PU©©
©©
EPRas[’ ©©PU ©©

i
A -> B: EPRas[’
©©PU©©
©©
EPRas[’ ©©PU ©©
©© EPUb[EPRas[K ©©

g note session key is chosen by A, hence
AS need not be trusted to protect it
g timestamps prevent replay but require
synchronized clocks
a !
 

g required when sender & receiver are

not in communications at same time
(egÄ email)
g have header in clear so can be
delivered by email system
g may want contents of body
protected & sender authenticated
M 
  


g can refine use of KDC but can¶t

have final exchange of nonces, vis:
R
A->KDC: ’
©© ’  ©© 
ÀÄ KDC -> A: EKa[Ks ©© ’  ©©  ©©
E [ ©©’

i
A -> B: ! [ ©©’
©© EKs[M
g does not protect against replays
~ could rely on timestamp in message,
though email delays make this
problematic
  
 
g have seen some public-key approaches
g if confidentiality is major concern, can
use:
A->B: EPUb[Ks ©© EKs[M
~ has encrypted session key, encrypted message

g if authentication needed use a digital

signature with a digital certificate:
A->B: M ©© EPRa[H(M) ©© EPRas[
©©DA©©PUa
~ with message, signature, certificate
  

"#

g US Govt approved signature scheme

g designed by NS
& NSA in early 90's
g published as FPS-186 in 1991
g revised in 1993, 1996 & then 2000
g uses the SHA hash algorithm
g DSS is the standard, DSA is the algorithm
g FPS 186-2 (2000) includes alternative
RSA & elliptic curve signature variants
    "#
g creates a 320 bit signature
g with 512-1024 bit security
g smaller and faster than RSA
g a digital signature scheme only
g security depends on difficulty of
computing discrete logarithms
g variant of ElGamal & Schnorr schemes
   "#
  
$  
g have shared global public key values (p,q,g):
~ choose q, a 160 bit
~ choose a large prime ?

g where L= 512 to 1024 bits and is a multiple of 64
g and q is a prime factor of ?
~ choose „
?
g where 
? ? 
 ?  
g users choose private & compute public key:
~ choose þ

~ compute p
„þ 
 ?
  | 
g to  a message x the sender:
~ generates a random signature key O
O

~ nbÄ O must be random, be destroyed
after use, and never be reused
g then computes signature pair:
Y
„O
 ?
 

Ox þY
 
g sends signature Y  with
message x
  % & 

g having received M & signature

Y 
g to h a signature, recipient
computes:
u

 

xu
 

Yu
 

„p
 ? 
 
g if 
Y then signature is verified
g see book web site for details of
proof why


g have discussed:
~ digital signatures
~ authentication protocols (mutual &
one-way)
~ digital signature algorithm and
standard