Security PIB Differences: Fixing 2006 and 2011

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Security PIB Differences Date Submitted: 17 May, 2012 Source: Tero Kivinen, Company: INSIDE Secure Address: Eerikinkatu 28, FI-00180 Helsinki, Finland Voice:+358 20 500 7800, FAX: +358 20 500 7801, E-Mail: kivinen@iki.fi Re: Security PIB Differences Abstract: Pictures describing the changes between 2006 and 2011 security PIB Purpose: How to fix the security in the 2006 and 2011 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. Tero Kivinen, INSIDE Secure

2. Tero Kivinen Los Angeles, CA January 22, 2014 Security PIB Differences between 2006 and 2011, and problem in macFrameCounter Tero Kivinen, INSIDE Secure

3. Tero Kivinen, INSIDE Secure Security PIB differences between 2006 and 2011 • Number of Items • In 2006 there is List of items and counter for the items (macKeyTableEntries, macDeviceTable Entries etc) • In 2011 there is just Sets or Lists no counts • Added fields in 2011 • SecurityLevelDescriptor has AllowedSecurityLevels field

4. Tero Kivinen, INSIDE Secure KeyDescriptors • KeyIdLookupDescriptor is very different • 2006 has only LookupData and Size • 2011 has expanded fields: • KeyIdMode, KeySource, KeyIndex, DeviceAddrMode, DevicePANId, DeviceAddress • KeyDeviceList removed in 2011 • In 2006 it had UniqueDevice, BlackListed • DeviceDescriptorHandle was moved to KeyDescriptors level

5. Tero Kivinen, INSIDE Secure 2006 MAC PIB

6. Tero Kivinen, INSIDE Secure 2011 MAC PIB

7. Tero Kivinen, INSIDE Secure Both have problems • macFrameCounter is global to device • FrameCounter is per remote peer

8. Tero Kivinen, INSIDE Secure macFrameCounter • This is global to device • This is used when sending packets out • I.e regardless who the device sends packet to or what key is used the counter is incremented. • When this reaches 0xffffffff the device needs to rekey all keys • Makes using more than one key per device almost useless • You cannot for example create multiple keys at once and start using next one when first one needs to be rekeyed. • You cannot create separate key for device where you are sending lots of data. • Cannot create low volume broadcast key for broadcasts and high volume unicast key for the peer sending lots of data

9. Tero Kivinen, INSIDE Secure FrameCounter • This is per remote peer • Identified by PANId, ShortAddress, ExtAddress • This is used to check the replay attacks, i.e. if incoming FrameCounter from the device is smaller than this it is dropped. • This makes it useless to have multiple keys between same peers

10. Tero Kivinen, INSIDE Secure What should be done • macFrameCounter needs to be per key: • should be moved to the KeyDescriptors table. • It should be incremented every time key is used. • FrameCounter needs to be per key and per remote peer. • DeviceDescriptors table should also have keyIndex if KeyIdMode is not 0x00.

11. Tero Kivinen, INSIDE Secure Why this was not problem earlier • Only problem if you are using multiple keys between peers, i.e. have KeyIdMode that is not 0x00, and you have multiple KeyIndex values between peers. • Might be bigger problem when bigger networks want to use multiple keys and do not want to rekey all of them at the same time