Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Overview of Security Architecture] Date Submitted: [April 17, 2002] Source: [Daniel V. Bailey, Product Manager for Wireless Networks and Ari Singer, Principal Engineer] Company [NTRU] Address [5 Burlington Woods, Burlington, MA 01803] Voice:[(781) 418-2500], FAX: [(781) 418-2507], E-Mail:[dbailey@ntru.com] Re: [Draft P802.15.4/D14] Abstract: [This presentation gives an overview of security architecture issues for the 802.15.4 draft standard.] Purpose: [To familiarize the working group with the security architecture.] Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. Agenda • Use Cases • Scalable Security • Protecting the Network • Performance

3. Home Security and Automation • Electrical and heating • Want your neighbors turning on/off the lights/heat? • Wireless door monitoring/opening • Want your neighbors opening your doors? • Wireless keypads • Certainly something has to control your home automation center… • Smoke/flame/carbon monoxide detectors • Anyone see The Thomas Crown Affair? • Consumers will not accept solutions without security!

4. Remote Sensors and Actuators • Industrial applications • Nuclear power plants (!) • Automated factory controls • Sensors that respond to correct imbalances in temperature, humidity, viscosity, … • Medical applications • HIPPA compliance for privacy of medical data • Medical sensors (thermometers, sphygmomanometers, …) • Security is a critical enabler of these applications!

5. Agenda • Use Cases • Scalable Security • Protecting the Network • Performance

6. Scalable security • Different applications have different security needs! • Highly constrained devices face difficult choices • Power, bandwidth, computation time, cost, … • Mode 0: No security. • Mode 1: Only symmetric-key cryptography. Provides data encryption and integrity using a key supplied by the DME • User-entered password • Mode 2: Mode 1 with public-key cryptography to establish keys • Robust key management

7. What does this buy you? • Wires provide three security assurances: • Only devices I want can join the network • Only devices I want can read network traffic • Only devices I want can write network traffic • …since I’d notice if someone plugged in • These are our goals! • Authentication and Access Control restrict association • Encryption provides privacy on transmitted data • Integrity shows transmitted data wasn’t altered and came from an authenticated device • Freshness shows transmitted data wasn’t replayed

8. Security Mode 1 • How are our goals met? • User enters a password on both devices • Goal 1: Only devices I want can join the network • Devices won’t talk unless they mutually prove knowledge of the password • Goal 2: Only devices I want can read network traffic • All data is encrypted with a key derived from the password • Goal 3: Only devices I want can intelligibly write network traffic • All data is integrity-protected with a key derived from the password • To prevent replay, data is rejected if it isn’t fresh • Data should be sent/received within a few superframes of a timestamp

9. Why Do Many Devices Need More? • Key establishment is difficult with an all-symmetric system: • User-entered keys/passwords • Low-power transmission of symmetric key allows for passive (easy!) attacks • I could use a parabolic dish antenna, obtain the key and just listen • Messy (secret) key management • Requires either long-term key storage (NVRAM or unique fixed key burned into all devices) or • New user-assisted key establishment for every association • A device that regularly joins n piconets needs n symmetric keys • If stored, they add up like web-browser cookies • If my device talks to your device, your device gets my fixed key • You can control my device from then on or • Read my content from then on!

10. Security Mode 2 • Allows robust key management • No user-entered passwords!! • User introduces devices instead • Low-power transmission of public key allows only active (hard!) attacks • I could transmit my key louder, but the genuine devices couldn’t talk! • Analog Certificates: printed on a card or the bottom of the device • Digital Certificates: If devices both trust another entity they can both contact • User action: Press a button on both devices at once • Open enrollment: PNC trusts every public key it hears in the next 30 seconds, then “locks down” • Range: The user confirms the device sending the key is x meters away • One-time authentication and key exchange • Devices store keys in EEPROM/other persistent storage

11. How Will This Work? • A device may be in one of three states: • Unassociated, unauthenticated A device may only issue Class I commands like Associate and may not send data • Associated, unauthenticated A device may only issue Class II or Class III commands like Authenticate-Request • Associated, authenticated A device may issue any applicable command • Any command received from a device in excess of its authorization is ignored • Any data sent or received when group keys are active is rejected unless it is protected by the group keys

12. Command Classes • Class I – Commands that may be sent when the device is not yet associated (e.g. associate) • Class II – Commands that never require cryptographic protection (e.g. authentication request or distribute info) • Class III – Commands that require group key cryptographic protection (e.g. New PNC announcement) • Class IV – Commands that require key management key cryptographic protection (e.g. distribute key request)

13. Agenda • Use Cases • Scalable Security • Protecting the Network • Performance

14. How Do We Protect the Beacon? • The beacon includes a Security Session ID (SSID) so devices know which piconet-wide key is in use • Beacon also includes a Time Token. It’s really a beacon counter to be used in all messages to prevent replay of messages in future superframes. • We use a message authentication code, or MAC. Let’s call it an integrity code. • The integrity code prevents an outside attacker from modifying data in the beacon.

15. How Do We Protect Commands? • 802.1x was broken due to failure to protect commands! • Commands are protected independently from each other. • Commands include the current SSID and time token that were sent in the protected beacon for group related commands. • Commands also include the counter from the peer relationship for key management commands.

16. How Do We Protect Data? • Data is encrypted using the current group DEK. • Header and data are integrity protected using the current group DIK. • Data includes the current SSID and time token that were sent in the protected beacon.

17. What Does a Device Need to Know? • A device has a public/private key pair, installed at provisioning time. • An authenticated device shares a unique DEK and DIK with the PNC agreed on during the authentication process • An authenticated device shares a different DEK and DIK with the rest of the piconet.

18. What Does a Device Need to Know? • A device keeps a table (access control list) of the other DEVs with which it has a trust relationship • A simple device only needs one entry: the PNC! • The public key itself need not be stored • The PNC will need storage for each associated DEV • Ideally, we’d like to put this in EEPROM • When the electricity goes out, I don’t want to have to reintroduce every device to the PNC

19. What Does a Device Need to Know? • Each device keeps some data about the current group keys • If the beacon has the same SSID and a greater time token, the time token is updated and the key is valid for that superframe • If the PNC ID and the PNC ID in the beacon are different, a new device is now PNC and the device attempts to authenticate to the new PNC

20. Agenda • Use Cases • Scalable Security • Protecting the Network • Performance

21. Implications of Data Rate • Symmetric components (encryption, integrity) must meet the data rate • Public key costs on a per-session basis, not per-bit • Small implementation of AES symmetric cipher in around 15,000 gates • The challenge: minimize footprint to meet a target data rate at a target cost (area, clock rate,…) • You’ll need a custom hardware implementation for encryption and integrity for best time/power performance • Software implementations also possible

22. Performance on a Microcontroller • What about authentication and key establishment for secure association in Mode 2? • Microcontrollers vary widely, so here’s three implementations of NTRUEncrypt on 8051-class processors: • Standard time/space tradeoffs exist. These numbers optimized for speed • As few as 502 bytes at this security level, less than 256 bytes for shorter-term security

23. Conclusion • There’s a LOT of information here. • Devices that need security get just what they need • Secured devices have maximum latitude in delicate cost/power/bandwidth tradeoffs