Scribd
Upload
74 views23 pages

Fourth Edition by William Stallings

Digital Signatures have looked at message authentication but does not address issues of lack of trust Digital Signatures provide the ability to: verify author, date and time of signature authenticate message contents be verified by third parties to resolve disputes Hence include authentication function with additional capabilities Direct Digital Signatures involve use of sender and receiver assumed receiver has senderPs public-key digital signature made by sender signing entire message or hash with private-key can encrypt using receivers publickey important that sign first then encrypt message and signature security depends on send

Uploaded by

kstu1112
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
74 views23 pages

Fourth Edition by William Stallings

Digital Signatures have looked at message authentication but does not address issues of lack of trust Digital Signatures provide the ability to: verify author, date and time of signature authenticate message contents be verified by third parties to resolve disputes Hence include authentication function with additional capabilities Direct Digital Signatures involve use of sender and receiver assumed receiver has senderPs public-key digital signature made by sender signing entire message or hash with private-key can encrypt using receivers publickey important that sign first then encrypt message and signature security depends on send

Uploaded by

kstu1112
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

|  

   
  
| 
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

You might also like