Timed Efficient Stream Loss-tolerant Authentication 1 Presentation

Timed Efficient Stream Loss-tolerant Authentication 1

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

Unicast Vs. Broadcast l l 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. – – 3 Useful for efficient and large-scale data dissemination Examples: Radio broadcast, Satellite broadcast, IP multicast, etc.

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

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

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

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

Solution #2: Digital Signatures l l 8 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…

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

Solution #3: Digital Signatures One signature for X packets l l l 10 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

Solution #3 - DRAWBACKS l l Still relatively high in bandwidth/time overhead Not robust to packet lost Scalability problems Not robust to DOS attacks – – 11 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!

Solution #4: K different keys & K different MAC’s l l l 12 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

Solution #4 - DRAWBACKS l l l 13 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!

Other solutions and main concept l Information-theoretically mechanism – l 14 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.

One-Way Chains l l 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: – – 15 Choose randomly the last element of the chain sl Chain elements are computed by repeatedly applying the one way function F

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

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

(. One-Way Chains Properties (cont l l l 18 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

. Achieving loose time Sync l l 19 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 - δ

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

(. Achieving loose time Sync. (cont Protocol Steps: l Receiver records its local time t. R l R sends to S Nonce l S replies with (Sender Time TS || Nonce) signed with its private key KS-1 l 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: tsender < tr_current - t. R + t. S • 21 Again, Digital Signature may lead to DOS attacks on Server!

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

Requirements for a viable : broadcast authentication protocol l l 23 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!

TESLA’s implemetnation requirements l l l 24 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)

Sketch of TESLA protocol l l l 25 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!!!

(. Sketch of TESLA protocol (cont l l 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: ( Mi || MAC (Ki, Mi ) || Kn ) We send the message || its MAC || a previous key to verify previous MAC’s (n < i). 26

Sender Setup l The sender divides the time into uniform intervals of duration Tint. – l The sender assigns a key from the one-way key chain to each time interval in sequenceeach key Ki will be active in time interval i. – 27 Interval 0 starts at time T 0, interval 1 starts at time T 0+Tint and so on 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

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

Receivers Setup l When initially synchronizing with the sender, each receiver gets in the Sync Reply the following: – – 29 Interval Duration, Tint Start time Ti, and index i of the start time interval Key disclosure delay d A key commitment to the key chain Ki (i

Broadcasting Authenticated Messages l l 30 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 Kj-d

Security improvement for the (…scheme (not so critical l l l 31 Since using the same key for two different purposes is considered a cryptography weakness, an additional One Way Function F’ is used since we don’t want to use key Kj both to derive Kj-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’(Ki) In that case, a packet of interval i which contains message Mj will have the following structure: Pj = ( Mj || MAC(K’i, Mj) || Ki-d )

Key Chain Usage Scheme 32 Packet Example: Pj = (Mj || MAC (K’i-1, Mj) || Ki-1 -d)

Authentication at Receiver: Definitions l l l 33 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!

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

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

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

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… l TESLA relies on a loose synchronization. A resynchronization is recommended periodically l 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… l 37

TESLA as a PKI mechanism l l l Þ 38 Assuming all nodes in network are loosely timesynchronized 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 )

TESLA as PKI (cont. ) - Usage l l 39 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!

Applying non-repudiation to TESLA l 40 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):

!Extra: TESLA for everyone l 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 56 Kbps modem – Consider Mr. Miagi from Japan using a 10 Mbps T 3 connection… Obviously same disclosure time will not fit both! 41

Extra Discussion l l l 42 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 Do. S attacks discussion

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

44