Li Tie Yan

1
Seminar of Infocomm security dept. at I2R
Security in Sensor network (Research issues)
Li Tie Yan InfoComm Security Department
(ICSD) Institute for Infocomm Research
(I2R) 23rd, Jul. 2004
2
Outline

• Sensor constraints, components comparison
• Security map of sensor network
• Research issues
• Light weight crypto-algorithms
• Security (attacks) analysis on distributed
  sensor network
• Key management schemes for distributed
  sensor network
• Other issues
• Secure location (context aware security)
• Secure data fusion (secure information
  aggregation)
• Challenges
• TinySec-link layer security architecture
• Ongoing project

3
Sensor constraints

• What is Sensor?
• A device that produces a measurable response to a
  change in a physical condition such as
  temperature or in a chemical condition such as
  concentration.
• Constraints Berkeley Mote (Mica Motes feature
  a 8MHz processor, 128K of program space 4k
  RAM, 512k flash, 36 byte packets, 19.2kbps and
  run on 2 AA batteries). Varied on cost, size,
  power and all for 300.
• Risks RF noise and multipath fading causes
  severe packet loss
• Easy to eavesdrop and to launch spoofing or
  Denial-of-Service attacks
• Mobility requires rerouting of packets.
• Nodes are defective, lost, damaged,
  compromised, or expired
• Applications Wildlife (GDI, Berkeley 2002)
  Habitat monitoring military surveillance,
  Medical system

4
Sensor components
Location finding system
Mobilizer
Processing Unit
Sensing Unit
ADC
Sensor
Transceiver
Processor
Storage
Power Generator
Power Unit
5
Sensor comparisons

• Sensor network vs. Ad-hoc network
• The number of sensor nodes in a sensor network
  can be several orders of magnitude higher
  than the nodes in an ad hoc network
• Sensor nodes are densely deployed
• Sensor nodes are prone to failure
• The topology of a sensor network changes very
  frequently
• Sensor nodes mainly use a broadcast
  communication paradigm, whereas most ad hoc
  networks are based on point-to-point
  communications
• Sensor nodes may not have global identification
  because of the large amount of overhead and large
  number of sensors

• Sensor vs. RFID
• Active (lt1000M) vs. passive (lt10M)
• A tag with US 5 cents. (i.e. 1 cent on Chip
  design, 1 cent on chip manufacture, 1 cent on RF
  module, 1 cent on IC/antenna assembly, 1 cent on
  packaging.)
• A tag store up to 1k bits (i.e. 100 bits for an
  ID, enough for many applications)
• A tag support 2000 logical gates (e.g. SHA-1
  needs 20000 gates).
• Very different applications (i.e. replacing
  barcode for SCM)

6
Security map
7
Security map
8
Research issues

• Light weight crypto-algorithms (TinySec, Link
  layer encryption mechanism of U.C. Berkeley)
• Constraint Based on TinyOS of Berkeley Mote
  (Mica Motes feature a 4MHz processor, 128K of
  program space 4k RAM, 36 byte packets, and
  run on 2 AA batteries).
• Light-weight Less overhead per packet
  (conventionally, the overhead is 16 byte).
• Assumption Keys are pre-distributed and shared
  by sensors (simplest solution).
• Analysis Cryptanalysis, attack analysis
• Attacks TinyOS Bless protocols (suffer Bogus
  routing information, selective forwarding,
  sinkholes, Sybil, wormholes, HELLO floods)

• Standard work
• 802.15.4, IEEE standard on MAC and PHY layer of
  LR-WPAN (Zigbee). (e.g. micaZ)

9
Research issues

• Attacks on sensor networks
• Denial of Service, by Wood et al. in IEEE
  Computer2002.
• Routing security, by Karlof et al. in 1st IEEE
  workshop SNPA03.
• Sybil attack, by Newsome et al. in ACM IPSN04.
• Key management schemes
• Key management, by Eschenauer et al. in ACM
  CCS02.
• SPINS, by Perrig et al. in Wireless Networks
  Journal (WINE), 2002.
• Random Key Assignment, by pietro et al. in ACM
  SASN '03.
• Establishing Pairwise Keys, by Liu et al. in ACM
  CCS03.
• LEAP, by Zhu et al. in proc. of ACM CCS03.
• Pairwise Key Pre-distribution, by Du et al. in
  ACM CCS03.
• Random Key Predistribution, by Chan et al. in
  IEEE SP03
• Deployment knowledge, by Du et al. in IEEE
  INFOCOM'04.

10
Other issues

• Location aware security (a problem of context
  aware security)
• Privacy-Aware Location, Gruteser et al. in
  USENIX HOTOS IX, 2003.
• Location-Based Pairwise Key Establishments, Liu
  et al. in ACM SASN '03.
• Location claims, by Sastry et al. in ACM
  WiSe03.
• Data fusion security (a problem known as False
  data injection)
• SIA, by Przydatek et al. in proc. of ACM
  SenSys03.
• Secure aggregation, by Hu et al. in workshop on
  security and assureance in Ad hoc Networks, 2003.
  
• Witeness, by Du et al. in proc. of IEEE
  GLOBECOM03.
• SEF, by Ye et al. in proc. of IEEE INFOCOM04.
• Integrity protection, by Vogt et al. in
  technical report no. 434, ETH Zrich.
• IHA, by Zhu et al. in proc. of IEEE SP04.
• uTESLA, by Perrig et al. in proc. of ACM
  Mobicom01.
• LEAP, by Zhu et al. in proc. of ACM CCS03.

Authentication based
11
Challenges

• Software only cryptography (best balance of
  security and performance, PKC)
• Efficient key management (support random key
  pre-distribution, PKC)
• Robust multi-hop routing protocols (against node
  compromise DoS attacks)
• Location aware security (or context aware
  security)
• Secure and resilient aggregation (towards False
  data injection)
• Secure data centric storage (secure indexing,
  secure overlay)

12
TinySec (The fact)

• Integration
• OS TinyOS 1.1.0
• Processors Mica, Mica2, Mica2Dot using Atmel
  Processors
• Radio RFM TR1000 and Chipcon CC1000
• SIM TOSSIM simulator
• Implementation
• 3000 lines of NesC code
• RAM 455 bytes (not an issue for applications,
  can be reduced to 256 bytes)
• MEM 7000 bytes of program space
• Real time Two priority TinyOS scheduling
  process (cryptographic computations must be
  completed by the time the radio finishes sending
  the start symbol)
• Usage
• Build maintains a key file and uses a key from
  the file, includes the key at compile time.
• Application make TINYSECtrue to enable
  TinySec-Auth.

13
TinySec (protocol stack)
Sensor applications
Sensor middleware
TinyOS active message
Light Weight Crypto-algorithms
Packet
RFM
14
TinySec (Components)
Interface TinySec
TinySecM
Radio Stack MicaHighSpeedRadioM/ CC1000RadioIntM

CBC-ModeM
CBC-MACM
Interface BlockCipher BlockCipherInfo
SkipJackM

• Use a block cipher for both encryption
  authentication
• Skipjack is good for 8-bit devices low RAM
  overhead

15
TinySec (Packets Predicted Overhead)
Old packet (CRC) 7 b
Authentication Only (TinySec-Auth) 8 b
Authentication, Encryption (TinySec-AE) 12 b
IV
16
TinySec (Encryption)

• Confidentiality achieved by encryption
  Encryption schemes (modes) can be built using
  block ciphers
• CBC-mode break a m bit message into 64 bit
  chunks (m1,m2,..) Transmit (c1, c2, )
• iv is needed to achieve semantic security (A
  message looks different every time it is
  encrypted).
• iv reuse may leak information

17
TinySec (Authentication)

• Encryption is not enough to ensure message
  integrity, Receiver cannot detect changes in the
  ciphertext Resulting plaintext will still be
  valid. Integrity achieved by a message
  authentication code
• A t bit cryptographic checksum with a k bit key
  from an m bit message Can detect both malicious
  changes and random errors
• Replaces CRC can be built using a block cipher
• MAC key should be different than encryption key

m2
m1
length
Ek
Ek
Ek
MAC
CBC-MAC Mode
18
TinySec (IV allocation)

• Most secure idea for IV
• Counter must be persistent across reboot
• Gives each sender 65000 messages before IV is
  reused (worst case)

2
2
19
TinySec (Analysis)

• Access control and integrity
• Probability of blind MAC forgery ½32
• Replay protection not provided, but can be done
  better at higher layers
• Confidentiality Reused IVs can leak
  information
• IV reuse will occur after 216 messages from each
  node 1 msg / min for 45 days
• increase IV length ? adds packet overhead
• key update protocol ? adds complexity
• Applications have different confidentiality
  requirements need a mechanism to easily quantify
  and configure confidentiality guarantees
• Applications may provide IVs implicitly
• Apps may be able to guarantee sufficient
  variability in their messages (e.g. through
  timestamps)

20
TinySec (Latency)
LM

• Test set up
• 4x9 grid in Woz of Mica2s
• Landmark routing code from midterm demo
• 200 measurements per hopcount

B
A
BS

• Test purpose
• Measure latency at different hopcounts
• Determine difficulty in adding TinySec to
  existing application
• Results
• TinySec-Auth 1.1 byte time
• TinySec-AE 4.6 byte time

21
Latency
22
Latency Byte Times
23
TinySec (Energy)

• Test set up
• Single mote transmitting a packet
• Measure voltage drop with oscilloscope
• Results
• TinySec-Auth 3 energy overhead (of which 1
  comes from increased packet length and 2 from
  extra crypto-computation)
• TinySec-AE 10 energy overhead (of which 6
  from increased packet size and 4 from
  crypto-computation)
• Hardware accelerated crypto-computation has an
  upper bound on energy saving

24
3
Energy
10
25
TinySec (Bandwidth)

• Test set up
• Vary number of senders
• Each sender sends as fast as possible
• Measure number of packets successfully received
  in a time period
• Results
• TinySec-Auth identical to TinyOS protocol stack
  (one byte overhead)
• TinySec-AE 6 lower throughput (more than 5
  senders, 5 bytes larger packets
• Throughput difference is only due to differences
  in packet length, not the computational costs.

26
Bandwidth
TinySec-Auth same throughput TinySec-AE 6 less
throughput
27
TinySec (Performance Summary)
28
TinySec-other researches

• TinySec related approaches
• TinyPK Authentication and DH key exchange
  (BBN).
• TinyCrypt ECC key exchange (Harvard Univ.)
• Light-weight key management Key exchange,
  group management, key revocation (SRI).
• Securesense Dynamic security service
  composition (UMASS).
• PKC Public key crypto in sensor. (WPI)
• SenSec (I2R)
• Others Many efforts in Industry

29
Ongoing (I2R flagship project)
There are rich design proposals on securing
(distributed) sensor networks as well as
practical appliances, however we have relatively
less experience on pragmatic security issues.

• Practically, we will build strong (enough)
  security for the current project. For example, we
  may study the security requirements of the
  current project. Based on that, we design
  security architecture and develop relevant
  security protocols and tools of ensuring
  communication security, network security and
  application security.
• Theoretically, we will study potential research
  issues beyond the current solution. Briefly, we
  focus on dynamic, large scale of sensor networks
  and the Sybil or DoS attacks on them. We also
  investigate location aware security and data
  fusion security.

30
Website
http//www.i2r.a-star.edu.sg/icsd/SecureSensor/
Key management, Calling for
Collaboration on PKC (ECC), Location
aggregation If you have passion on designing
symmetric/asymmetric crypto/security mechanisms
for wireless/constrained devices, lets do sth.
interesting!
Thank you! Q A