TinyPK Energy Efficient Security for Wireless Sensor Networks 16 December 2003 NEST PI Meeting Santa

1
TinyPK Energy Efficient Securityfor Wireless
Sensor Networks16 December 2003NEST PI
MeetingSanta Fe, NMRon WatroBBN
Technologieswww.is.bbn.com/projects/lws-nest
2
Outline of Talk

• Administrative Slides and Tech Summary
• Results in Last 6 Months
• Software updates
• Mote-to-Mote Key Exchange
• Authenticated XNP
• Tech Transfer and Program Issues

3
Administrative

• Project Title Lightweight Security for Wireless
  Networks
• Program Manager Vijay Raghavan
• PI Name Ron Watro
• BBN Team Members Derrick Kong, Sue-fen Cuti,
  Daniel Coffin
• PI Phone Number 617-873-2551 (office),
  781-710-5016 (cell)
• PI E-Mail Address rwatro_at_bbn.com
• Company/Institution BBNT Solutions LLC
• Contract Number F30602-02-C-0200
• AO Number AOK783(16)
• Award Start Date 9/9/2002
• Award End Date 9/8/2004
• Agent Name/Organization Roger J. Dziegiel Jr.,
  AFRL/IFTB, Rome

4
Lightweight Security for Wireless Networks
Ron Watro BBN Technologies
Problem and Challenge
New Ideas

• Public Key (PK) Crypto can be made lightweight
  enough for selected applications in Mica Mote
  networks!!
• Security models can be designed to match sensor
  net applications
• Essentials of our approach
• Plan for NEST-wide coordinated security services
• Search for NEST application areas
• Interaction with other sensor programs
• Design of TinyPK to go with TinyOS and TinySec

Spoof Signal Rejection
Sensor Detection
Impact

• Protect Sensor Network Comm from
• Replay Attacks
• Overrun Attacks
• Weak symmetric key management
• Support IFF-type functionality for sensor
  networks
• Provide support for authentication of remote
  users
• Provide support for merging of networks

5
Problem Description/Objective

• Specific technical problem(s) being solved
• Definition of sensor network security
  requirements
• Participation in program-wide definition of a
  NEST security architecture
• Implementation of the PK-enabled aspects of the
  aforementioned NEST security architecture
• Contribution to the goals of the NEST program
• Provide protection of sensor comm from INFOWAR
  attack
• Add realism and DoD relevance to challenge
  problems
• Specific success criteria for your project
• Efficiency and effectiveness of security
  architecture
• Performance of security function implementation
• Technology transfer

6
Overview of NEST TinyPK Project

• TinyPK Tiny Public Key
• Security architecture and implementation for
  wireless sensor networks
• TinyPK provides authentication services and key
  management for TinySec
• Conventional wisdom was that PK services would be
  too heavy-weight for motes

7
Public Key Basics (for RSA)

• Public key operations (verify and encrypt) can be
  short calculations
• Private key operations (sign and decrypt) are
  often much longer calculations

8
Making PK Fit on Sensor Nets

• Design new, more efficient algorithms and
  protocols
• For example, new faster public key encryption
  schemes
• Design sensor security asymmetrically
• Put the heavier burden on external networks and
  users of sensors
• Flatten designs and integrate security into
  applications
• Will make code harder to maintain
• Limited acceptance of vulnerabilities
• Do a threat assessment

9
Project Status

• Milestone 1 Authentication of external party to
  a mote and key exchange (July 03 Demo)
• Based on conventional RSA
• Expensive private operations performed by
  external parties
• Milestone 2 Authentication of mote to the
  external party (July 03 Demo)
• Uses a CA-signed token created at mote
  manufacturing time
• Avoids expensive private operations on motes
• Milestone 3 Initial mote-to-mote key exchange
  (Diffie-Hellman) (completed Sep 03)
• Milestone 4 Secured Across the Network
  Programming (XNP) (first release Dec 03)
• Milestone 5 Secure Dynamic Network Extension
• Integrates updated TinyPK, AuthXNP, etc (July 04)

10
Goals and Success Criteria

• Concrete metrics
• Successful defense against attacks
• Efficiency of security mechanisms
• Effectiveness of security architecture
• Technology Transfer
• DoD organizations adopting the technology
• Briefings to customers and conferences
• Connections to other researchers and vendors

11
Secure Comm Problem
Special Ops Force (SOF)
Sensor Field

• External parties need access to sensor data
• Assume a SOF needs access to a TinySec Sensor
  Field
• Not practical to preplace secret keys in all
  potential data users
• Need protocols that allow
• Motes to authenticate the SOF
• Secure communication between SOF and Sensor Field
• SOF to authenticate the Sensor Field

12
Secure Comm Solution
Certification Authority with Protected Private Key
Sensor Field
Special Ops Force (SOF)

• Public Key Cryptography
• A Certification Authority (CA) holds a protected
  private key
• Each mote has a copy of the CA public key
• The SOF has its own public/private key pair and
  the SOFs public key is signed by the CA

13
Demo One Sep-up

• Operation of protocol demonstrated
• RSA authentication from the SOF to the PK mote
• Protection against replay attack with
  challenge-response protocol
• Mote Set Up
• PK Mote to run RSA (public transformation)
  and hold CA public key and TinySec
  key
• Attached mote to do message pass-through
  and flow control
• External PC with Attached Mote
• Represents the SOF
• Computation (private transformation) done by PC
• Radio communication done by mote
• Produces the challenge and receives encrypted
  TinySec key

Attached Mote
External PC
14
Authentication and Key Exchange
Challenge containing the signed public key and
other details
Validate public key and respond with PK-encrypt
TinySec key
PK-decrypt TinySec key and save it for future use
15
Mote Authentication
Request for validation sent under TinySec
PK-encrypted credential returned under TinySec
Decrypt and validate credential record ID
16
Project Status

• Changes in technical approach
• none
• Progress since last NEST PI Meeting
• Porting previous work from MICA to MICA2
• Surprise Found huge performance boost!
• Implemented conventional mote-to-mote key
  exchange
• Applied TinyPK to help secure XNP
• Tech transfer
• Organized a panel session on sensor network
  security
• Presented TinySec at panel session

17
TinyPK Results on Original MICA (slow!!)

• Timing tests for RSA, public key operation with
  exponent 3 and varying modulus sizes
• Private key timing not available far too slow.
• Key-exchange Exponentiation with a 512-bit
  modulus and 120 bit exponent with 50 one-bits
  315 sec!!

18
Crypto Options

• Elliptic Curve Cryptography (ECC)
• Public Key Algorithm based on discrete log in
  certain finite groups
• Widely accepted as fundamentally secure
• Widely proposed for low-end devices
• Small ECC keys are security equivalent to much
  larger conventional keys (160 bits to 1024 bits)
• Issues
• Numerous patents in this area
• Open source release may be problematic
• DoD has broad ECC license from Certicom

19
Mote-to-Mote Key Exchangeon Mica 2
20
What is Diffie-Hellman (DH)?

• Public key based protocol for key agreement
• The parties share a large prime p and a generator
  g (for that prime) p, g are public
• Each mote generates a random number
• - x, y are private

gx mod p
y random
x random
gy mod p
(gy mod p) x mod p g(xy) mod p
(gx mod p) y mod p Shared key
21
Characters of keys

• The security of the system is based on the
  difficulty of computing the discrete logarithm.
  The choice of g and p has a substantial impact.
• p must be a large prime
• 512 bits is minimum for p, 1024 bits is desirable
• (p 1) / 2 should also be a prime.
• g has to be capable of generating every element
  from 1 to p-1 when multiplied by itself a certain
  number of times, modulo the prime p
• No reason not to choose the smallest g you can,
  generally a one-digit number, e.g. 2.

22
Description of Mote DH

• A known prime/generator pair is loaded with DH
  code into motes. Demo uses a p with 768 bits.
  Generator value is 2.
• Each mote proceeds as follows
• Generate a random number (exponent) and calculate
  the generator raised to that number
• Send out data (gx mod p)
• Receive the others data, calculate the secret
  key and display it on the laptop.
• Mote LED color
• Red LED indicates motes doing computation
• Green LED indicates motes sending data to the
  other mote
• Yellow LED indicates mote encounters errors
• Both laptops should display the same new random
  key

23
Performance and Future Work

• Current modular exponentiation speeds
• 19 sec for 768 bits Prime and 114 bits exponent
• 34 sec for 1024 bits prime and 114 bits exponent
• Possible next steps
• Better random number generation
• Protection against man-in-middle attack
• Elliptic Curve Cryptography
• Key validation
• Application areas
• Sensor network cryptonet extension

24
TinyPK Performance Boost!

• TinyPK software moved from Mica1 to Mica2
• Speed increase was a factor of 10!
• Clock speed explains a factor of 2
• Compiler explains remaining boost
• Early Mica1s used the Atmega 103
• Mica2 is Atmega 128 only

25
Three Step Key Exchange
RA
RB, MAC(B, A, RB, RA)
A
B
MAC(A, B, RA, RB)
RA, RB Ephemeral public keys MAC Message
authentication code

• Menezes-Qu-Vanstone (MQV) Protocol
• Provides protection against man-in-the-middle
  attacks
• Can optionally provide key confirmation
• Both entities in process must have public/private
  key pairs and ability to verify keys (preloaded
  or via CA).
• Can use different underlying cryptographic
  algorithms, but generally implemented with EC.

26
Secure Dynamic Network Extension

• Motes deployed in groups
• Selected motes authenticated to each other and
  perform key exchange
• Could support extreme scaling

27
Authenticated XNP
28
XNP Across the Net Programming

• XNP must be explicitly enabled on motes
• First security recommendation
• Keep XNP off unless it is required for the
  mission
• If XNP is required for mission, several options
• No security (not recommended!)
• Preplaced secret symmetric key security
• Stops the outsider attacks
• Drawback Any mote can reprogram all the others
• Simple TinyPK approach one key pair generated
• The public key goes in the motes
• The private key goes in the reprogrammers
• Creates an asymmetry between mote and
  reprogrammer
• TinyPK with a Certification Authority (AuthXNP)
• Some residual vulnerabilities (especially to
  denial of service) persist even with best TinyPK
  approach

29
XNP Current Command Steps

• Download Phase
• START_DOWNLOAD Signal application to release
  resources
• DOWNLOADING Mote store s-record to external
  EEPRO M
• DOWNLOAD_COMPLETE Termination of the download
• Query Phase
• GET_CIDMISSING Query mote if any missing
  capsules
• Reprogram Phase
• ISP_EXEC Request mote to reprogram itself
• GET_PIDSTAUS Verify program ID is correct

30
AuthXNP Current Command Steps

• Download Phase
• START_DOWNLOAD Signal application to release
  resources
• TinyPK Authentication
• DOWNLOADING Mote store s-record to external
  EEPRO M
• DOWNLOAD_COMPLETE Termination of the download
• Query Phase
• GET_CIDMISSING Query mote if any missing
  capsules
• Reprogram Phase
• ISP_EXEC Request mote to reprogram itself
• GET_PIDSTAUS Verify program ID is correct

31
TinyPK Authentication Background
PK Mote
Reprogrammer
CA signed public key Reprogrammer signed
nonce, checksum
unsigned packets to get reprogrammers pub
key, nonce and checksum Verify nonce and
checksum
bad_checksum


replay attack Form return message
with TinySec key
Verify correct nonce Write session key
and nonce Send TinySec key to attached Mote
Color code for mote Green communication mode
Red computation mode Orange error mode in yellow
32
Authentication XNP in Java

• Authentication only happens on Download Phase
• TinyPK authentication packets are sent between
  START_DOWNLOAD and DOWNLOADING commands.
• START_DOWNLOAD command will signal the
  application to release resources and/or stop
  processing, set stage for TinyPK operations in
  mote, verifying signature, .
• If authentication succeeds, continue to next
  step, Downloading
• Otherwise stop processing. The possible errors
  could be bad-checksum, replay attack
• Authentication message is in TinyPKMsg format,
  its own message handler
• Requires multiple packets to deliver, each packet
  only delivered once
• Only accepts the first motes response, ignore
  the rest

33
Authentication XNP in Mote

• Its own message event handler
• CA public key is hard coded for verifying
  received TinyPK message, signature
• Replay attack detection old nonce is saved to
  internal EEPROM address, 0xFF6 0xFFE, so it
  will survive after the reboot and reprogram, but
  not after an UISP --erase.
• Current nonce not newer than the old nonce,
  replay attack!
• Nonce may be best to be put in the Matchbox to
  avoid the overwrite.

34
AuthXNP 1 Start download
35
AuthXNP 2 Start authentication
36
AuthXNP 3 Authentication succeeds
37
AuthXNP 4 Download code
38
AuthXNP 5 Failed with REPLAY
tinyPK.properties
Properties for tinyPK.properties Mon Dec 08
140745 EST 2003 nonce\u0000\u0000\u0000\u00F9W\
\u201E\u00B8 replaytrue
39
AuthXNP 6 After download abort
40
XNP-specific Future Work

• Complete basic AuthXNP
• After TinyPK authentication done, send TinySec
  key to reprogrammer using message
• Enable Xnp.java to handle multiple mote responses
• Resolve different returned TinySec key between
  motes
• Resolve multiple realms issue
• Improve the message replay protection.
• Make AuthXNP into a library component
• Coordinate with new improved XNP development

41
Summary

• TinyPK demo software available
• Not hardened security code
• Public Key crypto definitely feasible on current
  mote devices
• Processing power on mote level computing devices
  is improving as they evolve
• Batteries, antennas limiting factors in
  miniaturization
• TinyPK next steps
• Large scale application demo
• Updates to key exchange and AuthXNP
• Possible support to SOCOM challenge problem

42
Deliverables and Publications

• David Carman, Daniel Coffin, Bruno Dutertre,
  Vipin Swarup, Ronald Watro, Forum Session
  Security for Wireless Sensor Networks, Annual
  Computer Security Applications Conference, Dec
  2003.
• Diffie-Hellman Demo for Mica 2 Motes, BBN
  Technologies

43
Another Possible Target for TinyPK

• Unattended Ground Sensor (UGS)
• IXO Sensor Program w/ BAE
• ARL Blue Sensor Network Radio
• Communications
• AJ/LPI/LPD spread spectrum signal
• 2-8 Kbps data rate
• Computational Capability
• Low-power MCORE main processor
• TI DSP co-processor used for signal processing
• Security Requirements
• Pairwise and group key management
• Link and network-layer encryption and message
  authentication
• TinyPK functions would run very rapidly on such a
  platform

44
Program Issue

• Will DoD deployments of low cost distributed
  sensors require AJ/LPI/LPD comm?
• If so, does that fundamental change the platform
  requirements for NEST?