Security in the Air Wireless Sensor Networks Security Framework WSNSF

1
Security in the AirWireless Sensor Networks
Security Framework (WSNSF)
Tanveer Zia
Supervisor Prof. Albert Y. Zomaya Co-Supervisor
Dr. Selvakennedy Selvadurai
2
A bit of history
MANETS
Wireless sensor networks
Attacks against WEP published before the ink was
dried
3
Sensor nets so what?

• Whats different about sensor nets?
• Stringent resource constraints
• Insecure wireless networks
• No physical security
• Interaction with the physical
• environment

4
This talk

• Motes specifications, limitations and
  applications
• Why security in Sensor nets? Unique issues and
  challenges, an attack example
• Is Crypto all we need?
• Key Management schemes
• Berkeleys TinySec Cryptanalysis
• Our Approach
• WSNSF
• Cluster formation Leader election
• Secure Triple Key Management Scheme
• Secure Routing
• Comparing WSNSF with TinySec
• Analysis of proposed framework
• Future Work and Summary
• Publications and References

Todays focus
5
Motes
Berkeley's MICA2

• Processor 8Mhz, Atmel ATMega128L
• Memory 128KB Flash and 4KB RAM
• External storage 512KB
• Default power 2xAA
• Radio 916Mhz and 38.4Kbits/sec (default 19.2
  kbits/sec)
• Transmission range 300m
• Available code space 4500bytes
• OS TinyOS

6
WSN Applications

• Battle field and homeland security
• Enemy movement (tanks, soldiers, terrorists etc)
• Environmental monitoring
• Habitat monitoring
• Early bush fire detection
• Farming applications
• Hospital tracking systems
• Tracking patients, doctors, drug administrators
• Traffic congestions monitoring
• Traffic flow and jams

Wireless Sensor nets a promising future!
7
WSN Security

• Why security?
• Why security is different in WSN?

8
Security Primitives CIAA

• Confidentiality
• Need the ability to conceal message from a
  passive attacker
• Integrity
• Need the ability to confirm the message has not
  been tampered with
• Authentication
• Need to know if the messages are from the node it
  claims to be from
• Access Control
• Need the ability to determine if a node has the
  ability to use the resources

9
Why security is different in WSN?

• Sensor Node Constraints
• Battery (2xAA)
• Processing power (8Mhz)
• Memory (lt128KB Flash and lt4KB RAM)
• Energy Usage
• 3V x (20 to 30)mA, 1.8V x (1 to 10)mA
• Networking Constraints
• Wireless
• Ad hoc
• Unattended

10
Challenges

• Must avoid complex key management
• Simple and must be super-easy to deploy
• Crypto must run on wimpy devices
• Were not talking 2GHz P4s here!
• Dinky CPU (4-8 MHz), little RAM (? 256 bytes),
  lousy battery
• Public-key cryptography?
• Need to minimize packet overhead
• Radio is very power-intensive
• 1 bit transmitted ? 1000 CPU ops
• TinyOS packets are ? 28 bytes long
• Cant afford to throw around an 128-bit IV here,
  a 128-bit MAC there

11
Attacks on sensor nets
12
An Example
Avg Temp
network
basestation
29
25
Avg X (x1 xn) / n
30
27
31
Computing the average temperature
13
An Example an attack
result is drastically affected
Avg Temp
network
basestation
29
Avg X (x1 xn) / n
25
30
27
100
31
X
Computing the average temperature
14
Protocols analysed
All are insecure!
15
Is crypto all we need?
It doesnt matter how good your crypto is if it
is never used. -- unknown
16
Limitations of crypto

• Cant prevent traffic analysis
• Cant prevent re-transmitted packets
• Cant prevent replayed packets
• Cant prevent delayed packets
• Cant prevent packets from being jammed
• Cant prevent malicious insiders, captured nodes
• Crypto is not magic fairy dust
• It wont magically make insecure services
• secure.

17
Key Management Schemes

• Trusted Server Scheme
• Depends on trusted server like Kerberos, no
  trusted infrastructure in WSN
• Asymmetric (Public Key) Scheme
• Infeasible due to limited resources in WSN
• Key Pre-Distribution Scheme

18
Key pre-distribution

• Master key approach
• Memory efficient but lack the security
• Tamper resistant hardware, cost?
• Pair-wise key approach
• N-1 keys for each node
• Good security
• Requires a lot of memory
• Lack scalability

19
Current approaches

• 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.
• TinySec, by Chris Karlof et al, UC Berkeley in
  SenSys04
• (the most current one)

20
TinySec (our benchmark)

• 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
• 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.

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

• Optional design (No TinySec, TinySec-Auth
  (default), TinySec-AE). Confusing
• Using a block cipher for both encryption
  authentication is smart. Processing encryption
  authentication separately is not wise
• Assuming Msg gt 8 bytes.
• How to process smaller msg?
• Routing?
• How the routing takes place?
• The IV in TinySec
• Each sensor keeps an IV for every destination
  address
• If too many destination addresses, high memory
  consumption
• If limited memory space, same IV being used
  repeatedly
• TinySec -- assume each sensor communicate with
  only a few sensors

23
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

24
Our approach
WSNSF
Cluster formation Leader Election
Secure Triple Key Management Scheme
Secure Routing
25
Our secure triple key management scheme

• Proposed secure keys
• Kn (network key)
• Generated by the base station, pre-deployed in
  each sensor node, and shared by the entire sensor
  network. Nodes use this key to encrypt the data
  and pass onto next hop
• Ks (sensor key)
• Generated by the base station, pre-deployed in
  each sensor node, and shared by the entire sensor
  network. Base station, cluster leaders and nodes
  use this key to decrypt and process.
• Kc (cluster key)
• Generated by the cluster leader, and shared by
  the nodes in that particular cluster. Nodes from
  a cluster use this key to decrypt the data.

26
Key calculation

• Base station to node key calculation
• Nodes to cluster leader key calculation
• Cluster leader to cluster leader key calculation
• Cluster leader to base station key calculation

27
Notations
28
BS to Node key calculation
Base station uses Kn to encrypt and broadcast
data. When a sensor node receives the message,
it decrypts it by using its Ks. In the figure
after four slides, base station uses Kn1..nn to
broadcast the message. This process follows as
Base station encrypts its own ID, a current time
stamp TS and its Kn as a private key. Base
station generates a random seed S and assumes
itself at level 0. The packet contains following
fields
Sensor node decrypts the message received from
the base station using Ks.
29
Nodes to CL key calculation
When a node sends a message to cluster leader, it
constructs the message as follows ID, Kn, TS,
MAC, S (message) Cluster leader checks the ID
from the packet, if the ID in the packet matches
the ID it holds, verifies the authentication and
integrity of the packet through MAC. Otherwise,
packet is dropped by the cluster leader.
30
CL to CL key calculation
Cluster leader aggregates the messages received
from its nodes and forwards it to next level
cluster leader or if the cluster leader is one
hop closer to the base station, it directly sends
to the bases station. Receiving cluster leader
checks its routing table and constructs the
following packet to be sent to next level cluster
leader or base station. Cluster leader adds its
own ID, its network key in incoming packet and
rebuilds the packet as under ID, Kn, ID, Kn,
TS, MAC, S (Aggr message)
31
CL to BS key calculation
Base station receives the packet from its
directly connected cluster leader it checks the
ID of sending cluster leader, verifies the
authentication and integrity of the packet
through MAC. Cluster leader directly connected
with base station adds its own ID along with the
packet received from the sending cluster leader.
Packet contains the following fields IDID,
Kn ID, Kn, TS, MAC, S (Aggr message)
32
Key calculation
33
Secure Routing

• Nodes to base station secure routing algorithm
• Base station to nodes secure routing algorithm

34
Nodes to BS secure routing

• Sensor nodes use Kn to encrypt and transmit the
  data
• Transmission of encrypted data from nodes to
  cluster leader
• Appending ID to data and then forwarding it to
  higher level of cluster leaders
• Cluster leader uses Ks to decrypt and then uses
  its Kn to encrypt and send the data to next level
  of cluster leaders, eventually reaching the base
  station

35
Nodes to BS secure routing algorithm
Step 1 If sensor node i wants to send data to
its cluster leader, go to step 2, else exit the
algorithm Step 2 Sensor node i requests the
cluster leader to send the Kc to decrypt the data
if needed. Step 3 Sensor node i uses Kc and its
own Kn to compute the encryption key Ki, cn. Step
4 Sensor node i encrypts the data with Ki,cn
and appends its ID and the TS to the encrypted
data and then sends them to the cluster
leader. Step 5 Cluster leader receives the
data, appends its own ID, and then sends them to
the higher-level cluster leader or to the base
station if directly connected. Go to Step 1.
Figure here demonstrates this algorithm and
illustrates the communication between sensor node
i and the cluster leader.
36
BS to nodes secure routing

• Broadcasting of Ks and Kn by the base station
• Decryption and authentication of data by the base
  station
• Receiving and verification of data from nodes

37
BS to nodes secure routing algorithm
Step 1 Check if there is any need to broadcast
the message. If so, broadcast the message
encrypting it with Kn. Step 2 If there is no
need to broadcast the message then check if there
is any incoming message from the cluster leaders.
If there is no data being sent to the base
station go to step 1. Step 3 If there is any
data coming to the base station then decrypt the
data using Ks, ID of the node and TS within the
data. Step 4 Check if the decryption key Ks
has decrypted the data perfectly. This leads to
check the credibility of the TS and the ID. If
the decrypted data is not perfect discard the
data and go to step 6. Step 5 Process the
decrypted data and obtain the message sent by
sensor nodes Step 6 Decides whether to request
all sensor nodes for retransmission of data. If
not necessary then go back to step 1. Step 7 If
a request is necessary, send the request to the
sensor nodes to retransmit the data. When this
session is finished go back to step 1. Flow chart
here illustrates the base station to node
algorithm
38
Triple-Key packet format
This gives us 44 bytes of packet overhead. Taking
into account 128K program memory of ATmega128L
MICA2 our framework can be best implemented in a
network of thousands of sensor nodes. Given a
4b MAC, an adversary will have 232 chances in
blindly forging a valid message. With a 19.2Kb/S
channel, one can only send 40 forgery attempts
per second, so sending 232 packets at this rate
would take over 20 months.
39
TinySec WSNSF-Triple keys (comparison)
Old packet (CRC) 7 b
Authentication Only (TinySec-Auth) 8 b
Authentication, Encryption (TinySec-AE) 12 b
IV
Data (0..29)
MAC (4)
ID (3)
Keys (3)
TS (1)
S (1)
IV
(Triple-Keys) 12 b
40
WSNSF-Triple keys (Predicted Overhead)
41
Analysis of proposed security framework
(continue..)

• Pros
• Successfully delivering all security primitives -
  CIAA
• Better usage of limited energy and memory
• End-to-end secrecy enables performance
  optimizations (dont decrypt re-encrypt at
  every hop)
• Enables more sophisticated per-node keying
• Each sensor node need only one IV
• Supports in-network transformation and
  aggregation
• Robust to node capture (if a node is captured,
  very little information will be disclosed)
• Adapts the secure routing mechanism
• Reduces the impact of DoS attacks
• Cons
• Number of nodes

42
Future work

• Implementing or simulating WSNSF in Berkeleys
  MICA motes
• Malicious Node detection
• Some naïve ideas
• A node monitoring mechanism
• Energy threshold
• Eliminating malicious nodes from the network
• Location aware security
• Data fusion security

43
Publications References
Zia, T.A., and Zomaya, A.Y., A Secure
Triple-Key Management Scheme for Wireless Sensor
Networks , In the proceedings of the IEEE
InfoCom 2006 Students Workshop, April 23-24,
2006, Barcelona, Spain. (In press) Zia, T.A.,
and Zomaya, A.Y., A Security Framework for
Wireless Sensor Networks, In the proceedings of
the IEEE Sensors Applications Symposium (SAS06),
February 7-9, 2006 , Houston, Texas. Zia, T.A.,
and Zomaya, A.Y., An Analysis of Simulations
and Programming in Wireless Sensor Networks, In
the proceedings of the International Workshop on
Sensor Networks and Applications (SNA05), October
20-22, 2005, Beijing, China.
Chris karlof, Naveen Shastry and David Wagner
TinySec A Link layer Security Architecture for
Wireless Sensor Networks, SenSys04, November
3-5 2004, Baltimore, Maryland, USA Chris Karlof
and David Wagner, Secure Routing in Wireless
Sensor Networks Attacks and Countermeasures,
University of California at Berkeley, USA
2003. Tieyan Li, Hongjun Wu and Feng Bao,
SenSec Design, Institute for Infocomm Research
I2R, Singapore, 2004 Crossbow Technologies
Inc http//www.xbow.com Retrieved on 22/02/06
44
Feedback and Questions?