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 || MACK(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 sl

– 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: Slast, Slast-1, Slast-2,..., S0

Usage: S0, S1,… Slast

17

One-Way Chains Properties

The first element in the chain, is committed to the entire chain: Fi(si) = s0

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

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 = KS-1 and public key = KS

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 tR R sends to S Nonce S replies with (Sender Time TS || Nonce) signed with

its private key KS-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: tsender < tr_current - tR + tS

• Again, Digital Signature may lead to DOS attacks on Server!

Nonce

Sign(tS || Nonce)Upper bound on server’s time:

ts < tr_current –tR + tS

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: ( Mi || MAC (Ki, Mi ) || Kn )

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 Tint.– Interval 0 starts at time T0, interval 1 starts at time

T0+Tint and so on The sender assigns a key from the one-way

key chain to each time interval in sequence- each key Ki 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*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)

29

Receivers Setup

When initially synchronizing with the sender, each receiver gets in the Sync Reply the following:– 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<j-d where j is

the current interval index )

* In order to fit our previous examples, think of i as i=0, T0, K0 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 Kj-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 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 )

32

Key Chain Usage Scheme

Packet Example: Pj = (Mj || MAC (K’i-1, Mj) || Ki-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 Pj in interval i, the receiver can use Ki-d disclosed in Pj to determine i. (since Fi-d(Ki-d) = K0…)

Assuming loose-synchronization, the receiver can know the highest interval the sender can be in, x = [(ts – T0) /Tint ] (where ts 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 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.– 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 Ki is disclosed: Check if it already knows Ki or a later key 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

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