1 / 13

Lecture 6.1: Extras: Merkle Trees

Lecture 6.1: Extras: Merkle Trees. Frequent practical problem : how to sign a chunked msg. Peer-to-peer delivery Message divided into independent chunks Frequently received out of order, and from distinct peers Signature verification: needs to wait until COMPLETE message reconstruction

ferdinand-booth
Download Presentation

Lecture 6.1: Extras: Merkle Trees

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 6.1:Extras: Merkle Trees

  2. Frequentpracticalproblem: howtosign a chunkedmsg • Peer-to-peer delivery • Message divided into independent chunks • Frequently received out of order, and from distinct peers • Signature verification: needs to wait until COMPLETE message reconstruction • But what about fake injected chunks? • Per-chunk signatures: too expensive and too much overhead • Can we find a better solution? VERY LONG MESSAGE SIGNATURE … CHUNK 1 CHUNK 2 CHUNK N CHUNK 3 CHUNK 4

  3. Merkle’s idea: Hashtree Digitally signed ROOT = H( H{H[H(A),H(B)],H[H(C),H(D)]} , H{H[H(E),H(F)],H[H(G),H(H)]} ) H{H[H(A),H(B)],H[H(C),H(D)]} H{H[H(E),H(F)],H[H(G),H(H)]} H[H(A),H(B)] H[H(C),H(D)] H[H(E),H(F)] H[H(G),H(H)] H(A) H(B) H(C) H(D) H(E) H(F) H(G) H(H) A B C D E F G H

  4. Single chunkverification:use “siblings” ROOT = H[C3, S3] C3 = H{S2,C2} S3 =H{H[H(E),H(F)],H[H(G),H(H)]} S2 = H[H(A),H(B)] C2=H[C1,S1] H[H(E),H(F)] H[H(G),H(H)] H(A) H(B) C1=H(C) S1 = H(D) H(E) H(F) H(G) H(H) A B C D E F G H Log(N) siblings needed

  5. Applications (limitedlist) • Chunk validation (see example) • One-time signatures • Node authentication • Signature spreading • ….

  6. Lecture 6.2:Extras: Source Authentication: TESLA

  7. Issue: source authentication in multicast/broadcast NODE A Secret K NODE B Secret K MESSAGE, HMAC(K,MESSAGE) Unicast: one sender only, hence one possible message source. But what about multicast? More than one possible source! NODE A Secret K NODE B Secret K MESSAGE, HMAC(K,MESSAGE) NODE C Secret K Spoofing possible!!

  8. The problem and the “solution” • The problem: • Symmetricauthenticationdoes NOT provide source authenticity in groupcommunication • The solution: • Digitalsignature, obviously… • … butconsider: • High overhead • Computational/timerequirementsforsigning and (especially) verifying! • Little more than 150 RSA-2048 decryptions/sec overfullydedicated Intel core 2 1.83 GHzwith Vista 32 bit… • Compare withsymmetricauth, 3-5 ORDERS OF MAGNITUDE FASTER!

  9. A possible alternative • Amortize signature cost over MULTIPLE packets • Transmit P1…Pn • At the end transmit signed H(P1…Pn) • One signature every n packets • Killing problem: • What about lost packets??? • What about fake injected packets • one is enough to vanish all effort  DoS

  10. TESLA • Use a symmetricauthenticationmechanism in an “asymmetric” manner • Asymmetry = time! • TESLA = TimedEfficientStreamLoss-TolerantAuthentication • A. Perrig, R. Canetti, J. D. Tygar, D. Song (2000) • RFC 4082 • Proposed in the frame of MSEC (MulticastIPsec)

  11. The (basic) idea • Assumption: timesynchronization (loose) • Core idea: delayeddisclosureof key! Sender: generates key K known only to himself Transmits MSG, HMAC(K,MSG) Receiver: Buffers MSG and waits Sender: now broadcasts key K Receiver: Verifies that MSG was authentic! ………… Time epoch N+x Time epoch N

  12. Key chains (tocopewithlosses) • Usual idea: usekeys in reverse otherfromtheir (chain) generation • Result: receiverneedsonlytoreadone key toauthenticateallpastmsg – hencetoleratinglosses K0 = H(K1) Kn = random Kn-1 = H(Kn)

  13. Technicaldetails • Not presented for reasons of time shortage  • Key chain: differs from key used in auth • Synchro protocols • Hash chain efficient computation and maintenance, o(log^2 N) • Refer to RFC or papers

More Related