DOC PREVIEW
Berkeley ELENG 290Q - Security and Efficiency Enhancements Overview

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

René Struik, Certicom ResearchNovember 13, 2008 IEEE P802.15-0xxx-00-004eIEEE P802.15Wireless Personal Area NetworksProject IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)TitleSecurity and Efficiency Enhancements OverviewDate [13-Nov-08]SourceRené StruikCerticom Corp.5520 Explorer Drive, 4th FloorMississauga, ON L4W 5L1E-mail: [email protected]: +1 (905) 501-6083Fax: +1 (905) 507-4230Re: Security and Efficiency Enhancements for IEEE 802.15.4eAbstract This document provides an overview of security and efficiency enhancements for 802.15.4e, based on the streamlined version of Clauses 7.5.8 and 7.6 of IEEE 802.15.4-2006.Purpose Security and efficiency enhancements of IEEE 802.15.4-2006Notice 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 1René Struik, Certicom ResearchNovember 13, 2008 IEEE P802.15-0xxx-00-004e1.1 Overview of Provided FunctionalityFrame security with IEEE 802.15.4e is based on the frame security provisions in the 802.15.4-2006 specification with the following provisions:Same as with 802.15.4-2006:Security provisions:– Confidentiality, data authenticity, replay protection (with old specification, not always replay protectionor data authenticity)– Protection of broadcast and multicast frames possible (with old specification, this mechanism was broken)– Easier set-up of protection parameters possible (with old specification, one had to pre-install these parameters via ‘out-of-scope’ mechanism)– Possibility to vary protection per frame, using a single key (with old specification, protection was fixedand key was married to protection level)– Consideration of system lifecycle issues, e.g., allowing unsecured communications until higher layer sets up key (with old specification, this was ‘out-of-scope’)– Optimization of storage of keying material (with old specification, frame counter was function of device and key; with new specification, this is function of device only [thus, saving cost, e.g., when working with two versions of network key])– Security policy checks per frame possible (with old specification, protection level fixed irrespective of frame type)– Key usage policy checks possible (with old specification, any key could be used with any frame)Further enhancements to 802.15.4-2006:Security provisions: Strong replay protection rather than weak replay protection (since clock available) More refined security policy check (also prevents some DoS attacks) Protection of acknowledgement frames possibleSystem lifecycle support:– Facility for smooth key updates network-wide keys – Refinement to facility for unsecured initial device enrolment (device-dependent rather than just frame type dependent)Implementation cost: Reorganization of tables, to facilitate low-cost implementations  Additional status messages Reduced storage cost of keying material (frame counters, device addresses, keys)NOTE: Implementation of enhancement does not jeopardize 802.15.4-2006 complianceSubmission Page 2René Struik, Certicom ResearchNovember 13, 2008 IEEE P802.15-0xxx-00-004e1.2 How to Implement Enhancements to 802.15.4-2006 Security Functionality for 802.15.4eEnhancements to 802.15.4-2006 Security Functionality may be implemented by using the streamlined version of the 802.15.4-2006 security specification, with the following provisions:1.2.1 Transmission (§7.5.6.1): p. 188, l. 16: Add language to the effect that the current time macCurrentTime will be stored.1.2.2 Reception and rejection (§7.5.6.2): p. 190, l. 24: Add language to the effect that the current time macCurrentTime will be stored.1.2.3 Outgoing frame security procedure (§7.5.8.2.1): p. 202, l. 29-31: Add FrameCounterMode parameter; add macCurrentTime parameter. Adapt MAC sublayer service primitives (§7.1) accordingly. p. 202, Step d), ii). l. 47-48: Extend definition of AuxLen parameter, to take into account FrameCounterMode as well. p. 203, Step f): Obtain macFrameCounter attribute from macCurrentTime parameter; check that valuenever decreases.  p. 203, Step i), iii): Set frame counter to representation of macFrameCounter compliant with FrameCounterMode parameter.1.2.4 Incoming frame security procedure (§7.5.8.2.3): p. 204, l. 37-41: Add FrameCounterMode parameter; add macCurrentTime parameter. Adapt MAC sublayer service primitives (§7.1) accordingly. p. 205, Step i), l. 36-39: Reconstruct frame counter from representation hereof in auxiliary security header, taken into account the frame counter mode and locally maintained info as to the current time (so-called frame counter conversion). p. 205, Step j), l. 40-43: Correlate the frame counter and the current time macCurrentTime; reject frame if these differ by more than a set amount (presumably, because the frame was stale).Remarks (RS): p. 205, Step g), l. 26-29: What if device not there? If one does not do source address filtering, one might still wish to accept incoming frame (e.g., to allow forwarding of frames secured using network-wide key). We may wish to implement a source address filtering mechanism anyway, also for unsecuredincoming traffic. Changes to facilitate secured acknowledgements: §7.5.8.2.1: Add language on how to compress auxiliary security header. §7.5.8.2.3: Add language on how to reconstruct full auxiliary security header. §7.5.6.1, p. 189, l. 24-29: Rewrite this paragraph, so as to include outgoing frame processing on acknowledgement messages. Adapt §7.5.6.4 accordingly, to take into account changes to acceptable latency (e.g., parameter aTurnAroundTime) and resends. §7.5.6.2, pp. 189-190: Expand description to cover handling of incoming secured acknowledgment frames as well.1.3 A Note on Higher-Layer Security FunctionalityHigher-layer functionality may be implemented almost the same as MAC Layer Security Functionality (cf. §1.2 above), with the following caveats:1.3.1 Common information elements across layersSubmission Page 3René Struik, Certicom


View Full Document

Berkeley ELENG 290Q - Security and Efficiency Enhancements Overview

Documents in this Course
Lab 1

Lab 1

16 pages

Lab 1

Lab 1

16 pages

Load more
Download Security and Efficiency Enhancements Overview
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Security and Efficiency Enhancements Overview and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Security and Efficiency Enhancements Overview 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?