Direct Digital Signatures

DIRECT DIGITAL SIGNATURES

·        involve only sender & receiver

·        assumed receiver has sender‟s public-key

·        digital signature made by sender signing entire message or hash with private-key

·        can encrypt using receivers public-key

·        important that sign first then encrypt message & signature

·        security depends on sender‟s private-key

1. Arbitrated Digital Signatures

·        involves use of arbiter A

o   validates any signed message then dated and sent to recipient

·        requires suitable level of trust in arbiter

·        can be implemented with either private or public-key algorithms

·        arbiter may or may not see message

Authentication Protocols

·        used to convince parties of each others identity and to exchange session keys

·        may be one-way or mutual

·        key issues are

^o     confidentiality – to protect session keys

^o     timeliness – to prevent replay attacks

·        published protocols are often found to have flaws and need to be modified

2. Replay Attacks

where a valid signed message is copied and later resent

^o     simple replay

^o     repetition that can be logged

^o     repetition that cannot be detected

^o     backward replay without modification

countermeasures include

^o     use of sequence numbers (generally impractical)

^o     timestamps (needs synchronized clocks)

^o     challenge/response (using unique nonce)

Using Symmetric Encryption

o   as discussed previously can use a twolevel hierarchy of keys

o   usually with a trusted Key Distribution Center (KDC)

^o     each party shares own master key with KDC

^o     KDC generates session keys used for connections between parties

^o     master keys used to distribute these to them

·        can refine use of KDC but can‟t have final exchange of nonces, vis:

^o     A->KDC: IDA || IDB || N1

^o     KDC -> A: EKa [Ks || IDB || N1 || EKb [Ks||IDA] ]

^o     A -> B: EKb [Ks||IDA] || EKs [M]

o   does not protect against replays could rely on timestamp in message, though email delays make this problematic

Using Public-Key Encryption

o   have a range of approaches based on the use of public-key encryption

o   need to ensure have correct public keys for other parties

o   using a central Authentication Server (AS)

o   various protocols exist using timestamps or nonces

o   if confidentiality is major concern, can use:

A->B: EPUb [Ks] || EKs [M]

has encrypted session key, encrypted message

o   if authentication needed use a digital signature with a digital certificate:

A->B: M || EPRa [H(M)] || EPRas [T||IDA||PUa]

with message, signature, certificate