1. The TESLA Broadcast Authentication Protocol CS 218 Fall 2017

2. 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

3. 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

4. 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

5. 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?

6. 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

7. 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

8. 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 . . .

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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