February, 2016 IEEE P802.15-416r0 IEEE P802.15 Wireless Personal Area Networks Project IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Title TG4b MAC Security Clarification Date Submitted [9 August, 2004] Source [Jonathan Avey] [Ember Corporation] [313 Congress St, Boston, MA 02210] Voice: Fax: E-mail: [ ] [ ] [jonathan.avey@ember.com ] Re: [15-04-0239-00-004b-tg4b-call-proposals.doc] Abstract [Parts of the IEEE 802.15.4-2003 draft that describe the operation of security are inconsistant and incomplete. This document offers clarifications and additional information to inconsistancies.] Purpose [This document is provided to the TG4b group to help draft clarifying text and diagrams, as per 15-04-0239-00-004b-tg4b-call-proposals.] 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. Submission Page 1 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 Table of Contents 1. INTRODUCTION: ......................................................................................................................... 3 2. REFERENCES IN 802.15.4 SPECIFICATION .......... ERROR! BOOKMARK NOT DEFINED. 3. EXAMPLE PACKET ACCEPTED IN JUNE 16TH 2003 CALL .. ERROR! BOOKMARK NOT DEFINED. Submission Page 2 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 1. Introduction: In IEEE 802.15.4-2003 (“the specification”), the optional frame counter and key sequence counter for security are not included in the description of the MAC frame formats. They are difficult to follow in other references to incoming and outgoing frames with security and prone to misinterpretation, including references to a payload field in the MAC payload. The specification is inconsistant; it includes some references which do not show any data which is not authenticated in the MAC Header and MAC Payload and some references which do not authenticate these fields. An example frame with security was presented to the 802.15.4 working group in the June 16 th 2003 which explicitly shows which portions of the frame are authenticated and which portions are authenticated and encrypted. The example shows the frame counter and key sequence counter included in the frame before security and used as data that is authenticated, and was accepted as correct. This document uses the example frame, and offers text and graphics to make the IEEE 802.15.4-2003 security specification self-consistant. Submission Page 3 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 2. REFERENCES IN 802.15.4-2003: - 7.2.1.7 Frame payload field The frame payload field has a variable length and contains information specific to individual frame types. If the security enabled subfield is set to 1 in the frame control field, the frame payload is protected as defined by the security suite selected for that relationship. Problem. The frame payload is defined to include information that is not protected, ie when frame counter and key seq counter are added. Proposed Solution. Protect the included frame counter and key seq number explicitly by authenticating it. Also to show in frame formats the possible included fields due to security. - 7.2.2.1 Beacon frame format The beacon frame shall be formatted as illustrated in Figure 37. Problem. The MAC Payload does not show the optional frame counter and key seq number. Proposed Solution. These need to be added at the start of the MAC payload 0/4 and 0/1 respectively in Figure 37. - 7.2.2.2 Data frame format The data frame shall be formatted as illustrated in Figure 45. Problem. The MAC Payload does not show the optional frame counter and key seq number. Proposed Solution. These need to be added at the start of the MAC payload 0/4 and 0/1 respectively in Figure 45. - 7.2.2.4 MAC command frame format The MAC command frame shall be formatted as illustrated in Figure 47. Problem. The MAC Payload does not show the optional frame counter and key seq number. Proposed Solution. These need to be added at the start of the MAC payload 0/4 and 0/1 respectively in Figure 47. - 7.5.8.4.1 Processing outgoing frames in secured mode Paragraph 5 If the security suite specifies the use of encryption, the encryption operation shall be applied only to the data in the payload field within the MAC payload, i.e. the beacon payload field (see 7.2.2.1.8), command payload field (see 7.2.2.4.3) or data payload field (see 7.2.2.2.2), depending on the frame type. The remaining fields shall be left unencrypted. If a frame does not contain a payload field, encryption shall not be used. The result of the encryption operation shall be inserted into the payload field of the frame in the place of the original data. Problem. Refers to the payload field within the MAC payload. This can be confusing. Proposed Solution ? - 7.5.8.4.2 Processing incoming frames in secured mode Paragraph 7 Submission Page 4 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 If the security suite specifies the use of encryption, the decryption operation shall be applied only to the data in the payload field within the MAC payload, i.e. the beacon payload field (see 7.2.2.1.8), command payload field (see 7.2.2.4.3) or data payload field (see 7.2.2.2.2), depending on the frame type. If a frame does not contain any data in the payload field, decryption shall not be used. The result of the decryption operation shall be inserted into the payload field of the frame in the place of the original encrypted data. Problem. Confusing talking about unnamed payload fields in payload fields. Proposed Solution. ? - 7.6.3.3.1 Outgoing frame operations When the AES-CCM security suite is invoked to protect an outgoing frame, the MAC sublayer shall perform the following operations: 1) Obtain its own 64-bit extended address, aExtendedAddress, along with the frame counter and the sequence counter from the MAC PIB, and construct the nonce as specified in 7.6.3.1.3. 2) Encrypt and authenticate the MAC header and MAC payload in the frame using CCM authentication and encryption, as specified in 7.6.1.6, with the parameters specified in 7.6.3.2. Use the MAC header and nonpayload fields in the MAC payload as the authentication data, a, the payload field in the MAC payload as the message, m, and the nonce computed in step 1. 3) Combine the frame counter, sequence counter and output from step 2 (including the encrypted payload and encrypted integrity code), as specified in 7.6.3.1.2, to obtain the new payload field. 4) Increment the frame counter as specified in 7.6.1.3 and, if the incrementing succeeds, insert the new counter value into the MAC PIB. If the incrementing operation fails due to the counter value rolling over, the device shall abort the operation and issue the MLME-COMM-STATUS. indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. Problem. Frame Counter and Key Sequence Counter fields added after authentication without showing them as part of the format of the packet previously. Proposed Solution. Include them first in the packet before authentication and authenticate those fields. 7.6.3.3.1 Outgoing frame operations When the AES-CCM security suite is invoked to protect an outgoing frame, the MAC sublayer shall perform the following operations: 1) Obtain its own 64-bit extended address, aExtendedAddress, along with the frame counter and the sequence counter from the MAC PIB, and construct the nonce as specified in 7.6.3.1.3. 2) Encrypt and authenticate the MAC header and MAC payload in the frame using CCM authentication and encryption, as specified in 7.6.1.6, with the parameters specified in 7.6.3.2. Use the MAC header including the frame counter, sequence counter and MAC payload as the authentication data, a, the payload field in the MAC payload as the message, m, and the nonce computed in step 1. 3) Increment the frame counter as specified in 7.6.1.3 and, if the incrementing succeeds, insert the new counter value into the MAC PIB. If the incrementing operation fails due to the counter value rolling over, the device shall abort the operation and issue the MLME-COMM-STATUS. indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. - 7.6.3.3.2 Incoming frame operations When the AES-CCM security suite is invoked to protect an incoming frame, the MAC sublayer shall perform the following operations in order: 1) If the optional external frame and external key sequence counters are included in the corresponding macDefaultSecurityMaterial or ACLSecurityMaterial field, ensure sequential freshness by verifying that the received key sequence counter is greater than or equal to the external key sequence counter from that device. If the key sequence counter is equal to the external key Submission Page 5 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 sequence counter, verify that the received frame counter is greater than the external frame counter from that device. If either of these checks fail, the device shall reject the frame and issue the MLME-COMM-STATUS.indication primitive to the higher layer with a ReasonCode of FAILED_SECURITY_CHECK. 2) Obtain the 64-bit extended address of the source either from the frame or from the ACL, remove the frame counter and sequence counter from the payload field in the MAC payload and construct the nonce as specified in 7.6.3.1.3. If the nonce cannot be constructed due to the data being unavailable, the device shall reject the frame and issue the MLME-COMM-STATUS. indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. 3) Decrypt the encrypted payload field and verify the integrity code using CCM decryption and authentication, as specified in 7.6.1.6, with the parameters specified in 7.6.3.2. Use the MAC header and non-payload fields in the MAC payload as the authentication data, a, the encrypted payload field as the message, m, and the nonce computed in step 2. If the integrity code fails, the device shall discard the frame and issue the MLME-COMM-STATUS.indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. 4) Replace the existing payload field in the MAC payload with the decrypted data from step 3. If optional operation 1) was performed, and the checks succeeded, the last known sequence counter and last known frame counter shall be set to the received values. Problem. Frame Counter and Key Sequence Counter fields removed before authentication without showing them as part of the format of the packet previously. Proposed Solution. Include them when authenticating and do not include them as part of the MAC payload after this. Only the encrypted portion is payload data. 7.6.3.3.2 Incoming frame operations When the AES-CCM security suite is invoked to protect an incoming frame, the MAC sublayer shall perform the following operations in order: 1) If the optional external frame and external key sequence counters are included in the corresponding macDefaultSecurityMaterial or ACLSecurityMaterial field, ensure sequential freshness by verifying that the received key sequence counter is greater than or equal to the external key sequence counter from that device. If the key sequence counter is equal to the external key sequence counter, verify that the received frame counter is greater than the external frame counter from that device. If either of these checks fail, the device shall reject the frame and issue the MLME-COMM-STATUS.indication primitive to the higher layer with a ReasonCode of FAILED_SECURITY_CHECK. 2) Obtain the 64-bit extended address of the source either from the frame or from the ACL, use the frame counter and sequence counter from the payload field in the MAC payload and construct the nonce as specified in 7.6.3.1.3. If the nonce cannot be constructed due to the data being unavailable, the device shall reject the frame and issue the MLME-COMM-STATUS. indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. 3) Decrypt the encrypted payload field and verify the integrity code using CCM decryption and authentication, as specified in 7.6.1.6, with the parameters specified in 7.6.3.2. Use the MAC header and the MAC payload as the authentication data, a, the encrypted payload field as the message, m, and the nonce computed in step 2. If the integrity code fails, the device shall discard the frame and issue the MLME-COMM-STATUS.indication primitive to the higher layers with a ReasonCode of FAILED_SECURITY_CHECK. 4) Replace the existing payload field in the MAC payload with the decrypted data from step 3. If optional operation 1) was performed, and the checks succeeded, the last known sequence counter and last known frame counter shall be set to the received values. Submission Page 6 Jonathan Avey, Ember Corporation February, 2016 Submission IEEE P802.15-416r0 Page 7 Jonathan Avey, Ember Corporation February, 2016 IEEE P802.15-416r0 3. EXAMPLE PACKET ACCEPTED IN JUNE 16TH 2003 CALL: CCM Transmit Example Packet Values are in hexadecimal except for bit field definitions and length calculations. C0 C1 C2 C3 A0 A1 A0 A1 C4 C6 Source Address A2 A3 A4 A5 Destination Address A2 A3 A4 A5 Source PAN BE EF Dest PAN BE EF C5 Key C7 C8 C9 A6 A7 A6 A8 CA CB CC CD CE CF L(packet) = l(a) + l(m) + l(mic) + l(CRC) L(packet) = 28 + 23 + 8 + 2 = 61 (0x3D) l(a) = 28 l(m) = 23 M=3 l(mic) = 2*M+2 = 8 Frame Counter 00 01 02 03 key seq counter 01 CTR Flag 01 bit 7 RES 0 bit 6 RES 0 bit 5 0 0 bit 4 0 0 bit 3 0 0 bit 2 CBC Flag 59 bit 7 RES 0 bit 6 ADATA 1 bit 5 bit 4 M 1 bit 3 bit 2 1 0 0 0 bit 1 L-1 0 bit 0 bit 1 L-1 0 bit 0 Nonce A0 A1 Source Address 8 bytes A2 A3 A4 A5 Frame Control Subfield Submission CC bit 15 bit 14 Source Addr Mode 64 bit address 1 1 bit 13 bit 12 RES 0 1 Block Counter (initial value) A7 Frame count 4 bytes 00 01 02 03 Page 8 09 0 A6 1 bit 11 bit 10 Dest Addr Mode 64 bit address 1 1 Keycnt 00 01 1 01 Jonathan Avey, Ember Corporation bit 9 bit 8 RES bit 7 0 0 0 bit 6 Inter PAN No 0 bit 5 Ack Req No 0 bit 4 Frame P No 0 bit 3 Sec En Yes 1 bit 2 0 bit 1 Frame Type Data 0 bit 0 1 February, 2016 IEEE P802.15-416r0 Data * All Data values in hexadecimal Zero Stuff AES * XX denotes 8 don't care bits AES Submission XOR AES Page 9 XOR AES XOR AES XOR AES XOR XOR XOR AES AES Jonathan Avey, Ember Corporation