TESLA Certificates: An Authentication Tool for Networks of Compute-Constrained Devices Mathias Bohge

Transcription

1 TESLA Certificates: An Authentication Tool for Networks of Compute-Constrained Devices Mathias Bohge Wade Trappe Telecommunication Networks Group Wireless Information Network Laboratory Technical University of Berlin Rutgers University Sekr T5-2, Einsteinufer 25, Berlin, Germany 73 Brett Rd., Piscataway, NJ USA Abstract In the near future wireless networks will consist of lowpowered, compute-constrained devices. These devices will have limited ability to perform the expensive computational operations associated with public key cryptography. This will limit the usefulness of conventional authentication mechanisms based on public key certificates in these domains. In this paper we introduce an alternative to conventional public key certificates that is based upon symmetric key cryptography and the principles of delayed key disclosure. The work formalizes concepts presented in earlier work on a broadcast authentication protocol, known as TESLA. TESLA certificates rely upon a tradeoff between computation and authentication delay in order to achieve a certificate infrastructure that reduces computational complexity associated with certificate verification when compared with traditional public key infrastructure certificates. urther, we introduce a modification to the TESLA protocol that provides partial authentication of multicast data, which allows for partial authentication in our TESLA certificate framework. As an application, we apply TESLA certificates to the problem of maintaining authentication during handoff in a generic mobile network. INTRODUCTION We are rapidly approaching an era of pervasive computing and communication, where low-powered wireless devices will be deployed everywhere. These devices will serve many different purposes, from allowing us to communicate while we are mobile, to performing measurements for remote sensing applications for environmental monitoring or healthcare services. As these devices become integrated into our daily lives, it will become increasingly critical to secure their operation. These devices, however, will not have the same amount of resources available as their wired counterparts. In fact, due to their resource constraints, full-fledged security solutions are not appropriate, and it is important that resource-efficient alternatives are developed. Entity authentication is an essential security function for any system. Traditional authentication methods that are based on public key cryptography are not suitable for networks of low-powered devices since public key cryptography involves intensive computation. Therefore, use of public key certificates is restricted in future wireless environments. In this paper, we will develop a method for entity authentication that is an alternative to public key certificates. Our approach is motivated by work of Perrig et al. [1, 2, 3]. The work presented in [2] introduced guidelines for building a public key infrastructure using a broadcast authentication protocol known as TESLA. The work presented here extends their results to describe a specific certificate structure based upon TESLA. The resulting certificate framework, which we call TESLA certificates, replaces public key operations with more efficient symmetric cryptography operations, such as using message authentication codes. urther, we also introduce a mechanism for achieving partial authentication using TESLA that allows for partial authentication of TESLA certificates. TESLA AND TESLA CERTIICATES The task of certificates is to certify identity. Today, the most widely used certification systems are PGP [4] and X.509 [5]. Both rely on public key cryptography, which makes them unsuitable for low-powered, computationallyconstrained devices. These devices should not have to verify an RSA-signature associated with a public key certificate. Therefore, if we wish to have a certificate-based authentication system for these low-powered devices, we need a certificate that does not employ public key cryptography. TESLA [1, 3] is a broadcast authentication technique that achieves asymmetric properties, in spite of using purely symmetric cryptographic functions (MAC functions). Due to the use of MACs, TESLA enables low-powered nodes to perform source authentication. TESLA is based upon the principle of delayed key disclosure, which has found application in several works on authentication for network communication[6, 7]. We now briefly review TESLA. To begin, TESLA divides time into intervals of equal duration. Time slot n is assigned a corresponding key tk n. or each packet generated during time interval n, the sender appends a MAC that is created using the secret key tk n. Each receiver buffers the packets, without being able to authenticate them, until the sender discloses the key tk n by broadcasting the corresponding key-seed s n. Once s n is disclosed, anyone with s n can calculate tk n and can pretend to be the sender by forging MACs. Therefore, the use of tk n for creating MACs is

2 igure 1. The steps involved in using TESLA certificates. limited to time interval n, and future time intervals use future keys. urther, s n isn t disclosed until d time slots later, where d is governed by an estimate of the maximum network delay for all recipients. The keys tk n are derived from the key-seeds using a publicly available one-way function. The key-seeds are related to each other via a reverse-time chain of one-way functions. To create the chain of key-seeds, the sender chooses a terminal seed s l, and generates the previous seed s l 1 using a one-way function. Similarly, the remaining seeds {s 0, s 1,, s l } are derived via s l sl 1 sl 2... s1 s0. (1) The sender uses the seed-chain in the opposite direction (starting with seed s 0 ) to derive the TESLA keys by applying the one-way function via s n tk n. (2) When a user receives a packet, he first checks whether the packet is fresh (i.e. it was sent in a timeslot whose TESLAkey hasn t been disclosed) or dated. The receiver discards all dated packets and buffers only the fresh ones. Once the user receives a TESLA-seed s n, he checks (s n ) = s n 1 to be sure of s n s authenticity. He derives tk n by tk n = (s n ), (3) and authenticates the packets that were sent in timeslot n. TESLA Certificates In [2], the authors described necessary conditions for achieving asymmetric properties with TESLA, and outlined the construction of a PKI based on TESLA. We now formalize the application of TESLA to form a TESLA-based PKI. Specifically, we introduce a new type of certificate that uses TESLA instead of public key cryptography. In ig. 1, we present the entities involved in TESLA certificates, and the steps involved in using TESLA certificates. Much like conventional public key certificates, we have a certificate authority CA, who is responsible for creating the certificates for entity B. A low-powered device, depicted by D, will contact B to use its service. Initially, the CA has established a key K CA,B that it shares with B. The steps involved in TESLA certificates are: 1. The CA periodically issues TESLA certificates for B. During time slot n, the certificate authority (CA) doesn t sign the TESLA-certificate with its private key, but uses the non-disclosed TESLA key tk CAn to create a MAC that is included in the certificate. The subject B s public key is replaced by the subject s authentication key ak Bn, which is encrypted by the CA using the same TESLA key tk CAn. Cert CAn (B) = (ID B, (4) {ak Bn } tkcan, n + d, MAC tkcan (...)) Here n + d indicates the TESLA certificate s expiration date. The certificate is sent to B along with the matching authentication key ak Bn : CA B : (5) (Cert CAn (B), {ak Bn } KCA,B, MAC KCA,B (...)). 2. Sometime between time n and n + d, D contacts B requesting to use B s service, D B : (request). (6) 3. ollowing the request in step 2, B must prove its identity to node D. B sends an authentication packet, which consists of the TESLA certificate and a MAC that was created using B s authentication key ak Bn : B D : (Cert CAn (B), MAC akb n (request)). Upon receiving the authentication packet, D measures the freshness of the certificate by checking the timestamp of Cert CAn (B) to make sure that it has arrived before time n + d, when the CA announces tk CAn. If Cert CAn (B) is fresh, D buffers the authentication packet. 4. The CA discloses its TESLA key tk CAn at time n + d. Upon receiving tk CAn, D checks the authenticity of the TESLA certificate by checking MAC tkca, then it decrypts n B s authentication key ak Bn and checks MAC. User akb n D is able to certify the identity of B as long as it receives the TESLA certificate Cert CAn (B) before time n+d, when the CA reveals the TESLA key T K CAn. The lifetime of a TESLA-certificate is short. It depends on the disclosure time of the TESLA key that the certificate authority used when creating the MAC and encrypting the subject s authentication key. Choosing a key that will be disclosed soon, lowers the delay in the authentication process at node D, but results in increased overhead when issuing new certificates. The tradeoff between delay and overhead is a critical issue for further study. AN APPLICATION O TESLA CERTIICATES We now apply TESLA certificates to the problem of maintaining authentication during handoff in a mobile network.

3 Algorithm: Mobile node handoff at time n Result : Authenticity and a shared secret K B,D between the senor node D and the new access point B 1 B D : (apho, Cert CAn (B ), MAC akb n (...)) 2 D B : (apho, Cert CA (D), MAC akap,d (...)) 3 B D : (hook, {K B,D} akap,d, MAC akb n (...)) Algorithm 1: Mobile Node Handoff. Consider a network of access points B, and low-powered nodes D. The access points provide the service of forwarding information from the low-powered nodes to an application connected to the Internet. urther, assume that there is a certificate authority CA that is able to communicate with all nodes on the network. Initially, D communicates securely with an access point B using a shared key K B,D. Suppose that the CA gives a conventional (public key) certificate to D of the form Cert CA (D) = (7) (ID D, {ak AP,D } gkap, T S A, SIGN KCA (...)). The certificate contains D s ID, a timestamp T S A and a symmetric authentication key ak AP,D that will allow D to communicate with any access point. The key ak AP,D is given to D via a secure channel during initialization. urther, ak AP,D is encrypted with a key, gk AP, which has been given to every access point of the network by the CA. The signature SIGN KCA (...) proves that this certificate is issued by the certificate authority. We emphasize that D never has to verify SIGN since this is his own certificate, and therefore D does not incur the computational complexity associated with public key signature verification. Now suppose that D moves and is no longer within range of B, but instead within range of B. Since D has moved to a new access point, it must certify the identity of B, as well as establish a new shared key K B,D. In order for D to authenticate B, it contacts B by sending a request for an access point handoff (apho). In response, B sends D its TESLA certificate Cert CAn (B ) for time n, and a MAC that will be used by D to verify the identity of B after the CA reveals the TESLA key. Next, D answers with its own certificate and a MAC that it creates using its authentication key ak AP,D. B will then send to D the new key K B,D that is encrypted using ak AP,D, which B had obtained from D s certificate Cert CA (D). Using ak AP,D, D can obtain the new key K B,D. However, before D can check B s identity, it has to wait until the CA publishes the TESLA key tk CAn during time slot n + d. Once D receives that key, D can check B s certificate and confirm the identity of B. Subsequently, D may resume sending its data to the application by securely sending its data to B using K B,D. PERORMANCE ISSUES There are two performance issues that we now discuss: computation and delay. Computation We have conducted an initial evaluation the amount of time required for a 4096-bit message authentication using SHA-1, and for 2048-bit RSA signing using the libtomcrypt library[8]. Using gprof on a Pentium-4 2GHz Linux machine, we measured that SHA-1 required an average of 46 milliseconds to perform, while RSA signing required an average of 2.26 seconds to perform. Although this platform is not the same as a typical mobile device, the timing measurements do allow us to estimate that the RSA operation requires roughly 4900 times more power than performing SHA-1. This suggests the computational savings available when using TESLA certificates. In our mobile node handoff protocol, we have allocated the computational load in a manner suited to each device s capabilities. Specifically, we have not burdened the mobile nodes with public key operations. Instead, due to their use of TESLA certificates, the mobile nodes use computationally efficient MACs to perform authentication. On the other hand, we have placed more computational burden upon the higher-powered access points by requiring them to perform public key cryptographic operations associated with the conventional PKI certificate. We are currently studying the use of TESLA and TESLA certificates for wireless sensor networks, and plan to conduct a more thorough estimation of power consumption on Cerfcubes [9], which is the sensor node device planned for our testbed. We note that although TESLA certificates reduce the amount of computation performed, this might not necessarily result in extended battery-life since, for many wireless devices, transmitting and receiving packets are costly operations. A careful analysis of the tradeoff between communication costs and computational costs for typical entity authentication services that will occur on wireless devices should be performed. Reducing Delay via Partial Authentication It has been observed that one drawback of the TESLA protocol is delay. The very property which provides the asymmetry necessary for authentication, also introduces two new issues. irst, many applications are inherently delaysensitive and cannot tolerate delay at the sender or at the receiver. Voice over Internet Protocol (VoIP) applications are a prime example of this, where even short delays significantly affect the perceived quality of service. Second, since TESLA involves buffering, it provides an adversary an easy avenue for performing a denial-of-service (DoS) attack.

4 An adversary may simply send false data to a receiver in order to fill the receiver s authentication buffer, causing newly arriving packets to be dropped. In [3], several modifications are proposed for the TESLA multicast authentication scheme. Reducing the authentication delay was considered an important issue for improving TESLA, and the authors present a scheme where receiver buffering is traded-off at the expense of source buffering. Rather than off load the buffering to the source, we propose to exploit a possibility in the authentication buffer at the receiver. Our basic approach to the problem of reducing the delay in TESLA is similar to the concurrent TESLA scheme presented in [3]. The concurrent TESLA approach was originally intended for allowing different receivers to authenticate packets according to different delays, while requiring less additional communication overhead than conventional TESLA. The method that we are about to describe differs from the concurrent TESLA scheme in its motivation and implementation. Rather than allow different users to completely authenticate packets at different delay times, as in the concurrent TESLA scheme, we propose to make use of multiple staggered keys in the delayed key disclosure so that packets may be partially authenticated prior to the disclosure of the appropriate authentication key. The use of partial authentication is a potentially powerful tool as it provides intermediate security levels between the extremes of not-authenticated and fully authenticated. These intermediate security levels can allow for new application-level security policies to be developed. As an example, consider a multimedia application in which media packets have a QoS delay requirement. As packets arrive, they are put in the staggered TESLA authentication buffer. If, at a certain time, the application deems that the service quality delivered to the user is not acceptable, the application will release packets that are partially authenticated in order to improve the delivered quality. An application-level security policy for releasing partially authenticated data should describe what level of partial authentication is allowed for improving QoS. In spite of the similarities with the concurrent TESLA scheme, and for the sake of clarity, we shall refer to the proposed method as staggered TESLA. As in TESLA, we start with a chain of keys or seeds that are related by application of a one-way function, namely s l sl 1 sl 2... s1 s0. (8) These seed values are used to derive the TESLA authentication keys by applying a one-way function as in s n tk n. (9) Time is again slotted into intervals, that are indexed according to the time variable i. We denote a data packet for time i by M i. We note, however, that this leads to ambiguity when referring to multiple data packets that are being created by a igure 2. TESLA. A queue chain for the receiver in staggered source during time interval i. We have chosen not to add extra labelling to remove this ambiguity for the sake of simplicity of exposition. inally, the TESLA seed s i will be disclosed at a later time i+d according to the maximum network delay needed for all receivers to receive a packet sent at time i, as in the standard TESLA protocol[1]. Now, as in TESLA, during time i, the data message M i will have authentication information appended to it in order to form the transmitted packet P i. However, unlike TESLA, multiple message authentication codes will be appended. These MACs will use L of the TESLA keys. or example, P i would be P i = [M i MAC tki (M i ) MAC tki 1 (M i ) (10) MAC tki L 1 (M i )]. We note that it is not necessary that the different MACs have the same length. This fact can be exploited to reduce the size of the packet P i if needed. ollowing the formation of P i, it is sent out on the network. In a normal TESLA scheme, the seed s i would be disclosed at time i + d, and packets from time i could not begin the authentication process until after i + d. However, by using multiple MACs, we introduce a type of memory into the authentication process and can begin authentication prior to disclosure of s i. or the staggered TESLA scheme, the receiver s buffer is altered from a conventional buffer into a sequence of queues. We have depicted such a chained buffer for L = 3 in ig. 2. The receiver puts the packet P i into the top level of the queue, and waits for the seed s i 2 to arrive so it can calculate tk i 2. After calculating tk i 2, the packet is tested for authenticity by verifying MAC tki 2 (M i ). If this verification fails, the packet is dropped from the queue, while if it passes, the packet is partially authenticated and graduates to the next layer of the buffer. This layer waits for s i 1 to arrive before it can test P i. Again, the packet is either dropped or graduated to the next layer of the queue. This process repeats through the seeds and TESLA keys until tk i is used for the final, and complete, authentication of P i.

5 The advantage of the staggered TESLA scheme is that a receiver does not have to wait for the seed s i to be revealed in order to start authenticating packets. Instead, the receiver can use whatever TESLA keys he has received in order to begin the authentication process and remove possibly bogus packets, such as those involved in a DoS attack. We noted earlier that the size of the MACs do not have to be the same. In fact, since one of our goals is to provide a filter to remove false packets before s i is revealed, we can choose the size of MAC tki L 1 to be small. or example, assuming ideal mixing behavior of the MAC, taking MAC tki L 1 to be only a single bit would mean that an adversary with no knowledge of the true tk i L 1 would only have a 50% chance of forgery, or a MAC of two bits would mean an adversary would only have a 25% chance of forgery. Next, suppose an adversary is a member of the multicast group. It is possible for the adversary to receive a seed, say s i j, and use this to forge portions of P i. This will allow the forged packet to pass the first few authentication tests in staggered TESLA. Ultimately, however, a packet forged for time i by a member of the multicast group must be tested using tk i, which is guaranteed to fail since s i is released according to the maximum network delay condition described in the original TESLA protocol. Therefore, rather than have d intervals of time available for performing a DoS attack, an adversary who is a member of the group has strictly less than d time intervals to fill the target receiver s buffer. Thus, staggered TESLA appears to provide some advantage against a DoS attack as it requires an internal adversary to attempt a DoS at a higher attack data rate than he would have had to employ against conventional TESLA. The selection of L, along with the size of the MACs that are employed, depends on the security requirements and the network conditions. An interesting direction for further investigation that we plan to explore is the appropriate determination of L based upon minimum network delay (the minimum delay from the source to each receiver), as well as the underlying network topology and routing information. As a final note, we discuss how staggered TESLA can be used in TESLA certificates. Since staggered TESLA allows for partial authentication, it also provides a mechanism for partially authenticating TESLA certificates. This partial authentication is useful for removing false certificates before key disclosure. urther, it also allows for partial entity authentication, in which an entity may be given progressively higher levels of access as his certificate becomes more authenticated. CONCLUSION In this paper we have introduced an alternative to conventional public key certificates that is based upon symmetric key cryptography and the principles of delayed key disclosure. The work formalizes concepts presented in earlier work on TESLA by introducing a new certificate framework, which we call TESLA certificates. TESLA certificates rely upon a tradeoff between computation and authentication delay in order to achieve a certificate infrastructure that reduces computational complexity associated with certificate verification when compared with traditional public key infrastructure certificates. We applied TESLA certificates to the problem of maintaining authentication during handoff in a generic mobile network. We discussed two basic types of performance issues: computation and delay. urther, we introduced a modification to the TESLA protocol that provides partial authentication of multicast data. Unlike the concurrent TESLA schemes proposed earlier, our staggered TESLA allows for partial authentication of data, which makes it harder for an adversary to perform a denial-of-service attack, and also allows for partial authentication in TESLA certificates. inally, we note that further investigation needs to be done to examine the tradeoff between computation and communication, and the resulting effect each has upon battery consumption in order to determine the suitability of TESLA certificates for networks of mobile devices. ACKNOWLEDGEMENTS The authors would like to thank Adrian Perrig for referring them to the discussion of TESLA, and the outline of a PKI based on TESLA in [2]. REERENCES [1] A. Perrig, R. Canetti, B. Brisco, D. Song, and D. Tygar, TESLA: Multicast source authentication transform introduction, IET working draft, draft-ietf-msec-tesla-intro-01.txt. [2] A. Perrig, R. Canetti, J.D. Tygar, and D. Song, The TESLA broadcast authentication protocol, in RSA Cryptobytes, [3] A. Perrig, R. Canetti, D. Song, and J.D. Tygar, Efficient and secure source authentication for multicast, in Proceedings of Network and Distributed System Security Symposium, ebruary [4] P. R. Zimmermann, The official PGP user s guide, MIT Press, [5] ITU-T, The directory: authentication framework, IT - Open Systems Interconnection. [6] S. Cheung, An efficient message authenticaiton scheme for link state routing, in Proceedings of 13th Annual Computer Security Applications Conference, [7] R.J. Anderson,. Bergadano, B. Crispo, J.H. Lee, C. Manifavas, and R.M. Needham, A new family of authentication protocols, Operating Systems Review, vol. 32, no. 4, pp. 9 20, [8] Libtomcrypt, [9] Intrinsyc product page,