Jan 2014 doc IEEE 802 15 14 0065

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Project: IEEE P 802. 15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Security PIB Differences Date Submitted: 23 January, 2014 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 P 802. 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 P 802. 15. Submission 1 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Security PIB Differences between 2006 and 2011, and problem in mac. Frame. Counter Tero Kivinen Los Angeles, CA January 23, 2014 Submission 2 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Security PIB differences between 2006 and 2011 • Number of Items – In 2006 there is List of items and counter for the items (mac. Key. Table. Entries, mac. Device. Table Entries etc) – In 2011 there is just Sets or Lists no counts • Added fields in 2011 – Security. Level. Descriptor has Allowed. Security. Levels field Submission 3 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Key. Descriptors • Key. Id. Lookup. Descriptor is very different – 2006 has only Lookup. Data and Size – 2011 has expanded fields: • Key. Id. Mode, Key. Source, Key. Index, Device. Addr. Mode, Device. PANId, Device. Address • Key. Device. List removed in 2011 – In 2006 it had Unique. Device, Black. Listed – Device. Descriptor. Handle was moved to Submission Key. Descriptors level Tero Kivinen, INSIDE Secure 4

Jan 2014 Submission doc. : IEEE 802. 15 -14 -0065 -02 -0 mag 2006 MAC PIB 5 Tero Kivinen, INSIDE Secure

Jan 2014 Submission doc. : IEEE 802. 15 -14 -0065 -02 -0 mag 2011 MAC PIB 6 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Both have problems • mac. Frame. Counter is global to device • Frame. Counter is per remote peer Submission 7 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag mac. Frame. Counter • 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 0 xffff the device needs to rekey all keys – With 1 Mbit/s speed, device sending data at full speed that is about 50 days – When device sending at full speed needs to rekey its unicast key, the whole network will also need to rekey its broadcast key. Submission • Makes using more than one. Tero key. Kivinen, per device INSIDE Secure 8

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Frame. Counter • This is per remote peer – Identified by PANId, Short. Address, Ext. Address – This is used to check the replay attacks, i. e. if incoming Frame. Counter from the device is smaller than this it is dropped. – This makes it useless to have multiple keys between same peers Submission 9 Tero Kivinen, INSIDE Secure

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag What should be done • mac. Frame. Counter needs to be per key: – should be moved to the Key. Descriptors table. – It should be incremented every time key is used. • Frame. Counter needs to be per key and per remote peer. – Device. Descriptors table should have key. Id. Lookup. List having list of Submission Terohaving Kivinen, INSIDE Secure key. Id. Lookup. Descriptor, i. e. 10

Jan 2014 doc. : IEEE 802. 15 -14 -0065 -02 -0 mag Why this was not problem earlier • Only problem if you are using multiple keys between peers, i. e. have Key. Id. Mode that is not 0 x 00, and you have multiple Key. Index 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 Submission 11 Tero Kivinen, INSIDE Secure