Resolution of security issues

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 Voice617 951-0200, FAX 617
951-0999, E-Mailrpoor_at_ieee.org, 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 Th
is document is submitted for consideration for
revisions to the 802.15.4-2003 specification. Not
ice 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.
2
Security Resolutions 802.15.4

• Robert Poor (Ember Corporation)
• Rene Struik (Certicom Research)

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 doesnt 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

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.

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.

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.

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

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

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

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
  networks 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

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 (!)