Presentation is loading. Please wait.
Published byHope Pitts Modified over 7 years ago
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security Resolutions] Date Submitted: [15 September, 2004] Source: [Robert Poor (1), Rene Struik (2)] Company [(1) Ember Corporation, (2) Certicom Research] Address [(1) 343 Congress Street, 5th Floor, Boston, MA 02210 / (2) 5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada] Voice:[617 951-0200], FAX: [617 951-0999], E-Mail:[email@example.com,] Re: [Call For Contributions 15-04-0239 and PAR 15-04-0037] Abstract:[This document proposes resolutions to a set of issues relating to the security suite in IEEE 802.15.4-2003] Purpose:[This document is submitted for consideration for revisions to the 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.
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 2 Security Resolutions 802.15.4 Robert Poor (Ember Corporation) Rene Struik (Certicom Research)
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 3 #14, #45: CCM* Description: The current 15.4 security suite is composed of three components: AES-CCM (for encryption and authentication), CBC-MAC (for authentication only), and AES-CTR (encryption only). Problem 1: These three separate components require a larger implementation (counted in gates or code) than the unified CCM* implementation. Problem 2: Switching between these modes compromises security unless you keep separate keys, which requires additional storage. Problem 3: CBC-MAC doesn’t provide freshness and is subject to replay attacks. Proposal: Replace security suite with CCM* as described in 15-04- 0537-00 (replaces 02-469r0). (Note on backward compatibility: current specification allows devices to negotiate security, falling back to ‘no security’ as required.) PAR Compliance: “remove inflexible security use”
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 4 #30: What fields are authenticated? Problem: The IEEE 802.15.4-2003 spec is ambiguous or unclear as to what components of a packet are subject to authentication. Proposal: Authenticate MAC header and MAC payload, i.e. everything except the FCS. (Refer to figure 34 in 15.4-2003). Clarify wording as suggested in 15-04-0416-00-004b. PAR Compliance: Resolving ambiguities.
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 5 Eliminate Key Sequence Counter Problem: In practice, Key Sequence Counter serves no useful function (is always fixed at 0), and generates one byte overhead in each security-enabled frame. Proposal: Eliminate Key Sequence Counter. This increases over the air efficiency, reduces the size of the ACL tables, simplifies processing in CCM. (Note on backward compatibility: If this change is introduced as part of CCM* update, there will be no backward compatibility issue.) PAR compliance: Removing unnecessary complexity, reduce MAC overhead, MAC header compression.
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 6 #44: Security Endianess Clarification Problem: The definition of Least Significant Bit and Most Significant Bit is inconsistent between Section 7.6 and Annex B. Solution: Adopt solution presented in 15-04-xxxx-00-security- endianess.doc PAR compliance: Resolve ambiguities.
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 7 Broadcast Encryption Problem: Broadcast encryption does not provide freshness when using the default (broadcast) key, making the system subject to replay attacks. Proposal: Implement fix as described in document 15-04-0539- 00. Receiver keeps track of the frame counter for each device sending to it using default key, similar to what is currently done for peer-to-peer traffic (which uses peer-to-peer keys). PAR Compliance: remove inflexible key usage, fix security holes, remove ambiguities
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 8 Which Key to use for Peer to Peer Problem: Node A may have a shared key to use with Node B. If node B lacks that shared key, it will try to use the default key (aka broadcast key) when receiving a packet from Node A, resulting in a decryption failure. Higher level code cannot determine why the decryption failed. Proposal: Explicitly identify key is not a function of source and destination device (see document 15-04-039-00) PAR compliance: remove inflexible key usage, remove ambiguities, reduce complexities
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 9 Dynamic protection levels Problem: Nodes can only derive applicable security/protection level from statically maintained information, thus leading to unworkable broadcast encryption (if recipients have different security expectations) and high-cost system set-up Proposal 1: Differentiate applicable protection level on frame-by- frame basis; Proposal 2: differentiate minimum expected protection level Proposal 3: allow synchronization of expected protection levels on-the-fly PAR compliance: remove inflexible key usage, reduce complexities, reduce cost, reduce latency
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 10 Group keying and multicast Problem: secure broadcast is not possible, if devices would change key over lifetime; secure multicast is also not possible Proposal 1: Incorporate secure broadcast over network’s lifetime; Proposal 2: incorporate secure multicast (and unsecured multicast) See also 15-04-0539-00 PAR compliance: remove inflexible key usage, reduce complexities, reduce key storage cost, reduce latency, incorporate multicast
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 11 Compress security overhead if possible Problem: security overhead is substantial (currently 5 bytes per secured frame). Proposal 1: reduce frame counter overhead from 4 to 1 bytes per frame Proposal 2: piggyback on DSN entry for reduction of frame counter size by 1 further octet (thus eliminating it) See also 02/474r2 and 15-04-039-00 PAR compliance: remove security overhead, reduce battery usage at no computational cost (1 integer increment only), eliminate risk of Denial of Service attack by insiders (!)
doc.: IEEE 802.15-04-0540-01 Submission September 16, 2004 Poor & Struik / Ember & CerticomSlide 12 Centralized frame counters Problem: frame counters depend on device and key, thus invoking quite a big key storage cost (Example: 16 RFD talk with coordinator using n versions of broadcast key 16 X n X 4=64 n bytes for frame counters) Proposal: centralize frame counters, such as to have these depend on device only (this requires #stored frame counter = # devices sending) See also 15-04-0539-00 PAR compliance: reduce storage requirements keying material
© 2023 SlidePlayer.com Inc.
All rights reserved.