From c.tavoularis@utoronto.ca Tue Nov 13 11:01:07 2001 Return-Path: Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fADG14R07554 for ; Tue, 13 Nov 2001 11:01:05 -0500 (EST) Received: from webmail3.ns.utoronto.ca ([128.100.132.26] EHLO webmail3 ident: IDENT-NOT-QUERIED [port 40341]) by bureau6.utcc.utoronto.ca with ESMTP id <238603-14240>; Tue, 13 Nov 2001 11:00:00 -0500 Received: by webmail3.ns.utoronto.ca id <414676-225>; Tue, 13 Nov 2001 10:59:45 -0500 To: egs@CS.Cornell.EDU Subject: 615 PAPER 47 Message-ID: <1005667181.3bf1436d61b3f@webmail.utoronto.ca> Date: Tue, 13 Nov 2001 10:59:41 -0500 (EST) From: c.tavoularis@utoronto.ca MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 SPINS is a security protocol for sensor networks whose nodes suffer from very limited computational power, memory and battery life for communication. SPINS consists of ě-TESLA for authenticated streaming broadcast and SNEP encryption for data confidentiality, two-party data authentication and data freshness. SPINS is intended for networks of self-organizing multihop routing sensor nodes with one base station with more battery power and memory and a connection to outside networks. The communication patterns addressed by SPINS are between nodes and the base station, and communication between two or more nodes is assumed to go through the base station to achieve all-inclusive security. It is assumed that the BS is a secure and trusted entity and a shared secret key is bootstrapped between each node and the BS. Broadcasting is vulnerable to attacks including eavesdropping, message injection and message replay, and individual nodes are untrusted. SPINS uses symmetric key cryptography since asymmetric cryptography is too expensive resource-wise. SNEP uses a message authentication code (MAC) derived from the bootstrapped key. This provides semantic security that prevents the message from being inferred by the encrypted message. To minimize communication overhead, it uses a shared counter between the sender and receiver. In addition, strong data freshness can be achieved by adding a nonce. ě-TESLA 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. The goal of SPINS is very challenging since addition of security into a network necessarily entails overhead for which networks such as SmartDust cannot afford. It appears that SPINS protects against many types of attacks in such networks. SPINS can be employed for authenticated ad hoc routing and exploits periodic routing beacons for ě-TESLA key disclosure. It also can be used to set up a key agreement between two nodes. SPINS highly relies on a powerful base station, which is a fair assumption in sensor networks which require a sink to gather and process sensed information. From teifel@csl.cornell.edu Tue Nov 13 15:11:02 2001 Return-Path: Received: from disney.csl.cornell.edu (disney.csl.cornell.edu [132.236.71.87]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fADKB0R10500 for ; Tue, 13 Nov 2001 15:11:00 -0500 (EST) Received: from localhost (teifel@localhost) by disney.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id fADKAta02329 for ; Tue, 13 Nov 2001 15:10:55 -0500 (EST) (envelope-from teifel@disney.csl.cornell.edu) X-Authentication-Warning: disney.csl.cornell.edu: teifel owned process doing -bs Date: Tue, 13 Nov 2001 15:10:55 -0500 (EST) From: "John R. Teifel" To: Subject: 615 PAPER 47 Message-ID: <20011113150605.U2248-100000@disney.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ********************************************************* ********************************************************* ** PDF output of my latex slides can be found at: ** ** www.csl.cornell.edu/~teifel/615/main.pdf ** ********************************************************* ********************************************************* From papadp@ece.cornell.edu Wed Nov 14 19:14:26 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAF0EPR02781 for ; Wed, 14 Nov 2001 19:14:25 -0500 (EST) Received: from kiki.ece.cornell.edu (kiki.ece.cornell.edu [128.84.83.13]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAF0CqR04700 for ; Wed, 14 Nov 2001 19:12:52 -0500 Date: Wed, 14 Nov 2001 19:17:34 -0500 (EST) From: "Panagiotis (Panos) Papadimitratos" To: Emin Gun Sirer Subject: 615 PAPER 47 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Review of: "SPINS: Security Protocols for Sensor Networks," by A. Perrig, R. Szewczyk, V. Wen, D. Culler, J.D. Tygar The authors propose a scheme providing security features to sensor networks, and their main concern is to show the feasibilty of this task given the limited resources of the network nodes. The scheme targets a restricted, infrastructure-oriented environment, with a trusted central entity, instantiated by a set of base stations. The communication is always between a signle node and the access point (AP) or broadcasts from the AP, which is the only trusted entity in the network and possesses an encrytion and authentication symmetric (secret) key. The contribution of the paper is the design of a protocol for authenticating the broadcasted messages, and more importantly evidence that it can be implemented in the sensor-network context. But the idea of using elements of a hash chain as keys and the reliance on loose synchronisation, dissemination of the key and a posteriori validation of authenticity and integrity has been proposed in 1997 !!!! And in a multi-hop setting, which, it appears, is not the emphasis of the SPINS work judging from the experimental setup. Moreover, the idea of the shared counter does not work if cipher blocks are lost. An additional mechanism is needed to recover. And their bootsrapping is too expensive compared to the benefit of "semantic security". Finally, the claimed as 'routing' protocol is practically a straightforward application of their multicast/key distribution work, and is far from being an ad hoc routing protocol. From viran@csl.cornell.edu Wed Nov 14 21:21:31 2001 Return-Path: Received: from moore.csl.cornell.edu (moore.csl.cornell.edu [132.236.71.83]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAF2LUR14941 for ; Wed, 14 Nov 2001 21:21:30 -0500 (EST) Received: from localhost (viran@localhost) by moore.csl.cornell.edu (8.11.3/8.9.2) with ESMTP id fAF2LNW85569 for ; Wed, 14 Nov 2001 21:21:23 -0500 (EST) (envelope-from viran@moore.csl.cornell.edu) X-Authentication-Warning: moore.csl.cornell.edu: viran owned process doing -bs Date: Wed, 14 Nov 2001 21:21:23 -0500 (EST) From: "Virantha N. Ekanayake" To: Subject: 615 Paper 47 Message-ID: <20011114211950.U84962-100000@moore.csl.cornell.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS presents a way for security to be added to a wireless sensor networks. Current public key crytography are impractival for sensor networks. They use symmetric cryptography since asymmetric schemes require long signatures and high computation requirements. In their scheme, base stations are trusted and supply a key to each node. They build the system on the SmartDust sensor network running TinyOS and it purportedly supports data encryption, data authentication, and data freshness. Evaluation was pretty ridiculous -- security implementations should evaluate how secure the system is. In this case, they just brushed aside the issue and presented some bogus stuff on message overhead and energy costs. There's no evaluation of how well the security is. Frankly I'm skeptical -- they assume trusted base stations, so what's to prevent a rogue node masquerading as a sensor to suddenly start behaving like a base station and capturing nodes? Also, although I'm not an expert, I wonder just how secure their version of RC5 is? They discarded previously done small encryption algorithms because they aren't mature, but then they use an "optimized" version of RC5 hacked out of OpenSSL which may be completely unsecure because of all the modifications, and then do not present any data on how resilient it is to attacks. Also, they assume a counter state at the sensor node and base station that must not repeat during the lifetime of the system -- this means that each sensor must have some non-volatile memory to store the counter value in case of reset. I believe that their goal of security for sensor networks is a worthy one, but I think it may be a little constrained at this stage. I'm not sure their reasoning behind discarding asymmetric encryption is valid, as data and computation requirements should not be treated as the end-all limitations in sensor networks. From ramasv@CS.Cornell.EDU Wed Nov 14 23:31:09 2001 Return-Path: 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.7) with ESMTP id fAF4V8R28746 for ; Wed, 14 Nov 2001 23:31:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: cs615 PAPER 47 Date: Wed, 14 Nov 2001 23:31:07 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D4301E7F292@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: cs615 PAPER 47 Thread-Index: AcFtjlhdts/r09oGQ/WmyQHSAuIgcQ== From: "Venu Ramasubramanian" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fAF4V8R28746 SPINS: Security Protocols for Sensor Networks This paper describes a set of security protocol designed to ensure data confidentiality, integrity, freshness and authenticity in a terribly resource constrained instance of a sensor network. The authors have designed two protocols m-Tesla and SNEP whose code and state size is tiny enough to fit into their system with 512B RAM. The protocols described here are very concise for their system. However, their claim that this is a general set of protocols well suitable for sensor networks in general is not acceptable. The SNEP protocol provides data confidentiality by using shared key cryptography. Shared-key between the sensor node and trusted base station is pre-initialized before the sensor network is deployed. Data freshness is ensured by using incrementing counters as extra information appended to data before encryption. This implies that data communication can exist only between the sensor nodes and base stations and any secure communication between two sensor nodes will need to commence with a secure key-sharing protocols. Further in the presence of thousands of sensor nodes, the base stattion might become a bottleneck for data communication. These limits the general applicability of this scheme to all sensor networks. The m-tesla is a data authentication protocol that authenticates base stations to the sensor nodes. The presence of symmetric shared keys between the sensors and base-station help them to build an authntication scheme without much overhead. Base station's key periodically changes and the base station sends the key to the sensors after a time delay. The interesting feature is that if any key in the chain is know, that can be used to authenticate any further keys. The symmetric shared key is used to supply the first key in the chain. However, this causes a delay in the processing of messages as the authentication can be checked only when the key is sent after some time. This protocol helps authenticated broadcasts from base stations. There is a very high reliance on the initial shared key between sensor and base station. It seems that if a sensor node gets in to the hand of the adversary, then he can find its secret key and send false information to other sensors and to the base station. The paper starangely does not discuss anything about the kind of attacks the protocols are resilient against. From eyh5@ee.cornell.edu Thu Nov 15 08:23:45 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFDNiR21699 for ; Thu, 15 Nov 2001 08:23:44 -0500 (EST) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAFDM8R17075 for ; Thu, 15 Nov 2001 08:22:08 -0500 Date: Thu, 15 Nov 2001 08:22:16 -0500 (EST) From: Edward Hua X-X-Sender: To: Subject: 615 Paper 47 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS: Security Protocols for Sensor Networks Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J.D. Tygar This paper proposes a suite of security protocols that can be implemented in sensor networks, where the amount of available memory space allowed for each sensor node is extremely limited. SPINS, as these protocols are collectively called, are comprised of two components: uTESLA (micro-Timed Efficient, Streaming, Loss-tolerant Authentication Protocol) and SNEP (Secure Network Encryption Protocol). UTESLA provides authenticated streaming broadcast, whereas SNEP provides data confidentiality , two-party data authentication, and data freshness, all with low overhead. SPINS runs on TinyOS as its operating system. The challenge of offering security in a sensor network, where the nodes are millimeter-scaled devices, is manifested by the limitations on node resources, such as battery life and working memory. The nodes communicate with each other over the air interface, and broadcast is seen as a good choice of disseminating information. The sensor network has a base station, which serves as a focal point to gather data transmitted from the nodes, and which in turn relays to its parent network. In designing SPINS, several things are kept in mind. They are data confidentiality, data authentication, data integrity, and data freshness. SNEP is designed to support these attributes of sensor network security, with uTESLA used to authenticate broadcast packets from a node. In implementing SPINS, a critical issue is how to save as much space as possible without compromising network security. To that end, the researchers piece together five features. They choose the RC5 as the block cipher because of its small code size and good efficiency. A counter (CTR) mode of block ciphers is used for both encryption and decryption. Another capability CTR has is that it provides weak freshness of the packets. In addition, the researchers include a message authentication code (MAC) to serve as a pseudo-random number generator (PRG). This piece of code is included to further improve the power conservation. CBC-MAC is used to provide message authentication. Finally, the PRG function is used to derive the secret master key and all keys subsequently used. All keys derived are computationally independent, and thus prevent an attack to one from gaining the complete knowledge of all. The evaluation of SPINS yields impressive results in terms of cost of energy for tasks executed by the sensor network. Most of the overhead, about 20% of the total energy consumption, comes from the transmission of extra data. The overall overhead consumption of power is less than 29%. This represents a fairly good percentage given that data packets are adequately protected with the constraints on the memory space. One question I have for the authors of this paper is: Does this evaluation here also include the work done by the base station? Base stations in such a sensor network play a very important role, as it has more capacity to aggregate the incoming data from all the sensors, and serves as a gateway to transmit the data to an outside network it is connected to. This SPINS here seems to only have addressed the security of the sensor nodes but not that of the base station. It may be therefore reasonable to assume that the base station has a separate security protocol to address security issues. From avneesh@csl.cornell.edu Thu Nov 15 11:53:11 2001 Return-Path: Received: from capricorn.ds.csl.cornell.edu (capricorn.csl.cornell.edu [132.236.71.92]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFGrAR24864 for ; Thu, 15 Nov 2001 11:53:10 -0500 (EST) content-class: urn:content-classes:message Subject: 615 Paper 47 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 15 Nov 2001 11:55:31 -0500 Message-ID: <97C142C1212ED545B0023A177F5349C40A09EB@capricorn.ds.csl.cornell.edu> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 Paper 47 Thread-Index: AcFt9lXWJ2Hy4aEmS9O6iB8EknkALA== From: "Avneesh Bhatnagar" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fAFGrAR24864 SPINS: Security Protocols for sensor networks This paper discusses the limits and implementation of a suite of security protocols for sensor networks. Sensor nodes do not have the raw computational power and storage capacity that is required for the storage and manipulation of asymmetric security protocols. Hence the design as presented is that of a symmetric security arrangements which depends upon freshness of information as well as existence of a 'common state' exhibited through the use of counters between the base station and the sensor node. The security protocols for sensor networks (SPINS) are divided into two major suites: SNEP( Secure Network Encryption Protocol), which provides data confidentiality, data authentication, integrity and freshness; and micro-Tesla for authenticated streaming broadcast. The architecture chosen is similar to the smart dust architecture, with multiple base stations of higher battery/storage capacity, which interface with the sensor network. The 'trust' setup allows sensor nodes to be untrusted, but the base stations have to be part of a trusted computing base. Each sensor node thus shares a master key with the base station. In order to maintain sensor security, the following conditions are handled: a. Data confidentiality: Setup/bootstrap secure channels while encrypting data (CTR) with a secret key that the intended receiver possesses. b. Data authentication: Sender and receiver share a message authentication code of all the communicated data. c. Data Integrity: Achieved through data authentication. d. Data Freshness: Achieved through the use of nonces. SNEP: In SNEP, the data is first encrypted with an encryption key and a shared counter value. Along with this, a message authentication code (MAC), is generated using another key: Kmac and the counter as well as the above encrypted data. This provides the required semantic security and achieves (a-c). Data freshness is weakly enforced by this counter, but a stronger condition can be evaluated by using a nonce (random number) which is exchanged between sender and receiver using an authenticated protocol. uTESLA: uTESLA is a light weight implementation of the TESLA protocol, which simulates asymmetry by delayed broadcast of symmetric keys. However in order to do this, the base station and nodes have to be loosely synchronized. Using a pre-determined one way function F (in this case: MD5), a key chain can be setup with Kt the key at time interval t being used to compute the MAC. However to introduce the asymmetry, the sender waits some time after t, before advertising the key Kt. A new receiver is bootstrapped by having one authentic key of the key chain. Loose time synchronization helps the receiver establish a key disclosure schedule, while for nodes broadcasting data, the base station keeps the one way chain and sends keys to the broadcasting node, when needed. The authors evaluate the performance in terms of code overhead and energy costs and show that their implementation is feasible. However all the issues have not really been addressed, primarily a dos attack problem. Some comments: a. The overall throughput of the sensor network should have been evaluated, since I think that the results shown are intuitive, considering that the authors mention code optimization throughout the paper. Thus giving percentage reductions as the only evaluation seems redundant. b. There is this issue of the base station participating in the sensor nodes' secure broadcast. This makes the utilization of the centralized component stronger, so it would have been interesting to see the overall energy impact that this has on the base station. c. The shared counter is another issue, where does the node begin, once it has been shut down? d. I feel that this paper has highlighted some of the problems and achieved good code optimization rather than solving the security problem altogether. Dos is the most common and easily achievable attack in such a network. e.g. in a military setting a malicious sensor node can be dropped which does this. From ranveer@CS.Cornell.EDU Thu Nov 15 12:03:56 2001 Return-Path: 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.7) with ESMTP id fAFH3sR26482 for ; Thu, 15 Nov 2001 12:03:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 615 PAPER 47 Date: Thu, 15 Nov 2001 12:03:54 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D430232E6B1@opus.cs.cornell.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 615 PAPER 47 Thread-Index: AcFt93gLCrI4R88oEdW5bgCQJ59Etw== From: "Ranveer Chandra" To: "Emin Gun Sirer" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sundial.cs.cornell.edu id fAFH3sR26482 SPINS: Security Protocols for Sensor Networks This paper proposes a security mechanism for sensor networks to ensure data confidentiality, authentication, integrity and freshness. Two security protocols are presented: SNEP for the above features in unicast, and mu-tesla for authenticated broadcast. Asymmetric key sharing techniques are expensive for bandwidth constrained sensor networks, and so the proposed protocols use symmetric keys. The main disadvantage of symmetric key cryptography is the distribution of the shared keys. SPINS overcomes this problem by allowing the shared keys to be established during deployment. SNEP also allows for data freshness by allowing a counter at the sensor nodes that is incremented at each time step. The concatenation of the message and the counter is encrypted and sent to the BAS. This secures the protocol from replay attacks. Further, a random nonce is used to ensure strong freshness. mu-Tesla uses a loosely synchronized clock to ensure secure broadcasts. Asymmetry is introduced by delayed disclosure of symmetric keys. The main contribution of this paper is the proposal of a low overhead security protocol. mu-Tesla is also particularly attractive in the setting of sensor networks. However, the proposed scheme has obvious disadvantages: 1) The protocol suffers from the disadvantage of Symmetric Cryptography, i.e. in the distribution of keys. If the keys are shared during deployment, how does it cope with addition of new nodes. In the current implementation, keys are shared only with the BAS!! In an ideal setting we would want any pair of nodes to interact directly with each other. 2) All the traffic is routed through the BAS. How scalable is this approach in the presence of thousands of sensor nodes? Worse still, if two neighbor nodes far from the BAS want to communicate, they will have to use the BAS!! 3) Symmetric cryptography is definitely not the way to go, if we want to avoid the problem in (2). Symmetric cryptography requires nodes to share keys with all the other nodes. If we want to avoid a centralized scheme, nodes will have to store thousands of shared keys, which makes the protocol unscalable!! A better approach would be used a combination of symmetric and asymmetric cryptography. Clusterheads could operate with asymetric keys, while within a cluster nodes would communicate using a low overhead symmetric key. However, this is just a very wild idea.... From samar@ece.cornell.edu Thu Nov 15 12:38:30 2001 Return-Path: Received: from memphis.ece.cornell.edu (memphis.ece.cornell.edu [128.84.81.8]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFHcSR00392 for ; Thu, 15 Nov 2001 12:38:28 -0500 (EST) Received: from aquinas.ee.cornell.edu (aquinas.ee.cornell.edu [128.84.236.57]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id fAFHaqR25214 for ; Thu, 15 Nov 2001 12:36:52 -0500 Date: Thu, 15 Nov 2001 12:37:20 -0500 (EST) From: Prince Samar X-Sender: samar@aquinas.ee.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 47 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS: Security Protocols for Sensor Networks Securing sensor communication is particularly challenging due to the resource constraints on available battery power, processing capacity and storage. The paper presents a set of Security Protocols for Sensor Networks (SPINS) which has two building blocks: SNEP and micro-TESLA. The protocols rely on the presence of a controlling base-station which can be trusted by all the sensor nodes. Also, each node trusts itself. For the available resources in sensor networks, use of asymmetric cryptography is expensive and so SPINS uses symmetric cryptography. All cryptographic primitives are constructed out of a single block cipher for code reuse. Presence of common states between communicating nodes is utilized to reduce communication overhead. SNEP utilizes a common counter between sender and receiver which is incremented after each message communicated between the two. This requires a reliable link layer protocol. A message authentication code (MAC) is utilized. SNEP offer semantic security, data authentication, relay protection, weak freshness and low communication overhead. mu-TESLA provides authentication for broadcast messages. One requirement for it is that the nodes and base-stations should be loosely time-synchronized, each node has the knowledge of an upper bound for the maximum synchronization error. It also requires a buffer where a node can store the received packets until it receives the key. Each MAC key is a key of a key chain, generated by a public one-way function F. The paper does not discuss the kind of attacks possible on the sensor network. A mobile multi-hop network does not seem to be the goal of the work, as inferred from their experimental set-up and discussion. Scalability and single point of failure are also issues not adequately addressed. From mh97@cornell.edu Thu Nov 15 12:40:52 2001 Return-Path: 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.7) with ESMTP id fAFHepR00562 for ; Thu, 15 Nov 2001 12:40:51 -0500 (EST) Received: from mars (syr-66-24-28-66.twcny.rr.com [66.24.28.66]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id MAA18421 for ; Thu, 15 Nov 2001 12:40:49 -0500 (EST) From: "hao ming" To: Subject: 615 PAPER 47 Date: Thu, 15 Nov 2001 12:39:41 -0500 Message-ID: <000c01c16dfc$8175ed20$6901a8c0@mars> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal the paper addresses the secure issue for the sensors networks. i agree that secure communication is badly needed by the sensor network considering the potential applications of this kind of network. the SPINE consists of two parts. SNEP, dealing with the data confidetiality, authetication, freshness and interity; uTESLA deals with broadcasting authentication. the basic assumptions include trusted basestations, loosely synchronized clocks. because of he limitation of sensors in the sense of resources, the paper presents a symmetric authentication mechanism. basically, each node shares a secret master key with trusted basestation. the encrption and MAC key are derived from the master key. the message is encripted by the encription key to ensure the data confidentiality. MAC code for the message is computed for message to ensure the integrity and authentication. involing counter value of the local node offers the sementic security. for broadcasting, the uTELA uses delayed disclosed key to ensure the security even in the case of some compromised nodes. this scheme depends on the synchronizaed clocks. the main idea of this scheme is that BS sends packets first, nodes buffering the packets; later BS sends the key to all nodes. on the differnt intervel, different keys are used which can be computed from a one-way function. thus even a node steals the key, it is twoo late for it to send packets. the idea is brillient though it did not originate from this paper. there are concerns about the secure communication among the nodes without involving basestations. becasue the setup of shared secret key between nodes has to invole basestation each time unless nodes stores those keys. but as the size of sensor network is so big, i think it may be feasible for a node storing only keys of its neighbors. in reality, it may be enough. after this paper, i am still not clear that how secure the SPINE is. i doubt there are metrics evaluating the degree of security like those evaluating the performance of CPU speed, network badwidth and so on. after the compromise because of the sparcely available resources, how much security is achieved using SPINE. another intereting question is how BS detects the broaken nodes. one way to do that is let a group of nodes sensing same information. if one of nodes sends wrong information, the BS can detect it by comparing those information. -ming From andre@CS.Cornell.EDU Thu Nov 15 12:59:23 2001 Return-Path: Received: from sundown.cs.cornell.edu (sundown.cs.cornell.edu [128.84.96.20]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFHxLR02725; Thu, 15 Nov 2001 12:59:22 -0500 (EST) Received: from khaffy (mail@d2102.dialup.cornell.edu [132.236.155.102]) by sundown.cs.cornell.edu (8.11.3/8.11.3/R-3.6) with ESMTP id fAFHxJ222959; Thu, 15 Nov 2001 12:59:20 -0500 (EST) Received: from andre by khaffy with local (Exim 3.22 #1 (Debian)) id 164LCs-0000kg-00; Thu, 15 Nov 2001 13:01:22 +0100 Date: Thu, 15 Nov 2001 13:01:22 +0100 From: =?iso-8859-1?Q?Andr=E9?= Allavena To: egs@CS.Cornell.EDU Cc: andre@CS.Cornell.EDU Subject: 615 PAPER 47 Message-ID: <20011115130122.A2778@khaffy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.18i Sender: =?iso-8859-1?Q?Andr=E9_Allavena?= SPINS: Security Protocols for Sensor Networks This paper presents an approach to securing the communications between sensor nodes and a base station. The constraints are the following: - tiny devices (slow processor, really small memory) - do not impact on communication costs (energy is a scare resource) - the base station is assumed t be trust worthy Because of the low resource possibilities, the cryptographic system as to be sysmetric (assymetric would necessitate too many resources). So there is a pair of key for each sensor (the other one is for the base station). One to One comunication: SNEP (BS - sensor) Data is first encrypted, the encryption is signed. The key to do that uses the privious key and a counter which increments with time (the sensors and the base station are assumed to be roughly syncronised) Hence there is semantic security, data authentication, reply protection and weak freshness (ordering) Broadcast: µTESLA (BS -> sensors) This uses the S/Key one time password idea: there is a pubmic one way function, and the sensor nodes all know the base key K_0 (the base station, and only it, know K_n such that f(f(f(...f(K_n)))))=K_0). Time is sequenced: Messages are crytped using K_1 during 0 and T, using K_2 during T and 2T, etc. During the next phase (or the following one due to time syncronisation) the previous key is broadcasted. Authentication can be done now (but the packets must be held in a buffer). This can be an issue (too many packets being stored). Also, not much is said for inter sensor communication (routing - is there really a need here). Missing is a definition of who is/are the adversary we are trying to protect against. What is its resources? An other concern is the way they use the counter to modify the key. Do they just add the numbers? Do they do something else? Knowing the scheme, you should be able to discover the time frame (this defetively if you corrompt one sensor, and maybe even if you don't do so). Then you can syncronise increments in the key with different encryptions. Can you do something with this? You might, at least they don't say a word that they woun't care. -- André Allavena (local) 148 B Valentine Place École Centrale Paris (France) Ithaca NY 14850 USA Cornell University (NY) (permanent) 879 Route de Beausoleil PhD in Computer Science 06320 La Turbie FRANCE From gupta@CS.Cornell.EDU Thu Nov 15 13:25:14 2001 Return-Path: Received: from zinger.cs.cornell.edu (zinger.cs.cornell.edu [128.84.96.55]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFIPCR06006 for ; Thu, 15 Nov 2001 13:25:12 -0500 (EST) From: Indranil Gupta Received: (from gupta@localhost) by zinger.cs.cornell.edu (8.11.3/8.11.3/C-3.2) id fAFIPCC06203 for egs@cs.cornell.edu; Thu, 15 Nov 2001 13:25:12 -0500 (EST) Message-Id: <200111151825.fAFIPCC06203@zinger.cs.cornell.edu> Subject: 615 PAPER 47 To: egs@CS.Cornell.EDU Date: Thu, 15 Nov 2001 13:25:12 -0500 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SPINS: Security protocols for sensor networks. Perrig, Szewczyk, Culler, Tygar. Reviewer: Indranil Gupta The authors present protocols for data confidentiality, authentication (and integrity). This is done through a public-key (and private key) infrastructure. The authors concentrate on low overhead for security protocols, as sensor nodes typically are small-scale. Packets sent from these sensor nodes are typically lesser than 30 B long, and the computational overhead on the sensor nodes also needs to be low. The SNEP sub-protocol uses message authentication codes (MACs) and a safe (implicit) sequence number to ensure secure and efficient communication between a pair of end points. These techniques also ensure replay protection (seq #s), data authentication (MAC), and weak freshness (MACs). Mu-Tesla is a protocol for authenticated broadcast, and it uses a reverse key chain, obtained through hashing, to authenticate broadcasts. The reverse key chain ensures that no one can duplicate the key, yet the next new key can be verified from the chain of previous keys. The protocols add a third of overhead to packet transmission (in terms of energy), and perform better than TinyOS' original security protocols. Comments: - One of the shortcomings in most papers on security in ad-hoc (or sensor) networks is that they consider the hosts within the network to be trusted. A host with a public-private key may be malicious, and send out information, properly authenticated, that causes the system to stall or crash. The black hole routing problem is an example. - Having small keys (say 16 bits) brings in the question of a new tradeoff not seen in traditional systems. There is an added rate of public key dissemination (of each node) to all nodes, and this overhead plays off against the overhead of having larger keys. From jcb35@cornell.edu Thu Nov 15 14:37:52 2001 Return-Path: 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.7) with ESMTP id fAFJbpR15281 for ; Thu, 15 Nov 2001 14:37:51 -0500 (EST) 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 OAA01395 for ; Thu, 15 Nov 2001 14:37:46 -0500 (EST) From: jcb35@cornell.edu Date: Thu, 15 Nov 2001 14:37:46 -0500 (EST) X-Sender: jcb35@travelers.mail.cornell.edu To: egs@CS.Cornell.EDU Subject: 615 PAPER 47 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII SPINS: Security Protocols for Sensor Networks This paper discusses security in sensor networks where each node has a very small amount of resources and must be energy conscious. Previous schemes for security cannot be effective in ad hoc networks due to the limitations of processing power and ram. This paper identifies a couple of security protocols for sensor networks: SNEP - this protocol uses a shared counter between the sender and receiver for a block cipher. A message authentication code (MAC) serves for two-party authentication and data integrity. uTESLA - This is based on TESLA, but uses symmetric mechanisms for signature. It discloses keys once per epoch instead of each packet. Also, uTESLA restricts the number of authenticated sensors because it is expensive to store a one-way key chain in a limited amount of memory. From daehyun@csl.cornell.edu Thu Nov 15 14:46:53 2001 Return-Path: Received: from wilkes.csl.cornell.edu (wilkes.csl.cornell.edu [132.236.71.69]) by sundial.cs.cornell.edu (8.11.3/8.11.3/M-3.7) with ESMTP id fAFJkpR16134 for ; Thu, 15 Nov 2001 14:46:51 -0500 (EST) Received: (from daehyun@localhost) by wilkes.csl.cornell.edu (8.9.3/8.9.2) id OAA53098 for egs@cs.cornell.edu; Thu, 15 Nov 2001 14:46:46 -0500 (EST) (envelope-from daehyun) From: Daehyun Kim Message-Id: <200111151946.OAA53098@wilkes.csl.cornell.edu> Subject: 615 PAPER 47 To: egs@CS.Cornell.EDU Date: Thu, 15 Nov 2001 14:46:46 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This paper presented a protocol called Security Protocols for Sensor Network (SPINS). SPINS is designed to solve security issues on the resource constrained wireless networks. SPINS is compose of two building blocks - Secure Network encryption Protocol (SNEP) and Micro Timed Efficient Streaming Loss-tolerant Authentication Protocol (uTESLA). SNEP provides Data confidentiality, two-party data authentication and data freshness. And, uTESLA provides authenticated broadcast. Data confidentiality is achieved by encryption. Data authentication is used for receivers to verify the sender of data. Two types of data freshness is given - weak freshness which provides only a partial ordering and strong freshness which provides a total order. uTESLA solves the problem of conventional asymmetric digital signatures which requires high communication overhead so is not suitable for sensor networks. The main contribution of the paper is that they paid attention to the security problem of sensor network. The security issues of resource limited networks have different characteristics from those of other conventional networks. this paper identifies those features and proposed a solution for the problems. I think there is a problem in the evaluation of their protocol. They evaluated the efficiency of their protocols. But they didn't say much about the security issues. In my opinion, their evaluation method is out of point. From wbell@CS.Cornell.EDU Thu Nov 15 17:03:36 2001 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.7) with ESMTP id fAFM3ZR13157 for ; Thu, 15 Nov 2001 17:03:35 -0500 (EST) Received: from [192.168.1.106] (syr-66-24-16-64.twcny.rr.com [66.24.16.64]) by postoffice.mail.cornell.edu (8.9.3/8.9.3) with ESMTP id RAA17611 for ; Thu, 15 Nov 2001 17:03:14 -0500 (EST) Subject: 615 PAPER #47 From: Walter Bell To: egs@CS.Cornell.EDU Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.1+cvs.2001.11.07.16.47 (Preview Release) Date: 15 Nov 2001 16:59:46 -0500 Message-Id: <1005861631.1428.0.camel@brute> Mime-Version: 1.0 47) SPINS: Security Protocols for Sensor Networks This paper addresses the issue that's been sitting in the back of our minds during most of this class: so we can do great things with wireless ad-hoc networks, but haven't we opened a huge security hole on many fronts? This paper attempts to provide an infrastructure for providing more secure communication between sensor nodes in a sensor network. They focus on message authentication and message encryption under very constrained environments. They present results of their findings using their small nodes with 8k of instruction memory and 512 bytes of memory. The conclusion is that conventional security mechanisms cannot be used on small sensor networks, and that managing the tradeoffs between security and resource consumption is required in order to be feasible in these environments. To that end, they evaluate different approaches to providing secure communication and the trade offs involved. The first thing they note is that the most expensive operation a node can do is transmit data; hence it is not feasible to increase the size of messages transmitted substantially, and hence they are limited to encryption and authentication mechanisms that rely on shared state and don't explicitely send unnecessary data between nodes. The other resource consumption problem comes with limited memory; the encryption and decryption code must be small, as well as the memory needed to do the encryption and decryption must be small as well. This tends to throw out asymmetric encryption mechanism because of the seperate encryption and decryption code. I think the analysis was useful here, but the importance of the specifics is fleeting as processors become more powerful and memories become larger. There will always be the need for smaller and smaller nodes, but it's not clear that the specifics here are that important. It would be worthwhile to do a survey of the available technologies in this space and their advantages/drawbacks on very constrained nodes.