15-03-0320-02-0400 Submission November, 2003 Rene Struik, Certicom Corp.Slide 1 Project: IEEE...
-
Upload
shanna-black -
Category
Documents
-
view
212 -
download
0
Transcript of 15-03-0320-02-0400 Submission November, 2003 Rene Struik, Certicom Corp.Slide 1 Project: IEEE...
November, 2003
Rene Struik, Certicom Corp.Slide 1
15-03-0320-02-0400
Submission
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Suggestions for Improvement of the IEEE 802.15.4 WPAN Standard]Date Submitted: [November 11, 2003]Source: [René Struik] Company [Certicom Corp.]Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1]Voice:[+1 (905) 501-6083], FAX: [+1 (905) 507-4230], E-Mail:[[email protected]]
Re: [Current IEEE 802.15.4 Low-Rate WPAN standard (Draft D18).]
Abstract: [This document gives some recommendations to assist in improving the security and flexibility of the IEEE 802.15.4 Low-Rate WPAN standard.]
Purpose: [Assist in improving the IEEE 802.15.4 WPAN standard (Draft D18).]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.
November, 2003
Rene Struik, Certicom Corp.Slide 2
15-03-0320-02-0400
Submission
Suggestions for Improvement of the IEEE 802.15.4 WPAN Standard
René Struik, Certicom Research
November, 2003
Rene Struik, Certicom Corp.Slide 3
15-03-0320-02-0400
Submission
Outline:• Security Suite Specification
- Implementation cost• Multicasting Support• Security Status Information overhead
- Reduction of bandwidth cost• Security Suite Selection and Usage
- Effectiveness and efficiency Other remarks• More security and efficiency concerns
- more on IEEE 802.15.4/ZigBee interface
November, 2003
Rene Struik, Certicom Corp.Slide 4
15-03-0320-02-0400
Submission
Security Suite Specification (1)Current draft specification distinguishes 8 security suites, depending on combinationof encryption and data authentication used:• Encryption: ON/OFF• Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128}
Current security suite specifications are based on 3 security mechanisms:1. CBC-MAC mode, to provide for data authentication only;2. AES-CTR mode, to provide data confidentiality only;3. AES-CCM mode, to provide both data confidentiality and data authenticity.
Problems:- Different security suites have to use different keys (see §7.6.1.8), for security
concerns- The AES-CBC-MAC specification (§7.6.4) is vulnerable to replay attacks, since it does not provide for ‘freshness’ guarantees
Consequences:- Need to implement 3 security mechanisms, to allow for flexibility (thus, impact on code size) - Higher layer mechanisms cannot re-use MAC keying material, because of security concerns (thus, impact on key storage size)
November, 2003
Rene Struik, Certicom Corp.Slide 5
15-03-0320-02-0400
Submission
Security Suite Specification (2)Proposed security suite specification - secureSpecification of security suites is based on 1 security mechanism:• AES-CCM* mode, to provide data confidentiality only, data authenticity only, or
both data confidentiality and data authenticity/integrity
Consequences:- AES-CCM* mode has same security properties as the AES-CCM mode specification in Annex B- AES-CCM* mode allows secure re-use of same key, both in MAC and higher layers- AES-CCM* mode has same format as AES-CCM mode specification for NIST- Data authenticity-only mode (‘CBC-MAC’) not vulnerable to replay attack any more- Need to implement only 1 security mechanism (thus, favorable for code size)
CCM* vs. CCM:- CCM* allows the length M of the authentication field to be zero (‘encryption-only’);- CCM* imposes restriction on nonce if different authentication tag lengths used (this prevents attack on CCM with variable tags [Rogaway, David Wagner, 2003])
For details, see
http://csrc.nist.gov/CryptoToolkit/modes/comments/index.html
November, 2003
Rene Struik, Certicom Corp.Slide 6
15-03-0320-02-0400
Submission
Multicasting Support (1)Current draft specification does not support multicasting
Consequences:- No advantage taken of broadcast character PAN communications (without relay)- Need to retransmit same data to different devices in a group
* bandwidth and energy inefficient* latency issues (e.g., with lighting applications)
- No secured broadcast possible
Proposed encoding of multicast info:Destination address allows differentiation between multicast address, peer-to-peer address, and broadcast address)
- Multicast indicator: 1-bit value in MAC Header (e.g., in Frame Control Field)- Group address (components):
* group creator address: address of the device that originated (=created) the group: with mode options* group sequence number:
1-octet field, to allow up to 256 groups per originating device: in same spot as key sequence counter
November, 2003
Rene Struik, Certicom Corp.Slide 7
15-03-0320-02-0400
Submission
Multicasting Support (2)Property of group address format:- No confusion between group addresses created by different devices (due to partitioning address space according to group originator)
A receiving device (§7.5.6.2) accepts group address if the group address(DestAddress, KeySeqNo) indicates a group of which it is a member
Notes:1. Frame filtering implementation:- hardware-based: peer-to-peer (full address), unsecured broadcast traffic- software-based: peer-to-peer (short address), multicast, secured broadcast traffic2. Group membership test:To be implemented at higher layer
GroupId G={group members}
(secured MAC broadcasts require multicast addressing capability)
November, 2003
Rene Struik, Certicom Corp.Slide 8
15-03-0320-02-0400
Submission
Multicasting Support (3)
Addressing fields:<source address> ::= <physical address><destination address> ::= <physical address> | <logical address>
{option indicated by 1-bit multicast indicator}<physical address> ::= implicit: coordinator | <short address> |
<short Address><PAN Id> | <long address>{option indicated by 2-bit addressing mode}
<logical address> ::= <group source> <group Id><group source> ::= <physical address><group Id> ::= <group counter>
“Atoms” (end symbols in grammar):<short address> ::= 16-bit address<long address> ::= 64-bit address<PAN Id> ::= 16-bit PAN address<group counter> ::= 1-octet field {this allows 256 groups with same group source}
November, 2003
Rene Struik, Certicom Corp.Slide 9
15-03-0320-02-0400
Submission
Multicasting Support (4)MAC Header
Frame Control
AddressingFields
SequenceCounter
Frame Payload Frame Control Sequence
MAC Payload MAC Footer
Status Info Data
Data
MAC HeaderFrame Control
AddressingFields
SequenceCounter
Frame Payload Frame Control Sequence
MAC Payload MAC Footer
Security Status InfoKey
Counter
DataSecured
DataFrame Counter
MAC HeaderFrame Control
AddressingFields
SequenceCounter
Frame Payload Frame Control Sequence
MAC Payload MAC Footer
Status InfoGroup
Counter
Data
Data
Unprotected frame(peer-to-peer, broadcast)
Unprotected frame(multicast)
Protected frame(peer-to-peer, broadcast, multicast)
Key Counter not necessary for peer-to-peer!
November, 2003
Rene Struik, Certicom Corp.Slide 10
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (1)Current draft specification adds 5 bytes of security status info overhead to protected frames providing confidentiality (see §7.6.2 for AES-CTR and §7.6.3 for AES-CCM)
Consequences:- Large fixed overhead of 5 bytes per secured frame, whether security status info is already reliably available at recipient’s side or not
Proposed encoding of security status information:- Security status information is represented more efficiently, exploiting side information- Sending device may decide for itself whether to send all security status info completely (uncompressed) or only partially (compressed)- Sending device has way of determining whether receiving device might have lost synchronization of security status info (e.g., via slightly modified ACK mechanism)Consequences: - Security status info only sent when required, due to loss of synchronization- Expected bandwidth saving per protected frame: (almost) 4 bytes- Bandwidth saving range per protected frame: from 1 byte (uncompressed) to 4 bytes (compressed)
November, 2003
Rene Struik, Certicom Corp.Slide 11
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (2)
MAC Header
Frame Control
AddressingFields
SequenceCounter
Frame Payload Frame Control Sequence
MAC Payload MAC Footer
Security Status Info
KeyCounter
Data
SecuredDataFrame Counter
New Frame Counter
New Frame Counter Seq.No.
SequenceCounter
New Security Status Info
KeyCounter
Data
SecuredData
New Frame Counter
SequenceCounter
Existing protected frame format
Proposed uncompressedprotected frame format
(note the removal of the duplicate string)
Illustration of how to save 1 byte security status information overhead, by exploiting
side information on the sequence counter
I. Reduction of security status info overhead by 1 byte per protected frame
November, 2003
Rene Struik, Certicom Corp.Slide 12
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (3)I. Reduction of security status info overhead by 1 byte per protected frame (cont’d)
- Frame Counter N: 32-bit non-repeating value, used for providing security- Sequence Counter DSN: 8-bit integer value, used for loose synchronization between sent messages and ACK hereon. Incremented by 1 (mod 256) per sent frame
Proposed method (lazy updates by sender)• Frame counter N: initialized at any value; when used, updated from N to value N0 N such that N0 :=min{N’ N | N’ DSN (mod 256)}. (Here, DSN is current value of Sequence Counter in frame to be sent)• Outgoing frames that require ACK are re-encrypted in exactly the same way till ACK received or till retries exhausted
Corollary: • The property N DSN (mod 256) is invariant at each time instance N is used
Note: It is easy to compute N0 from N (hint: compare N (mod 256) and DSN).
November, 2003
Rene Struik, Certicom Corp.Slide 13
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (4)
MAC HeaderFrame Control
AddressingFields
SequenceCounter
Frame Payload Frame Control Sequence
MAC Payload MAC Footer
New Frame Counter
New Frame Counter
New Security Status InfoKey
Counter
DataSecured
DataSequenceCounter
Proposed uncompressed protected frame format
Proposed compressed protected frame format
Illustration of how to save 3 bytes security status information overhead, by exploiting the
re-synch capabilities of the sequence counter
New Frame Counter
Compr. Security Status InfoKey
Counter
DataSecured
DataSequenceCounter
II. Removing security status info overhead per protected frame altogether†
†: the KeySeqCtr is always sent for robustness reasons: it allows smooth ZigBee key updates and facilitates easy future extensions of the 802.15.4 standard using multicasting, whether secured or not.
November, 2003
Rene Struik, Certicom Corp.Slide 14
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (5)II. Removing of security status info overhead per protected frame altogether (cont’d)
- Frame Counter N: 32-bit non-repeating value, used for providing security- Sequence Counter DSN: 8-bit integer value, used for loose synchronization between sent messages and ACK hereon. Incremented by 1 (mod 256) per sent frame
Proposed method (lazy updates by recipient)• Frame counter N: initialized at value 0; when used, updated from N to value N0 N such that N0 :=min{N’ N | N’ DSN (mod 256)}. (Here, DSN is current value of Sequence Counter in received frame)
Corollary: Let NA be the value of the frame counter used by sender.• If the recipient’s value of N satisfies N NA N+256, then N0 = NA and decryption proceeds exactly the same as in the current D17 draft.• If the recipient’s value of N0 satisfies NA N or NA NA+256, then N0 NA and decryption proceeds incorrectly* (same effect as active change of Frame Counter in uncompressed scenario). This is so-called loss of synchronization.
*: of course, this can only be detected if the protected frame provides for authenticity (as an encryption-only mechanism does not provide for authenticity)
November, 2003
Rene Struik, Certicom Corp.Slide 15
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (6)
Security fields (in-order receipt indicator):<FrameCounter> ::= <compressed counter> | <long frame counter>
{option indicated by 1-bit reduced nonce indicator}
“Atoms” (end symbols in grammar):<compressed counter> ::= 1-octet field <long frame counter> ::= 4-octet field
November, 2003
Rene Struik, Certicom Corp.Slide 16
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (7)III. Reduction of security status info overhead – what if re-synchronization needed?
Proposed error-handling (3 cases):• Feedback channel always on (always ACKs): Rules: Frame transmitted in uncompressed format, if no ACK received (and in compressed format otherwise) {Note: no change to ACK necessary} Loss-of-synchronization NEVER occurs, so behavior exactly as in current draft.
• Feedback channel never on (no ACKs at all): Rules: Avoid error-handling altogether by sending uncompressed frames regularly This always works if receiving device is awake at least once in every 256-frame counter interval; in that case, exactly the same behavior as in draft
• Feedback channel sometimes on (ACKs sometimes): Rules: - Recipient: If decryption on compressed frame rejected, do not send ACK next time - Sender: If no ACK received, next frame sent in uncompressed form (this makes sure that re-synch is achieved with a delay of 1 ACK’ed frame only)
November, 2003
Rene Struik, Certicom Corp.Slide 17
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (7a)III. Reduction of security status info overhead – re-synchronization examples
•Feedback channel always on (always ACKs):
Loss-of-synchronization NEVER occurs, so behavior exactly as in current draft(including number of retries afforded) – Remark: if decryption fails long enough,[hacker] recipient runs out-of-synch still (Note: this can be fixed as on next slide (6b))
msg1
ACK
7 7
7
msg2
ACK
2 258
2
msg3
NAK
33 289
msg3
ACK
289 289
33
7
258
258
289
Message flow Frame Counter
Frame Counter
uncompressed
compressed
msg4
ACK
34 290
34 290
November, 2003
Rene Struik, Certicom Corp.Slide 18
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (7b)III. Reduction of security status info overhead – re-synchronization examples
•Feedback channel sometimes on (ACKs sometimes):
Loss-of-synchronization might occur, but is solved with a delay of 1 ACK’ed frame
msg1ACK
7 7
7
msg2 loss2
258
msg3 ACK32
288
msg4
33 289
7
Message flow Frame Counter
Frame Counter
uncompressedcompressed
msg5 NAK (due to error-flag)
34 290
32 Enable error-flag: decryption error
reject (dueto error-flag)
msg5ACK
290 290
290
7
290 Disable error-flag: frame counter OK
Message sent with ACK request
November, 2003
Rene Struik, Certicom Corp.Slide 19
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (7c)III. Reduction of security status info overhead – re-synchronization examples
•Feedback channel never on (no ACKs at all):
Loss-of-synchronization might occur, but is solved with next received uncompressed frame
msg1
7 7
msg2 loss2
258
msg3
288 288
msg4
33 289
7
Message flow Frame Counter
Frame Counter
uncompressedcompressed
msg5
547 547
288
289
289
805
msg6
89 601
loss
msg7
805 805
November, 2003
Rene Struik, Certicom Corp.Slide 20
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (8)IV. Reduction of security status info overhead – distinguishing (un)compressed formats
Proposed encoding of compressed vs. uncompressed protected frame formats:Indicate compressed/uncompressed mode option in Frame Control Field. (This does not cost anything, since one can simply use 1 of the 6 reserved bits for this).
Other potential options:- Indicate compressed/uncompressed mode option in Frame Field (This does cost 8 bits, since there are currently no reserved bits available to encode this information.)- Do not indicate compressed/uncompressed mode option (This is instable (!!!), since it causes instability of the system and might necessitate 2 decryption executions, to determine which one of the compressed or uncompressed modes was actually used)
November, 2003
Rene Struik, Certicom Corp.Slide 21
15-03-0320-02-0400
Submission
Reducing Security Status Information Overhead (9)
Impact of change on draft (cont’d):
• Changes to Clause 7.6: - (Re)construct Full Frame Counter from Sequence Counter and stored Frame Counter - Add to the acceptance rules for incoming frames (in §7.5.6.2) the following text:
‘If the Compression Error Flag is set, the received frame shall be in uncompressed format, i.e, the Compression Enabled field in the Frame Control Field shall be disabled’.
- During the secure processing of incoming frames (in §7.5.9.4, §7.6.3), set the Compression Error Flag if the received frame was sent in compressed format and decryption fails; disable a set Compression Error Flag if the received frame was sent in uncompressed format and decryption succeeds. - If a message is sent with the ACK field set and no ACK is received, the message shall be resent in uncompressed format, i.e., with the Compression Enabled field in the Frame Control Field enabled (in §7.5.6.5, §7.5.9.4, §7.6.3). - Incoming and outgoing secured messages shall be processed as if these are in uncompressed format (thus, making re-encryption and retransmission unnecessary)
- Adapt notational conventions in Clauses 7.6.1.3: remove lines 19-29, Page 165 - Change the format of the AES-CCM MAC Payload (Figure 67, §7.6.3.1.2) as follows:
Have options for the length of the Frame Counter field: 0 or 3 octets,depending upon the
(see document 02/468r1)
November, 2003
Rene Struik, Certicom Corp.Slide 22
15-03-0320-02-0400
Submission
Security Suite Selection (1)Current specification distinguishes 8 security suites, depending on combinationof encryption and data authentication used:• Encryption: ON/OFF• Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128}
Existing security suite selection and usage (as in Draft D18) • SEC field indicates whether data is secured or not • Security services (data encryption/authentication) statically depend on security suite negotiated between devices, irrespective of frame type• Mechanism for negotiation of security suite not defined in current standardConsequences:- Out-of-scope mechanism needed for authentic exchange of info on what security suite to use. Need to re-negotiate every time security properties communication change- Communication to multiple recipients with different security suites requires data protection using each of these mechanisms, thus causing extra bandwidth overhead and extra processing (up to 8 times as much)- Inflexible, since security services cannot be tailored towards protection requirements for individual frame types
November, 2003
Rene Struik, Certicom Corp.Slide 23
15-03-0320-02-0400
Submission
Security Suite Selection (2)Current specification distinguishes 8 security suites, depending on combinationof encryption and data authentication used:• Encryption: ON/OFF• Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128} Proposed security suite selection:- SEC field indicates the security services (data encryption/authenticity) that are provided over frame type (beacon, ACK, command, data frame).- Communicating device may decide for itself on how to protect frames it sends: SEC=Encr Auth, where Encr={ON, OFF} and where Auth={0,32-bit,64-bit,128-bit}Consequences:- Inside-scope mechanism for determining what security suite to use - Communication to multiple recipients requires protection using only 1 mechanism*, thus eliminating previously necessary extra bandwidth overhead and processing- Flexible, since security services can be tailored towards protection requirements for individual frame types (e.g., authenticity for beacons, something else for others)- Allows reduction of #security suites, effectively from 8 to 1 (in §7.6)
November, 2003
Rene Struik, Certicom Corp.Slide 24
15-03-0320-02-0400
Submission
Security Suite Selection (3)Security fields:<SEC> ::= <encryption flag> <authentication flag><encryption flag>:= On, OFF<authentication flag> ::= none, low, medium, high {corresponds to 0, 4, 8, 16 bytes}
{security options indicated by 3-bit protection level indicator}
November, 2003
Rene Struik, Certicom Corp.Slide 25
15-03-0320-02-0400
Submission
Other Remarks — Selection (1)Security concerns• Message protection is currently a function of the recipient, whereas it should be a function of the sender (for his information is at stake). This is extremely bad security practice• If devices do not yet share a key, they automatically use the default key. This creates a false sense of security. As a minimum, an attempt must be made to derive a shared key• The ACL mode is not defined if encryption is enabled (see §7.5.9.4)• Broadcast encryption (i.e., use of the default key) is insecure, since it does not provide for freshness guarantees
Efficiency• Each recipient can only share 1 key with each sender. This unnecessarily complicates secure communications (e.g., it means that if A B, and A B,C, then the latter communications initiated by A towards B and C cannot use the same key for B and C).
November, 2003
Rene Struik, Certicom Corp.Slide 26
15-03-0320-02-0400
Submission
Other Remarks — Selection (2)Efficiency, Trade-offs IEEE802.15.4/ZigBee• There is no mechanism that enables one to distinguish keys from one another. This is bad practice, since key updates might be necessary. Moreover, it makes the definition of Key Management at the ZigBee level unnecessarily hard
Solution: Change the definition of the Key Sequence Counter (§7.6.1.8) as follows:
‘The key sequence counter is a counter that is fixed by the higher layer. This value may be used by the higher layers to facilitate key management: the
value of the key sequence counter identifies the key that is shared by devices
that are engaged in a security relationship.
--------------------------I would be happy to work with the editors to get the comments incorporated in the standard, to allow a more secure operation of 802.15.4 and a smooth interface between 802.15.4 and external standards, such as ZigBee
November, 2003
Rene Struik, Certicom Corp.Slide 27
15-03-0320-02-0400
Submission
Fine-Grained Security Support – Description GrammarSecurity fields:<SEC> ::= <encryption flag> <authentication flag><encryption flag>:= On, OFF<authentication flag> ::= none, low, medium, high {i.e., 0, 4, 8, 16 bytes}
{options indicated by 3-bit protection level indicator}<Key Id> ::= <ImplKeyId> | <ExplKeyId>
{option indicated by 1-bit ‘bastardized’ use of group key indicator}
<ImplKeyId> ::= emptyset<ExplKeyId> ::= <key source><Key Id><KeySource> ::= <group source><Key Id> ::= <group Id>
Freshness fields (in-order receipt indicator)<FrameCounter> ::= <compressed counter> | <long frame counter>
{option indicated by 1-bit reduced nonce indicator}
“Atoms” (end symbols in grammar):<compressed counter> ::= 1-octet field <long frame counter> ::= 4-octet field