DIGITAL SIGNATURES and AUTHENTICATION PROTOCOLS - Chapter 13 Digital Signature Standard

AUTHENTICATION vs SIGNATURE A  B protects against{C} Signature sign protects against{A,C}

SIGNATURE CHARACTERISTICS Author Verifiable Date Authenticate by Time Contents Third Party

SIGNATURE TYPES Direct X  Y weakness: security of private key Arbitrated + date X  A  Y

ARBITRATED DIGITAL SIGNATURE TECHNIQUES

Table 13.1: Scheme (a) Arbiter Sees Message Conventional Encryption: After X  A  Y Dispute between X and Y Y  A: EKay[IDx||M||EKax[IDx||H(M)]]

Table 13.1: Scheme (b) Arbiter Does Not See Message Conventional Encryption: Arbiter : neither can read message Eavesdropper

Table 13.1: Scheme (c) Arbiter Does Not See Message Public-Key (double) Encryption: advantages: 1. No information shared before communication 2. if KRx compromised date is still correct 3. message secret from Arbiter and Eavesdropper

REPLAY ATTACKS E m  Simple Replay: X m E m Logged Replay: X m||T0 t E m||T0 (< T0 later) i m Undetected Replay:X m e E m  Backward Replay: X m X m E

TIMESTAMP m||T X Y synchronized clocks

CHALLENGE/RESPONSE Use NONCE: N X Y m||N handshake required

ATTACK ON Fig 7.9 Eavesdropper gets Old Ks: Replay Step 3 Intercept Step 4 Impersonate Step 5 Bogus Messages  Y

SOLUTION: TIMESTAMP A IDA||IDB KDC 2. KDC EKA[ KS||IDB||T||EKB[KS||IDA||T] ] A 3. A EKB[KS||IDA||T] B 4. B EKS[N1] A 5. A EKS[f(N1)] B

CLOCK ATTACKS To counteract: Suppress – Replay attacks: 1. Check clocks regularly use KDC clock 2. Handshaking via Nonce

AN IMPROVED PROTOCOL over Fig 7.9 To counteract suppress-replay attacks: A IDA|| NA B B IDB||NB||EKB[IDA||NA||TB] KDC KDC EKA[IDB||NA||KS||TB]||EKB[IDA||KS||TB]||NB A A EKB[IDA||KS||TB]||EKS[NB] B No clock synch. TB only checked by B

AUTHENTICATION SERVER - no secret key distribution (public key) A IDA||IDB AS AS EKRAS[IDA||KUA||T]||EKRAS[IDB||KUB||T] A 3. A EKRAS[IDA||KUA||T]||EKRAS[IDB||KUB||T]||EKUB[EKRA[KS||T]] B Problem: Clock Synch.

ALTERNATIVE NONCE PROTOCOL 1. A IDA||IDB KDC 2. KDC EKRauth[IDB||KUB] A 3. A EKUB[NA||IDA] B 4. B IDB||IDA||EKUauth[NA] KDC 5. KDC EKRauth[IDA||KUA]||EKUB[EKRauth[NA||KS||IDA||IDB]] B 6. B EKUA[EKRauth[NA||KS||IDA||IDB]||NB] A 7. A EKS[NB] B

ONE-WAY AUTHENTICATION (e.g. email) Encrypt Message Authenticate Sender

SYMMETRIC-KEY (one-way auth.) A IDA||IDB||N1 KDC KDC EKA[KS||IDB||N1||EKB[KS||IDA]] A 3. A EKB[KS,IDA]||EKS[M] B

PUBLIC-KEY (one-way auth.) Use Figs 11.1b,c, and d or A EKUB[KS]||EKS[M] B A M||EKRA[H(M)] B

PUBLIC-KEY (one-way auth.) Send A’s public key to B A M||EKRA[H(M)]||EKRAS[T||IDA||KUA] B

DSS : USES SHA-1 Signature YES Encryption NO Key-Exchange NO

DSS : USES SHA-1

precompute gk mod p, k-1 mod q DISCRETE LOG p,q,g – global public keys x - user private key y - user public key k - user per-message secret number r = (gk mod p) mod q s = [k-1(H(M) + xr)] mod q Signature = (r,s) precompute gk mod p, k-1 mod q

VERIFY w = (s’)-1 mod q u1 = [H(M’)w] mod q u2 = (r’)w mod q v = [(gu1.yu2) mod p] mod q where y = gx mod p v = r’ ? y = gx is one-way: x  y YES y  x NO

DIGITAL SIGNATURE ALGORITHM

DSS SIGNING AND VERIFYING