[IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Privacy preservation schemes for querying wireless sensor networks

Download [IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Privacy preservation schemes for querying wireless sensor networks

Post on 11-Apr-2017




6 download


Privacy Preservation Schemes for Querying Wireless Sensor NetworksTassos DimitriouAthens Information Technology19.5 km Markopoulo Ave., 19002, PeaniaAthens, GreeceEmail: tdim@ait.edu.grAhmad SabouriChair of Mobile Business & Multilateral SecurityGoethe University FrankfurtFrankfurt, GermanyEmail: ahmad.sabouri@m-chair.netAbstractIn this work we study the problem of queryprivacy in large scale sensor networks. Motivated by a noveltrust model in which clients query networks owned by trustedentities but operated by potentially untrusted adversaries, weconsider several proposals for protecting the identities of thequeried sensors.Our schemes do not rely on the use of public key cryptogra-phy nor do they make any assumptions on the topology of thenetwork. Inspired by the data-centric communication modeland the collaborative nature of sensor networks, our proposalsdistribute the data in random locations to be later retrievedby random direction queries, using only local computationsand total absence of coordination. It is perhaps of interestto note that query privacy is achieved using only lightweight,symmetric cryptographic primitives.Extensive analytical and experimental results confirm thatthe proposed protocols can achieve their goals using onlyminimal communication and storage overhead.I. INTRODUCTIONWireless Sensor Networks (WSNs) have been an attractiveparadigm for pervasive computing oriented applications.WSNs have found wide applications in areas as diverseas environmental and habitat monitoring, healthcare, homeautomation, and traffic control.To accomplish the targeted functionalities, large scaleWSNs usually collect or generate vast amounts of data dur-ing their lifetime. However, the traditional trust model wherethe owner and consumers of the network are considered to bethe same does not make sense for such large scale networks.For example, NEPTUNE [1], GEOSS[2], and ORION[3] arebuilding ocean observatories and systems for observing andreporting earth, ocean and atmosphere information. The trustmodel of these networks is shaped by two factors. First,multiple organizations are involved, acting both as fundingsources and primary investigators. Even though networkowners may need to collaborate for administrative purposes,they dont have to fully trust each other due to diverginginterests. Second, external organizations interested in theareas monitored by the sensor network may be willing topay for access to sensor readings [13].The type of networks described above introduces newconcerns regarding privacy for the end-users. Since end-users are accessing the network via services provided bythe network owners and operators, information about theiridentity along with their access pattern or the region ofinterest can be abused by the servers against the usersinterest.In this work we consider the problem of query privacyin outsourced WSNs. Motivated by robustness, scaling andenergy efficiency aspects, we propose a number of schemesthat draw their inspiration from the Data-Centric (DC) com-munication paradigm of sensor networks [4]. Our schemesare based on the observation that if sensor readings aredistributed in random locations in the network and queriesare sent towards random destinations, query privacy can beenforced even under the presence of malicious nodes in thenetwork. We compare our findings against previous workand we validate the performance and the effectiveness of ouralgorithms using both analytical and experimental results.The rest of this paper is organized as follows. Section IIdiscusses previous methods along with their strong and weakpoints. The network model, assumptions and the privacyproblem we consider in this work are stated in Section III.Section IV, gives the details of our schemes and an analyticalmodel for the costs incurred. A data tagging scheme isnecessary to achieve the desired privacy properties; this isdiscussed in Section V. Several issues related to the proposedprotocols are discussed and validated experimentally inSection VI. Finally, Section VII concludes the paper.II. RELATED WORKProviding anonymity across untrusted networks has beenstudied in various contexts ([5], [6], [7]). Onion Routing[8]principles also became the basis of many schemes such asTOR[9] for providing anonymity in untrusted networks.Regarding WSNs, an initial attempt to provide anonymityof network structure has been made in [6] where thenetwork protocol leverages a dynamic virtual infrastruc-ture on top of the physical layer. Anonymity in clusteredwireless sensor networks has been studied in [10] and twoanonymous schemes have been proposed. However, theseschemes assume the secret keys shared between sensornodes and the base station are not compromised and thatnodes inside a cluster are not distinguishable. Assumingknowledge of the location by the nodes and the ability ofSeventh IEEE International Workshop on Sensor Networks and Systems for Pervasive Computing978-1-61284-937-9/11/$26.00 2011 IEEE 178direct communication with the base station, [5] providestwo techniques of anonymity based on one-way keyed hashchains. It is possible, however, for an adversary to eavesdropon the communication and compromise a nodes data andencryption keys [11].Another work on anonymous data collection [12] is basedon perturbations but does not use provably secure crypto-graphic techniques. In order to provide query privacy inWSNs, [13] proposed a scheme using two servers. Thisapproach, however, is not efficient in terms of storage be-cause each node must share a key with a client. Furthermore,privacy is completely lost against colluding servers.A recent work on privacy-preserving querying in WSNswas presented in [11] based on the Onion Routing methodol-ogy. This scheme, however, is based on asymmetric cryptog-raphy which is not a good option for low processing powerdevices. Furthermore, the onion routing scheme results in alarge overhead for the message size and leads to high powerconsumption since transmission is the most costly operationin sensor nodes. Finally, knowledge of the network topologyis assumed which is not the case in our proposed schemes.III. NETWORK MODEL AND ASSUMPTIONSThe network setting we consider here consists of nodesdenoted by {1, 2, ..., }. Sensors are considered to havesome storage facilities to save their own measured data orthe data received from others.There are three distinct entities participating in the pro-tocol namely the network owner, the network operator andthe client which we refer to them as , and , respectively. is the entity who initializes thenodes and may share some keys with them. providesthe gateway, , to the clients in order to access thenetwork. Any query which goes through the network mustbe submitted to . Responses to queries are returned to for delivery to the client. The privacy problem in thiswork follows the same formulation as in [11]. Since owns , it will be considered as a potential adversary. Thechallenge here is to ensure that the identity of the queriedsensor cannot be disclosed by the adversary.In this paper we consider an adversary as an honest-but-curious one who controls both and [11]. Itcan eavesdrop on the packets but does not actively interferewith the specified behavior of the protocol. Furthermore is considered to be able to compromise nodes in thenetwork, where 0 . Once a node is infected, learns all of its secret keys and can thus obtain the plaintextof all incoming and outgoing messages. We note that theprivacy of is out of scope for this work. doesnot care if knows that she is querying the network.IV. PRIVACY PRESERVATION SCHEMESExternal Storage model: The simplest model that could beused to achieve query privacy is to have an external storageserver which belongs to the trusted party and receivesdata collected by the sensors. In this case all queries aresubmitted to the storage server. Here the network follows thereport-on-sense model; all nodes send their data constantlyat a cost of () per event. Since there is no need to keepany information internally, the cost for local data storage is(1). Overall, this scheme is impractical if the sensing rateof sensors is large compared to number of queries. Privacyhere reduces to the Private Information Retrieval (PIR) [14]problem which has been well studied in the literature buthas not not reached the point of being practical yet [11].Local Storage model: In this model, event informationis stored locally at each node. However, queries must beflooded to all nodes at a cost of (). To avoid privacy loss,the client must query and receive data from the entire set ofsensors since otherwise it would be easy to spot the reportingnode. This would achieve perfect privacy but would resultin a massive waste of energy. To avoid this problem, theauthors in [11] assume knowledge of the network topologyand use the onion routing technique to target a specific node.The goal is to reduce communication costs while at the sametime achieving a good level of privacy.Data-Centric model: In the data-centric (DC) model, dataare named by attributes; a node storing information aboutan event is determined by the events name. Thus, all datarelated to similar events will be stored at the same node (notnecessarily the node that originally gathered the data) [4].The advantage of this approach is that queries for data can besent directly to the node storing these named data, at a costof (), thereby avoiding the query flooding typicallyrequired in other proposals. Unfortunately, this method isunattractive from a privacy point of view. Addressing aspecific storage node can leak information about the originalone as the mapping between sensing nodes and storage onesis deterministic and well known in advance. In what follows,we will address this problem while at the same time maintainthe communication benefits of the DC approach.A. Random Direction QueryThe idea is to abandon the deterministic model of address-ing nodes and utilize the routing topology of the networkto select witnesses for a nodes data. In particular, wewill propose protocols that randomize the witnesses for agiven nodes readings (by replicating these readings), so thatthe adversary cannot anticipate their identities. An implicitbenefit of this approach is that we no longer need to rely onknowledge of the network topology as in [11].For this approach to work there must exist a taggingmechanism so that witnesses can identify requested datawithout disclosing any information about the originator. Adescription of such a tagging mechanism is deferred toSection V. Once such a mechanism is in place, randomqueries can be used to obtain the required data without179revealing the identity of the queried node. We can organizethe details of this approach in the following three steps:Sensing: Upon a new reading, each node selects randomlocations and sends its data to the closest nodes to eachlocation using a geographical routing algorithm such asGPSR [15]. Data is encrypted using a key shared betweenthe sensor and before deployment, and tagged appro-priately (Section V). Encrypted data does not disclose theidentity of the originator so even the direct neighbors of thenode cannot realize if it is fresh data or forwarded ones.The tag transmitted with each encrypted reading gives theopportunity to match the query with the data. The originatorstamps the data with an expiration time so that replicas canbe discarded after expiration.Querying: There is a server owned by the trustedparty where can request for a query to be properlygenerated. Therefore can easily take this query andsubmit it to . will forward this query to randomdestinations hoping to hit one of the replicas.Replying: When a node receives a query, it analyzes thetagging information included in the query to check if it hasthe requested data available in its storage. In the case ofmatching tag, the node replies back with the encrypted data.In order to have a successful query at least one of the selected destinations must be among the replicas. Thequery will fail when all the selected nodes are from the non-replicas. Thus, the probability of failure is (, )/(, ), which can be upper bounded by (1/)or , given that (1 ) < , for < 1. Hence theprobability of having at least one of the queries meetingthe data is 1 . For example, when = or = = , is at least 63% and grows rapidly forlarger values of , .Regarding resources, on average each replica node mustsupport () readings. Thus, in a 10000 node network,a random node will be the recipient of about a hundredreadings from nodes that sense and transmit their data.Also, due to each replication process, there are point-to-point communications per sender which leads to a cost of() for sensing plus () for querying, or ()if = = ().Figure 1 depicts how this scheme works when = 2 and = 3. The originator node indicated by a solid black circlehas replicated its data in 1 and 2. has sent the queryto the three destinations 1, 2 and 3. As it is shown,only the third query has met the required data.B. Random Direction Query+To reduce the costs of the previous protocol, we inves-tigate a different scheme inspired by the work on RumorRouting [16]. We note that nodes in a sensor networkoperate both as sensing devices and as routers. For a sensorsFigure 1. Random Direction Query: = 2, = 3reading (or query) to travel from note to node , itmust pass through a number of intermediate nodes. If theseintermediate nodes also store the sensor data, effectively aline is drawn across the network. If a query ever crossessuch a line, then the data will reach the client much fasterthan in the first case. This will result in significant savingsin communication costs as we explain below.It can be shown ([17]) that the expected number of inter-sections of randomly drawn lines intersecting within thebounds of the unit circle is given by ( 1) ( 16 + 2451442).So, with three lines, we expect to have two collisions.Similarly[16], Monte-Carlo simulations show the probabilityof two lines intersecting in a bounded rectangular region tobe approximately equal to 69%. So, in our enhanced queryscheme, we are going to achieve a high probability of hittingthe required data by replicating them on all the nodes in thepath toward the selected locations as well as checking allthe intermediate nodes in the query paths. 69% probabilityof success is for the case where = = 1.The transmission cost now is reduced by factor of ()for sensing and querying. Since we need to keep the taggeddata on all the nodes in the path, the storage cost per replicastill remains equal to (), on average.The same example is used as before (Figure 1) but thistime, all the nodes in the path towards 1 and 2 keep acopy of data in their storage and all the nodes in the querypath will be investigated for the required data. In this case,the query toward 2 also meets the desired data in its way.C. Approximate Costs & ComparisonIn this section we develop an analytical model to comparethe various schemes. Let denote the total number ofreadings (sensed events) and the total number of queries.Table I provides the overall communication costs of ourschemes in terms of , , , , , and . Althoughthe external server case reduces to the PIR problem, it isincluded here for comparison.180Table ICOMMUNICATION COSTSTransmissionExternal Storage Server Random Direction Query = = + = (( +))Random Direction Query+ = = 1 + = (( +))For example, in the second row we see that for everysensed event, the sensing node must replicate the event in other sensors for a total cost of . Similarly, everyquery must be disseminated to random locations for a totalcost of . The same is true in the third row but nowboth , are constant.To provide a comparison with the work in [11], however,we need to take into account the packet size. The work in[11] follows the Onion Routing technique in which casethe packet carries information for all the nodes in path,therefore the one-hop transmission cost is not the same as inour schemes (in our case a packet carries just one sensorsdata). In particular, the authors required the size of onion tobe always the same in order not to disclose any informationabout the distance to the target. Thus the onion needs tohave a size of (). In what follows we define a newmetric, the Effective Transmission Load (ETL), as = ,where is the transmission cost of a constant size packetand the packet size. For the schemes presented in thispaper the packet size is (1). As a result we can summarizethe ETL factor for each of the schemes in Table II.Table IIEFFECTIVE TRANSMISSION LOAD (ETL)ETLExternal Storage Server Random Direction Query ( + )Random Direction Query+ ( + )Onion Routing approach [11] 2 = 2The simplest Random Direction Query scheme comparesfavorably with the scheme in [11], provided the total numberof readings is smaller than the number of of queriesin the network. This can be the case of a frequently queriedsensor network.1 The enhanced scheme is a clear winnerin terms of communications costs (case = = 1) byalmost a factor of (). The larger storage costs in thesecases maybe be considered a necessary tradeoff to accountfor the heavier asymmetric cryptography computations andnetwork topology knowledge required in [11].1Independence of in the Onion routing case is attributed to the use ofthe read-on-demand model. In this model a node never senses continuouslybut is tasked to sense only when instructed. Thus a comparison with ourschemes is meaningful only with respect to the cost of querying the networkfor data.V. TAGGING SCHEMEIn this section we consider the details of our taggingscheme. Let () and () denote the encrypted data andtag sent by sensor to a set of random replicas. When wishes to query for data, it makes a request to the trustedserver operated by and a tag is generated whichis forwarded to . is then disseminated to a set ofrandom destinations according to the methods described inthe previous section. If a replica is found such that the stored() equals , the corresponding encrypted data ()is transmitted back to and eventually to whichupon decryption delivers it to the client.Obviously, if the tagging scheme is deterministic there isa basic, brute force attack: an adversary records and thenqueries for sensor data until the server returns the targetvalue . In that case, learns the ID of the queriednode. Thus, we need to ensure that the tagging scheme isprobabilistic so that even if the same sensor is queried twice,the generated tag delivered by to will be different.The concept of indistinguishability is well studied in theliterature and comes under the name of semantic security[18]. Intuitively, if an encryption system possesses the prop-erty of indistinguishability, an adversary will be unable todistinguish pairs of ciphertexts based on the message theyencrypt. Thus, it makes sense to use a semantically secureencryption scheme to generate the tags of the messages (herewe dont have to use a Message Authentication Code schemesince, according to our threat model, the service we want toprovide is neither integrity nor authenticity of transmittedmessages). The details of our scheme follow.Let be the sensor under question and let be the key itshares with the trusted server (preloaded before deployment).For simplicity we assume that sensing occurs in phases, soduring phase , senses data . Then first produces aciphertext = (, , , ) of the data and then atag = (, ). Both and are disseminated to aset of random replicas.The key used in the construction of the tag is a phase-dependent key produced by the operation = (, ),where () is a secure one-way hash function. Upon queryby a client, the trusted server can generate this key on the flyusing the key it shares with and knowledge of the phase. Then it can also generate = (, ) that willbe forwarded to for propagation to a set of randomdestinations. Notice that indistinguishability of ciphertextsguarantees that no information leaks about the identity ofthe queried sensor. Thus the basic attack cannot longer beapplied. The question, however, becomes: how can a replicanode match the tag propagated by with the one storedin its memory if tags are different?If key is known to the replica , then can performa trial decryption of all the tags in its memory and see ifit gets back a valid plaintext (tag). If this is the case, it181Figure 2. Simulation Results for Random Direction Query Schemehas found a matching tag and can respond back with theciphertext (, , , ). So, it is necessary for toget hold of the one-time key . Although in principle itis possible to establish keys on the fly between nodes in asensor network ([19], [20]), we will refrain from doing so.Instead, we will allow to transmit in the clear oncethe phase is over. Sensor will simply send the tagging keyto the same sensors as it sent its encrypted data and tag.This is safe to do since the tag does not contain any datathat can relate a tag with a nodes ID. A malicious node upondecrypting such a tag will only get the phase value underconsideration. But this is the same for all nodes sensingdata during phase . This is also a direct consequence ofour threat model since the adversary neither modifies orblocks messages nor it interferes with a sensors behavior.2So, releasing the tagging key does not have any impact ofthe privacy of the queried nodes.VI. EXPERIMENTAL RESULTSIn this section we evaluate the effectiveness of the pro-posed schemes. We generated random network topologiesby placing 1000 nodes uniformly at random in the unitsquare with a network density (i.e. number of neighbors)ranging between 5 and 20. To ensure statistical validity, eachexperiment was repeated 100 times in which every nodereplicated its data towards random locations and queriesfor randomly selected nodes were sent towards randomdirections.We have simulated the Random Direction Query (RDQ)scheme having = , 2, 3 and 4 . Figure 2depicts the query success probability as a function of thenetwork density. Clearly the values of and must be inthe order of in order to achieve a considerable querysuccess rate. The other important factor is network densityand connectivity. As the number of neighbors increase, we2The only case that a malicious node can tell that a particular taggingkey originates from a specific node is if it overhears transmissions anddiscovers that was never the receiver of such a key. But this is highlyunlikely in a sensor network where nodes have comparable radio rangessince it would require that and have exactly the same neighbors.Figure 3. Simulation Results for Random Direction Query+ Schemewill have a better chance to route a replication and a query tothe same node. The results of these experiments imply thatin order to have a success probability of 90% we shouldhave at least = 3 and density factor around 10.Evaluation of the Random Direction Query+ (RDQ+)scheme is demonstrated in Figure 3 for = = 2, 4, 8 and12 and varying network densities. When compared with theprevious scheme we can see that the case = = 8 is aseffective as the case = 4 when the network is denseenough. The savings here are a factor in communicationoverhead. Figure 4(a) illustrates that the communication costper query grows as a function of , where = = 4and the density factor is 15. We have also measured theaverage storage requirements per node in this experimentand the results (Figure 4(b)) verify that the amount ofrequired storage is again proportional to .A. Further EnhancementsThe RDQ+ scheme was further analyzed considering thefact that whenever a node transmits some information toone of its neighbors, the rest can hear this message. So, wemodified the RDQ+ scheme in such a way to take advantageof this overhearing when forwarding a query to the nexthop. As a result, the probability of hitting a replica by aquery increases by 5-10%, depending on the case, withoutany additional storage or communication overhead (detailsomitted due to space restrictions).RDQ+ is also more robust against transmission failures inreplicating and retrieving data in the network since both datapackets and queries are sent to multiple directions. So, if oneof the data packets (readings, tags or keys) or queries fails,there is still a chance to receive the required data from therest of the replicas. As it is shown in Figure 4(c), increasingthe end-to-end failure probability even as much as 40%, thesuccess probability decreases by less than 10% for the casewhere = = 4 and the density factor is 15.Regarding the level of privacy achieved, it should be clearthat can find the ID of the queried sensor only if belongs to the set of compromised nodes (loss of privacyis proportional to / ). This is because neither the tagging182(a) (b) (c)Figure 4. (a) Growth of Communication Cost per query for RDQ+ when = = 4 and density factor is 15 (b) Growth of Storage per reading forRDQ+ when = = 4 and density factor is 15 (c) Effect of End-to-End Failure rate on success probabilityscheme nor the data stored in replicas reveal any informationabout the queried node. It is conceivable, however, that in anetwork where sensors rarely generate any readings, can locate the queried node if in two (or more) of thereplication lines emanating from , controls at leasttwo of the nodes in the line. Using location information fromthe compromised nodes, the queried node would be locatednear the point of intersection of these two lines.Assuming each replication line has length , the prob-ability of having two or more (out of ) replication pathswith at least two compromised nodes can be shown to beproportional to 2/ , for small and (details omitted).However, a simple fix exists if we modify the RDQ+ schemeas follows: instead of sending the data along a line, eachnode forwards the received data to a randomly selectedneighbor which makes an angle of more than 90 degreeswith the node which it has received the data from. Usingthis simple mechanism, the privacy problem disappears atthe expense of reducing the success probability by a mere4% (details again omitted).VII. CONCLUSIONSIn this paper, we have considered the problem of queryprivacy for clients of WSNs in which the network op-erator cannot be trusted. Without relying on public keycryptography or other heavy cryptographic mechanisms, wehave addressed the privacy problem using randomization forgetting the required data. Inspired by the data-centric modelof communication in sensor networks, we started with theRandom Direction Query scheme and gradually improvedthe performance by providing tradeoffs between storage andcommunication overheads. All schemes were evaluated bothanalytically and experimentally, validating their performanceand their effectiveness in protecting the sensor IDs to bequeried. It is of interest to note that query privacy isachieved using only standard, symmetric cryptography andno knowledge of the topology of the network.VIII. ACKNOWLEDGEMENTSResearch leading to these results has been fundedby European Communitys 7th Framework Programme(FP7/2007-2013), Call reference SEC-2007-1, under GrantAgreement no: 217925.REFERENCES[1] NEPTUNE: http://www.neptune.washington.edu/.[2] Global Earth Observation System of Systems (GEOSS):http://www.epa.gov/geoss/.[3] ORION: http://www.oceanleadership.org/programs-and-partnerships/ocean-observing/.[4] S. Shenker, S. Ratnasamy, B. Karp, R. Govindan, and D. Estrin,Data-centric storage in sensornets, Computer Communication Re-view, vol. 33, no. 1, pp. 137142, 2003.[5] Y. Ouyang, Z. Le, Y. Xu, N. Triandopoulos, S. Zhang, J. Ford, andF. Makedon, Providing anonymity in wireless sensor networks,Inter. Conf. on Pervasive Services, 2007.[6] A. Wadaa, S. Olariu, L. Wilson, M. Eltoweissy, and K. Jones, Onproviding anonymity in wireless sensor networks, ICPADS, 2004.[7] D. Chaum, Untraceable electronic mail, return addresses, and digitalpseudonyms, Commun. ACM, vol. 24, no. 2, pp. 8488, 1981.[8] D. M. Goldschlag, M. G. Reed, and P. F. Syverson, Onion routing,Commun. ACM, vol. 42, no. 2, pp. 3941, 1999.[9] R. Dingledine, N. Mathewson, and P. F. Syverson, TOR: The second-generation onion router, in USENIX Security Symposium, 2004.[10] S. Misra and G. Xue, Efficient anonymity schemes for clusteredwireless sensor networks, IJSNet, vol. 1, no. 1/2, pp. 5063, 2006.[11] E. D. Cristofaro, X. Ding, and G. Tsudik, Privacy-preserving query-ing in sensor networks, CoRR, 2009.[12] J. Horey, M. M. Groat, S. Forrest, and F. Esponda, Anonymous datacollection in sensor networks, in 4th Inter. Conf. on Mobile andUbiquitous Systems, 2007.[13] B. Carbunar, Y. Yu, W. Shi, M. Pearce, and V. Vasudevan, Queryprivacy in wireless sensor networks, TOSN, vol. 6, no. 2, 2010.[14] B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, Privateinformation retrieval, in FOCS 95.[15] B. Karp and H. T. Kung, GPSR: greedy perimeter stateless routingfor wireless networks, in MOBICOM, 2000.[16] D. Braginsky and D. Estrin, Rumor routing algorthim for sensornetworks, in WSNA, 2002, pp. 2231.[17] H. Solomon, Geometric probability. Society for Industrial andApplied Mathematics, Philadelphia, 1978.[18] S. Goldwasser and S. Micali, Probabilistic encryption, J. Comput.Syst. Sci., vol. 28, no. 2, pp. 270299, 1984.[19] L. Eschenauer and V. D. Gligor, A key-management scheme fordistributed sensor networks, in ACM Conf. on Computer and Com-munications Security, 2002, pp. 4147.[20] H. Soroush, M. Salajegheh, and T. Dimitriou, Providing transparentsecurity services to sensor networks, in IEEE International Confer-ence on Communications (ICC), 2007.183 /ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 2.00333 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 400 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00167 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles true /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /NA /PreserveEditing false /UntaggedCMYKHandling /UseDocumentProfile /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice


View more >