Wireless Networks 8, 521–534, 2002 2002 Kluwer Academic Publishers. Manufactured in The Netherlands.SPINS: Security Protocols for Sensor NetworksADRIAN PERRIG, ROBERT SZEWCZYK, J.D. TYGAR, VICTOR WEN and DAVID E. CULLERDepartment of Electrical Engineering and Computer Sciences, University of California, Berkeley, 387 Soda Hall, Berkeley, CA 94720, USAAbstract. Wireless sensor networks will be widely deployed in the near future. While much research has focused on making these networksfeasible and useful, security has received little attention. We present a suite of security protocols optimized for sensor networks: SPINS.SPINS has two secure building blocks: SNEP and µTESLA. SNEP includes: data confidentiality, two-party data authentication, andevidence of data freshness. µTESLA provides authenticated broadcast for severely resource-constrained environments. We implementedthe above protocols, and show that they are practical even on minimal hardware: the performance of the protocol suite easily matches thedata rate of our network. Additionally, we demonstrate that the suite can be used for building higher level protocols.Keywords: secure communication protocols, sensor networks, mobile ad hoc networks, MANET, authentication of wireless communica-tion, secrecy and confidentiality, cryptography1. IntroductionWe envision a future where thousands to millions of smallsensors form self-organizing wireless networks. How can weprovide security for these sensor networks? Security is noteasy; compared with conventional desktop computers, severechallenges exist – these sensors will have limited processingpower, storage, bandwidth, and energy.We need to surmount these challenges, because security isso important. Sensor networks will expand to fill all aspectsof our lives. Here are some typical applications:• Emergency response information: sensor networks willcollect information about the status of buildings, people,and transportation pathways. Sensor information must becollected and passed on in meaningful, secure ways toemergency response personnel.• Energy management: in 2001 power blackouts plaguedCalifornia. Energy distribution will be better managedwhen we begin to use remote sensors. For example, thepower load that can be carried on an electrical line dependson ambient temperature and the immediate temperatureon the wire. If these were monitored by remote sensorsand the remote sensors received information about desiredload and current load, it would be possible to distributeload better. This would avoid circumstances where Cali-fornians cannot receive electricity while surplus electricityexists in other parts of the country.• Medical monitoring: we envision a future where individu-als with some types of medical conditions receive constantmonitoring through sensors that monitor health conditions.For some types of medical conditions, remote sensors mayapply remedies (such as instant release of emergency med-ication to the bloodstream).• Logistics and inventory management: commerce in Amer-ica is based on moving goods, including commoditiesfrom locations where surpluses exist to locations whereneeds exist. Using remote sensors can substantially im-prove these mechanisms. These mechanisms will varyin scale – ranging from worldwide distribution of goodsthrough transportation and pipeline networks to inventorymanagement within a single retail store.• Battlefield management: remote sensors can help elimi-nate some of the confusion associated with combat. Theycan allow accurate collection of information about currentbattlefield conditions as well as giving appropriate infor-mation to soldiers, weapons, and vehicles in the battlefield.At UC Berkeley, we think these systems are important, andwe are starting a major initiative to explore the use of wirelesssensor networks. (More information on this new initiative,CITRIS, can be found at www.citris.berkeley.edu.)Serious security and privacy questions arise if third partiescan read or tamper with sensor data. We envision wirelesssensor networks being widely used – including for emergencyand life-critical systems – and here the questions of securityare foremost.This article presents a set of Security Protocols for SensorNetworks, SPINS. The chief contributions of this article are:• Exploring the challenges for security in sensor networks.• Designing and developing µTESLA (the “micro” versionof TESLA), providing authenticated streaming broadcast.• Designing and developing SNEP (Secure Network En-cryption Protocol) providing data confidentiality, two-party data authentication, and data freshness, with lowoverhead.• Designing and developing an authenticated routing proto-col using our building blocks.1.1. Sensor hardwareAt UC Berkeley, we are building prototype networks of smallsensor devices under the SmartDust program [45], one of thecomponents of CITRIS. We have deployed these in one of522 PERRIG ET AL.Table 1Characteristics of prototype SmartDust nodes.CPU 8-bit, 4 MHzStorage 8 Kbytes instruction flash512 bytes RAM512 bytes EEPROMCommunication 916 MHz radioBandwidth 10 KbpsOperating system TinyOSOS code space 3500 bytesAvailable code space 4500 bytesour EECS buildings, Cory Hall. We are currently using thesefor a very simple application – heating and air-conditioningcontrol in the building. However, the same mechanisms thatwe describe in this paper can be modified to support sensorthat handle emergency system such as fire, earthquake, andhazardous material response.By design, these sensors are inexpensive, low-power de-vices. As a result, they have limited computational and com-munication resources. The sensors form a self-organizingwireless network and form a multihop routing topology. Typi-cal applications may periodically transmit sensor readings forprocessing.Our current prototype consists of nodes, small batterypowered devices, that communicate with a more powerfulbase station, which in turn is connected to an outside net-work. Table 1 summarizes the performance characteristics ofthese devices. At 4 MHz, they are slow and underpowered(the CPU has good support for bit and byte level I/O opera-tions, but lacks support for many arithmetic and some logicoperations). They are only 8-bit processors (note that accord-ing to [53], 80% of all microprocessors shipped in 2000 were4 bit or 8 bit devices). Communication is slow at 10 Kbps.The operating system is particularly interesting for thesedevices. We use