Timed Efficient Stream Loss-Tolerant Authentication. (RFC 4082)

1. Timed Efficient Stream Loss-Tolerant Authentication. (RFC 4082) Habib Moukalled 1/29/08

2. * Today's Road Map * • Brief overview and history of broadcast authentication. • Methodology behind broadcast authentication. • Overview of TESLA. • One-way chains in cryptography. • Time synchronization protocol. • Bringing it all together. • A closer look at TESLA. • A quick wrap up. • Weaknesses in the TESLA protocol • Questions, comments, criticism.

3. Multicast Vs. Unicast Unicast Multicast • Unicast is the sending of information packets to a single destination. • Multicast the delivery of information to a group of destinations simultaneously, while using the most efficient strategy possible.

4. Broadcast Authentication • GIVE DEMO • In Multicast, a single packet can reach millions of receivers. • Through source authentication, receivers of multicast packets can verify if that packet comes from the correct source.

5. Broadcast Authentication • Why do we authenticate? • To ensure a sender of a packet is indeed that sender, and to make sure the packet has not been changed along the way... • How do we authenticate? • We could append a MAC (Message Authentication Code) to each packet that is transmitted. • Packet format: • Where the MAC is computed using a shared key. • This should work, shouldn't it?

6. Symmetric cryptography in Broadcast Authentication • Not exactly... • The problem arises when the receiver has the secret key! • Now the sender's identity can be stolen. • The trusted receiver can now make fake packets and impersonate the sender to other future receivers. • Naturally we must look into asymmetric cryptographic solutions to provide us with a more reliable digital signature based scheme.

7. Paradigms of Broadcast Authentication • Signing each packet would definitely provide secure broadcast authentication. • What else does it provide? • Overhead in the time it takes to sign and verify packets. • Overhead in bandwidth. • Its safe to say, this will not do.

8. Broadcast Authentication via delayed key exchange • Researchers propose methods to eliminate overhead by using a single signature over all packets that need to be transmitted. • But even methods that provide Broadcast Authentication via a delayed key exchange have extreme vulnerabilities. • A DOS (Denial-of-Service) attack can be introduced by overwhelming a receiver with phony sender packets. • Since signature verification is computationally expensive, the receiver is now left authenticating meaningless packets. • And thus our security on the receivers end is broken... • And thus, TESLA was born!

9. Timed Efficient Stream Loss-Tolerant Authentication. (RFC 4082) • The sender attaches to each packet a MAC, with key known only to itself. • Meanwhile; the receiver buffers the received packet without a way to authenticate it yet. • A while later, the sender will disclose to the receiver, allowing the receiver to authenticate the packet. • In order to make this work, TESLA requires that the sender and receiver are loosely time synchronized. TESLA will make use of one-way chainsas a cryptographic hash function primitive.

10. Timed Efficient Stream Loss-Tolerant Authentication. (RFC 4082) • As long as the time synchronization is in place, one MAC per packet will suffice. • NOTE: TESLA uses symmetric cryptography, but due to the delayed key exchange, TESLA has an asymmetric property.

11. A quick review of hash functions • A hash function is a function that takes a string or message of any length as its input argument. • A hash function produces a string of fixed length as its output also known as the message digest. • An individual hash value also called a digestis a kind of “signature” for a stream of data that represents the contents.

12. One-way chains • One-way chains are widely used as a cryptographic primitive, especially in protocols that need to commit to a sequence of random values. • We can use a one-way chain to generate a string of length , by randomly picking the last element of the chain . • We then are able to generate a one-way chain by repeatedly applying the one-way function , to get our next value of the chain.

13. One-way chains cont. • To verify an element is the element at index of a hash chain, we can check that • In the more general case, commits to , if • to verify is part of the chain while knowing • , we simply compute • If this condition holds, commits to • NOTE: in TESLA we want to reveal the chain in the order: • How can we store the chain?

14. One-way chains cont. • We could create the chain all at once, and store each element. • but wait, that requires storage and computation time... • Better yet! We can just store , and then compute any other element of our chain on demand! • And luckily for us, researchers have devised methods for efficient storage of one-way chains such that a one-way chain with elements requires storage and computation time for accessing each element.

15. Time synchronization • As mentioned earlier, TESLA does not require strong time synchronization properties. • The receiver only needs to know an upper bound on the sender’s local time. • We will denote the exact difference between the sender and receiver’s time with • Since we are dealing with loose time synchronization, we are interested in the maximum time synchronization error, which is the upper bound of our exact difference

16. Time synchronization cont. • An example: • We have no way of knowing the real synchronization error • However, now we have the full Round Trip Time (RTT) as our synchronization error. • The receiver having their own time can compute the upper bound on the sender’s time as:

17. A note on security when synchronizing • In the protocol, the receiver first records its local time and sends a time synchronization request to the sender. • the time synchronization request contains a nonce, the heart of the security of our time synchronization protocol. • if a hacker could guess the receiver’s nonce, they would be able to send a time synchronization request to the sender with that particular nonce. • the hacker then could replay the response later to the receiver. • Upon receiving the synchronization request, the sender will record its local time as and reply with a signed packet that contains and the nonce.

18. Quick and dirty overview of the protocol • At this point we will assume the sender and the receiver are synchronized up to some time synchronization error , by using our synchronization protocol. • Next the sender will split up time into uniform intervals. • Now the sender will form a one-way chain of self-authenticating values. The values are assigned sequentially to the time intervals (one key per time interval). • Any value of a time interval can be used to determine the values of previous time intervals, since our one-way chain will be used in reverse order.

19. Protocol cont. • Now the sender will be attaching a MAC to each packet. • The MAC is computed over the entire contents of the packet. • For each packet, the sender will now determine the proper time interval, and use the corresponding time interval value from the one-way chain to be the key used in computing the MAC. • The sender will disclose the most recent one-way chain value possible, and send it along with a packet to the receiver.

20. Protocol cont. • Now each receiver will have to check if the disclosed key is correct. • This can be done using a self-authentication method along with the previously released keys. • So basically, the receiver will check the correctness of the MAC of the buffered packets sent within the time interval of the disclosed key. • As long as the MAC is correct, the receiver will accept the packet. • NOTE: In broadcast communication packets will be lost. But one-way chains can be recomputed using later value, which allows us to recover from lost packets.

21. Sender’s set up • The sender has to divide time into uniform intervals of duration • Time interval 0 will start at time • And time interval 1 starts at time , where • time interval 2 will start at time , where so on and so forth. • The sender assigns one key from the one-way chain to each time interval in the time sequence. • The sender determines the length of the one-way chain . And the length of our chain will determine the maximum transmission duration before a new one-way chain has to be computed.

22. Sender’s set up cont. • The sender picks a random value for . • Using a pseudo-random function , the sender constructs the one-way function . • The rest of the chain will be computed recursively using . • NOTE: the recurrence yields: and its because of this property we have the ability to compute any value in the key chain from the value , without having to know the intermediate intervals. • And each will remain active over the interval .

23. Bootstrapping the receivers • Again, before a receiver can authenticate messages, the sender and receiver have to be synchronized as explained in our time synchronization protocol. • The sender is responsible for the key disclosure schedule. And ensures it by transmission of the following: • Time Interval Schedule: • Interval duration . • Start time . • The index of interval , which is the length of the • one-way chain. • Key disclosure delay d, which corresponds to the number of intervals. • Finally, the commitment to the keychain • where is the current interval index.

24. Broadcasting the authenticated messages • At this point the sender already knows which keys in our one-way chain correspond to a time interval. • We also know every time that a sender broadcasts a message a MAC will be appended to the packet using the key that corresponds to the appropriate time interval. • The key will remain a secret for intervals. • Meaning: messages sent in the interval j will provide the ability to disclose the key . • Security Note: We !!!DO NOT!!! Want to use the same key multiple times in different cryptographic operations. • eg: we do not want to use the key to derive and our MAC.

25. Broadcasting the authed messages cont. • instead we use the pseudo random function to construct the one-way function . • we use to derive they key to compute the MAC of messages: . • To broadcast message in the time interval , the sender constructs the packet: • This figure depicts one-way key chain derivation, the MAC key derivation, the time intervals, and some sample packets that the sender broadcasts.

26. Authentication on the receivers end • When the sender discloses the key, all parties have potential access to that particular key. • This allows an attacker to create a fake message and forge a MAC using the disclosed key. • When packets arrive, the receiver must verify MACs of the arriving packets were based on safe keys • A safe keyis one that is only known by the sender and safe packetsthat contain safe messageswhose MACs are computed with safe keys.

27. Authentication on the receivers end cont. • This is how we do it: • A sender sends the packet in the interval . • When the packet arrives at the receiver, they will use the self-authenticating key disclosed in the packet • to determine . • The receiver then checks the latest possible time interval • that the sender could be in (remember, we can do this since the sender and receiver are loosely time synchronized). • If (where is the disclosure delay) then the receivers packet is safe. • therefore the sender has not reached the interval where it discloses the key , the key that verifies the packet .

28. Authentication on the receivers end cont. • At this point, the receiver is still unable to verify the authenticity of packet sent in the interval . • So the receiver adds the triplet to a buffer, and will verify it after knowing . • Once is disclosed, the receiver will check to see if it already knows or a later key where . • If is indeed the latest key received, the receiver will check whether or not it is a valid key by using some earlier key where using the property: • Finally, the receiver will compute: and verifies the authenticity of packets on the interval , as well as the intervals for which the key has not yet been received.

29. Summary • TESLA makes use of one-way chains as a cryptographic primitive. • It is through these one way chains we are able to create a unique key for every possible time interval on demand. • Though the initial request of the receiver is made in a unicast communication channel, after the sender and receiver are “loosely” synchronized through the time synchronization protocol, communications thereafter will be done in a broadcast fashion. • The security of the time synchronization protocol depends on the anonymity of the receiver’s nonce.

30. TESLA's weaknesses I do not feel like doing anymore, I think I have talked long enough, time to pick on you guys!

31. Questions ? / Comments ! / Criticism :( class can now ask questions, etc.

32. Sources 1.) Wikipedia keyword: Hash Function http://en.wikipedia.org/wiki/Hash_function 2.) Wikipedia keyword: Unicast http://en.wikipedia.org/wiki/Unicast 3.) Wikipedia keyword: Multicast http://en.wikipedia.org/wiki/Multicast 4.) CSCE 515 lecture notes from lecture: JavaNetProg.pdf 5.) D. Coppersmith and M. Jakobsson. Almost optimal hash sequence traversal. 6.) RFC 4082 7.) A Perrig, R. Canetti, J.D. Tygar, and D. Song. The TESLA Broadcast Authentication Protocol. 8.) M. Jakobsson. Fractal hash sequence representation and traversal.