Lecture #8: Security in Sensor Networks

1. Lecture #8: Security in Sensor Networks Ack: slides by Saurabh Ganeriwal

2. Sensor Network Functionality

3. Security Challenges • Securing the communication channel • Resource constrained devices, scale, lack on built-in access control mechanisms, possibility of node compromise etc. • Needs: data confidentiality, data integrity, node authentication • [Chen00, Undercoffer02, Perrig04] • Securing the physical context • Sensor readings meaningfully interpreted only in the physical context of the node • Needs: secure and verifiable estimation of physical context (location, time etc.) • [Manzo05, Capkun05, Sahar05] • Securing the sensor measurement • A single bad reading can mislead the whole network • Needs: explicit methods for sensor data authentication • [Ganeriwal04c]

4. Handle compromised nodes Existing solutions not portable Beyond network security Why do we need something new? • Sensor nodes have to be cheap • No physical security feasible. • Unmanned and untethered • No centralized supervision. • Severe resource constraints • Limited memory, computation power,… • Scale • Hundreds of nodes • Not just transmitting raw bits • Sensing, data processing, performing action. • Strong coupling with physical world. • Strong dependence on middleware services

5. Securing Middleware Securing Data processing Securing Network Communication Generalized architecture Applications Resilient aggregation Collaborative Data Processing Middleware Routing Timesync Localization Key Management Group Key Pair-wise key Cryptographic Mechanisms TinySec TinyPK AES in hardware

6. Organization of the Lecture • Securing Network Communication • Cryptographic mechanisms • Key Establishment & Management • Authenticated Broadcasts • Side Channel attacks • Securing Middleware • Localization • Time Synchronization • Securing Data Processing • Reputation-based Framework for Sensor Networks • Secure Event Reporting

7. Cryptography: Confidentiality, Integrity, Authentication, Availability

8. Confidentiality Eve should not be able to understand the information being sent by Alice to Bob. ACK: Source unknown, From the web

9. How to achieve confidentiality? Encrypt • Alice will perform encryption and will send the Ciphertext to Bob Encryption : EK(e){plaintext} = Ciphertext • On receiving the packet Bob will perform decryption to retrieve the plaintext. Decryption : EK(d){Ciphertext} = plaintext • Secret is in the keys K(e) and K(d). • Eve cannot perform valid decryption, as it does not know k(d). • If keys for encryption and decryption are the same, i.e., k(e) = k(d). • Symmetric cryptography • DES, AES, RC5 • If k(e)  k(d) • Asymmetric cryptography • RSA

10. Integrity Bob should be able to verify that information was not modified on the route. ACK: Source unknown, From the web

11. How to achieve integrity? Message Authentication Codes (MAC) • Alice attaches a cryptographic checksum (MAC) at the end of the packet. M = MAC{K, plaintext}; Send (plaintext, M) • On receiving the packet Bob recalculates the MAC and verifies whether it is equal to the one received in the packet. • If packet was modified, MAC verification will fail. • Why can’t Eve modify the plaintext, recalculate a new MAC and then send it to Bob. • Secret is again provided by the key K -> Only Alice and Bob knows it. • The MAC function has to be one-way! • MD5, SHA

12. Authentication Bob should be able to verify that it is Alice sending the message Comes as an auxiliary benefit from using secret keys ACK: Source unknown, From the web

13. Availability Alice should be able to send the message to Bob. Denial of service attacks ACK: Source unknown, From the web

14. How to counter availability attacks? • Studied in context of many sub-problems • And solutions are attack-specific • Three sub-properties that provides reasonable resistance to availability attacks: • Non-repudiation • Making everyone responsible for there actions! • Access Control • No external nodes should be able to access the resources of the network. • Both “non-repudiation” and “access control” have parallelism with authentication. • Freshness -> Differentiate between old and new messages • Use sequence number or clock.

15. Sensor Networks: Design Philosophy • In-network Processing, Decentralized decision making • Nodes need to securely communicate with other nodes in local vicinity. • End-to-end security protocols such as IPsec, WEP not applicable. • Develop link-layer security architecture. • Severe resource constraints • Concentrate on symmetric cryptography leaving asymmetric to only handle special cases. • Diverse requirements • Temperature monitoring v/s Counter-sniper system • Provide hooks to control the cryptography being used.

16. m1 m2 iv Ek Ek Ek c1 c2 CBC-Mode TinySec [Karlof03] • Use block ciphers for encryption – no size expansion! • CBC-mode: break a m bit message into 64 bit chunks (m1,m2,..) • Transmit (c1, c2, …) and iv • iv is needed to achieve semantic security • Same message looks different every time • Length of iv – 2 byte counter + existing packet header • Have implemented Skipjack • Same protocol being for MAC generation • 4 bytes long.

17. Tricks & Features • Don’t encrypt the destination address • Allows early rejection! • Support fine-grained mixed-mode usage • 3 settings: no crypto, integrity only, integrity+secrecy • Can select settings on a per-packet basis. • Reduce overhead • Get away with group field -> Global key provides network identity. • Get away with CRC -> MAC provides checksum. • On the fly crypto! • Interleave crypto calculations with I/O. • While transmitting first byte, encrypt the second byte. • Possible! • 0.82ms/block for crypto; 2.4ms/block to transmit over radio

18. Packets & Predicted Overhead Old packet (CRC): +7 b Integrity Only (TinySec-Auth): +8 b Integrity, Encryption (TinySec-AE) : +12 b IV

19. 802.15.4 standards • AES is available in hardware • Removes the need for software based cryptography such as TinySec • Design similarities to TinySec: • 3 security modes: off, auth, auth + encryption • MAC calculation is block cipher based • Design differences to TinySec • Larger security parameter choices, 16 byte IV • MAC size variable, 0..16 bytes • Encryption: CTR mode

20. KEY ESTABLISHEMNT & MANAGEMENT

21. How many keys a node should maintain? • Globally shared secret key • Safeguard from external attackers • Secret key with base station • Base station should be able to authenticate nodes. • Pairwise secret key • Nodes should be able to authenticate each other. • Most important! • Collaborative data processing holds the key to success.

22. Secure Link Approach I: Pre-assignment • General Idea • Pre-assign a unique key to every node. • Pairwise key establishment. • Use base station as central trust • Some existing protocols • SNEP [Perrig 01] • [Chen 00] • [Undercoffer 02]

23. Evaluation Advantages: • Perfectly resilient to node capture. • No leak of information. • Safeguards system against external adversaries. Neutral: • Pairwise key establishment is expensive. • Loss for dynamic topologies. Disadvantages: • Addition of new nodes. • Not scalable • Generate N unique & random keys (N can be 10,000)

24. Approach II: Random Key Assignment • Map random graph theory to key selecting problem • Each node randomly picks r keys from a unordered key pool S. • Use the common shared key to establish a secure link. • Relies on probabilistic key sharing among the nodes of a random graph. r = 2 K1, K3 A S has 100 keys K3 C K1 K1, K2,…, K100 K3, k7 D B K1, K5

25. Existing solutions • Basic Scheme [Eschenauer02] • Extended to q-composite scheme [Chen03] • Secure link only if nodes share q keys! • Adaptive Random key distribution [Huang03] • Use two dimensional key pools • Blom scheme [Wenliang03] • Based on public/private matrix • Polynomial key pools [Liu03] • Assign polynomial generator functions instead of keys • General framework for pairwise key establishment in sensor networks [Liu 04]

26. Evaluation Advantages: • Pairwise Key establishment Neutral: • Reasonably scalable • Resiliency to node capture • Addition of new nodes • How to stop the adversaries from snooping? Disadvantages: • Cannot safeguard against external adversaries • No globally consistent secret is maintained! • Very sensitive to choice of parameters • Wins can change to neutral to losses

27. Comparison

28. Approach III: Post-deployment derivation • Pre-assign a single global key (same for everyone) at every node • Derive further keys at runtime based on properties of the node from this global key. • Location based (LDK) [Ye04] • Physical attributes based (PAKE) [Ganeriwal04a] • Identity based [Anderson 05] • General approach • Both node 1 and node 2 will have the key KI before deployment • They both can calculate k12 K12 = HKI(id1 || PA1 || id2 || PA2) • They can start using k12 for securely communicating with each other without ever explicitly telling it to each other.

29. Key-set up phase Normal system No compromise during this phase Erase KI at this point No valid keys can be generated here Security analysis • External adversary • Cannot generate K12 as it does not have knowledge of KI • Internal adversary • Can potentially generate K12 • Trick – Get rid of KI as soon as possible

30. Evaluation Advantages: • Scalable • Deterministic pairwise key establishment • Deterministic unique key establishment • Safeguards from external adversaries • WORKING IMPLEMENTATION AVAILABLE Neutral: • Addition of new nodes • Requires trustworthy nodes to act as peers. Disadvantages: • Hinges on binary security • If bootstrap phase is fine, everything is fine.

31. Approach IV: Hardware Assist viaTrusted Platform Module

32. Trusted Platform Module (TPM)

33. Exploiting TPM in Sensor Networks

34. Establishing Symmetric Key

35. Key Establishment Protocol

36. Handling Mote Mobility

37. Handling Mote Mobility

38. Comparison of Key Establishment Schemes

39. Sample Implementation (Ganeriwal, 2005) Mote Microserver Latency Analysis 2 SG + 8 MicaZ

40. Other Uses of TPM • Secure in-network storage • Secure code deployment • Attestation of remote sensors

41. AUTHENTICATED BROADCASTS

42. Authenticated Broadcasts: Problem Formulation • Node wants to communicate with multiple nodes simultaneously • For example, base station wants to send some control information to all the nodes • Need for doing a broadcast • Nodes should be able to verify the identity of the sending node so that they do not act upon bogus information from a malicious node. • Need for authenticated broadcast. • So what is the problem? • Can’t the base station just attach a MAC. • Which keys should it use? • Pairwise keys cannot be used!

43. Private Key RSA Public Key Signature Data Text Text RSA Asymmetric cryptography • One sender, many receivers • Need for asymmetric primitives! • Private-public key • What does this buy us? • Many (all who have the public key) can verify but only can generate (the base station with the private key). • Public key to private key mapping is not feasible!

44. TinyPK – Tiny Public Key [TinyPK04] Being developed by BBN. Platform are motes • Slow but feasible! • Implemented key generation using Diffie-Hellman algorithm • ~19 sec for 768 bits Prime and 114 bits exponent • ~34 sec for 1024 bits prime and 114 bits exponent • Slow but a one-time cost – Don’t care Timing tests for RSA, public key operation with exponent 3 and varying modulus sizes: Results on Mica1 10x improvement on Mica 2

45. µTESLA [Perrig 01] Abstract asymmetric nature using symmetric cryptography • Divide time into slots • Use a different key in every slot. • Base station uses Ki in slot i. • Ki is not yet known to nodes. • They simply store the packet on receiving it. • Base station reveals Ki in slot i+ • Nodes on receiving the key • Authenticate key Ki • Authenticate packet received in slot i • So how does this helps? • As Ki was only known to the base station in slot i • Nobody could have impersonated the base station in slot i. • But Ki is now (slot i+) known to everyone. • But, ki is not valid any more for generating new packets.

46. F(Kn) F(K2) … Kn-1 K1 Key Authentication Use one way hash chain • F(K1) = K0, F(F(K2))) = K0 F(K1) K0 Kn Base station loads every node with K0 at the onset of the system

47. -Tesla in action • Keys are disclosed after 2 time intervals • Scenario 1 • P1, & P2 sent in slot 1 along with MAC generated using K1 • P3 sent in slot 2 along with MAC generated using K2 • P4, P5 sent in slot 3 along with MAC generated using K3 • A special packet is send disclosing K1 • Node authenticates by K0 =F(K1) • Node authenticated P1 & P2 by using K1

48. Evaluation Wins: • Based on cheaper symmetric primitives Neutral: • Nodes must buffer broadcasts until key is disclosed • Require time synchronization. Losses: • Too restrictive! • What about authenticated broadcasts in neighborhood? • Extensions to µ-TESLA protocol are also available • Concentration is on optimization such as looser time-sync assumptions, reduced packet overhead etc. • Authenticated broadcasts by nodes is still an unsolved problem!

49. Routing [Karlof03b] All insecure

50. Cryptanalysis: Breaking cryptography