1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [NTRU Security Tutorial]
Date Submitted: [May 10, 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) ], FAX: [(781) ],
Re: [Draft P /D14]
Abstract: [This presentation gives a tutorial overview of a proposed security solution for the draft standard.]
Purpose: [To familiarize the working group with the security architecture.]
Notice: This document has been prepared to assist the IEEE P 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 P

2. Agenda
Implementation Goals
Security Services
The Proposed Solution

3. Implementation Goals Low cost!
Algorithm agility
Applications must be able to choose algorithms
But the standard should provide for some interoperability
Low cost!
Low bandwidth overhead!
Low code space!
Low chip area!
Low power drain!
Low transmission time!
Support both star topology and peer to peer (master/slave)
Scalable
Must support a broad range of application security needs

4. Agenda
Implementation Goals
Security Services
The Proposed Solution

5. Security Services
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

6. Authentication and Access Control
Needed in situations in which a pre-established (e.g. manual) shared secret is not available
Use public-key algorithms like RSA, ECC, NTRUEncrypt
Based on number-theoretic operations
NTRUEncrypt uses only adds on 7-bit integers
Used once to establish a key used by a symmetric algorithm
Not to protect network traffic!
One-time cost at network setup time

7. Encryption Only needed when data is confidential
Symmetric-key algorithms like KEELOQ, RC4, DES, AES
Based on simple bit-manipulation operations like XOR, AND, lookup tables
Directly protects confidentiality of network traffic
Encrypts and decrypts data with a single key shared by both sender and receiver

8. Integrity
Shows data came from a particular DEV and wasn’t altered in transit
Often more important than encryption in a WPAN!
Provided by symmetric-key algorithms like KEELOQ, DES, AES
Based on simple bit-manipulation operations like XOR, AND, lookup tables
Integrity protected with a single key shared by both sender and receiver
A block cipher provides integrity for the same gates used for encryption

9. Freshness
Needed when integrity and timeliness are both required
Prevents insertion of old messages
Each device stores a counter that is included in the integrity protected messages
Best left to the application

10. Agenda
Implementation Goals
Security Services
The Proposed Solution

11. Selecting Security Services
A Security suite is selected for each relationship
Security suite is a collection of cryptographic algorithms
Determines which services are provided
SEC bit in frame control field indicates if frame is secured
Only provide security services that you need for your device
Obviously, each of these services costs resources

12. How Do We Hold Down Costs?
Once again:
Obviously, each of these services costs resources.
For some devices that need all services, the costs are acceptable
For other devices that don’t need all services, the costs won’t be acceptable
Baseline interoperability is still a goal
Conclusion:
should specify only the most fundamental of services, leaving all others to higher layers
Higher layers MUST be involved!

13. What’s fundamental here?
Access control list (ACL)
The MAC PIB contains a list of DEVs with which the MAC is permitted to talk
Maintained by the upper layers, read-only to the MAC
Payload protection
Symmetric-key encryption and/or
Symmetric-key integrity

14. Access Control List
The DME maintains the ACL, using the method best suited to the application.
What’s in the ACL?
Device address either an IEEE address or a default key to communicate with a number of unlisted devices
Supports master/slave and star topology networks
Device Address
Security Suite
Payload Keys
8 octets or 1 octet
1 octet
Variable
(16 octets typical)

15. Access Control List
Device Address
Security Suite
Payload Keys
8 octets or 1 octet
1 octet
Variable
(16 octets typical)
Many ways for DME to introduce devices and exchange payload keys:
User entry
“Learn” mode – Broadcast a symmetric key over the radio
Public-key Cryptography
“Learn” mode – Broadcast a public key over the radio (safer!)
User verifies correct public key received …

16. Payload Protection
Encryption and/or integrity provided as a black box to the MAC
If the SEC bit is set, MAC passes data to security suite
Security suite decrypts and/or checks integrity, and passes results to DME
Conclusion: MAC doesn’t need to know anything about the security suite. Just that it’s on!
Devices without security can just ignore frames with SEC=1
Security suite determines if encryption, integrity, or both are provided

17. Secure Frame Control Field Format
So what does a new frame control field look like?
A lot like the old one…
Note the change: the SEC bit
Bits: 0-2 3 4 5 6
7-8 9
10-11 12 13
14-15
Frame type
Dest. fields present
Dest. addr. mode
Source fields present
Source addr. mode
Reserved
SEC
Frame fragment specifier
Frame seq. bit
Frame following
Ack. policy

18. Protected beacon payload
Secure Beacon Format
So what does a secure beacon look like?
The same, apart from optionally protecting the payload
Octets: 2
3/10 1
variable 2
Frame control
(SEC = 0)
Address info
Sequence number
Superframe spec.
Pending address spec.
Address list
Beacon payload
Frame Sequence Check
Frame control (SEC = 1)
Protected beacon payload
Frame Check Sequence
MAC Header
MAC Payload
MAC Footer

19. Protected command payload
Secure Command Format
So what does a secure beacon look like?
The same, apart from optionally protecting the payload
Octets: 2
Variable 1
variable 2
Frame control
(SEC = 0)
Address information
Sequence number
Command type
Command payload
Frame sequence check
Frame control (SEC = 1)
Protected command payload
Frame sequence check
MAC header
MAC payload
MAC footer

20. Secure Data Frame Format
So what does a secure data frame look like?
Again, the same, apart from optionally protecting the payload
Octets: 2
Variable 1
variable 2
Frame control
(SEC = 0)
Address information
Sequence number
Data payload
Frame sequence check
Frame control (SEC = 1)
Protected data payload
Frame check sequence
MAC header
MAC payload
MAC footer

21. Recommended Security Suite
To offer interoperability,
Select a mandatory security suite or
Mandate a way for DEVs to negotiate a suite to use
Mandating one reduces device complexity, but won’t meet the needs of every application
Every security suite adds some overhead
Extremely constrained devices may not be able to tolerate any overhead
Some members have recommended Triple-DES.
Here’s our experience implementing Triple-DES
We think it’s a reasonable choice

22. Triple-DES DES has a 64-bit block size.
DES encryption has 16 rounds. Triple-DES encryption has 48.
Using DES for integrity takes another 16 rounds, except for the last block, which takes 48.
So we need 64 rounds per 64 bits.
Instantiating one round of DES in hardware on an 8-bit bus gives a throughput of 3 cycles/bit
So a 250 kbps data rate needs a 1 MHz clock.
Hardware implementations in 3.5 – 6 thousand gates.
Bandwidth overhead of 4 bytes or more for integrity code (4 is allowed), 1 byte for length
Bandwidth overhead of 9-16 bytes for encryption using CBC mode or 4 bytes or more for CTR mode

23. Triple-DES Security
Encryption standardized in ANSI X9.52, FIPS 46-3, …
Well-studied since the late 1970s.
112-bit key makes brute force key search attacks infeasible
Integrity Code standardized in ISO 9797, …
We provide integrity on the ciphertext, not the plaintext
Length field makes best attack brute force guessing on integrity code
4 byte integrity code gives 1 in 4 billion chance of correct guess
6.2 days of streaming at 250 kbps to get one fake message accepted
4 byte overhead on CTR encryption allows you to send 4 billion frames before needing to change keys

24. Intellectual Property
IBM held a patent on DES, dating from 1975.
It’s expired now, but it was never enforced anyway
Triple-DES-CBC first suggested in April, 1977
Unpatented by its authors.
1977 patents expired in 2000

25. What have we done?
Security architecture bandwidth overhead of a single bit per frame
Applications can choose the algorithms and features desired
These will add bandwidth overhead
We can still support ALL of a full security solution for high-security applications, while not burdening devices
No intellectual property!!

26. Did we meet our goals? Low cost!
Algorithm agility
Check!
Low cost!
Low bandwidth overhead/transmission time!
One bit/frame due to architecture. 8 or more bytes for interoperable algorithm, applications may choose alternate algorithms for lower overhead.
Low code space!
Applications implement only the services they need
Low chip area!
3-DES in thousand gates
Low power drain!
Clock rate of 1 MHz
Support both star topology and peer to peer (master/slave)
Scalable

27. Conclusion Devices that need security get just what they need
On a frame-by-frame basis
Secured devices have maximum latitude in delicate cost/power/bandwidth tradeoffs