Tieyan Li, Hongjun Wu, Feng Bao, Henry Lee

1
Flagship project SmartCondo-gtSecureSensor
SenSec Design (Technical Report v1.0)
Tieyan Li, Hongjun Wu, Feng Bao, Henry
Lee InfoComm Security Department (ICSD) Institute
for Infocomm Research (I2R) 23rd, Jul. 2004
2
Outline

• Objective
• Security architecture
• SenSec design
• Improvement and cryptanalysis on TinySec
• Resilient security mechanisms
• SenSec and TPSN
• TPSN without security
• TPSN with security
• SenSec module test plan
• Stage 1 (end of Aug.)
• Stage 2 (end of Oct.)
• Schedule

3
Objective
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.

4
Security architecture
5
SenSec design goal

• The security API TinySec works on Active
  Messaging (AM) layer. (In our project, we use an
  improved version - TinySec with cryptanalysis)
• It provides upper level applications and
  protocols a unified and transparent interface.
  (In our project, the CDIP and Routing group can
  use the unified security interface-TinySec)
• It fits well with the many-to-one traffic
  pattern and layered architecture of our sensor
  network environment. (It provides hierarchical
  access control and supports In-network
  processing)
• It maximizes the usability and minimizes the
  compromise by using three level keys. (It is
  resilient to various attacks)

6
SenSec-security API

• TinySec adoptation
• 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).
• Others (I2R)

• In our project, we wont re-design the security
  API but adopt TinySec with our improvement and
  cryptanalysis.
• Command result_t SendMsgEncryptAndAuth.send
  (uint8_t id, uint16_t addr,uint8_t length,
  TOS_MsgPtr data)

7
Improvement

• TinySec
• 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
• SenSec
• AE by default (SenSec-AE). Clearing
• Completing encryption authentication in one
  process. Saving energy (-2)
• Assuming all msg lengths (including lt 8 bytes).
  Padding additional bytes with msg length nlt8
  bytes

8
Cryptanalysis

• 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
• (say, 4 or 5). Not general.
• SenSec
• Keep the one byte group ID (distinguish the
  group messages)
• Each sensor only needs to keep one IV
• No restriction on the number of sensors in a
  group to communicate with each other (group id,
  one byte, differentiate the motes in the
  different groups)

9
SenSec (Packet format)
Old packet (CRC) 7 b
Authentication Only (TinySec-Auth) 8 b
Authentication, Encryption (TinySec-AE) 12 b
IV
Dest (2)
AM (1)
Len (1)
Data (0..29)
MAC (4)
Ctr (3)
Grp (1)
(SenSec) 12 b
IV
10
SenSec (Predicted Overhead)
11
SenSec (Performance Summary)
12
Resilient security mechanisms
Project Scenario
Instead of using one key, we use multiple keys
(hierarchical key structure) either for various
domains or for different requirements on a
hierarchical architecture.
13
Keying mechanisms

• Overall security assumption several hundreds
  bytes for keying materials.
• Global key (GK) (e.g. key used to broadcast in
  sensor network)
• Generated by the base station
• Pre-deployed with each sensor node
• Shared by all sensor network
• Cluster key (CK) (e.g. keys used in body
  monitoring system)
• Generated by the cluster head
• Assigned at the first deployment
• Shared by a small group of neighboring sensors
• Sensor key (SK) (e.g. keys used by individual
  sensor)
• Generated by the base station, based on a seed
  and the unique sensor id.
• Pre-deployed on each sensor node
• Each sensor share a sensor key with the base
  station

14
Why not end-to-end security?

• App-level API for end-to-end encryption (like
  SSL, IPsec and SSH)
• Pros
• End-to-end secrecy enables performance
  optimizations (dont decrypt re-encrypt at
  every hop)
• Enables more sophisticated per-node keying
• Robust to node capture
• Cons
• Dont fit into the many-to-one traffic pattern
  in sensor network
• Can not support in-network transformation and
  aggregation thus, not always appropriate,
• End-to-end integrity less clear-cut, due to DoS
  attacks
• In Sum
• It is possible to build end-to-end security
  given special application scenarios, but that
  could be application specific security API.

15
Outline

• Objective
• Security architecture
• SenSec design
• Improvement and cryptanalysis on TinySec
• Resilient security mechanisms
• SenSec and TPSN
• TPSN without security
• TPSN with security
• SenSec module test plan
• Stage 1 (end of Aug.)
• Stage 2 (end of Oct.)
• Schedule

16
TPSN implementation

• Current version
• TPSNsync-NesC-0.1, for MICA1/2
• Data Structure
• GTime
• Component
• SClock
• Interface
• TimeStamp
• CC1000RadioIntM.nc
• CC1000RadioC.nc
• RadioCRCPacket.nc
• GenericComm.nc
• TPSNsync

17
Component graph
18
What to do?

• Solution 1 Time synchronization protocol without
  security
• Application use GenericComm for TPSN messages
• Application use SecureGenericComm for other
  messages
• Co-existence of GenericComm and
  SecureGenericComm
• Clear, but need more memory
• Solution 2 Time synchronization protocol with
  security
• new CC1000RadioIntM.nc
• new CC1000RadioC.nc
• new RadioCRCPacket.nc
• new GenericComm.nc

19
Outline

• Objective
• Security architecture
• SenSec design
• Improvement and cryptanalysis on TinySec
• Resilient security mechanisms
• SenSec and TPSN
• TPSN without security
• TPSN with security
• SenSec module test plan
• Stage 1 (end of Aug.)
• Stage 2 (end of Oct.)
• Schedule

20
Test schedule

• Stage 1 (3 months, end of Aug.)
• Time synchronization protocol without security
  (SenSec-)
• Stage 2 (5 months, end of Oct.)
• Time synchronization protocol with security
  (SenSec-TPSN)
• Stage 3 (7 months, end of Dec.)
• Integration

21
Stage 1

• Time synchronization protocol without security
• Application use GenericComm for TPSN messages
• Application use SecureGenericComm for other
  messages
• Co-existence of GenericComm and
  SecureGenericComm
• Clear, but need more memory

22
Stage 1 (source code)

• tos.interfaces  (may not be the same name)
• SenSec.nc  _at_author Tieyan Li   
• SenSecControl.nc  _at_author Tieyan Li 
• MAC.nc  _at_author Hongjun Wu, Interface to
  compute a message authentication code.  
• BlockCipher.nc  _at_author Hongjun Wu   
• BlockCipherInfo.nc     _at_author Hongjun Wu
• BlockCipherMode.nc  _at_author Hongjun Wu, Presents
  an encryption mode interface on type of the
  BlockCipher interface
• tos.lib.TinySec  (may not be the same name)
• AMStandardSenSec.nc  _at_author Tieyan Li
• CBCMAC.nc  _at_author Hongjun Wu   
• CBCModeM.nc  _at_author Hongjun Wu, Implements
  Cross Block Chaining mode.   
• Security.nc  _at_author Tieyan Li   
• SecurityM.nc  _at_author Tieyan Li   
• SkipJackM.nc  _at_author Hongjun Wu  
• SenSecC.nc  _at_author Tieyan Li
• SenSecM.nc  _at_author Tieyan Li

23
Stage 1 (component graph)
24
Stage 2

• Time synchronization protocol with security
• new CC1000RadioIntM.nc
• new CC1000RadioC.nc
• new RadioCRCPacket.nc
• new GenericComm.nc

25
Stage 2 (source code)

• tos.interfaces  (may not be the same name)
• SenSec.nc  _at_author Tieyan Li   
• SenSecControl.nc  _at_author Tieyan Li 
• tos.lib.TinySec  (may not be the same name)
• AMStandardSenSec.nc  _at_author Tieyan Li
• Security.nc  _at_author Tieyan Li   
• SecurityM.nc  _at_author Tieyan Li   
• SenSecC.nc  _at_author Tieyan Li
• SenSecM.nc  _at_author Tieyan Li
• SecureGenericComm _at_author Tieyan Li
• RadioPacketSenSec _at_author Tieyan Li
• CC1000RadioSenSec _at_author Tieyan Li

26
Stage 2 (component graph)
27
To do works
28
Website
http//www.i2r.a-star.edu.sg/icsd/SecureSensor/
Thank you! Q A