1 / 30

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: [Security-and-Security-Architectural-Recommendations-for-the-802.15.4-Low-Rate-WPAN Date Submitted: [January 16, 2003] Source: [Rene Struik] Company [Certicom Corp.]

louis-cruz
Download Presentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security-and-Security-Architectural-Recommendations-for-the-802.15.4-Low-Rate-WPAN Date Submitted: [January 16, 2003] Source: [Rene 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:[rstruik@certicom.com] Re: [Draft D17 of the emerging IEEE 802.15.4 Low-Rate WPAN standard.] Abstract: [This document gives some security and security architectural recommendations to assist in improving the security and flexibility of the Draft D17 for IEEE 802.15.4 Low-Rate WPAN.] Purpose: [Assist sponsor ballot comment resolution process for the Draft D17 for the IEEE 802.15.4 WPAN.] 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. Rene Struik, Certicom Corp.

  2. Security and Security Architectural Recommendations for the IEEE 802.15.4 Low-Rate WPAN René Struik, Certicom Research Rene Struik, Certicom Corp.

  3. Outline: • Multicasting • Security Suite Specification • - Implementation cost • - Security concerns • - Solution • Representation Anomalies • - Implementation cost of inconsistent representations • - Solution • Security Suite Selection and Usage • - Effectiveness and efficiency • - Impact on IEEE 802.15.4/ZigBee interface • - Solution • Security Status Information overhead • - Bandwidth cost • - Solution • Other remarks • - more security and efficiency concerns • - more on IEEE 802.15.4/ZigBee interface Rene Struik, Certicom Corp.

  4. Bits: 0-2 Bits: 0-2 3-5 3 6 4 7 5 8-9 6-9 10-11 10-11 12 12-13 14-15 13 14-15 Frame type Security enabled (SEC) Frame pending ACK request Reserved Destination addressing field Reserved Source addressing mode Frame type Security enabled (SEC) Frame pending ACK request Reserved Destination addressing field Compression enabled Same PAN Id Source addressing mode • Summary of Main Recommendations • Existing format frame control field (as in draft D17, §7.2.1.1): • Proposed format frame control field: • PAN Id: no duplication saves 0,2, or 4 octets per frame (cf. Jose Gutierrez) • Compression: no resending of known security info saves 4 octets per frame • Addressing: multicast enabling with same frame formats • SECField: dynamic protection selection allows savings in, e.g., complexity • MaxFrameSize: aMaxFramesize can be enlarged from 102 to up to 122 octets • KeySeqCntr: redefinition allows distinguishing of keys (aids key management) • AES-CCM*: removes security vulnerabilities, saves key storage space Rene Struik, Certicom Corp.

  5. Multicasting Support (1) • Current draft specification does not support multicasting • Consequences: • - Need to retransmit same data to different devices in a group • - No advantage taken of broadcast character PAN communications (without relay) • Proposed encoding of multicast info: • - Destination address allows differentiation between multicast address and peer-to- • peer address • 16-bit addresses: • - all 2-octet device addresses start with a ‘0’ (32k addresses of this form possible) • - Group address: 2-octet address that starts with a ‘1’. The remaining 15 bits indicate • the device that originated (=created) the group • - Group sequence number: 1-octet field in the same spot as Key Sequence Counter • (this allows up to 256 groups per originating device) • A receiving device (see §7.5.6.2) accepts group address if • (DestAddress, Key Sequence Number) indicates the group of which he is a member Rene Struik, Certicom Corp.

  6. MAC Header MAC Footer MAC Header MAC Footer Status Info Data Data Unprotected frame (peer-to-peer, broadcast) Security Status Info Data Data Status Info Key Counter Secured Data Data Group Counter Frame Counter MAC Header MAC Footer MAC Payload MAC Payload MAC Payload Sequence Counter Sequence Counter Sequence Counter Frame Control Sequence Frame Control Sequence Frame Control Sequence Addressing Fields Addressing Fields Addressing Fields Frame Payload Frame Payload Frame Payload Frame Control Frame Control Frame Control Unprotected frame (multicast) Protected frame (peer-to-peer, broadcast, multicast) Multicasting Support (2) Rene Struik, Certicom Corp.

  7. Security Suite Specification (1) • Current draft specification distinguishes 8 security suites, depending on combination • of 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: • CBC-MAC mode, to provide for data authentication only; • AES-CTR mode, to provide data confidentiality only; • AES-CCM mode, to provide both data confidentiality and data authenticity. • All the security suites re-use the same key (see §7.6.1.8) • Consequences: • - Need to implement 3 security mechanisms, to allow for flexibility (thus, impact on • code size) • - Security mechanisms re-use the same key, which may render the combined usage of • the security suites insecure (see also next slides) Rene Struik, Certicom Corp.

  8. Security Suite Specification (2) • Security mechanisms underlying security suite specification • CBC-MAC mode, to provide for data authentication only; • AES-CTR mode, to provide data confidentiality only; • AES-CCM mode, to provide both data confidentiality and data authenticity. • All the security suites re-use the same key (see §7.6.1.8) • Security of individual security mechanisms • CBC-MAC mode: provably secure for messages of fixed length; believed secure for arbitrary messages, if length-pre-pended (Bellare, Kilian, Rogaway, 2000) • AES-CTR mode: provably secure, provided counters are never re-used over life-time of key (Mihir Bellare et al, 1997-1999) • AES-CCM mode: provably* secure, provided counters are never re-used over life-time of key (Jakob Jonsson, 2002) • Security of individual security suites in this standard • The AES-CBC-MAC specification (§7.6.4) is vulnerable to replay attacks, since it • does not provide for ‘freshness’ guarantees • *: Partial security proof presented at SAC 2002 (Aug 2002). Modified security proof submitted to NIST Modes of Operation (Sep 2002) Rene Struik, Certicom Corp.

  9. Security Suite Specification (3) Security of combined usage of security mechanisms Re-use of same key for the 3 security mechanisms renders the combined usage hereof insecure, due to interplay between these mechanisms An adversary can fabricate authentic messages that he has not observed before, without knowledge of the key, based on combining previously observed outputs of the AES-CTR mode and the AES-CCM mode, thus rendering the CBC-MAC mechanism insecure in this context Attack ingredients: - CBC-MAC on messages of variable length is insecure if not length-pre-pended (Bellare, Kilian, Rogaway, 2000) - CBC-MAC with length pre-pending is insecure if first block can be encrypted, with disrespect to the length information (since, one can then fabricate a ‘fresh’ authentic message using standard cryptanalytic techniques) - The AES-CTR mode and the AES-CCM mode allow such encryption of the first block (provided these mechanisms re-use the same data key) Workload: 1 AES-CTR/AES-CCM ops.; 1 CBC-MAC on message of ‘suitable’ size Rene Struik, Certicom Corp.

  10. Security Suite Specification (4) Security of combined usage of security mechanisms in this standard Adversary can fabricate authentic messages that he has not observed before, without knowledge of the key, based on combining previously observed outputs of the AES-CTR mode and the AES-CCM mode, thus rendering the CBC-MAC mechanism insecure This attack works for sure if the message consists of L octets, where L=1 or 130, and may very well work for messages of lengths L=65, 129, or 193. Other values not Investigated (yet). Note: The current draft specification does only allow frames of length L  aMAXPHYPacketSize, including frame overhead. Currently, one has aMAXPHYPacketSize:=127 (Table 19, §6.4.1). Therefore, this preliminary attack only works for a limited set of messages. Since this is only a preliminary attack, prudence dictates to treat the present combination of security mechanisms with extreme suspicion. Rene Struik, Certicom Corp.

  11. Security Suite Specification (5) • Current security suite specification (as in Draft D17) - insecure • Specification of security suites is based on 3 security mechanisms re-using the same key (see §7.6.1.8): CBC-MAC mode, AES-CTR mode, AES-CCM mode. • Security problems (see next slides): • Re-use of same key among different security suites is insecure. • AES-CBC-MAC specification (§7.6.4) is vulnerable to replay attacks. • Proposed security suite specification - secure • Specification 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, and allows secure re-use of same key • - AES-CCM* mode has same format as AES-CCM mode specification for NIST and allows single-chip implementation across 802.11 and 802.15 • 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) • *: AES-CCM* is a slight extension of the AES-CCM specification from Annex B.1, with a slightly more refined counter specification Rene Struik, Certicom Corp.

  12. Security Suite Specification (6) • Impact of change on draft: • Changes to Annex B (Security Implementation): • - Replace the specification of the AES-CCM mode in Annex B.1 by the specification of AES-CCM* • - Completely remove the current Annexes B.2 and B.3 • (see document 02/469r1) • Changes to Clause 7.6: • - Completely remove Clauses 7.6.1.4, 7.6.1.5, 7.6.2, 7.6.4 • - Adapt Table 76 (in §7.6): all 7 security suites now have sequential freshness • - Adapt notational conventions in Clauses 7.6.1.3: remove lines 19-29, Page 165 • - Change the format of the AES-CCM nonce (Figure 68, §7.6.3.1.3) as follows: • Replace the Key Sequence Counter field by the Security Suite Id (Table 76, §7.6) • (see document 02/468r1) Rene Struik, Certicom Corp.

  13. Representation Anomalies • Representation of integers N (0  N  Bk) as string of symbols w.r.t. basis B: • N:=Mk-1Bk-1 + Mk-2Bk-2 + … + M1 B1+ M0 , where 0  Mi  B • small/big endian: N  (Mk-1|| Mk-2|| …|| M1|| M0) vs.N  (M0|| M1|| …|| Mk-2|| Mk-1) • Representation of binary polynomial p(x) (with deg p(x)  k)as binary string: • p(x):=ak-1 xk-1 + ak-2 xk-2 + … + a1 x1+ a0 , where ai  {0,1} • Small/big endian: p(x)  (ak-1|| ak-2|| …|| a1|| a0)vs. p(x)  (a0|| a1|| …|| ak-2|| ak-1) • Existing representation (as in Draft D17) — inconsistent • non-security: low-endian representation everywhere (e.g., polynomial vs. binary • string; integer as octet string; integer vs. binary string and octet as integer) • security (see §7.6.1.3): big-endian representation octet as integer; low-endian • representation integer vs. octet string; mixture representation integer vs. binary string • Consequences: costly dual integer arithmetic routines required; error-prone • Proposed representation — consistent • everywhere (NO exceptions): low-endian representation (e.g., polynomial vs. binary • string, integer vs. octet string, integer vs. binary string) Rene Struik, Certicom Corp.

  14. Security Suite Selection (1) • Current specification distinguishes 8 security suites, depending on combination • of 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 D17) • 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 standard • Consequences: • 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 Rene Struik, Certicom Corp.

  15. Security Suite Selection (2) • Current specification distinguishes 8 security suites, depending on combination • of 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) • Saves storage in MACPIB tables (Table 71, Table 72, §7.5) Rene Struik, Certicom Corp.

  16. Bits: 0-2 Bits: 0-2 3 3-5 4 6 5 7 6-9 8-9 10-11 10-11 12-13 12-13 14-15 14-15 Frame type Frame type Security Algorithm Id (SEC) Security Enabled (SEC) Frame pending Frame pending ACK request ACK request Reserved Reserved Destination addressing field Destination addressing field Reserved Reserved Source addressing mode Source addressing mode Security Suite Selection (3) Impact of change on draft: Existing format frame control field (as in draft D17, §7.2.1.1): Proposed format frame control field: Algorithm Id info: 3 bits, specifying (a) Encryption on/off; (b) Data integrity level: #bits {L0, L1, L2, L3}, where {L0, L1, L2, L3}={0,32,64,128} Further impact: - Allows slight pruning of MACPIB tables (Table 71, Table 72, §7.5) - Requires security policy entry field in MACPIB table: ‘indication of minimum protection level expected’ - Check security policy during secure processing (in §7.5.9.4, §7.6.3) Rene Struik, Certicom Corp.

  17. 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) Rene Struik, Certicom Corp.

  18. MAC Header MAC Footer Security Status Info Data Key Counter Secured Data Frame Counter Existing protected frame format New Frame Counter Seq. No. Illustration of how to save 1 byte security status information overhead, by exploiting side information on the sequence counter MAC Payload Sequence Counter Frame Control Sequence Addressing Fields Frame Payload Frame Control New Frame Counter New Frame Counter Proposed uncompressed protected frame format (note the removal of the duplicate string) New Security Status Info Data Sequence Counter Sequence Counter Key Counter Secured Data Reducing Security Status Information Overhead (2) I. Reduction of security status info overhead by 1 byte per protected frame Rene Struik, Certicom Corp.

  19. 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). Rene Struik, Certicom Corp.

  20. MAC Header MAC Footer Proposed uncompressed protected frame format MAC Payload Sequence Counter Frame Control Sequence Addressing Fields Frame Payload Frame Control Illustration of how to save 3 bytes security status information overhead, by exploiting the re-synch capabilities of the sequence counter New Frame Counter New Frame Counter New Frame Counter Proposed compressed protected frame format Sequence Counter Sequence Counter Compr. Security Status Info New Security Status Info Data Data Key Counter Secured Data Key Counter Secured Data Reducing Security Status Information Overhead (4) 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. Rene Struik, Certicom Corp.

  21. 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 N0satisfies NA Nor 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) Rene Struik, Certicom Corp.

  22. Reducing Security Status Information Overhead (6) • III. Reduction of security status info overhead – what if re-synchronization needed? • Proposed error-handling (3 cases): • Feedback channel always on (alwaysACKs): • 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 (noACKs 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) Rene Struik, Certicom Corp.

  23. Reducing Security Status Information Overhead (6a) • III. Reduction of security status info overhead – re-synchronization examples • Feedback channel always on (alwaysACKs): • 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)) Frame Counter Frame Counter Message flow 7 7 258 258 289 7 msg1 uncompressed 7 ACK compressed 2 258 msg2 2 ACK 33 289 msg3 NAK 289 289 msg3 33 ACK 34 290 msg4 290 34 ACK Rene Struik, Certicom Corp.

  24. Reducing Security Status Information Overhead (6b) • 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 Frame Counter Frame Counter Message flow 7 7 7 msg1 uncompressed 7 ACK compressed 2 258 msg2 loss 32 7 288 msg3 32 ACK Enable error-flag: decryption error 33 reject (due to error-flag) 289 msg4 34 290 Message sent with ACK request msg5 NAK (due to error-flag) 290 290 290 msg5 Disable error-flag: frame counter OK 290 ACK Rene Struik, Certicom Corp.

  25. Reducing Security Status Information Overhead (6c) • 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 Frame Counter Frame Counter Message flow 7 7 7 msg1 uncompressed compressed 2 258 msg2 loss 288 288 289 289 805 288 msg3 33 289 msg4 547 547 loss msg5 89 601 msg6 805 805 msg7 Rene Struik, Certicom Corp.

  26. Reducing Security Status Information Overhead (7) • 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) Rene Struik, Certicom Corp.

  27. Bits: 0-2 Bits: 0-2 3 3 4 5 4 6-9 5 10-11 6-9 12 13 10-11 14-15 12-13 14-15 Frame type Security enabled (SEC) Frame pending ACK request Reserved Destination addressing field Compression enabled Reserved Source addressing mode Frame type Security Enabled (SEC) Frame pending ACK request Reserved Destination addressing field Reserved Source addressing mode Reducing Security Status Information Overhead (8) Impact of change on draft: Existing format frame control field (as in draft D17, §7.2.1.1): Proposed format frame control field: Rene Struik, Certicom Corp.

  28. 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) Rene Struik, Certicom Corp.

  29. 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. Rene Struik, Certicom Corp.

  30. 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. • -------------------------- • More comments have been submitted. • 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 Rene Struik, Certicom Corp.

More Related