September 16, 2004
IEEE P802.15-4/0539r0
Project
IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Title
Replacement Security Text
Date
Submitted
September 16, 2004
Source
René Struik
Certicom Corp.
5520 Explorer Drive, 4th Floor
Mississauga, ON, Canada L4W 5L1
Voice:
Fax:
E-mail:
+1 (905) 501-6083
+1 (905) 507-4230
[email protected]
Re:
IEEE 802.15.4-2003
Abstract
This document provides an overview of replacement security text (rough draft!).
Purpose
Facilitate adoption and incorporation of security improvements to the current
IEEE 802.15.4-2003 specification.
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
Rene Struik, Certicom
Table of contents
Table of contents .............................................................................................................................................2
1
References to security comments on 802.15.4-2003 and its predecessors ...............................................3
2
Replacement Security Text .......................................................................................................................4
2.1 Security-Related PIB Attributes ......................................................................................................4
3
Frame Security .........................................................................................................................................7
3.1 Auxiliary Frame Header Format ......................................................................................................7
3.1.1
Counter field .......................................................................................................................7
3.1.2
Security control field ...........................................................................................................7
3.1.3
Key Identification Field ......................................................................................................9
3.1.4
Constructing the Processed Auxiliary Frame Header .........................................................9
3.2 Security Parameters .......................................................................................................................10
3.2.1
CCM* Mode of Operation and Parameters .......................................................................10
3.2.2
Security Material ...............................................................................................................10
3.2.3
CCM* Nonce ....................................................................................................................10
3.3 Security Processing Steps ..............................................................................................................11
3.3.1
Outgoing Frame Operations ..............................................................................................11
3.3.2
Incoming Frame Operations ..............................................................................................12
4
Security Status Codes .............................................................................................................................15
4.1 Status Values .................................................................................................................................15
ANNEX A – Basic notions ............................................................................................................................16
A.1.1 Strings and string operations .............................................................................................16
A.1.2 Integers, octets, and their representation ...........................................................................16
A.1.3 Entities ..............................................................................................................................16
ANNEX B – CCM* mode of operation.........................................................................................................17
ANNEX C – Security Building Blocks .........................................................................................................18
C.1.1 Block-cipher ......................................................................................................................18
C.1.2 Mode of operation .............................................................................................................18
September 16, 2004
1
IEEE P802.15-4/0539r0
References to security comments on 802.15.4-2003 and its predecessors
IEEE 802.15.4 security documents (submitted by René Struik):
November 14, 2002:
02474r0P802-15_TG4-Security-and-Security-Architectural-Recommendations-for-the-IEEE-802.15.4-Low-Rate-WPAN
November 14, 2002:
02474r1P802-15_TG4-Security-and-Security-Architectural-Recommendations-for-the-IEEE-802.15.4-Low-Rate-WPAN
November 15, 2002:
02468r0P802-15_TG4-Draft-D17-Clause 7.6-Security-Recommendation-for-IEEE-802.15.4-Low-Rate-WPAN
November 15, 2002:
02469r0P802-15_TG4-Draft-D17-Annex B-Security-Recommendation-for-IEEE-802.15.4-Low-Rate-WPAN
January 16, 2003:
02474r2P802-15_TG4-Security-and-Security-Architectural-Recommendations-for-the-IEEE-802.15.4-Low-Rate-WPAN
July 24, 2003:
15-03-0320-00-0040P802-15_TG4-Suggestions-for-Improvement-of-the-IEEE-802.15.4-WPAN-Standard
July 25, 2003:
15-03-0320-01-0040P802-15_TG4-Suggestions-for-Improvement-of-the-IEEE-802.15.4-WPAN-Standard
November 11, 2003:
15-03-0320-02-0040P802-15_TG4-Suggestions-for-Improvement-of-the-IEEE-802.15.4-WPAN-Standard
July 22, 2003:
03284r0P802-15_TG4-Suggestions-for-Improvement-of-the-IEEE-802.15.4-Standard
July 18, 2003:
03285r0ZB-Suggestions-for-Improvement-of-the-IEEE-802.15.4-Standard
July 24, 2003:
03285r1ZB-Suggestions-for-Improvement-of-the-IEEE-802.15.4-Standard
May 11, 2004:
15-04-0245-00-004b-suggestions-improvement-ieee-802-15-4-2003-wpan-standard
July 15, 2004:
15-04-0245-01-004b-suggestions-improvement-ieee-802-15-4-2003-wpan-standard
July 15, 2004:
15-04-0245-01-004b-suggestions-improvement-ieee-802-15-4-2003-wpan-standard
September 16, 2004:
15-04-0537-00-004b-Formal-Specification-of-CCM-Star-Mode-of-Operation
Academic paper:
N. Sastry, D. Wagner, Security Considerations for IEEE 802.15.4 Networks, University of California, Berkely, CA, submitted for
publication.
Submission
Page 3
Rene Struik, Certicom
2
Replacement Security Text
2.1
Securit y- Related PI B Attributes
Reference 802.15.4-2003: Tables 72 and 73.
The security-related PIB attributes are required to manage security across all layers. Each of these attributes can be
read or written using GET.request and SET.request primitives at the appropriate layer, respectively. The securityrelated PIB-attributes are presented in Table 1 through Table 4. Not all these attributes need to be available at the
MAC layer. Nevertheless, it is useful to see security-related attributes in the context of the complete protocol stacks.
Security attributes that do not have to be visible to the MAC layer are indicated as such (in red).
Table 1 PIB security attributes
Attribute
LinkKeySet
Identifier
TBD
Type
Set of link
key
descriptor
entries.
See Table
2.
Set of
device
descriptor
entries.
See Table
4
Range
Description
Default
Variable
A set of link key descriptor
entries, each containing key
information and attributes.
Null set
Variable
A set of device descriptor
entries, each containing
device information and
security attributes.
Null set
DeviceSet
TBD
FrameCounter
TBD
Set of 4
octets
0x000000000xFFFFFFFF
SecurityMinimum
TBD
Integer
0x00-0x07
The frame counter used to
ensure sequential freshness
of frames sent by this device.
The minimal
required/expected security
level for outgoing and
incoming MAC frames. The
allowable security level
identifiers are presented in
Table 5. Note that other
layers of the protocol stack
may have their own minimum
expected security level.
0x00000000
0x06
September 16, 2004
IEEE P802.15-4/0539r0
Table 2 Elements of the link key descriptor
Name
Type
Range
KeySrcAddress
Device
address
Any valid
64-bit
address
KeySerialNumber
Set of 4
octets
0x000000000xFFFFFFFF
KeySeqNumber
Octet
0x00-0xFF
KeyValidityInfo
Set of 4
octets
0x000000000xFFFFFFFF
MembershipSet
Set of key
membership
descriptor
values. See
Table 3
Description
Default
Extended device address.
-
Unique identifier of the key
originating with the device indicated
by KeySrcAddress. Not visible at
MAC.
Short alias for the KeySerialNumber.
The value 0x00 indicates that this
key is a master key or peer-to-peer
key; the other values indicate that
this is a (group) link key. Not visible
at MAC for non-group keys.
Used to store key validity information
of the key in question. For
representation of time, see Error!
Reference source not found.. Not
visible at MAC.
-
-
0x00000000
Variable
Set of devices of which messages
were received using this group key,
including blacklist info (to indicate
whether received frame counter for
that device was exhausted, if
freshness is checked). This entry
may be discarded if the key in
question is a master key.
Null set
Indicator as to the presence of the
Key (Yes if TRUE; No if FALSE). If
FALSE, the info above specifies a
logical group address, with short
alias info and membership
information.
TRUE
KeyPresent
Boolean
TRUE or
FALSE
Key
Set of 16
octets
-
The actual value of the key.
-
Table 3 Elements of the key membership descriptor
Name
SrcAddress
BlackListStatus
Submission
Type
Range
Device
address
Any valid
64-bit
address
Extended device address.
TRUE or
FALSE
Indicator as to whether the device indicated by
SrcAddress previously communicated with this link
key, prior to exhaustion of the frame counter, if
freshness is checked. (Yes if TRUE; No if FALSE). If
TRUE, this indicates that the source device cannot
further use this key, since it exhausted its use of the
frame counter used with this key.
Boolean
Description
Page 5
Default
Device
specific
FALSE
Rene Struik, Certicom
Table 4 Elements of the device list descriptor
Name
Type
Range
SrcAddress
Device
address
Any valid
64-bit address
DeviceRole
Bitmap
Variable
CheckFreshness
Boolean
TRUE or
FALSE
FrameCounter
Set of 4
octets
0x000000000xFFFFFFFF
SecurityMinimum
Integer
0x00-0x07
Description
Extended device address.
Reserved for future use. Not visible
at MAC.
Indicator as to the presence of the
parameter FrameCounter (Yes if
TRUE; No if FALSE).
The frame counter used to ensure
sequential freshness of frames
received from the device indicated
by SrcAddress (shall be present if
CheckFreshness enabled)
The minimal required/expected
security level for outgoing and
incoming MAC frames. The
allowable security level identifiers
are presented in Table 5. Note that
other layers of the protocol stack
may have their own minimum
expected security level.
Default
Device
specific
Null set
TRUE
0x000000
00
0x06
September 16, 2004
3
IEEE P802.15-4/0539r0
Frame Security
Reference 802.15.4-2003: Clause 7.5.8.
This clause describes the security-related processing steps at the MAC layer. These layers shall use the auxiliary
frame header, as specified in 3.1, to convey security settings in a secured frame. Outgoing and incoming NWK and
APS frames shall be handled according to the procedures specified in sections 3.3.1 and 3.3.2, respectively.
3.1
Auxiliary Frame Header Format
The auxiliary frame header includes a counter field, a security control field, and a key identification field, and shall
be formatted as illustrated by Figure 1. The security control field specifies the settings used for the security
processing and indicates the makeup of the key identification field. If security is disabled, the counter shall be
omitted. (Note RS: we do not want to provide for in-order receipt/sequential freshness if security is disabled.)
0/1/4
Octets: 0/1
0/3/5/9
Counter field
Security control field
Key identification field
Figure 1 Auxiliary frame header format
3. 1. 1 Count e r f i eld
The counter field is used to provide for frame freshness and to prevent processing of duplicate frames. Its value is
determined from the frame counter of the device that is the source of the frame.
The counter field is represented as indicated by the reduced nonce subfield in the frame control field (see
‘compression bit’ on Slide 4 of IEEE submission 02/474r2 [to be edited]). If this subfield is set to 0, the counter field
shall be equal to the full 4-octet frame counter (uncompressed format); if this subfield is set to 1, the counter field
shall consist of the least significant octet of the frame counter only (compressed format).
Editor's Note —
’The text below needs to be incorporated in Clause 7.2.1 of 802.15.4-2003:
The reduced nonce subfield is a 1-bit field indicating the representation of the frame counter contained in the
auxiliary frame header (when security is enabled). This subfield shall be set to 0 if this frame counter is represented
as a 4-octet string (uncompressed format) and shall be set to 1 if this frame counter is represented as a 1-octet string
(compressed format).
Editor's Note —
’The text below needs to be incorporated in Clause 7.5.6.2 of 802.15.4-2003:
For details, see Slides 17-28 of IEEE document P802.15-02/474r2.
3. 1. 2 S ec ur it y cont ro l f i eld
The security control field is the empty string if the 1-bit security subfield contained in the frame control field is set
to 0, since then security is turned off (see Clause 7.2.1.1.2 of 802.15.4-2003). Otherwise, the security control field is
a 1-octet field and shall be formatted as shown in Figure 2.
Bit: 0-2
3
4
5
6-7
Security level
Key identification
mode
Reserved
Reserved
Key source addressing
mode
Figure 2 Security control field format
Submission
Page 7
Rene Struik, Certicom
3.1.2.1
S e c u r i t y l e ve l
The security level identifier indicates how an outgoing frame is to be secured, respectively, how an incoming frame
purportedly has been secured: it indicates whether or not the payload is encrypted and to what extent data
authenticity over the frame is provided, as reflected by the length of the message integrity code (MIC). The bitlength of the MIC may take the values 0, 32, 64 or 128 and determines the probability that a random guess of the
MIC would be correct. Note that protection against replay attacks requires the CheckFreshness field to be set. The
security properties of the security levels are listed in Table 5.
Table 5 Security levels available to the NWK and APS layers
Security
level
identifier
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
3.1.2.2
Security
Control
Field
(Figure 2)
‘000’
‘001’
‘010’
‘011’
‘100’
‘101’
‘110’
‘111’
Security
Attributes
Data
Encryption
Frame Integrity
(length M of MIC, in
number of octets)
None
OFF
NO (M = 0)
MIC-32
OFF
YES (M=4)
MIC-64
OFF
YES (M=8)
MIC-128
OFF
YES (M=16)
ENC
ON
NO (M = 0)
ENC-MIC-32
ON
YES (M=4)
ENC-MIC-64
ON
YES (M=8)
ENC-MIC-128
ON
YES (M=16)
Ke y identification mode
The key identification mode is a 1-bit field indicating whether or not the key by which the frame is secured is
derived implicitly or explicitly. This subfield shall be set to 0 if the key is derived implicitly (from addressing
information associated with the processed frame header) and shall be set to 1 if the key is derived explicitly (from
information contained in the key identification field). The key identification field of the auxiliary frame header
(Figure 1) shall only be present if this subfield has the value 1.
3.1.2.3
Ke y source addressing mode
The key source addressing mode field is a 2-bit subfield that is used to identify the addressing mode of the key
source within the key identification field and shall be set to one of the values indicated in Table 6. This subfield
shall be discarded if the key identification mode is set to 0.
September 16, 2004
IEEE P802.15-4/0539r0
Table 6 Values of the key-source address mode
Key source
addressing mode
B1 b0
Integer
Value
00
0x00
01
0x01
10
0x02
11
0x03
Description
The key source address is implicitly determined from the
address of the coordinator.
The key source address is the 16-bit short address of the
source entity.
The key source address is the right-concatenation of the
PAN ID and the 16-bit short address of the source entity.
The key source address is the extended 64-bit address of
the source entity.
Key source address
length (octets)
0
2
4
8
3. 1. 3 Ke y Id ent if i c at io n F i e ld
The key identification field shall only be present if the key identification mode subfield (see 3.1.2.2) has value 1. If
so, the key identification field explicitly indicates the key that shall be used for securing outgoing frames or that
purportedly has been used to secure incoming frames. The key identification field shall be formatted as indicated in
Figure 3. The key identification field consists a key source address and a key sequence number. The key source
address subfield shall indicate the address of the key originator, represented in the format indicated by the key
source addressing mode subfield (see 3.1.2.3). The key sequence number may allow unique identification of
different keys originating from the same key source. It is the responsibility of the key originator to make sure that
actively used keys that it issues have distinct key sequence numbers.
Octets: 0/2/4/8
0/1
Key source address
Key sequence number
Figure 3 Format for the key identification fields
3. 1. 4 Con st ruc t in g t h e P r o ce s se d Au x i li a r y F ra me H ea de r
The processed auxiliary frame header ProcessedAuxFrameHeader is obtained from the auxiliary frame header
AuxFrameHeader, essentially by converting its subfields to the full respresentations hereof. This process comprises
the following steps:
1.
Set FullNonce to the value of the counter field specified in clause 3.1.1. If the counter field is a 1-octet
field, recompute the complete (uncompressed) 4-octet frame counter based on the source device's frame
counter and set FullNonce to this 4-octet value.
2.
If the key identification field is present, (i.e., if the key identification mode bit in the security control field
(Figure 2) is set to 1), derive the 64-bit extended address from the key source address.
3.
The octet string ProcessedAuxFrameHeader is obtained from the auxiliary frame header AuxFrameHeader
by substituting the counter subfield by the string FullNonce obtained in step 1 above, by substituting the
security control field SCF by the string MaskedSCF obtained in step Error! Reference source not found.
above, and by substituting the key source address in the key identification field, if present, by its extended
address obtained in step 2 above.
Editor's Note —
’This preprocessing step allows resending of frames for which the sender did not receive an
acknowledgement message without the need to cryptographically process the frame again. This is due to the fact that
alternative representations are mapped to a fixed (long) representation prior to cryptographic processing.
Submission
Page 9
Rene Struik, Certicom
3.2
Securit y Parameters
This clause specifies the parameters used for the CCM* security operations.
3. 2. 1 CCM * M ode of O pe r at ion an d P ar a met e r s
Applying security to a frame on a particular security level corresponds to a particular instantiation of the AESCCM* mode of operation as specified in section C.1.2. The AES-CCM* mode of operation is an extension of the
AES-CCM mode that is used in the 802.15.4-2003 MAC specification and provides capabilities for authentication,
encryption, or both.
The cryptographic key shall be extracted from the security material in the MAC PIB as described in 3.2.2, and the
nonce shall be formatted as specified in 3.2.3.
Table 5 gives the relationship between the security level subfield of the security control field (i.e., see Figure 2), the
security level identifier, and the CCM* encryption/authentication properties used for these operations.
3. 2. 2 S ec ur it y M at e r ia l
For each entity to which a device sends or receives secured frames there is an ACL entry in the MAC PIB. The ACL
entry contains the implicit or explicit address of the entity (if explicit it also contains a key identifier – see 3.1.2.2)
and the corresponding security material associated with that entity. The security material shall consist of an AES
key, a frame counter for outgoing frames, and an external frame counter for incoming frames (see Figure 4).
The frame counter is the running counter that shall be used to construct the nonce field specified in clause 3.2.3.
This counter shall be incremented each time a secure frame is transmitted, as specified in 3.3.1and it shall not roll
over. The fact that this frame counter value changes for every frame helps to ensure that the CCM* nonce is unique
(and thus guarantees semantic security) and allows the recipient to use the counter to ensure freshness or to detect
duplicates. The recipient of a frame shall use the frame counter of the originator of the message to verify the
freshness of an incoming frame, as specified in 3.3.2.
Security Element
Size
(Octets)
AES Symmetric Key
16
The cryptographic key used to secure incoming and outgoing frames.
Frame Counter
(for outgoing frames)
4
The frame counter used by a device when originating a frame (same as the
FrameCounter parameter given in Table 1).
External Frame Counter
(for incoming frames)
4
The frame counter used by a device to verify freshness of incoming frames
(same as the FrameCounter parameter given in Table 4). This counter is
only available if the CheckFreshness parameter in Table 4 is enabled.
Description
Figure 4 CCM* security-related material
3. 2. 3 CCM * Non ce
The nonce input used for the CCM* encryption and authentication transformation and for the CCM* decryption and
authentication checking transformation consists of data explicitly included in the frame and data that both devices
can independently obtain. Figure 5 specifies the order and length of the subfields of the CCM* nonce. The source
address is the extended 64-bit MAC address SrcAddress of the device originating the frame. The frame counter is
the outgoing frame counter determined by the source device. The nonce's security level identifier is as defined in
Table 5 and shall correspond to the security control field (see Figure 2) of the frame being processed.
Octets: 8
4
1
Source address
Frame counter
Security level
Figure 5 CCM* nonce
September 16, 2004
3.3
IEEE P802.15-4/0539r0
Securit y Processing Steps
The operations performed on outgoing and incoming frames are given in 3.3.1 and 3.3.2, respectively.
3. 3. 1 O utgoi ng Fr a me O p e r at i ons
The outgoing frame operations vary depending on the security level. When security processing of an outgoing frame
is needed, the following operations shall be performed:
1.
Determine the security level identifier SecurityLevel and use Table 5 to determine the octet length M of the
authentication field. If the particular security level is not supported, set SecurePayload equal to the empty set
and fail with a status of UNSUPPORTED_SECURITY_LEVEL. Note RS: this step requires more detail, since
the SecurityLevel depends on the MAC frame type, the protection requirements by the sender and (potentially)
the expectations as to the minimum level of security by the recipient(s). This information can be derived by
inspecting Table 1 up to Table 4 (see Section 2.1).
2.
Obtain the frame counter to be used for security processing as follows:
3.
4.
5.
6.
a.
Obtain the frame counter (FrameCounter) associated with the source address of the outgoing frame;
b.
If FrameCounter cannot be obtained or if FrameCounter has as value the 4-octet representation of the
integer 232-1, set SecurePayload equal to the empty set and fail with a status of COUNTER_ERROR;
c.
If the security level indicates “no security”, set the SecurePayload equal to Payload and proceed to step 3
below.
Obtain the keying material to be used for security processing as follows:
a.
If the key identification mode field in the security control field is set to 0 (implicit key derivation), obtain
the key (LinkKey) associated with the source and destination addresses of the outgoing frame;
b.
Otherwise, obtain the group link key (LinkKey) associated with the explicit key identification fields in the
auxiliary frame header;
c.
If the LinkKey cannot be obtained, set SecurePayload equal to the empty set and fail with a status of
NO_DATA_KEY.
Obtain the extended source address to be used for security processing as follows:
a.
Obtain the 64-bit extended source address (SrcAddress) of the device originating the frame;
b.
If the SrcAddress cannot be obtained, set SecurePayload equal to the empty set and fail with a status of
ADDRESS_ERROR.
Execute the CCM* mode encryption and authentication checking operation, as specified in ANNEX B –, with
the following instantiations:
a.
The parameter M shall have the integer value M obtained in step 1 above;
b.
The key Key shall be the bit string LinkKey obtained in step 3 above;
c.
The nonce N shall be the 13-octet string constructed using the SrcAddress obtained in step 4 above, the
FrameCounter obtained in step 2 above, and the SecurityLevel obtained in step 1 above, as specified in
3.2.3;
d.
If encryption is enabled (ON), the octet string a shall be the string MACHeader and the octet string m shall
be the string Payload. If encryption is disabled (OFF), the octet string a shall be the string MACHeader ||
Payload and the octet string m shall be the empty string.
Return the results of the CCM* operation:
a.
If the CCM* mode invoked in step 5 outputs ‘invalid’, set SecurePayload equal to the empty set and fail
with Status equal to SECURITY_ERROR;
Submission
Page 11
Rene Struik, Certicom
b.
Let c be the output from step 5 above. Set the octet string SecurePayload to the string c if encryption is
enabled (ON) and to the string Payload || c if encryption is disabled (OFF).
3.
Update the internal frame counter (FrameCounter) associated with the source address of the outgoing frame
with (FrameCounter +1).
4.
Set Status equal to SUCCESS, and return.
3. 3. 2 Inc om ing F ra me O p e r at i ons
The incoming frame operations vary depending on the security level. When security processing of an incoming
frame is needed1, the following operations shall be performed:
1.
Determine the security level identifier SecurityLevel from MACHeader and use Table 5 to determine the octet
length M of the authentication field. If the particular security level is not supported, set Payload equal to the
empty set and fail with a status of UNSUPPORTED_SECURITY_LEVEL.
2.
Determine whether the security level applied to the incoming frame is adequate, as follows:
3.
4.
1
a.
Determine the minimal level of security (SecurityMinimum) necessary for the given frame; Note RS: this
step requires more detail, since SecurityMinimum depends on the MAC frame type and the expectations as
to the minimum level of security by the recipient. This information can be derived by inspecting Table 1 up
to Table 4 (see Section 2.1).
b.
If SecuritySuite is less than SecurityMinimum, then set Payload equal to the empty set and fail with a status
of SECURITY_ERROR.
Obtain the received frame counter to be used for security processing as follows:
a.
Determine the received frame count (ReceivedFrameCounter) from the auxiliary frame header;
b.
If ReceivedFrameCounter is only a single octet (i.e., it is a reduced nonce – see 3.1.1), then recompute the
full (uncompressed) ReceivedFrameCounter to the 4-octet representation of the least possible integer value
that is not smaller than the FrameCounter associated with the source address of the incoming frame and has
its least significant octet equal to ReceivedFrameCounter. In this computation, set FrameCounter to the
default value (i.e., representing the integer 0) if the source address of the incoming frame is not included in
the device list. If FrameCounter cannot be obtained or if this integer does not exist, set Payload equal to
the empty set and fail with a status of COUNTER_ERROR;
c.
If ReceivedFrameCounter has as value the 4-octet representation of the integer 232-1, then set Payload
equal to the empty set and fail with a status of COUNTER_ERROR;
d.
If the security level indicates "no security" and freshness is not to be checked (i.e., the CheckFreshness
field corresponding to the source address of the incoming frame is not set), set Payload equal to
SecurePayload and proceed to step 9 below.
If freshness is to be checked (i.e., the CheckFreshness field corresponding to the source address of the incoming
frame is set), execute the following steps:
a.
Obtain the frame counter (FrameCounter) associated with the source address of the incoming frame. If this
entry is not contained in the device list, set FrameCounter to the default value (i.e., representing the integer
0);
b.
If FrameCounter cannot be obtained, set Payload equal to the empty set and fail with a status of
COUNTER_ERROR;
c.
Ensure sequential freshness by verifying that ReceivedFrameCounter represents an integer that is greater
than or equal to the one represented by FrameCounter. If the freshness verification fails, set Payload equal
to the empty set and fail with Status equal to OLD_FRAME_COUNT;
Processing is only required if the frame is intended for the layer that calls for security processing.
September 16, 2004
5.
6.
7.
8.
9.
IEEE P802.15-4/0539r0
d.
If security is disabled or if the key identification mode field in the security control field is set to 0 (implicit
key derivation), obtain the BlackListStatus field of the source address of the incoming frame with respect to
the group associated with the source and destination addresses of the incoming frame;
e.
Otherwise, obtain the BlackListStatus field of the source address of the incoming frame with respect to the
group associated with the explicit key identification fields in the auxiliary frame header;
f.
If BlackListStatus cannot be obtained or if BlackListStatus has the value TRUE, set Payload equal to the
empty set and fail with a status of COUNTER_ERROR;
g.
If the security level indicates "no security", set Payload equal to SecurePayload and proceed to step 9
below.
Obtain the keying material to be used for security processing as follows:
a.
If the key identification mode field in the security control field is set to 0 (implicit key derivation), obtain
the key (LinkKey) associated with the source and destination addresses of the incoming frame;
b.
Otherwise, obtain the group link key (LinkKey) associated with the explicit key identification fields in the
auxiliary frame header;
c.
If the LinkKey cannot be obtained, set Payload equal to the empty set and fail with a status of
NO_DATA_KEY.
Obtain the extended source address to be used for security processing as follows:
a.
Obtain the 64-bit extended source address (SrcAddress) of the device originating the frame;
b.
If the SrcAddress cannot be obtained, set Payload equal to the empty set and fail with a status of
ADDRESS_ERROR.
Execute the CCM* mode decryption and authentication checking operation, as specified in 3.2.1 and ANNEX B
–, with the following instantiations:
a.
The parameter M shall have the integer value M obtained in step 1 above;
b.
The key Key shall be the string LinkKey obtained in step 5 above;
c.
The nonce N shall be the 13-octet string constructed using the SrcAddress obtained in step 6 above, the
FrameCounter obtained in step 3 above, and the SecurityLevel obtained in step 1 above, as specified in
3.2.3;
d.
Parse the octet string Payload as Payload1 || Payload2, where the right-most string Payload2 is an M-octet
string. If this operation fails, output ‘invalid’;
e.
If encryption is enabled (ON), the octet string a shall be the string ProcessedHeader and the octet string m
shall be the string Payload. If encryption is disabled (OFF), the octet string a shall be the string
ProcessedHeader || Payload1 and the octet string c shall be the string Payload2.
Return the results of the CCM* operation:
a.
If the CCM* mode invoked in step c outputs ‘invalid’, set Payload equal to the empty set and fail with
Status equal to SECURITY_ERROR;
b.
Let m be the output of step c above. Set the octet string Payload to the string m if encryption is enabled
(ON) and to the string Payload1 || m if encryption is disabled (OFF);
If the CheckFreshness field corresponding to the source address of the incoming frame is set, execute the
following steps in order:
a.
Check whether the source address of the incoming frame is contained in the device list. If not, add this
source address to the device list and set the parameters of this entry to their default settings (this includes
setting FrameCounter to the string representing the integer 0);
Submission
Page 13
Rene Struik, Certicom
b.
Update the frame counter FrameCounter associated with this source address with (ReceivedFrameCounter
+ 1);
c.
Check whether the source address of the incoming frame is contained in the membership set corresponding
to the group determined in step 4 above. If not, add this source address to the membership set and set the
parameters hereof to their default settings (i.e., set the BlackListStatus field to FALSE);
d.
If this updated value of FrameCounter has as value the 4-octet representation of the integer 232-1, set the
BlackListStatus field determined in step 4 above to TRUE.
10. Set Status equal to SUCCESS, and return.
September 16, 2004
4
IEEE P802.15-4/0539r0
Security Status Codes
4.1
Status Values
Table 7 describes the security status codes that may result from security processing.
Table 7 Error status enumerations for MAC security processing
Security status code enumeration
Value
Security status description
SEC_SUCCESS
0x00
No errors detected.
SEC_ERR_INVALID_PARAMETER
0x01
An invalid parameter was in the input.
SEC_ERR_INVALID_FORMAT
0x02
The frame format is invalid.
SEC_ERR_NO_LINK_KEY
0x06
No link key is available.
SEC_ERR_OLD_FRAME_COUNT
0x07
SEC_ERR_COUNTER_ERROR
0x08
SEC_ERR_UNSUPPORTED_SECURITY_LEVEL
0x09
SEC_ERR_SECURITY_ERROR
0x0A
SEC_ERR_ADDRESS_ERROR
0x10
The frame count in the received frame is
less than or equal to the stored frame count
corresponding to the given source address.
The frame count is not present or has
exceeded its maximum allowable value.
The indicated security level is not
supported.
The security processing (e.g., decryption or
authentication) failed.
Extended (source) address is missing.
Submission
Page 15
Rene Struik, Certicom
ANNEX A – Basic notions
A.1
A.1.1
Notation and representation
Strings and string operations
A string is a sequence of symbols over a specific set (e.g., the binary alphabet {0,1} or the set of all octets). The
length of a string is the number of symbols it contains (over the same alphabet). The right-concatenation of two
strings x and y of length m and n respectively (notation: x || y), is the string z of length m+n that coincides with x on
its leftmost m symbols and with y on its rightmost n symbols. An octet is a symbol string of length 8. In our context,
all octets are strings over the binary alphabet.
A.1.2
Integers, octets, and their representation
Throughout this specification, the representation of integers as octet strings and of octet strings as binary strings
shall be fixed. All integers shall be represented as octet strings in most-significant-octet first order. This
representation conforms to the convention in Section 4.3 of ANSI X9.63-2001 Error! Reference source not
found.. All octets shall be represented as binary strings in most-significant-bit first order.
A.1.3
Entities
Throughout this specification, each entity shall be a DEV and shall be uniquely identified by its 64-bit IEEE device
address Error! Reference source not found.. The parameter entlen shall have the integer value 64.
Editor's Note —
In the specification of each transformation, equivalent computations that result in
identical output are allowed, provided all checks and verifications are carried out completely.
Editor's Note —
Each of the schemes in this standard may have certain prerequisites. These are
conditions that shall be satisfied by implementations of the scheme. The actual specification of mechanisms that
provide these prerequisites is beyond the scope of the scheme itself. There are no secrecy requirements for the
choices that may have to be made in the prerequisites (e.g., choice of domain parameters, hash function, data
formats, etc.).
September 16, 2004
IEEE P802.15-4/0539r0
ANNEX B – CCM* mode of operation
See IEEE document {xxx}.
Submission
Page 17
Rene Struik, Certicom
ANNEX C – Security Building Blocks
This annex specifies the cryptographic primitives and mechanisms that are used to implement the security protocols
in this standard.
C.1
Symmetric-key cryptographic building blocks
The following symmetric-key cryptographic primitives and data elements are defined for use with all securityprocessing operations specified in this standard.
C.1.1
Block-cipher
The block-cipher used in this specification shall be the Advanced Encryption Standard AES-128, as specified in
FIPS Pub 197 Error! Reference source not found.. This block-cipher shall be used with symmetric keys with the
same size as that of the block-cipher: 128 bits. These symmetric keys shall be generated uniformly at random.
C.1.2
Mode of operation
The block-cipher mode of operation used in this specification shall be the CCM* mode of operation, as specified in
ANNEX B –, with the following instantiations:
1.
Each entity shall use the block-cipher E as specified in section C.1.1;
2.
All octets shall be represented as specified in section A.1.2;
3.
The parameter L shall have the integer value 2;
4.
The parameter M shall have one of the following integer values: 0, 4, 8, or 16.