sconce
play

SCONCE 1 sconce Pronunciation: \ skn(t)s\ Function: noun Etymology: - PDF document

Aug 07, 2023 •572 likes •985 views

9/4/2008 Security and Privacy in Unattended Sensor Networks (or How to Cope with a Mobile Adversary) Gene Tsudik SCONCE Secure Computing and Networking Center UC Irvine http://sconce.ics.uci.edu Joint work with: Roberto Di Pietro

  1. 9/4/2008 Security and Privacy in Unattended Sensor Networks (or How to Cope with a Mobile Adversary) Gene Tsudik SCONCE – Secure Computing and Networking Center UC Irvine http://sconce.ics.uci.edu Joint work with: Roberto Di Pietro Claudio Soriente Luigi Mancini Università di Roma 3 University of California, Irvine Università di Roma “La Sapienza” Angelo Spognardi Di Ma Università di Roma “La Sapienza” University of California, Irvine SCONCE 1 sconce Pronunciation: \� skän(t)s\ Function: noun Etymology: Middle English, from Anglo-French sconce, *esconse screened candle or lantern, from escunser to hide, obscure, from Old French escons, past participle of escondre to hide, from Vulgar Latin *excondere, : a bracket candlestick or group of candlesticks; also : an electric light : a bracket candlestick or group of candlesticks; also : an electric light fixture patterned on a candle sconce Why SCONCE? •Lights dark corridors / passages � provides security •Can be easily turned / blown off � provides privacy when needed 2 1

  2. 9/4/2008 My Group’s Current Research Topics � Security in Unattended Sensor Networks � Forward-secure aggregate authentication Coping with mobile adversary Coping with mobile adversary � � Self-healing sensors � � Usable Security � Pairing of Ubiquitous Devices (e.g., phones, PDAs): security + ease-of-use + low overhead Security/Privacy for RFID tags � Group Key Management � � How to share a secret key in a group (e.g., for conferences) in efficient and robust manner Privacy-Preserving Services � Revocation-Checking with Privacy � Privacy-Enhanced Internet Name Lookup (hiding source and target of DNS query) � � Authentication with Affiliation Hiding (Secret Handshakes): 2-party and multi-party � Policy-Based Privacy-Preserving Information Transfer Privacy in WSN queries � Privacy in suspicious MANETs � � DTN Security For further information, have a look at: sprout.ics.uci.edu, sconce.ics.uci.edu 3 Roadmap Brief Introduction to WSN-s � I t Introduction & Motivation d ti & M ti ti � � A different kind of WSN New Mobile Adversary Model (with many “flavors”) � Sensor Network without networking? � UWSN: Naïve defense strategies � Cryptography to the rescue yp g p y � Self-healing � Related Work � Conclusions + challenges � 4 2

  3. 9/4/2008 A “Typical” Wireless Sensor Network Many real, alleged and imagined applications � Networking � Sensor-to-sink communication (opt. sink-to-sensors) � Collection method � Periodic collection or � Event driven E t d i or � Query based = on-demand � Online Sink � Real-time off-loading of data 5 Lots of Prior Work on Sensor Security Sensor Security 6 3

  4. 9/4/2008 Lots of Prior Work on Sensor Security Sensor Security That’s me 7 Recent WSN Security Topics � Key management � Key management � Secure routing � Secure broad-/multi-casting � Secure querying � Secure data aggregation / statistics gg g � Efficient cryptographic primitives � Various attacks counter-measures, e.g. denial-of-message, cloning, sleep deprivation… 8 4

  5. 9/4/2008 Prior Work � Almost all prior work (pre-2008) assumed that the WSN is supervised by a TTP/Collector/Sink/Base-Station/etc. � Is this always so? � What if there is no “N” in “WSN”? � What if WSN is unattended most of the time? Forward-Secure Sequential Aggregate Authentication Aggregate Authentication 5

  6. 9/4/2008 Motivation Sink Unattended collection of sensors: • Sensors do not network. Why not? Sensors do not network. Why not? • Sensors unable to communicate to sink at will (in real time) • Collect data and wait for collector • Collector not fully trusted • Off-line trusted sink C o l l e c t o r s e n s o r s Goal: authenticate data accumulated during multiple intervals 11 Two Issues Issue 1: Threat of Sensor Compromise p � � Sensor characteristics: • Low cost • No tamper-resistance • Very limited communication capabilities � Adversarial and unattended environment � Compromise Possible � need Forward Security: • Protect pre compromise data • Protect pre-compromise data • Periodic key evolution Issue 2: Storage and Communication Overhead � � Sensors have limited on-board storage � Forward-security requires one authentication tag per message 12 6

  7. 9/4/2008 Forward Security • Makes sense with symmetric encryption, MACs and public key signatures • Time divided into equal intervals • Key evolved – via OWF F() -- at the end of each interval Key evolved – via OWF F() -- at the end of each interval K 0 K 1 K i K i+1 K v TIME T 0 T 1 T i T i+1 T v-1 T v ADV breaks in 13 but, cannot compute prior keys � and leaves � can compute all future keys! Sink or TTP Backward Security K 0 K 1 K i K i+1 K v TIME T 0 T 1 T i T i+1 T v-1 T v ADV breaks in 14 and leaves � cannot compute any future keys! 7

  8. 9/4/2008 Key Insulation & Intrusion Resilience � Forward security � Backward security? � Forward security � Backward security? � Backward security � Forward security? � Backward security + forward security = Intrusion-resilience or key insulation * Suppose Adv knows: K 0 …K i-1 ,K i+1 …K v * It must be infeasible for Adv to compute K i 15 Forward-Secure Sequential Aggregate ( FssAgg ) Authentication � Combine minimal storage with mitigating potential sensor (and its signing key) compromise sensor (and its signing key) compromise � Allow signer to combine multiple authentication tags (generated in different time periods) into a single constant-size tag � Compromise of current key does not endanger authenticity of � Compromise of current key does not endanger authenticity of pre-compromise data � Verification of aggregate simultaneously verifies every component signature 16 8

  9. 9/4/2008 FssAgg IS NOT THE SAME as Aggregated Signatures � Aggregated Signatures � More general construct � More general construct � X signers produce Y (Y>X) signatures � Anyone can combine them into one aggregated signature � Aggregation can be done altogether or incrementally � Caveat: mapping between signers and messages is EXTRA � FssAgg � One signer � One signer � Key evolves each interval � One message signed per interval � Aggregation is incremental: one signature at a time is folded into the aggregate 17 Definition Component algorithms : Component algorithms : 1. FssAgg.Kg : key generation, generate the initial signing key K 0 and the verification key VK σ 2. FssAgg.Asig : aggregate sign, generate a FssAgg signature 1 , i σ on message m i and aggregate-so-far FssAgg signature with k i 1 − , i 1 3. FssAgg.Upd : key update, generate K i from K i-1 , must be a one way f nction and sec rel erase K function, and securely erase K i-1 4. FssAgg.Aver : aggregate verify, verify a FssAgg signature with the verification key VK, accept or reject 18 9

  10. 9/4/2008 Properties 1. Correctness : any FssAgg signature produced by Asig y gg g p y g must be accepted by Aver. 2. Unforgeability : without the knowledge of any signing keys, no adversary can compute an FssAgg signature 3. Forward-security : No adversary who breaks in i-th time period can generate a valid signature containing a signed message for any period j<i 19 MAC-based Scheme 1. FssAgg.Kg : any symmetric key generation algorithm to generate k- bit secret s and set K 0 =VK= s σ = ) ( , ) a MAC K m 2. FssAgg.Asig : for new message m i : i i i σ = σ σ ) ( || ) b H − 1 , 1 , 1 i i i a) K i+1 = H(K i ) 3. FssAgg.Upd : b) Remove K i , move to time i+1 4. FssAgg.Aver : To verify σ 1, i : a) Re-compute (from VK ): K 1 … K i, σ c b) Re-compute 1 , i c) Compare σ 1, i ? σ 1, i c 20 10

  11. 9/4/2008 MAC-based Scheme � Fast and space-efficient � But: � Either collector cannot authenticate tags (if doesn’t have s) or � Collector can cheat (if he has s) � Two MAC-based aggregates? � one for collector and one for sink � Or use signatures… 21 Signature-based Scheme • Boneh/Lynn/Shacham. Asiacrypt 2001 Boneh/Gentry/Lynn/Shacham, Eurocrypt 2003 • Based on BLS/BGLS signature scheme; works on groups with bilinear map e: G 1 x G 2 � G T where: G 1 and G 2 groups of order p; 2) | G 1 |=|G 2 |=|G T |; G and G groups of order p; 2) | G |=|G |=|G |; 1) 1) 3) g 1 ,g 2 : generator of G 1 , G 2 1. FssAgg.Kg : pick random x 0 from Z p , Compute pairs (x i ,v i ) s.t. x i =H(x i-1 ), and v i =g 1 xi , set K 0 =x 0 , VK={v i } σ 2. FssAgg.Asig : given: new message m i , current key K i, and aggregate-so-far 1 − , i 1 σ = ) . ( , ) a BLS sign k h i i i σ = σ • σ b ) ) b − 1 , 1 , 1 i i i 3. FssAgg.Update: K i+1 = H(K i ) , remove K i i ∏ ( σ e , g ) ? e ( h , v ) σ 1, i 4. FssAgg.Aver : To verify 1 , i 2 t t = t 1 22 11

  12. 9/4/2008 Performance Metrics Signer efficiency � Space • Time � Size of aggregate signature � Size of signing key � Complexity of key update � Complexity of aggregate signing Verifier efficiency � Size of verification key � Complexity of aggregate verification 23 Performance Evaluation � MAC scheme is near-optimal � Signature scheme is not � Signer-friendly • Constant private key and signature size • Efficient signing and key update • Efficient signing and key update � Not verifier-friendly • Public key size - O( t) • Costly pairing operations in verification 24 12

More recommend