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

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

Multicast Vs. Unicast 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. Unicast Multicast

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.

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?

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.

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.

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!

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 chains as a cryptographic hash function primitive.

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.

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 digest is a kind of “signature” for a stream of data that represents the contents.

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.

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?

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 key is one that is only known by the sender and safe packets that contain safe messages whose MACs are computed with safe keys.

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.

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.

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.

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

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

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