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