Tieyan Li, Hongjun Wu, Feng Bao, Henry Lee'

1
Flagship project SmartCondo-gtSecureSensor
TinySec-Security API of TinyOS
Tieyan Li, Hongjun Wu, Feng Bao, Henry
Lee. InfoComm Security Department
(ICSD) Institute for Infocomm Research (I2R) 1st,
Jul. 2004
2
Outline

• Goal
• Improvement and cryptanalysis on TinySec
• Introducing TinySec (with constraints, from
  Tinysec Performance characteristics, by Chris
  K, Naveen S, David W, U. C. Berkeley, 2004)
• Improvement
• Cryptanalysis
• TinySec Security API
• Resilient security mechanisms
• Hierarchical access control
• Keying mechanisms
• Why not end to end security?
• To do works
• How to proceed in collaboration with other
  groups?

3
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)

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

5
TinySec (Interfaces)
App
App
SecureGenericComm
GenericComm
Radio
Radio
Making deployment easyplug-n-play crypto
link-layer security
6
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

7
TinySec (Source tree)

• apps.TestTinySec 
• TestTinySec.nc    
• TestTinySecM.nc Module to test TinySec.
•  apps.SecureTOSBase 
• SecureTOSBase.nc _at_author Phil Buonadonna _at_author
  Chris Karlof   
• SecureTOSBaseM.nc _at_author Phil Buonadonna _at_author
  Chris Karlof
• tos.interfaces  
• TinySec.nc _at_author Chris Karlof   
• TinySecControl.nc _at_author Chris Karlof   
• TinySecRadio.nc 
• SendMsg.nc Basic interface for sending AM
  messages.  
• MAC.nc Interface to compute a message
  authentication code.  
• BlockCipher.nc _at_author Naveen Sastry   
• BlockCipherInfo.nc    
• BlockCipherMode.nc Presents an encryption mode
  interface on type of the BlockCipher interface

8
TinySec (Source tree)

• tos.lib.TinySec 
• AMStandardTinySec.nc _at_author Jason Hill _at_author
  David Gay _at_author Philip Levis _at_author Chris
  Karlof   
• CBCMAC.nc _at_author Naveen Sastry   
• CBCModeM.nc Implements CBC Mode using Cipher Text
  Stealing (CBC-CTS) as described in Schneir's
  Applied Cryptography (195-6) and RFC-2040.   
• SecureGenericComm.nc _at_author Jason Hill _at_author
  David Gay _at_author Philip Levis _at_author Chris
  Karlof   
• Security.nc _at_author Chris Karlof   
• SecurityM.nc _at_author Chris Karlof   
• SkipJackM.nc From the NIST description of
  SkipJack.   
• TinySecC.nc _at_authorNaveen Sastry
• TinySecM.nc _at_author Chris Karlof
• tos.platform.mica2  
• CC1000RadioIntTinySecM.nc    
• CC1000RadioTinySecC.nc _at_author Philip nadonna  
• RadioCRCPacket.nc    
• RadioPacketTinySec.nc    
• RadioPacketTinySecM.nc

9
TinySec (Component graph)
10
TinySec (Component graph)
11
TinySec (Component graph)
12
TinySec (Component graph)
13
TinySec (Packets Predicted Overhead)
Old packet (CRC) 7 b
Authentication Only (TinySec-Auth) 8 b
Authentication, Encryption (TinySec-AE) 12 b
IV
14
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

15
Latency
16
Latency Byte Times
17
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

18
3
Energy
10
19
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.

20
Bandwidth
TinySec-Auth same throughput TinySec-AE 6 less
throughput
21
TinySec (Performance Summary)
22
TinySec-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)

23
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
• TinySec
• AE by default (TinySec-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

24
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.
• TinySec
• Each sensor only needs to keep one IV
• No restriction on the number of sensors to
  communicate with each mote

25
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.
26
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

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

28
To do works
29
How to proceed in collaboration?
Since TinySec will be transparent to the upper
layer applications, the CDIP, DD and SA groups
can simply use the existing messaging interface
(e.g. GenericComm on AM) or use the existing
TinySec interface (i.e. SecureGenericComm).
TinySec can be seamless integrated with any
legacy applications once completed.
Available at http//www.i2r.a-star.edu.sg/icsd/Se
cureSensor/papers/Secure-Sensor-0701.ppt
Thank you! Q A