本篇论文针对ZigBeeWirelessNetworks中的孤立节点问题，提出很好的解决方案。资源-CSDN文库

需积分: 10 110 浏览量 2010-01-13 09:10:50 上传评论收藏 125KB PDF 举报

资源推荐

资源详情

资源评论

December 14, 2009 IEEE P802.15-0848-03-004e

Submission Page 1

René Struik, Certicom Research

IEEE P802.15

Wireless Personal Area Networks

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

Title

Security and Efficiency Enhancements Overview

Date December 14, 2009

Source

René Struik

Certicom Corp.

5520 Explorer Drive, 4

Floor

Mississauga, ON L4W 5L1

E-mail: rstruik@certicom.com

Phone: +1 (905) 501-6083

Fax: +1 (905) 507-4230

Re: Security and Efficiency Enhancements for IEEE 802.15.4e

Abstract 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 (for details, cf. document: 08/0849r0).

Purpose Security and efficiency enhancements of IEEE 802.15.4-2006

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.

December 14, 2009 IEEE P802.15-0848-03-004e

Submission Page 2

René Struik, Certicom Research

1.1 Overview of Provided Functionality

Frame 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

protection or 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

fixed and 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 possible

System 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 compliance

December 14, 2009 IEEE P802.15-0848-03-004e

Submission Page 3

René Struik, Certicom Research

1.2 How to Implement Enhancements to 802.15.4-2006 Security Functionality for 802.15.4e

Enhancements 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 and locally

maintained info (so-called frame counter conversion), such that value never decreases.

• p. 203, Step i), iii): Set frame counter to representation of macFrameCounter compliant with

FrameCounterMode parameter.

• p. 203, Step m, l. 35: Mute frame header fields in the protected frame compliant with representation

mode parameter settings.

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).

• p. 205, Step k), l. 44-47: Reconstruct muted frame header fields from information in the received

frame and locally maintained status information.

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

unsecured incoming traffic.

• Changes to facilitate secured acknowledgements:

− §7.5.8.2.1: Add language on how to compress auxiliary security header and other header fields.

− §7.5.8.2.3: Add language on how to reconstruct full auxiliary security header and other header

fields.

− §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.

December 14, 2009 IEEE P802.15-0848-03-004e

Submission Page 4

René Struik, Certicom Research

− §7.5.6.2, pp. 189-190: Expand description to cover handling of incoming secured

acknowledgment frames as well.

1.2.5 PIB security material (§7.6.1):

• p. 203, Table 93: represent frame counter as 6-octet integers, rather than 4-octet integers. Adapt

overflow checks with security processing of outgoing frames (§7.5.8.2.1) and of incoming frames

(§7.5.8.2.3) accordingly (i.e., replace 0xffffffff by 0xffffffffffff).

1.3 A Note on Higher-Layer Security Functionality

Higher-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 layers

• Addresses: cryptographic processing and retrieval of keying information assumes that the IEEE

extended address EUI-64 is available. If necessary, address conversion needs to take place.

• Timing information: cryptographic processing assumes that timing information related to time of

actual receipt of frame is available. This information needs to be propagated ‘up the stack’ (hence,

mentioning hereof as I/O parameter in §1.2.3 and §1.2.4 above).

1.3.2 Different information elements across layers

• Timeliness criteria: correlation of the frame counter and the current time may yield rejection of the

frame if these differ by more than a set amount, presumably because the frame was stale (cf. §1.2.4

above). The conditions under which this test leads to rejection of the incoming frame may depend on

the layer in question, e.g., to take into account that multi-hop traffic has longer latency than single-

hop traffic.

• Security policy information: the security policy under which incoming frames are rejected may

depend on the frame type/stack layer in question. Note RS: In fact, the timeliness test above is another

example of such a security policy check, but now not with respect to the protection purportedly

applied to the frame or key used to implement this security transformation, but with respect to the

time the frame was purportedly sent by the purported originating device.

1.4 How to Use Parameter Settings

The security services offered via frame security, both at the MAC level (§1.2) and at higher levels (as

alluded to in §1.3), is guided by appropriate settings of security related parameters. A short discussion, in

the context of MAC and higher-layer communications, follows.

Security services offered

The cryptographic mechanism provides particular combinations of the following security services:

− Data confidentiality. Assurance that transmitted information is only disclosed to parties for which it is

intended.

− Data authenticity. Assurance of the source of transmitted information (and, hereby, that information

was not modified in transit).

− Replay protection. Assurance that duplicate information is detected.

− Timeliness (delay protection). Assurance that transmitted information was received in a timely

manner.

剩余18页未读，继续阅读

评论收藏

内容反馈

ybpstone

粉丝: 0
资源: 1

本篇论文针对 ZigBee Wireless Networks 中的孤立节点问题，提出很好的解决方案。

最新资源

本篇论文针对 ZigBee Wireless Networks 中的孤立节点问题，提出很好的解决方案。

The Orphan Problem in ZigBee Wireless Networks

ZigBee Wireless Networks and Transceivers 2008

ZigBee-Wireless-Networks-and-Transceivers中文翻译(第一章)

ZigBee_Wireless_Networks_and_Transceivers中文翻译.doc

ZigBee__Wireless__Networks__and_Transceivers.pdf

ZigBee Wireless Networks and Transceivers

Newnes.ZigBee.Wireless.Networks.and.Transceivers

ZigBee.Wireless.Networks.and.Transceivers

【重磅】ZigBee、物联网、Wifi等资料大合集.zip

zigee基础，两本外国经典教材

论文研究-基于ZigBee技术的孤立点入网算法研究.pdf

Zigbee Wireless Networking

Zigbee在大数量节点应用中的问题研究

Newnes.ZigBee.Wireless.Networks.and.Transceivers.Sep.2008.eBook-DDU

Zigbee wireless networking(ebook)

ZigBee_Wireless_Networks_and_Transceivers中文翻译.zip-综合文档

python大作业 含爬虫、数据可视化、地图、报告、及源码（整和为一个文件）（2014-2020全国各地区原油加工量）.rar

仿真电路以及操作方法

【纯干货啊】华为IPD流程管理(完整版).pptx

可编程语言标准IEC61131-3中文版.pdf

OFDM完整仿真过程与教程.zip

信号与系统——保研复习资料.pdf

Landsat_WRS2.zip

最全的Visio形状/图形库

AxureRP9项目原型50套、案例20个、元件库1套.zip

北理工+成电+东南——通信/信号保研面试真题.pdf

数字信号处理——保研复习资料.pdf

风电和储能并网Simulink模型

使用STM32F103C8T6+L298N+MG513P30电机使用外部中断法和输入捕获法进行编码器测速

最新资源

ZigBeeWirelessNetworks__and_Transceivers.pdf

python大作业含爬虫、数据可视化、地图、报告、及源码（整和为一个文件）（2014-2020全国各地区原油加工量）.rar