Document Sample
TESLA Powered By Docstoc
					    Timed Efficient Stream Loss-tolerant Authentication

    Presentation Outline

       Introduction to broadcast networks
       Other (worse?!) broadcast authentication
       Basic cryptography and time synchronization
       The TESLA Broadcast Authentication Protocol
       Extras

    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
        –   Examples: Radio broadcast, Satellite broadcast, IP
            multicast, etc.

    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.

    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.

    Solution #1: Use MAC

       Sender and all receivers know a symmetric key
       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.

    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???

    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

       Digital Signatures will do the work in terms of
        secure authentication. But…

    Solution #2- DRAWBACKS

     In terms of time to sign and verify siganatures
     In terms of bandwidth

       Hence using a digital signature per packet is
        not quite applicable…

     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

     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!

     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

     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!

     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.

     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

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

     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

     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

     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 - δ

     Achieving loose time Sync. (cont.)

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

     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!

Synchronization Scheme:
Goal: know upper bound on server’s time


                                Sign(tS || Nonce)
     Upper bound on
     server’s time:
     ts < tr_current –tR + tS
     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!
     TESLA’s implemetnation

        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

        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.)

        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).

     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
     Sender Setup (cont.)
        The sender determines the length N of the one-way
         –   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
28       Ki = FN-i(KN)
     Receivers Setup

        When initially synchronizing with the sender,
         each receiver gets in the Sync Reply the
         –   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.
     Broadcasting Authenticated

        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…)

        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 )
     Key Chain Usage Scheme

32    Packet Example: Pj = (Mj || MAC (K’i-1, Mj) || Ki-1-d)
     Authentication at Receiver:

        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

        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

     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.

     Receivers’ Action on key

     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!)

     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
      Under the above 2 last conditions, TESLA is very hard
       for an attacker to break…   

     TESLA as a PKI mechanism

        Assuming all nodes in network are loosely time-
        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

        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

        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!

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

     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


        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


Shared By: