The TESLA Broadcast Authentication Protocol CS 218 Fall 2017

Broadcast Technologies Some networks have native broadcast E.g., WiFi in the area of coverage Early Ethernet In other cases, broadcast is built on top of underlying network Perhaps using multihop techniques The goal is always to get a particular message to many different receivers Frequently, a broadcaster has a lot of data to send Not just a single packet Ideally, all of it gets delivered everywhere But as many packets should get delivered to as many recipients as possible

Authenticating Messages It’s often desirable to be able to verify the originator of a message In limited cases, it’s easy E.g., there’s a direct wire between you and the sender Harder for general cases Usually done with cryptography The sender applies some cryptographic operation to the message Which only the sender could perform The receiver verifies that the operation was properly applied Authenticating that the purported sender actually sent it

Cryptographic Message Authentication Usually done with digital signatures An extra piece of data attached to the message Typically created by a cryptographic operation involving both message content and sender identity Most common approach is public key (PK) cryptography Sender has a secret private key used to create the digital signature Receiver knows a matching public key that can be used to check the signature Effective, but computationally expensive

Using PK With Broadcast Get broadcaster’s public key to all receivers Sender uses his private key to sign each broadcast message One signature usable by all receivers Each receiver individually checks the signature Since receivers may not trust each other to properly check it For N receivers, then, N expensive PK operations Per message sent Too costly if many receivers and many messages How can we do it cheaper?

The TESLA Approach Synchronize the clocks of all nodes in the broadcast To within a reasonably small tolerance Sign broadcast messages using a reverse hash chain Receivers cannot authenticate messages at the moment they are received But can authenticate them later When sender reveals the hash value Synchronized clocks ensure that attacker cannot later forge a new message with the revealed hash

What Is A Reverse Hash Chain? Use a good hashing function Low collision probability No obvious relationship between value and its hash Start with a random number X Hash X to get X’ Hash X’ to get X’’ Keep hashing till you have enough values The last value is readily derivable from the next-to-last value But the next-to-last value can’t be derived from the last value

X h(X) = X’ h(X’) = X’’ h(X’’) = X’’’ h(X’’’) = X’’’’ For Example, Now what? h(X) = X’ Sign your message with X’’’’ h(X’) = X’’ h(X’’) = X’’’ Then broadcast it along with the signature h(X’’’) = X’’’’ But don’t reveal X’’’’ Yet . . .

How Do You Sign With the Hash Value? Run a message authentication algorithm (MAC) With the message and the hash value as inputs MACs deterministically produce short functions that depend on their inputs Often they are hash functions themselves So feed the message and the hash value into the MAC Actually a trifle more complicated Run the hash through a different hash function before using it for the MAC Basically for good cryptographic “hygiene” Use the output as the signature

What Do the Receivers Do? They have received the message and its signature But they can’t authenticate the message Yet . . . So they save it for later Eventually the sender reveals X’’’’ By sending it to the receivers Now the receivers can verify the signature on the message they saved So they can authenticate

But What About Forgeries? If the MAC is good, the signature can’t be forged unless you know the hash value But the sender just broadcast that value to everyone So can’t anyone who heard it forge a message using that hash value? Yes, but that’s where the synchronized clocks come into play

What Does Revealing X’’’’ Reveal? X’’’’ itself But not X’’’ Or any earlier value in the hash chain You can derive all later values Like X’’’’’ and X’’’’’’ But the broadcaster has moved beyond those He’s moving towards earlier chain values Assuming the hash is a good one-way function

Using the Clocks The sender and receivers’ clocks are all synchronized to within Δ The sender uses a particular hash value only for a pre-defined period of time Known to the receivers And their clocks are closely synchronized Once that pre-defined period ends, the sender can reveal the hash Any messages receivers get after the period are discarded Any messages they saved before the period ends can now be checked using the revealed hash

Illustrating the Process Take the hash value from the end of the hash chain as a key for a particular interval Run the key through another hash function to get a signing key Sign messages sent during the interval with that key After a safe time (dependent on Δ), sender reveals the key Receivers save the messages Then receivers check the messages’ signatures

Some Good Features of TESLA Approach Computationally cheap Works even if some messages are lost If receiver gets a later key in the chain, he can use it to derive any he lost Little expansion of messages to hold signature Works for large number of receivers Receivers’ buffering requirements are limited

Not So Good Features Some buffering required at receivers Can’t verify messages as they arrive So you also can’t use them on arrival Potentially long delay before they are usable Requires clock synchronization Which often requires running a protocol just for that purpose Maybe not if GPS is everywhere in the system