1 Timed Efficient Stream Loss-tolerant Authentication

2 Presentation Outline Introduction to broadcast networks Other (worse?!) broadcast authentication protocols Basic cryptography and time synchronization methods The TESLA Broadcast Authentication Protocol Extras

3 Unicast Vs. Broadcast Unicast is the most simple way of communication- X speaks to Y, Y speaks to X, and both live happily ever after … (NOT!) Broadcast means sending (hopefully … ) the same message to many recipients. – Useful for efficient and large-scale data dissemination – Examples: Radio broadcast, Satellite broadcast, IP multicast, etc.

4 Unicast threats and solutions We live on earth → Evil people exist … – Messages can be forged by evil people – Malicious spoofers can impersonate senders  Authentication mechanisms are needed! Classic unicast authentication mechanisms: – MAC, Digital Signature.

5 Broadcast Threats Same as unicast threats: – Messages can be forged by evil people – Malicious spoofers can impersonate senders  Authentication mechanisms are needed! But the solutions are not exactly the same … Possible solutions (and their pitfalls) to the threats will be displayed in the following foils.

6 Solution #1: Use MAC Sender and all receivers know a symmetric key K. Sender sends (MSG || MAC K (MSG) ) Each receiver computes MAC for the message, and checks against the received MAC. – IF equal- message is considered authenticated. – ELSE- message is considered forged.

7 Solution #1- DRAWBACKS Receivers are probably not angles. But they do know the symmetric key …  Receivers can impersonate sender, and fool other receivers!  Solution #1 is unacceptable! Maybe asymmetric crypto. will do the work???

8 Solution #2: Digital Signatures Sender knows how to sign, receivers know how to verify sender ’ s signature Sender sends (msg || SIGNATURE (msg) ) Each receiver verifies the signature for the message Digital Signatures will do the work in terms of secure authentication. But …

9 Solution #2- DRAWBACKS HIGH OVERHEAD In terms of time to sign and verify siganatures In terms of bandwidth Hence using a digital signature per packet is not quite applicable …

10 Solution #3: Digital Signatures One signature for X packets In order to reduce the overhead of one signature per packet, a single signature can be amortized over X packets, instead of just 1. Decreases bandwidth overhead Decreases total sign/verification time

11 Solution #3- DRAWBACKS Still relatively high in bandwidth/time overhead Not robust to packet lost Scalability problems Not robust to DOS attacks – A malicious entity can “ flood ” the receiver with bogus packets, supposedly containing a signature. – Since verifying a signature is computationally expensive, receiver will be overwhelmed verifying bogus signatures!

12 Solution #4: K different keys & K different MAC ’ s K different keys to authenticate every message with k different MAC ’ s Every receiver knows m keys, and therefore can verify m MAC ’ s Keys are distributed in such a way that no coalition of w receivers can forge a packet for a specific receiver

13 Solution #4- DRAWBACKS Very Complicated The security of this scheme depends on the assumption that at most a bounded number of receivers collude Scalability problems – a single new user can mess up everything!

14 Other solutions and main concept Information-theoretically mechanism – High overhead in large groups with many receivers So far, nothing is good enough. Anyway, it has been proven that in order to grant a collision resistant broadcast authentication protocol, either Digital Signatures or Time Synchronization must be used.

15 One-Way Chains One-Way chains allow us to create a sequence of (random) values given an initial value, by using a one-way function (for example Hash). Creation of a one-way chain of length l: – Choose randomly the last element of the chain s l – Chain elements are computed by repeatedly applying the one way function F

16 One Way Chains Scheme In TESLA (and in other protocols of course), the keys are revealed in reverse to their generation order: Genearation: S last, S last-1, S last-2,..., S 0 Usage: S 0, S 1,… S last

17 One-Way Chains Properties The first element in the chain, is committed to the entire chain: F i (s i ) = s 0 We can verify that an element s j is a part of the chain by checking that F j-i (s j ) = s i for some element s i that is in our chain ( and i< j) – S i commits to S j if (I < j) and both belong to the chain In TESLA, the chain elements are keys

18 One-Way Chains Properties (cont.) The chain can be generated offline, and have all its elements stored The first element can be stored, and other elements can be computed by demand In practice- Hybrid approach cant be used, using O(log n) time and memory, for a chain of length n

19 Achieving loose time Sync. Loose time synchronization requires knowing an upper bound on time differences In tesla, the receiver needs to know the upper bound on the sender ’ s time. Δ = Maximum time synchronization error The receiver in TESLA is not interested in the exact time difference - δ

20 Achieving loose time Sync. (cont.) Setup: The sender S has a digital signature key pair, private key = K S -1 and public key = K S Receiver knows how to get the Sender ’ s public key (otherwise he wouldn ’ t be able to verify the sender ’ s signature) Receiver chooses an unpredictable nonce.

21 Achieving loose time Sync. (cont.) Protocol Steps: Receiver records its local time t R R sends to S Nonce S replies with (Sender Time T S || Nonce) signed with its private key K S -1 Receiver verifies signature. If valid, and the nonce in the packet equals to the nonce it created, the receiver can compute the upper bound on current sender ’ s time: t sender < t r_current - t R + t S Again, Digital Signature may lead to DOS attacks on Server!

Nonce Sign(t S || Nonce) Upper bound on server’s time: t s < t r_current –t R + t S Synchronization Scheme: Goal: know upper bound on server’s time

23 Requirements for a viable broadcast authentication protocol: Low computation overhead for generation and verification of authentication information Low communication overhead Limited buffering for sender and receiver, hence timely authenticated for each packet Robustness to packet loss Scalability to large number of receivers  TESLA meets all these requirements! With low cost!

24 TESLA ’ s implemetnation requirements The sender and receivers must be at least loosely time synchronized Either the receiver or the sender must buffer some messages In typical configurations, authentication delay is low (on the order of one RTT)

25 Sketch of TESLA protocol Sender splits time into intervals Each time interval is applied a MAC Packets are sent along with their MAC Each MAC key has a disclosure delay. A MAC can be verified only after the disclosure delay for the secret key has passed. Receiver accepts only valid messages Lost packets are NOT retransmitted!!!

26 Sketch of TESLA protocol (cont.) The main idea is that a receiver can verify a message authentication only after some time intervals have passed. Each TESLA packet has the following structure: ( M i || MAC (K i, M i ) || K n ) We send the message || its MAC || a previous key to verify previous MAC ’ s (n < i).

27 Sender Setup The sender divides the time into uniform intervals of duration T int. – Interval 0 starts at time T 0, interval 1 starts at time T 0 +T int and so on The sender assigns a key from the one-way key chain to each time interval in sequence- each key K i will be active in time interval i. – The one-way chain is used in the reverse order of generation, hence any key can be used in order to derive the key values of previous intervals

28 Sender Setup (cont.) The sender determines the length N of the one-way chain. – Transmission duration is therefore limited by N*T int for that particular one-way key chain. The sender picks a random value for K N Using a PRF f the sender constructs the one way function: F(k) = f k (0) The remainder of the chain is computed recursively using K i = F(K i+1 )  We can compute any value in the key chain from K N even if we don ’ t have intermediate values using K i = F N-i (K N )

29 Receivers Setup When initially synchronizing with the sender, each receiver gets in the Sync Reply the following: – Interval Duration, T int – Start time T i, and index i of the start time interval – Key disclosure delay d – A key commitment to the key chain K i (i<j-d where j is the current interval index ) * In order to fit our previous examples, think of i as i=0, T 0, K 0 etc.

30 Broadcasting Authenticated Messages Each key in the one way chain corresponds to a time interval The key remains secret for d-1 intervals, therefore a message sent in interval j effectively discloses key K j-d

31 Security improvement for the scheme (not so critical … ) Since using the same key for two different purposes is considered a cryptography weakness, an additional One Way Function F ’ is used. F ’ is used since we don ’ t want to use key K j both to derive K j-1 and to compute MAC ’ s. F ’ is a PR One Way Function family: F ’ (k) = f ’ k (1) We use F ’ to derive the key to compute the MAC of a message: K ’ i =F ’ (K i ) In that case, a packet of interval i which contains message M j will have the following structure: P j = ( M j || MAC(K ’ i, M j ) || K i-d )

32 Key Chain Usage Scheme Packet Example: P j = (M j || MAC (K’ i-1, M j ) || K i-1-d )

33 Authentication at Receiver: Definitions Safe Key: A key that only the server knows Safe Packet: A packet which arrived when its corresponding MAC key was safe Receivers MUST discard any packet that is not safe, since attacker might have forged it!

34 Determining Safety of a Packet Assuming sender sent a packet P j in interval i, the receiver can use K i-d disclosed in P j to determine i. (since F i-d (K i-d ) = K 0 … ) Assuming loose-synchronization, the receiver can know the highest interval the sender can be in, x = [(t s – T 0 ) /T int ] (where t s is the upper bound on current server ’ s time. Packet is SAFE, if x < i + d

35 Authentication at Receiver Assuming receiver gets a packet P j on interval i IF the packet is safe, receiver stores the triplet (i, M j, MAC(K ’ i, M j ) ) in a buffer. The message authenticity will be verified when key K i arrives. – IF verification valid → Message passes on to app. – ELSE → Message discarded After verification the message is removed from the buffer.

36 Receivers ’ Action on key disclosure Assuming key K i is disclosed: Check if it already knows K i or a later key Check if the key is indeed a part of the chain, IF K v =F i-v (K i ) for some previous key K v that we know that is a part of the key chain If key is legitimate, authenticate messages from interval i and previous intervals (remember, it ’ s a one way chain → very easy!)

37 Tesla security discussion TESLA does not rely on any assumption on network delay, but if network delay is close to disclosure delay, packets will not be safe … TESLA relies on a loose synchronization. A resynchronization is recommended periodically The functions F and F ’ are secure Pseudo Random Functions.  Under the above 2 last conditions, TESLA is very hard for an attacker to break …

38 TESLA as a PKI mechanism Assuming all nodes in network are loosely time- synchronized Thinking of each key of a key as a key chain commitment- can be used as a Public Key Any loosely time synchronized receiver can authenticate messages, but not forge authentication  We can let the CA know all nodes ’ key chain commitments and disclosure time, and let all nodes know CA ’ s TESLA details (key-chain commitment and Disclosure time )

39 TESLA as PKI (cont.) - Usage Node A wants to verify nodes B packet authentication information. A contacts CA for B ’ s TESLA details CA sends them to A via a TESLA instance After CA discloses the corresponding key, A can verify B ’ s authentication data! Not bad!

40 Applying non-repudiation to TESLA TESLA does not provide non-repudiation Using a trusted Timestamp Server, we can achieve non-repudiation, (assuming all nodes are synchronized and trust Timestamp Server):

41 Extra: TESLA for everyone! TESLA can be adjusted to conform users with different bandwidth, using numerous Key Chains. Consider a live internet-radio broadcast: – Consider Ron from Israel using 56Kbps modem – Consider Mr. Miagi from Japan using a 10Mbps T3 connection … Obviously same disclosure time will not fit both!

42 Extra Discussion Applying Non-Repudiation to TESLA Immediate authentication, in price of an additional hash function and sender buffering Improvements to concurrent instances from previous slide Synchronization discussion DoS attacks discussion

43 Summary I have presented TESLA a broadcast authentication protocol which among its good attributes are: – Low in overhead – Scalable to many receivers – Robust to packet lost – Based on time Synchronization – Simple