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: [Security Comments on D10] Date Submitted: [July 6, 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 some security comments on D10.] Purpose: [To familiarize the working group with security-related comments.] 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. Review of Algorithm Choices In D10 • AES-CCM is the symmetric cipher • Provides encryption and integrity on data to be transmitted over the radio • Mode selected by TG4 and received a majority of support in 802.11i • ECIES is the mandatory public-key algorithm, selected in LB16 • NTRUEncrypt is an optional public-key algorithm

3. Change Mandatory Suite to RSA as Defined in 02/228r1 • RSA algorithm well-studied since 1977 • Patent expired September 20, 2000 • 02/228r1 based on PKCS #1 v. 2.1 standard • Extremely wide deployment and scrutiny: it’s in your web browser • More than 500,000,000 implementations according to RSA Security

4. Why Change to RSA? • Faster than ECC on many microcontrollers such as ST19KF16 • NIST recommends use of 1024-bit RSA keys until 2016 for sensitive but unclassified U.S. government data • Mandatory to implement algorithm in TLS and widely used in IETF RFCs • Mandatory to implement algorithm in EMVCo • Europay, Mastercard, and Visa’s joint venture to develop EMV Integrated Circuit Card Specifications for Payment Systems • “EMVCo has executed a feasibility study on the potential introduction of elliptic curves next to RSA. The conclusion of the study is that at this point in time there is no reason to do so. “ from www.emvco.com. Click on frequently asked questions … security • RSA OAEP included in OpenSSL toolkit

5. MLME-XXX.indication (or .confirm) • Add entries to the semantics tables: MLME-XXX.indication (or .confirm) ( SecurityUse, ACLEntry ) • SecurityUse indicates a received frame was secured • ACLEntry indicates a received frame came from a device in the device’s ACL • Allows security to be turned on/off on a frame by frame basis

6. MLME-XXX.request (or .response) • Add entries to the semantics tables: MLME-XXX.request (or .response) ( KeySelection ) • A device may share several keys with another device • PICONET-MGMT, the key management key I share with the PNC • PICONET-DATA, the payload protection key I share with the rest of the piconet • PEER-MGMT, a key management key I share with another device • PEER-DATA, a payload protection key I share with another device • KeySelection field tells the MAC which key to use

7. MLME-SECURITY-ERROR.indication • We need a way to indicate to the DME that a security error occurred: MLME-SECURITY-ERROR.indication ( SrcID, DestID, SECID, ReasonCode ) • SECID tells you which key was purportedly used • ReasonCode is UNAVAILABLE-KEY, FAILED-SECURITY-CHECK, BAD-TIME-TOKEN

8. Nonce in CCM • Recall that in AES-CCM mode we need a unique 13-byte nonce for each frame • We can construct most of the nonce from data we know before seeing this particular frame like: • 1-byte source DEV ID • 1-byte destination DEV ID • 6-byte current TimeToken • 2-byte secure frame counter • 3-byte fragmentation control field from the MAC header • The secure frame counter is 2 octets sent with every secure frame • Tells you how many times that key was used within a superframe for this sender

9. SECID • Security Session Identifier, formerly SSID • It’s actually a key identifier • Reduced from 8 bytes down to 2 bytes • To avoid collisions, change the high-order 2 bits to indicate the key’s function: • MSB: Piconet or peer-to-peer key? • Next-MSB: Management key or data key?

10. Section 9 descriptive text on secure frame processing • Recommend text to better explain how security is to be used • Applying and removing security to frames • Using security in beacons • Integrity is computed on the entire frame except for the FCS • The retry field in the frame control field in the MAC header needs to be set to 0 before computing integrity code in order to allow retransmission of frames without recomputing the CCM operations. • The DME informs the DEV which key should be used to protect a given frame • Encryption is only used for keys and data - not on commands or beacons