From jsy6@cornell.edu Wed Oct 16 23:12:29 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9H3CSh23768 for ; Wed, 16 Oct 2002 23:12:28 -0400 (EDT) Received: from mengr4m5 (dhcp98-99.cs.cornell.edu [128.84.98.99]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id XAA03163 for ; Wed, 16 Oct 2002 23:12:28 -0400 (EDT) Message-ID: <000801c2758b$001ed600$63625480@cs.cornell.edu> From: "Janet Yoon" To: Subject: 615 PAPER 39 Date: Wed, 16 Oct 2002 23:12:17 -0400 MIME-Version: 1.0 X-Security: MIME headers sanitized on sundial.cs.cornell.edu See http://www.impsec.org/email-tools/sanitizer-intro.html for details. $Revision: 1.132 $Date: 2001-12-05 20:20:17-08 X-Security: The postmaster has not enabled quarantine of poisoned messages. Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C27569.785A60C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C27569.785A60C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These papers deal with the security issues in sensor networks. SPINS = provide the building blocks of creating security applications in a = resource-constrained wireless environment. It consists of two parts: = SNEP and uTESLA. SNEP provides data confidentiality, 2-party = authentication, and data freshness with low overhead by relying on a = shared counter and a message authentication code (MAC). The second = security primitive, uTESLA provides authenticated broadcast via multiple = phases: sender setup, broadcasting authenticated packets, bootstrapping = a new receiver, and authenticating packets. These two building blocks = are designed for three specific communication patterns: node to node, = base to node, and base to all nodes. They can be adapted for node to = node and node broadcast. SNEP and uTESLA can also be used to build = higher applications such as authenticated routing and 2-party key = agreement protocol. Some limitations of SNEP is that it does not = address info leaks through convert channels, it does not fully deal with = compromised nodes (it only guarantees security if at most one node is = compromised), it does not protect against denial of service attacks, and = it only achieves authentication, not non-repudiation. =20 =20 Ariadne (A secure on-demand routing protocol for Ad Hoc Networks) = provides security in face of compromised nodes and prevention of the = following denial of service attacks: routing disruption and resource = consumption. Like SPINS, Ariadne is based on efficient symmetric = cryptographic primitives. The on-demand routing protocol is based on = that of DSR and the broadcast authentication protocol used is TESLA. = Limitations of Ariadne are that it assumes that links are bi-directional = and it ignores attacks on the Medium Access Control protocols. Also, = the key set up assumes a secure Key Distribution Center. Safety from = compromised nodes is dependent on reliable broadcasting. ------=_NextPart_000_0005_01C27569.785A60C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

These papers deal with the security issues in = sensor=20 networks. SPINS provide = the=20 building blocks of creating security applications in a = resource-constrained=20 wireless environment. It = consists=20 of two parts: SNEP and uTESLA. = SNEP=20 provides data confidentiality, 2-party authentication, and data = freshness with=20 low overhead by relying on a shared counter and a message authentication = code=20 (MAC). The second = security=20 primitive, uTESLA provides authenticated broadcast via multiple phases: = sender=20 setup, broadcasting authenticated packets, bootstrapping a new receiver, = and=20 authenticating packets. = These two=20 building blocks are designed for three specific communication patterns: = node to=20 node, base to node, and base to all nodes. =20 They can be adapted for node to node and node broadcast. SNEP and uTESLA can also be = used to=20 build higher applications such as authenticated routing and 2-party key=20 agreement protocol. Some=20 limitations of SNEP is that it does not address info leaks through = convert=20 channels, it does not fully deal with compromised nodes (it only = guarantees=20 security if at most one node is compromised), it does not protect = against denial=20 of service attacks, and it only achieves authentication, not=20 non-repudiation. =

Ariadne=20 (A secure on-demand routing protocol for Ad Hoc Networks) provides = security in=20 face of compromised nodes and prevention of the following denial of = service=20 attacks: routing disruption and resource consumption. Like SPINS, Ariadne is based = on=20 efficient symmetric cryptographic primitives. The on-demand routing protocol = is based=20 on that of DSR and the broadcast authentication protocol used is TESLA.=20 Limitations of Ariadne are that it assumes that links are bi-directional = and it=20 ignores attacks on the Medium Access Control protocols. Also, the key set up assumes a = secure=20 Key Distribution Center. = Safety=20 from compromised nodes is dependent on reliable broadcasting. =20

------=_NextPart_000_0005_01C27569.785A60C0-- From nbs24@cornell.edu Thu Oct 17 00:24:55 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9H4Osh07465 for ; Thu, 17 Oct 2002 00:24:54 -0400 (EDT) Received: by travelers.mail.cornell.edu (8.9.3/8.9.3) id AAA22947; Thu, 17 Oct 2002 00:24:51 -0400 (EDT) Date: Thu, 17 Oct 2002 00:24:51 -0400 (EDT) From: nbs24@cornell.edu Message-Id: <200210170424.AAA22947@travelers.mail.cornell.edu> To: egs@CS.Cornell.EDU Errors-To: nbs24@cornell.edu Reply-To: nbs24@cornell.edu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9 Sender: nbs24@cornell.edu X-Originating-IP: 64.185.145.94 Subject: 615 PAPER 39 SPINS The goal of SPINS is to provide a strong cryptography in spite of limited memory size and limited power supply. Their network consists of base stations and network nodes. Their design assumes broadcast over RF links, with base stations having longer battery life than network nodes. A network node can broadcast to a base station and vice versa. Also, a base station can broadcast to all nodes. The trusted elements are base stations and nodes of themselves. The design goals are to obtain data confidentiality, authentication, integrity and freshness. The concepts of weak freshness (provision of partial message ordering without delay information) and strong freshness (provision of total order on a request-response pair, with delay estimation) are introduced. The authors propose SNEP (the first security building block) which provides low communication overhead, achieves semantic security, and provides data authentication, replay protection and weak message freshness. SNEP precedes a message with a random bit string before encryption to prevent an attacker from inferring plaintext of encrypted messages. SNEP uses a counter shared between the sender and receiver to ensure above without having to send the random data over the RF channel. uTESLA, the second security building block, provides authenticated broadcast through a delayed disclosure of symmetric keys. They show that communication and energy overhead is minimal in their implementation while leveraging existing hardware. They do not consider the effect of information leakage from covert channels, compromised sensors and denial of service networks on their protocol. Ariadne Ariadne is a secure on-demand (based on DSR) ad hoc networking protocol. The goal here is to design a simple and efficient mechanism for achieving high attack robustness. The authors present several attack scenarios under the broad categories of routing disruption attack, where attacker attempts to cause legitimate data packets to be routed in dysfunctional ways, and resource consumption attacks, where attacker injects packets into the network in an attempt to consume valuable resources such as bandwidth, memory and power. The paper describes possible attacks such as routing loops, black holes, gray holes, network partitioning, blackmail and rushing attacks. Routing messages are authenticated using one of three schemes: shared secrets between each pair of nodes (MAC), shared secrets between communicating nodes combined with broadcast authentication (TESLA) or digital signatures. It is assumed all links are bidirectional and all nodes are loosely synchronized. It is also assumed that the sender trusts the receiver. Ariadne’s limitations also include the assumption that the physical layer is not vulnerable to attacks. From mr228@cornell.edu Thu Oct 17 04:31:17 2002 Received: from cornell.edu (cornell.edu [132.236.56.6]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9H8VGh21570 for ; Thu, 17 Oct 2002 04:31:16 -0400 (EDT) Received: from cornell.edu (syr-24-58-48-238.twcny.rr.com [24.58.48.238]) by cornell.edu (8.9.3/8.9.3) with ESMTP id EAA16173 for ; Thu, 17 Oct 2002 04:31:15 -0400 (EDT) Message-ID: <3DAE758A.38D3758@cornell.edu> Date: Thu, 17 Oct 2002 04:32:10 -0400 From: Mark Robson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Both of the papers discuss security in networks with power constrained nodes. The main restriction this imposes is the inability to use public-key cryptography. SPINS consists on two parts: SNEP and uTESLA. SNEP provides data confidentiality, 2-way authentication, and data freshness (this requires clock syncronization within some small threshold). A shared counter is used and combined with MACs to produce a system relying only on shared key cryptography. uTESLA allows authenticated broadcast. There may be D.O.S. attacks that SPINS is susceptible to -- the paper fails to mention them. Ariadne is largely the same as SPINS. It also uses only symmetric key crypto and builds on TESLA. The major limitation here is the reliance upon a secure (and obviously trusted) KDC. Both protocols have the limitation of either needing the nodes to be given shared keys apriori or a KDC to distribute keys, except you can't distribute keys over the protocol until the protocol channels are secure. There are also concerns over what to do once the initial symmetric key is compromised. Both papers assume some degree of node synchronization. From xz56@cornell.edu Thu Oct 17 04:32:50 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9H8Wnh22364 for ; Thu, 17 Oct 2002 04:32:49 -0400 (EDT) Received: from XIN (dhcp99-16.cs.cornell.edu [128.84.99.16]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id EAA03460 for ; Thu, 17 Oct 2002 04:32:48 -0400 (EDT) Message-ID: <006a01c275b7$c552d440$10635480@XIN> From: "Xin Zhang" To: "Emin Gun Sirer" Subject: 615 PAPER 39 Date: Thu, 17 Oct 2002 04:32:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 SPINS mainly deals with data security with respect to data transmission over the wireless networks, while Ariadne is a secure routing protocol. Since both of them aim at solving the security problem specially caused by broadcast, they are all based on TESLA, a protocol for authenticated broadcast and adapt it for systems where computing power is limited. TESLA uses symmetric primitive, but achieves asymmetry which is required by broadcast authentication by using clock synchronization. Based on loose synchronization, EACH node divides time into units, estimates the transmission time and chooses the key for the approximate time that receiver will get the packet. The keys are generated in a one-way chain and the receiver checks it in basically same as it's generated, thus achieve authentication. SPINS has two components: SNEP transforms each bit into a random string (much like CDMA) which avoids eavesdrop but incur higher data rate. It compensates it by using shared counter between sender and receiver to get rid of counter from the msg. However, it seems to me this shared counter can't be as reliable. SNEP provides secure data. Another component, uTESLA, adapts TESLA for sensor network by restricting # of authenticated senders and sending and receiving key per unit time (with some delay because nodes are not strictly synchronized) instead of per packet. Since the alignment of packets' transmission introduces delay, the services should be the types allowing this, such as data collection, but not on-time communication. Ariadne is basically a secured version of DSR. It applies TESLA to routing info exchange hop-by-hop, so thwarts the attacks like forged requests, forged error, contaminated packets, etc. From shafat@CS.Cornell.EDU Thu Oct 17 05:31:39 2002 Received: from exchange.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9H9Vdh02391 for ; Thu, 17 Oct 2002 05:31:39 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: 615 PAPER 39 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 17 Oct 2002 05:31:39 -0400 Message-ID: <47BCBC2A65D1D5478176F5615EA7976D134FAD@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 39 Thread-Index: AcJ1v/62SF/1/HcSSU2tLvRhEZhZJQ== From: "Syed Shafat Zaman" To: "Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sundial.cs.cornell.edu id g9H9Vdh02391 These two papers deal with security concerns in wireless networks. The first paper presents a set of security protocols called SPINS. It allows sensor networks to implement security protocols in resource constrained wireless environments, which makes it particularly useful for numerous practical applications. SPINS has two major components: SNEP (Sensor Network Encryption Protocol) and micro-TESLA. SNEP provides functionalities like data confidentiality, two-party authentication, data integrity and data freshness based on a counter, a master key from which all other keys can be derived and a message authentication code (MAC). micro-TESLA, on the other hand, is a toned-down version of the authenticated broadcast protocol TESLA and is specifically designed to run on sensor networks. It is based on asymmetric cryptographic mechanisms that allows nodes to authenticate the sender of data packets. The paper also describes how SPINS was implemented, and the data is evaluated to reflect its effectiveness in sensor networks. The second paper talks about a secure on-demand routing protocol for ad hoc networks, known as Ariadne. It first talks about a general class of malicious attacks that an ad hoc network may have to bear, and proposes various ways to avoid them by specifying design goals of Ariadne. It is primarily based on DSR to implement the routing part of the protocol, and relies on TESLA to secure the network by authenticating routing messages. The paper also, however, presents two other ways of data authentication that Ariadne can be used with: digital signatures and message authentication codes (MACs). Since Ariadne is based on DSR, it dynamically discovers nodes, and only when needed, and authenticates with the help of TESLA each packet it receives. The system has been simulated on ns2, and quite surprisingly, the extra overhead of adding these security mechanisms to DSR does not affect the performance of Ariadne when compared to the unoptimized version of DSR. In fact, with some metrics, it does better. SPINS could be employed in a highly sensitive environment where any sort of malicious attack could have a huge impact. One such scenario is the sensors in a nuclear power plant for example. If the network is tampered with, or if the sensors fail to send their readings to the central monitoring station, an attacker could easily make the whole system partially, if not fully, obsolete. From tmroeder@CS.Cornell.EDU Thu Oct 17 09:57:49 2002 Received: from dhcp98-88.cs.cornell.edu (dhcp98-88.cs.cornell.edu [128.84.98.88]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HDvnh01757 for ; Thu, 17 Oct 2002 09:57:49 -0400 (EDT) Received: (from tmroeder@localhost) by dhcp98-88.cs.cornell.edu (8.11.6/8.11.6) id g9HDu3A25263; Thu, 17 Oct 2002 09:56:03 -0400 From: Thomas Roeder MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15790.49523.153499.488047@dhcp98-88.cs.cornell.edu> Date: Thu, 17 Oct 2002 09:56:03 -0400 To: Emin Gun Sirer Subject: 615 PAPER #39 X-Mailer: VM 7.07 under Emacs 21.2.1 The SPINS protocol seeks to provide a pair of authentication protocols for sensor networks which are severely resource constrained. SNEP looks to symmetric-key algorithms to save space on the minute devices they use and to provide data freshness via an ACK-ing mechanism. (ie the sender knows that the receiver sent the response after receiving the given packet). micro-TESLA tries to provide authenticated broadcast using a one-way function to verify keys which are disclosed after a certain interval. Both protocols are highly optimized to run on tiny processors, and seek to minimize the amount of computation as well as transmission required to authenticate effectively. The first complete question is, "What are the types of secure services one could build using SPINS ? Is it sufficient for the types of secure operations one may want to do ?" The obvious types of applications involve measurements in a well-controlled location (they use for example, their building), where the only common possible type of malicious interference comes in the air. In other words, physical compromise of the nodes is not a major concern. Since physical compromise of the nodes in SPINS would lead to disclosure of at least one key, it could be used to send incorrect data to the base stations, which is worse than having the node fail through lack of power. Furthermore, since it relies heavily on the existence of base stations with real computing power, it is not deployable in truly hostile environments, where there is no guarantee of having deployed a base station within communication reach. (this might occur in battlefield situations, for example, where one would like to distribute the nodes from a distance) As a side note for Ariadne, I think that it is a strange name for a security protocol, since Ariadne herself was not one who blocked an attack, but, on the contrary, facilitated discovery (of the path out of the Minotaur's maze). Ariadne seeks to provide a secure ad-hoc routing protocol (ie. untarnished routes are immune from attack), and block many types of DoS attacks. It uses DSR and TESLA (for broadcast authentication). They disregard physical-layer jamming as a DoS attack, citing other work which they claim avoids it. They also disregard MAC-layer attacks, although they give no solution for avoiding them. They wish to support all type of nodes. Their Key Distribution Center, however, takes them out of the realm of ad-hoc wireless, and requires them to be in a relatively controlled environment, at least any time they must do any key setup. The other question we need to answer today is "What are the limits of Ariadne's secure routing?" As stated above, they ignore a significant number of parameters, any of which would allow a large class of attacks to be executed. Further, the attacker which owns a cut of the network can arbitrarily lie about the events on the other side of the cut, and thus avoid detection by the good nodes on either side of the network. From kwalsh@CS.Cornell.EDU Thu Oct 17 10:19:22 2002 Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HEJMh06160 for ; Thu, 17 Oct 2002 10:19:22 -0400 (EDT) Received: from localhost (curly.cs.duke.edu [152.3.140.76]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA11659 for ; Thu, 17 Oct 2002 10:19:21 -0400 (EDT) From: kwalsh@CS.Cornell.EDU Received: from 132.236.29.65 ( [132.236.29.65]) as user walsh@imap.cs.duke.edu by login.cs.duke.edu with HTTP; Thu, 17 Oct 2002 10:19:21 -0400 Message-ID: <1034864361.3daec6e984c0f@login.cs.duke.edu> Date: Thu, 17 Oct 2002 10:19:21 -0400 To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 132.236.29.65 SPINS: Security Protocols for Sensor Networks SPINS proposes two “building blocks” for secure mobile networks. The SNEP mechanism provides data confidentiality (data can be read only by the intended receiver), data authentication (data with an implied sender can only be sent by the implied sender), data integrity (the received data was not altered during transmission), and both weak and strong freshness (partial ordering on received messages, and total ordering on request/response pairs). The mechanism achieves these properties by using symmetric encryption (DS5), with shared keys. The intended communication pattern is between a single node and a base station. This limitation arises from the need for pair-wise shared keys, and a significant amount of shared state. The mechanism could also be used for node- to-node communication given a key distribution mechanism, such as using a common trusted base station during call initiation. The main problem arising from SNEP appears to be the shared message counter value. This seems difficult in the face of unreliable wireless communication, especially since messages are often reordered as well as dropped. Further, the shared counter value can hardly be called a secret, since it increments in a very predictable and observable manner. uTesla provides a base-station to all nodes authenticated broadcast. Essentially, the base station pre-generates a key for all future epochs, disclosing the keys only after some number of epochs have past. If nodes have loosely (bounded skew) synchronized clocks and are assured of receiving messages in a bounded amount of time, each can then infer the current epoch, wait for the key disclosure, and then verify the key using a previously shared initial key. Clock synchronization seems to be a downfall, as well as the assumption that messages are delivered in bounded time. Further, messages cannot be authenticated (or even read) until several epochs have passed. Many of these limitations come from SPINS overriding goal of using as little memory and computation as possible (a questionable goal, as Gun points out). I have trouble imagining the types of sensor networks in which SPINS would be applicable. In our previous examination of nested-queries, aggregation, and intelligent queries, nodes need to communicate much more frequently with each other than with a dedicated base station. SPINS essentially blocks any possibility of data aggregation, triggered devices, etc., by interposing a trusted central base station. SPINS also seems to require a good deal of initial setup. If the base station fails, or a new base station introduced, do all sensors have to be reprogrammed? And if so, does this introduce the possibility of an adversarial base station taking over the network? From bd39@cornell.edu Thu Oct 17 10:54:33 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HEsXh14744 for ; Thu, 17 Oct 2002 10:54:33 -0400 (EDT) Received: from boweilaptop.cornell.edu (dhcp-128-84-93-38-wifi.ece.cornell.edu [128.84.93.38]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id KAA20760 for ; Thu, 17 Oct 2002 10:54:31 -0400 (EDT) Message-Id: <5.1.0.14.2.20021017105233.00bdfb88@postoffice2.mail.cornell.edu> X-Sender: bd39@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 10:52:55 -0400 To: egs@CS.Cornell.EDU From: Bowei Du Subject: 615 PAPER 39 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed SPINS This paper is the first paper we have read concerning security in Ad-hoc sensor networks. This paper introduces 2 primitives, SNEP, which provides data authentication, confidentiality and freshness and mu Tesla, which provides authentication broadcast. The enviroment in which these protocols run a) nodes are extremely resource limited b) nodes communicate with Base Stations which have plentiful computational resources. Base Stations also immediatedly trusted element of this system and distribute a single shared key to nodes in its vicinity. SNEP - Messages are encrypted with a counter or nonce (with the shared master key), preceded by random number to ensure authentication and freshness of the data. It seems that the main advantage of this new protocol is the small size of the encryption header (8 bits + random number preceding the packet.) mu Tesla - Base station broadcasts are encrypted with a secret key that is revealed in a subsequent broadcast. Keys originating from the basestation are computed through a 1-way generator function. Time synchronization between the base station and sensor maintain a key disclosure schedule. Key from future time intervals are used to validate keys from previous time intervals. Issues - What if nodes go down and come back up? Then how can they join this network? What prevents adversaries from a DoS attack with the timed key disclosure schedule by replaying broadcasts to nodes that haven't heard it. (Broadcasts not instantaneous.) What if a sensor was compromised? (this can easily happen, especially out in the field). Original distribution of the master key seems like an issue that needs to be solved. From adam@graphics.cornell.edu Thu Oct 17 11:29:50 2002 Received: from bach.graphics.cornell.edu (bach.graphics.cornell.edu [128.84.247.50]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFToh23127 for ; Thu, 17 Oct 2002 11:29:50 -0400 (EDT) Received: from envy.graphics.cornell.edu (envy.graphics.cornell.edu [128.84.247.206]) by bach.graphics.cornell.edu (8.12.1/8.12.1) with ESMTP id g9HFTf0k040783 for ; Thu, 17 Oct 2002 11:29:41 -0400 (EDT) Date: Thu, 17 Oct 2002 11:29:26 -0400 (EDT) From: Adam Kravetz To: egs@CS.Cornell.EDU Subject: cs615 paper 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS: The idea behind SPINS is to build as lightweight as possible a secure transmission protocol. It's main contribution is being able to provide Data confidentiality, two-party data authentication, and data freshness. It also hopes to provide data broadcast security for "extremely constrained network environments". Security is a question which all devices and methods of communications must face. A sensor needs to take this into consideration, but not sacrifice speed, mobility, lifespan, flexibility at too much of an expense. SPINS consists of two parts first SNEP and then uTESLA. SNEP's purpose is to ensure data confidentiality, authentication, integrity and freshness while minimizing overhead. It exploits MAC (Message Authentication Code) attributes to do most of this work. SPINS could be applied in the obvious way to ensure that your sensor's data is not being "picked up" by any nearby listeners. The implementation however leaves lots to be desired. The size of the devices used is relatively unrealistic by todays standards. We could certainly imagine a much more heavyweight (processor, ram, battery) setup that would be just as portable, although the goal of lightweight (in resource consumption) and robust security is still relavant. ARIADNE: Ariadne's biggest contribution is an implemention of an ad-hoc protocol to deal w/ secure routing. It also formalizes the many kinds of ad-hoc network attacks that one can be subjected to. Ariadne uses symmetric cryptography (like SPINS it stays away from RSA or Diffie-Hellman for efficiency over security reasons) to accomplish its tasks and uses an extended DSR to act as a base routing protocol. Ariadne's goal is to prohibit or stop many different kinds of DoS attacks in which is could be subjected to. It suffers however a huge weakness (or one that most basic symmetric security ideas have) that there is a need for some sort of non-secure, secret sharing external of this system. Using digital sigs, TESLA or pairwise shared secrets some sort of mechanism needs to help setup this system. From hs247@cornell.edu Thu Oct 17 11:40:16 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFeGh25445 for ; Thu, 17 Oct 2002 11:40:16 -0400 (EDT) Received: by travelers.mail.cornell.edu (8.9.3/8.9.3) id LAA07424; Thu, 17 Oct 2002 11:40:13 -0400 (EDT) Date: Thu, 17 Oct 2002 11:40:13 -0400 (EDT) From: hs247@cornell.edu Message-Id: <200210171540.LAA07424@travelers.mail.cornell.edu> To: egs@CS.Cornell.EDU Errors-To: hs247@cornell.edu Reply-To: hs247@cornell.edu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: IMP/PHP3 Imap webMail Program 2.0.9 Sender: hs247@cornell.edu X-Originating-IP: 128.84.99.213 Subject: 615 Paper 39 In this set of papers we look at two security protocols for wireless networks. SPINS is a security protocol that was designed and implemented for sensor networks, while Adriadne was designed for on-demand routing protocols (more specifically DSR). SPINS introduces 2 secure building blocks. SNEP is a secret key protocol which only adds 8 bytes per message. It provides Semantic security by secret key encryption, Data authentication with MAC (digital signature) and uses a counter to do replay protection. The problem with using a counter is that state has to be maintained on each node. If the base node somehow goes down, it is hard to recover. Maintain state also makes it vulnerable to denial of service attacks. SNEP can only be used for node to node communication because all nodes have knowledge of the MAC. uTESLA was also introduced. It is a scaled down version of TESLA (with key disclosure per epoch, restrictions on the number of senders and uses symmetric mechanisms instead of digital signatures). uTESLA allows authentication of broadcast messages. Adriadne tries to address the problems of security in an ad-hoc routing protocol. It introduces three methods of authentication: TESLA, digital signatures, and MACs. They claim that DSR is particular good for security reason because the source can decide whether or not to trust nodes (and therefore routes). You can use digital signatures to authenticate route requests, use MACS for Route replies, and TESLA for broadcasts. TESLA can be used to filter out malicious attackers that try to flood the network. Combined with TESLA, Adriandne can use “Route discovery chains” which can authenticate route discovery requests, and filter out the ones that are malicious. Both schemes rely on TESLA. And limitation about TESLA is that it relies on clock synchronization. How can this be achieved in an ad-hoc network? But this is like the chicken/egg problem. Secure communication relies on clock synchronization; yet proper clock synchronization relies on secure communication (one could imaging a compromised node being able to establish bogus time messages). With SPINS one could imagine building an application such as a fire station alerter. The sensors could be fire detectors, and the base station could be a fire station. Once a fire is detected, the detectors could notify the fire station. The security comes in to play when you want to make sure that the originator of the data is actually where the fire is (ie. data authentication). Also you would need replay prevention to make sure we don’t get messages that are replayed by an intruder. Another application could be the use of sensors to gather data for the military. One could imagine a plane dropping a bunch of sensors to give the base station data that would help in planning military strategies. Some things you want to worry about are whether or not the data is from a node that you actually deployed. Also, you don’t want enemies to plant fake nodes that propagate false data. Since the protocol and keys are designed for resource limited environments, research on how easy to break these codes would be interesting. For example, how easy is it to decipher a message? (The logic behind this is that, if these protocols are actually good enough, it should be sufficient for regular wired networks). So if these protocols are easy to break, maybe they aren’t practical to deploy. One major limitation of Adriadne is the reliance on a key distribution center for key distribution. In the paper, they note that key distribution is an expensive process, and for Adriandne, they will just assume this is done. However, this sort of goes against the ad-hoc paradigm as for nodes to join a network, it has to now go to a centralized KDC to get keys for its other nodes in the neighbourhood. Now, with DSR, you only need to store the keys that you are interested in, but if you want to communicate with a certain node, you have to ask the KDC for the key. In this way the KDC is a limitation. Also, having to store all the (n+1) keys in a node with limited resources is a problem. From mvp9@cornell.edu Thu Oct 17 11:44:40 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFidh26607 for ; Thu, 17 Oct 2002 11:44:39 -0400 (EDT) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA10691 for ; Thu, 17 Oct 2002 11:44:36 -0400 (EDT) Date: Thu, 17 Oct 2002 11:44:36 -0400 (EDT) From: mvp9@cornell.edu X-Sender: mvp9@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The SPINS paper introduces a two-part protocol that seeks to provide data confidentiality and authentication1 in a sensor network where resources are highly limited. Since the constraints preclude public-key cryptography, the protocols are mostly based on shared keys. The first protocol in SPINS, SNEP works on a shared counter to provide authentication and security on point-point communication. uTESLA provides authenticated broadcast. Both focus on providing low-overhead communication and assume node to base-station connections although with the penalty of keeping all keys, communication could be done directly between nodes. There are several problems with the paper overall. How are keys initially disributed? Doing so within the network gives rise to a chicken and egg problem, while distributing them out-of-band has its own security concerns. Also many security concerns remain unaddressed -- covert channels, compromized nodes, Mac level, DoS and other physical attacks, the centralization of base stations. The second paper discusses Adriane, a secure protocol in an adversarial ad-hoc environment. It is related to DSR and uses TESLA security mechanisms. As in SPINS, the security is based on a shared key system, but can also use digital signatures, which brings all the problems related to having a KDC. However, Adriane focuses on providing security even when multiple nodes are compromised. Its mechanisms are also resistant to many types of DoS attacks. However, it assumes reliable broadcast which introduces many weaknesses and doesn't prevent Mac-level attacks. Once again, initial distribution of keys is a problem. Both schemes address only a subset of possible problems. Whereever either is deployed, physical security must be assured and various low-level protocol attacks must be ruled out. There must also be a time and possibility of setting up an maintaining base stations. Thus for SPINS, it is more amenable to defensive setups than offensive ones; for example, monitoring sensitive processes, however since compramization of even one node is dangerous, other layers of security are necessary. Adriane can be used for maintaining secure infrastructure, for example to coordinate security in a building. But any truly dynamic model is not really an option for either, since they require physical security and base stations. From mp98@cornell.edu Thu Oct 17 11:45:31 2002 Received: from postoffice.mail.cornell.edu (postoffice.mail.cornell.edu [132.236.56.7]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFjVh26686 for ; Thu, 17 Oct 2002 11:45:31 -0400 (EDT) Received: from cornell.edu (dhcp-193.rover.cornell.edu [128.84.24.193]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA17124 for ; Thu, 17 Oct 2002 11:45:29 -0400 (EDT) From: mp98@cornell.edu Date: Thu, 17 Oct 2002 11:45:53 -0400 Mime-Version: 1.0 (Apple Message framework v546) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: 615 Paper 39 To: egs@CS.Cornell.EDU Content-Transfer-Encoding: 7bit Message-Id: <84CA2CE0-E1E7-11D6-BB8D-003065EE5F0A@cornell.edu> X-Mailer: Apple Mail (2.546) SPINS This paper describes SPINS, a set or practices to secure a sensor network of sensors with limited memory and computation resources. The memory limitations are such that public key cryptography becomes infeasible and all transactions must be based around a symmetrical cipher. Another limitations include the inherently insecure nature of the broadcast medium. On the plus side, the base stations may be considered secure participants. SPINS contains two components: SNEP and uTESLA. SNEP is responsible for basic data encryption and authentication. It encrypts messages using RC5 in CTR mode and computes MACS's of the transmitted messages. SNEP also provides weak data freshness. That is, it ensures some ordering of messages but does not ensure a direct request and response ordering. This strong data freshness, however, is possible using SNEP by generating nounces. uTesla is a variation on TESLA, a protocol for authenticated broadcast, but designed to have a much smaller communications load (to save power) and memory requirements. Only symmetrical cryptography is used because public key is too expensive. The problem with symmetrical key based authentication is that a compromised receiver can spoof messages (he has the authenticating key). To get around this, uTesla uses a series of MAC keys generated in an SKEY fashion and received from the base station who periodically reveals the next key. Hence, broadcasts may be verified as authentic by the receiver after the seed for their keys is revealed by the base station. As long as the key Ki is not used before any of Ki, Ki+1, Ki+2, etc. are revealed, this system is secure. The main contribution of this paper is of course adopting cryptographically secure algorithms to a realm with tiny memory and processor power. As viewed in their results, they add only a trivial amount of extra computation and data overhead. Although power will always be a problem, memory and cycles will not: In the future embedded encryption will be cheap, even public key. It is arguably even cheap now (smart cards) and it is foolish not to take advantage of it. Also on the subject of Cryptography: The CTR block cipher mode is not a one-time pad--It is a stream cipher. The use of the counter in the MAC of a basic SNEP message seems unnecessary. Why not just use MAC(Kmac,D)? One can only decrypt D if one knows the counter anyway. Stopping a compromised sensor from spoofing the base station is tricky. Everyone knows the base station's address, and because sensors do not have asymmetrical encryption, it's a tricky problem as to how to tell who the real server is (without asymmetrical crypto, the base station and sensors must share secrets). ARIADNE Ariadne is a modified form of DSR designed around security. They consider several different authentication mechanisms, but the only really feasible one is TESLA which is just like uTESLA except the nodes themselves reveal their keys rather than relying on a base station. The other methods either fail because of too many keys (in the case of symmetrical key authentication each node needs to be aware of n^2 keys) or too much computation (public key). They categorize attacks as route disruption (i.e. creating loops, dropping packets) and resource consumption (i.e. sending out a lot of ROUTE REQUEST packets) and try to achieve resilience from them by modifying the DSR packets so that each Route Request packet can be authenticated for every node along the way and that this packet cannot be modified. This is achieved by appending a list of TESLA MAC signatures to the Route Request packets (to ensure that all nodes on the path are whom they say they are) and including a running has of these MAC's (to ensure that no extra ones have been removed or inserted). The route reply packet must follow the same path in reverse (in contrast to DSR's assumption that links may be unidirectional) so that the nodes can now append their keys for authentication. The distinguishing feature of this paper is that it is our first encounter with a routing protocol with a measure of security, in the form of unimpersonability. Their results show that their performance is not terribly worse than that of DSR without their additions. One obvious problem with their assumptions is that of key distribution: Key distribution in TESLA is based around the idea that every pair of communicating nodes has a shared key. Setting these up in a wireless network is nontrivial, and their suggestion of a KDC seems open to spoofing and man-in-the-middle attacks. Of course this isn't the crux of their paper, but it shows the difficulty of key distribution in an environment without PKC and CA's. From vrg3@cornell.edu Thu Oct 17 11:46:21 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFkLh26791 for ; Thu, 17 Oct 2002 11:46:21 -0400 (EDT) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA12097 for ; Thu, 17 Oct 2002 11:46:18 -0400 (EDT) Date: Thu, 17 Oct 2002 11:46:18 -0400 (EDT) From: vrg3@cornell.edu X-Sender: vrg3@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS is a combination of two techniques to provide security for wireless sensor networks where computation, power, and storage are limited. The network is assumed to consist of the sensor nodes plus a base station with more resources. SNEP is a means of encrypting messages that ensures confidentiality, authentication, integrity, and freshness. microTESLA allows for authentication of broadcasts. Each of these is traditionally done using asymmetric (e.g. public-key) cryptography, but that is unsuitable for the tiny computers on the nodes of a sensor network. SNEP bootstraps with initially shared keys between the base station and the nodes and relies on a counter shared implicitly. microTESLA uses temporal asymmetry to authenticate broadcasts using symmetrical encryption; the key to decrypt a broadcast is only transmitted in an epoch following the broadcast. The keys also depend on each other according to a one-way function, so any key can be easily used to compute preceding keys. microTESLA does not include a technique to prevent eavesdropping of broadcasts. It is not clear that the resources of mobile sensor nodes will remain limited even in the near future. However, currently it is the case. An interesting example of where a SPINS-type network may be useful would be in a hospital, where sensors could be attached to patients. The patients' vital signs could be monitored wirelessly, allowing them mobility. A simple base station infrastructure could be deployed in the semi-controlled environment. SNEP's confidentiality is important, as patient information needs to be confidential. Authentication (and integrity) are very important so that proper medical care can be provided. A malicious intruder, unchecked, could potentially cause people injury. Ariadne is essentially a secure version of DSR. One big contribution of the Ariadne paper is a formalization of the potential types of attacks an ad-hoc network might experience. Ariadne uses either full TESLA, pairwise shared keys, or a public key digital signature system to authenticate routing packets. Implementing Ariadne required certain optimizations to be removed from DSR. The simulations compared Ariadne to this non-optimized DSR as well as the full optimized DSR. It was interesting to note that Ariadne often outperformed the non-optimized DSR, due to the delays involved in TESLA. These delays caused extremely short-lived routes to slip through the cracks rather than to be used for an impractically short time. Ariadne's creators chose to disregard any types of attacks that Ariadne could not easily prevent, such as attacks at the MAC level or injection of data packets. Ariadne secures routing but does not secure data transfer. From bd39@cornell.edu Thu Oct 17 11:57:47 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFvkh29996 for ; Thu, 17 Oct 2002 11:57:46 -0400 (EDT) Received: from boweilaptop.cornell.edu (dhcp-128-84-93-87-wifi.ece.cornell.edu [128.84.93.87]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA11233 for ; Thu, 17 Oct 2002 11:57:44 -0400 (EDT) Message-Id: <5.1.0.14.2.20021017115557.00bdc6d8@postoffice2.mail.cornell.edu> X-Sender: bd39@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 11:56:07 -0400 To: egs@CS.Cornell.EDU From: Bowei Du Subject: 615 PAPER 39 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Ariadne The goal Ariadne is to provide a routing protocol which is secure in the face of adversarial attack from outside or from compromised nodes. Ariadne assumption that there is a key setup for each authentication method (shared paired node, TESLA, digital signatures) done through a mechanism such as a KDC. Ariadne is an extension of the DSR protocol, adding authentication of the sender of the protocol packets and the itegrity of the packet information. Route requests are authenticated to be from the source by a MAC. Routing information is authenticated by a hash per-hop. TESLA or signatures are are used to authenticate broadcasts. Ariadne seem to handle cases where the attacker cannot pose as a friendly node, i.e. the attackers cannot authenticate themselves to other nodes. The protocol does not seem to cover cases where friendly nodes have been compromised. What if signed source routes are replayed? I.e. a dsr node that refuses to update its cache? As with the other protocol, the establishment of a common shared secret key seems to be a weak point. How would this occur in an ad-hoc network? From mtp22@cornell.edu Thu Oct 17 11:59:10 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HFx9h00364 for ; Thu, 17 Oct 2002 11:59:09 -0400 (EDT) Received: from narnia (syr-24-58-57-15.twcny.rr.com [24.58.57.15]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA16910 for ; Thu, 17 Oct 2002 11:59:08 -0400 (EDT) Content-Type: text/plain; charset="iso-8859-1" From: Matt Piotrowski Reply-To: mtp22@cornell.edu To: egs@CS.Cornell.EDU Subject: 615 Paper 39 Date: Thu, 17 Oct 2002 11:59:42 -0400 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <02101711594207.00645@narnia> Content-Transfer-Encoding: 8bit The protocols discussed in these papers, SPINS and Ariadne, focus on security for resource-constrained networks, particularly sensor networks and mobile ad hoc networks. They try to avoid the use of public key cryptography to accomplish this, and instead prefer the much more computationally efficient symmetric cryptography. Symmetric cryptography, however, has its own problems in that in order for two nodes to communicate using symmetric cryptography, they must share a secret, and this secret must be distributed by something resembling public key cryptography. This is a weakness of both protocols. SPINS gets around it by trusting base stations; Ariadne never really gets around it. The SPINS paper introduces two security primitives: SNEP and uTESLA. SNEP provides data protection, and uTESLA provides broadcast authentication. uTESLA is built upon TESLA, the main difference being that uTESLA gets rid of TESLA's reliance on public key cryptography. Instead, the key chains rely upon time synchronization. One could build a number of secure services on top of these security primitives. One secure service would be a secure PKI for the application layer. A major problem with programs like ssh is that they require the public keys to be safely distributed. Thus, they are vulnerable to man in the middle attacks. With the data protection provided by SNEP, the two nodes on both ends of the ssh session could securely exchange public keys. Another service we could build is secure multicast using a combination of uTESLA and SNEP. This would be useful for things such as a radio station on the network that was concerned about providing an authentic service. From ag75@cornell.edu Thu Oct 17 12:06:22 2002 Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HG6Mh01761 for ; Thu, 17 Oct 2002 12:06:22 -0400 (EDT) Received: from travelers.mail.cornell.edu (travelers.mail.cornell.edu [132.236.56.13]) by travelers.mail.cornell.edu (8.9.3/8.9.3) with SMTP id MAA27713 for ; Thu, 17 Oct 2002 12:06:19 -0400 (EDT) Date: Thu, 17 Oct 2002 12:06:19 -0400 (EDT) From: ag75@cornell.edu X-Sender: ag75@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This week we are presented with two protocols: SPINS and Ariadne. The focus of both protocols is security, and they both strive to implement security using as few resources as possible. SPINS is designed with sensor networks in mind. It can be used for such things as controlling air conditioning and lighting systems, and for monitoring buildings for fires or dangerous particles in air. It assumes bidirectional communication links and that the base station can be trusted. SPINS is made up of two secure building blocks: SNEP and uTESLA. SNEP provides data confidentiality, two-party data authentication, data integrity and data freshness. uTESLA provides authentication for data broadcasts. While SPINS looks promising for resource-constrained environments, such as sensor networks, there are a few problems. The protocols does not deal with information leakage through covert channels, it does not deal completely with compromised sensors, it does not deal with DoS attacks and it can't achieve non-repudiation. Additionally, while the authors give a lot of info in their evaluation about the size of the code and claim that they implemented the protocol and that it works, we do not see any simulation results. Ariadne is designed to provide secure, on-demand routing for ad hoc networks. The authors use DSR as the basis for the protocol and make the basic version of DSR secure. The protocol does not allow for many of the enhancements to DSR because it only attempts to authenticate nodes. Thus, Thus, enhancements, such as link-state caching, can't be implemented since Ariadne does not authenticate links. Like SPINS, Ariadne assumes bidirectional communication links, but it does not need any trusted hardware. Ariadne prevents attackers or compromised nodes from tampering with uncompromised routes and prevents a large number of DoS attacks. However, the authors ignore attacks on MAC protocols and jamming. The simulation performed by the authors shows that Ariadne performs quite well compared to the non-secure, unoptimized DSR. From smw17@cornell.edu Thu Oct 17 12:07:39 2002 Received: from cornell.edu (cornell.edu [132.236.56.6]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HG7ch01916 for ; Thu, 17 Oct 2002 12:07:38 -0400 (EDT) Received: from cornell.edu ([128.84.84.84]) by cornell.edu (8.9.3/8.9.3) with ESMTP id MAA14553 for ; Thu, 17 Oct 2002 12:07:37 -0400 (EDT) Message-ID: <3DAE4BFD.8050906@cornell.edu> Date: Thu, 17 Oct 2002 01:34:53 -0400 From: Sean Welch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Emin Gun Sirer Subject: 615 PAPER 39 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit SPINS - SPINS is a security protocol expressly designed for networks of small, low-powered sensor networks with minimal processing and storage capabilities. The goals of this network are to permit a collection of nodes to communicate in a way such that a single node compromise will not spread to other nodes in the network. In order to achieve this goal, the authors modify the TELSA system to reduce the per-sensor overhead, reducing it to a minimal core capable of meeting the design goals. The basic system is comprised of a key and a one way function. Each node maintains a single key locally. When the node recieves a data value from the base station (the primary authenticating center), the data packet includes a MAC (Message Authentication Code) derived from the current key value. After a certain time interval, the base station generates a new key and releases the old key value. Once the key is released, the nodes can verify both that the released key is a valid sucessor to the previously released key, and that the MAC from the previous time interval was sent from the authenticating node. Messages with a stale timestamp (one for which the key may already have been released) are potential security risks, and should be discarded. This system provides authenticated transmission and weak freshness, with the capability for strong freshness when it is desireable to guarantee that a recieved packet was sent in response to a source transmission. These guarantees are useful certainly, but they only guarantee that a given compromised link/node will not be able to compromise further links. The system is still vulnerable to DOS attacks, deliberate mis-routing, and incorrect information sent by a compromised (but authenticated) node. Ariadne - Ariadne is a comprehensive attempt to provide a secure solution for ad-hoc networking. They incorporate three different schemes for node to node authentication, depending on the situation and details of the implementation. Ariadne is not designed to deal with passive (eavesdropping) attacks, instead focusing on active network attacks. This security is achieved in a number of ways. The first mechanism is a hop by hop authentication mechanism, shown in detail in the paper using TELSA to achieve the hop by hop authentication. This is combined with a hop by hop one-way hashing function that is applied at every node traversed. By applying the hashing function, a compromised node cannot simply remove or rewrite the desired route, as the removal would be detected at the final destination, and the packet rejected. All transactions in Ariadne are authenticated, and packets that cannot be reliably authenticated are discarded. Ariadne goes farther than authentication, attempting to reduce the effects caused by malicious behavior caused by active nodes with compromised keys. Intentional mis-routing is considered by maintaining multiple routes, and dynamically adjusting traffic patterns based on delivery fractions and overall link quality. In such a case, as long as there exists an uncompromised link from source to destination, it is possible to maintain a decent connection. They also consider the potential for severe network degradation through repeated Route Request floods. They consider both keying (as per the TELSA authentication) each route request, or simply dictating a schedule in which a route request can be issued. Ariadne definitely provides more security than most ad-hoc protocols, but it still cannot guarantee reliable transmission in the presence of untrustworthy nodes. A sufficient population of malicious nodes can still disrupt the network quite badly, no matter how much effort is put into detecting and avoiding them. In addition, mild actions by compromised nodes may not be significant enough to be detected by the various monitoring scenarios presented, leaving a network vulnerable to gradual, long-term attacks or strategically placed compromised nodes. From sc329@cornell.edu Thu Oct 17 12:19:40 2002 Received: from postoffice2.mail.cornell.edu (postoffice2.mail.cornell.edu [132.236.56.10]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HGJdh04997 for ; Thu, 17 Oct 2002 12:19:39 -0400 (EDT) Received: from sangeeth.cornell.edu (syr-24-58-36-135.twcny.rr.com [24.58.36.135]) by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA08668 for ; Thu, 17 Oct 2002 12:19:39 -0400 (EDT) Message-Id: <5.1.0.14.2.20021017104618.0284ec98@postoffice2.mail.cornell.edu> X-Sender: sc329@postoffice2.mail.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 17 Oct 2002 12:19:41 -0400 To: egs@CS.Cornell.EDU From: Sangeeth Chandrakumar Subject: 615 PAPER 39 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Submitted by - Sangeeth Chndrakumar SPINS is a security protocol for sensor networks which are extremely resourse-restrained. SPINS consists of two modules - SNEP encryption, which ensures data confidentiality, two-party data authentication and data freshness, and uTESLA for authenticated broadcasts. SPIN could be deployed in any self-organizing multi-hop sensor networks. It assumes the presence of a base station with more power and available memory. It is assumed that the base station is a trusted entity and all the nodes share a secret key with it upon bootstrapping. Spins uses symmetric key cryptography since asymmetric crytography requires much more resourses. It Introduces asymmetry through a delayed disclosure of symmetric keys, which results in efficient broadcast schemes. uTESLA requires that nodes and the BS are loosely time synchronized with an upper bound on synchronization error. MAC keys form a key chain that can be derived from each other using a one-way public function F. Each MAC key is associated with a time interval such that the receiver knows the key disclosure schedule. Therefore, MAC keys can be used for authentication with minimum overhead, and limited key lifetime forces the key to be obsolete even if a malicious node discovers it. Some of the services that could be build on SPINS: Authenticated routing: Periodic beacons can be used for route discovery. When a node receives a beacon packet form a node, it checks to see whether it has recieved a beacon from the base station during that epoch. If it does not hear any thing more, and the packet it received earlier had the right credentials, it accepts the sender as its parent in ints route to the base station. Node-to-Node Key agreement: Two nodes can set up a shares key between themselves with the help of the base station, since every node maintains a secret key with the base station. Once a key is established, then the two nodes can use the newly acquired secret shared key to communicate between themselves. Ariadne is an ad-hoc network routing protocol that provides security against one compromised node and arbitrary active attackers, and relies only on efficient symmetric cryptography. Ariadne operates on demand, dynamically discovering routes between nodes only when they are needed. Ariadne uses TESLA for efficient broadcast authentication and requiring loose time synchronization. Araidne uses TESLA for authenticating the route discovery process. The initiator of each request initializes the hash chain of MAC and the node lists. When an intermediate node receives this request, and if it is not a duplicate request, appends itself on the route list and replaces the hash chain field. When the target node receives the route request, it checks the validity if the request by determining the keys from the time interval specified that have not been specified yet, and also verifies the hash chain field.If tit determines that the route request is valid, it sends a route reply to the initiator with the entire MAC list. Once the initiator receives this reply, it verifies that each key in the key list valid. If all these steps succeed, the node accepts the route reply, otherwise it discards it. The main security hole in this scheme appears when you have a number of attackers acting together and bringing down some of the well-behaved nodes. The paper do not address such problems in detail From ashieh@CS.Cornell.EDU Thu Oct 17 13:53:16 2002 Received: from cfs24.cs.cornell.edu (cfs24.cs.cornell.edu [128.84.96.221]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HHrGh29517 for ; Thu, 17 Oct 2002 13:53:16 -0400 (EDT) Received: from localhost (ashieh@localhost) by cfs24.cs.cornell.edu (8.11.6/8.11.3/L-1.3) with ESMTP id g9HHrGs10372 for ; Thu, 17 Oct 2002 13:53:16 -0400 Date: Thu, 17 Oct 2002 13:53:16 -0400 (EDT) From: Alan Shieh To: egs@CS.Cornell.EDU Subject: 615 PAPER 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS Posted question: SPINS is especially suited for client-server applications because of the asymmetry between the relative cost of server- and application-enabled broadcasts. Applications that fit well into the SPINS model (naturally) include sensor applications, such as secure code and control updates. The centralization in SPINS greatly weakens the security of any point to point communications, since a compromise of the base station is a compromise of the entire network. Therefore, it seems that most applications can only sending and receiving information that is only as trusted as the base station itself. One cannot, for instance, build a secure chat client, or transmit location information exclusively to a trusted set of nodes. SPINS provides a secure communications infrastructure for CPU-constrained sensor networks. Broadcast authentication is achieved with TESLA, which uses a time-released one-way key chain (the source knows the entire chain, but the keys are used in a reverse order; when later keys are released all earlier keys can be verified using repeated applications of the one-way function.) Node to node authentication and secrecy is provided by a central authority. Each node shares a unique secret key with the authority (base station). The authority generates and transmits a session key using this secret key to each node upon demand. These keys shared between nodes and the base station are also used to encrypt and authenticate sensor information. Due to hardware limitations, the base station is the only node that maintains the broadcast key chains and stores the keys necessary for secret key dissemination between nodes. More low-level implementation details: Weak freshness - provided with CTR-mode on cipher Strong freshness - provided by concatenating nonce to input to MAC ** Shortcomings The simple uTESLA-based route discovery protocol does not provide very strong security. For instance, a wormhole attack could direct sensor traffic in the wrong direction, or to create blackholes in the network (since each node only considers the first advertisement that is heard). ** Future work - Allow nodes to securely add more than 2 peers to a shared secret group. This allows some level of secure multicast in that only members of a multicast group may decrypt the message, but any member can still impersonate another member. Authentication would require a multicast generalization of TESLA, or asymmetric scheme. Ariadne Posted question: A significant shortcoming of Ariadne's routing mechanism is the assumption of reliable broadcast. A compromised node can conceivably jam neighboring nodes with well-timed broadcasts. Conceivably, an attacker can selectively interfere with broadcasts to prevent the discovery of uncompromised routes. Such interference can be masked as normal network traffic, and would be difficult to detect. Moreover, Ariadne does not distinguish between congestion and subverted routes; this suggests vulnerability to attacks that increase congestion in certain parts of the network. Ariadne contributes a taxonomy of possible attacks on an ad-hoc routing protocol, as well as a secure variant of DSR. An active attacker can attempt to create routing loops, black or gray holes (spots in the network where packets disappear, possibly selectively), force longer routes to be used, manipulate a node "blacklist" to make nodes mistakenly believe that intact nodes have been compromised, and create wormholes to interfere with ordering assumptions about broadcast floods. Nodes may also flood the network with route discovery broadcasts to prevent Ariadne adds security features to basic DSR (without optimizations) to counteract these attacks. A one-way hash is cumulatively applied at each hop to a value known only to the source and destination; this is checked at the destination to prevent sending a route reply back along a bogus route. This prevents an attacker from deleting nodes from a route discovery. A MAC or signature list is accumulated along with the list of nodes to prevent arbitrary nodes from being inserted to a route. The destination computes a MAC for the route reply to prevent tampering while in-flight. When the source receives the route reply, it verifies the destination MAC, and checks the MAC list against the nodes that are listed as being in the route. Route error messages are authenticated in a similar manner to prevent attackers from purging good routes. These mechanisms prevent arbitrary manipulation of a route; an attacker can only insert compromised nodes into routing paths. To prevent such paths from being used, Ariadne sends packets through alternate routes and avoids unreliable routes. ** Shortcomings See answers to above question. ** Future work - Implement a secure caching optimization. - Use a more sophisticated attack detection mechanism. The one proposed in the paper is not sensitive to increases in latency or hop count along a path. There should be a mechanism for securing the routing header contents to prevent a compromised node from forwarding the packet along a longer route. From linga@CS.Cornell.EDU Thu Oct 17 14:48:48 2002 Received: from snoball.cs.cornell.edu (snoball.cs.cornell.edu [128.84.96.54]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.10) with ESMTP id g9HImlh13525 for ; Thu, 17 Oct 2002 14:48:47 -0400 (EDT) Received: from localhost (linga@localhost) by snoball.cs.cornell.edu (8.11.3/8.11.3/C-3.2) with ESMTP id g9HImlo17418 for ; Thu, 17 Oct 2002 14:48:47 -0400 (EDT) Date: Thu, 17 Oct 2002 14:48:47 -0400 (EDT) From: Prakash Linga To: Emin Gun Sirer Subject: 615 PAPER 39 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS Aim of the paper is to incorporate security into a resource-constrained system like sensor networks. Asymmetric cryptographic algorithms like RSA are expensive both interms of space and computational requirements. Symmetric crypto algorithms like Rohatgi's algorithms are expensive in terms of space. TESLA, an authenticated streaming broadcast protocol which falls into the symmetric class is also expensive - it uses a digital signature in the first step which is computationally expensive; has an overhead of around 34-bytes per packet. None of these approaches work in sensor networks. SPINS has mainly two parts: SNEP (for baseline security primitives) and mu-Tesla (for authenticated broadcast). Goals of SNEP include: semantic security, data authentication, replay protection, low communication overhead etc. Semantic security can be achieved through randomization. But this imposes additional overhead in terms of greater power utilization. Instead using a block cipher in counter mode (CTR) with a shared counter between the sender and the receiver should do the job. A message authentication code (MAC) is used to achieve two-party authentication and also data integrity. Coming to mu-Tesla: Main idea is to not use the standard asymmetric protocols but introduce the essential asymmetry through a delayed disclosure of symmetric keys. The authors argue that this approach works well and present some evaluation studies supporting their claim. Pros & Cons: A good first-step wrt security in resource-constrained environments like sensor networks. This enables authenticated routing which acts as a starting point for many services which coule be built on adhoc/sensor networks. It is clear whether the mild synchronization business is a good thing to do in different scenarios (esp in case of a large network). Also the protocol inherits all the disadvantages of TESLA, for example each node in the network must be able to estimate the end-to-end transmission delay to any other node in the network. ARIADNE This paper presents possible attacks against standard routing protocols in adhoc networks and proposes a new secure reactive routing protocol (ARIADNE - is this supposed to mean anything?). ARIADNE is again based on TESLA and hence uses only highly efficient (in terms of computation requirement) symmetric crypto primitives which may be expensive in terms of space reqiurement. Three schemes for authenticating messages have been investigated - shared secrets between a pair of communicating nodes, shared secrets with broadcast authentication and digital signatures. TESLA is used for broadcast authentication. This allows for other optimizations but requires loose synchronization. Attacks on physical and mac layer are ignored. For TESLA to work, each node in the network must be able to estimate the end-to-end transmission delay to any other node in the network. Periodic re-synchronization is used to compensate clock drift. General attacks are of two kinds - routing disruption attacks (causing a routing loop for example) and resource consumption attacks (injecting extra data and control packets to increase b/w usage). There are three important stages in Ariadne protocol: a way for destination to verify authenticity of ROUTE REQ; ways of authenticating data (the three mentioned above), a way to ensure that no node is missing from the node list in the request (this is done using per-hop hashing). Details of the protocol are presented and performance results show that Ariadne is comparable in performance to DSR with the added advantage of security. Pros & Cons: Provides a way of authentication and security in adhoc networks. Suffers from a lot of drawbacks the important of which are: a large space overhead, accurate transmission-delay estimation (for TESLA to work) etc.