Project: IEEE P802'15 Working Group for Wireless Personal Area Networks WPANs

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Security Support in Heterogeneous Mesh Date
Submitted 29 May, 2004 Source ISHIKAWA
Chiaki and OKUMA Yasuyuki Company YRP
Ubiquitous Networking Laboratory Address 2-20-1
Nishigotanda, Shinagawa, Tokyo, 141-0031,
Japan Voice81-3-5437-2270, FAX
81-3-5437-2271, E-Mailishikawa_at_ubin.jp,
kuma_at_ubin.jp Re n/a Abstract Supporting
multiple security profile is essential for
heterogeneous mesh management (i.e., mixed
devices). We raise issues that must be solved for
security management in mesh network settings and
note a few issues concerning the current
standards including 15.4. Purpose To raise
issues to be discussed in 802.15.5 (mesh)
standardization. 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.
2
Security Support in Heterogeneous Mesh

• ISHIKAWA, Chiaki
• OKUMA, Yasuyuki
• YRP Ubiquitous Networking Laboratory

3
Mesh Network

• Homogeneous Network
• devices with the same profile
• Heterogeneous Network
• devices with different profiles.
• The latter will be the majority in ad-hoc
  networking (in our view).

4
Heterogeneous Profiles

• Impact on self-organisation.
• We want to use optimal connection in terms of the
  security use (and other use for that matter).
• Quick Reconfiguration may be impacted.

5
Importance of the Security in Mesh.

• Security is important!
• It is not too much to stress this point many
  times over.
• It is so even in the case of mesh network.
• Make no mistake about it. An advertising kiosk in
  a public place needs security, too! (Contrary to
  what is noted in page 92, 2),
• Taking advantage of the best security feature of
  each node is important.

6
What is the security model of 15.5 (mesh)?

• Assumptions (Do people agree? )
• Mesh self-organizing and self-healing network.
• Low cost RFDs and slightly expensive FFDs.
• Shared keys used at for security purposes (say as
  in MAC layer (15.4)) can be written into RFDs at
  initial fabrication time, or at later stage
  (dynamically).
• FFD keys are rewritable dynamically.
• FFD nodes with multiple keys to talk to
  different RFDs are allowed (in terms of cost).

7
What is the security model of 15.5 (mesh)?
Continued.

• Is cryptographic feature of MAC-layer (15.4)
  usable or practically useful?
• If we need high-level security and application
  programs need to offer reliable end-to-end
  security (authentication, etc.), then the crypto
  feature of existing MAC layer (15.4) may not be
  required/used at all ?!
• Shouldn't we incorporate high-level features such
  as PKI even in MAC layer? (Not 15.4 direction so
  far.)
• AES implementation in HW itself is useful. But
  we may want API to use access the crypto
  functions directly, though.

8
How much security do we want in 15.5?

• Application Policy issues.
• But we must offer mechanisms.
• Security is relative.
• None lt-... Middle-ground ...-gtVery Tight
  ....... mesh ...................... e-commerce
• Issues.
• There may be networks which require no security
  at all, but we must be prepared to offer
  mechanisms when very high-level security is
  required.
• DoS against sensors is easy if we permit
  physical access, but assuming such physical
  tampering is impossible, we need to offer secure
  transport.

9
Our Observation 1.

• Fundamental Issue.
• 15.4 et al excludes many security issues.
• It seems that we can no longer get away with key
  management issues when we deal with heterogeneous
  mesh (!). We are very close to application now.
• We explain why we think so in the next few
  slides.
• Maybe we misunderstood something, but then such
  implicit assumptions must be made clear at this
  stage.

10
Scenario No. 1

• Initial state We have a mesh network consisting
  of one vendor's (A's) RFDs and FFDs.
• Now we want to add different vendor's (B's) RFDs
  (and FFDs if necessary) and want to reorganise
  the whole into a new mesh.
• This should be possible and not difficult.
• But what if we have used security keys? (cont'd).

11
Scenario 1 (cont'd)

• Various Key Usage Patterns.
• Case 1 Different keys for different RFDs.
• Complex. FFDs must support all the keys of RFDs
  to which they need to talk.
• Case 0 All RFDs share the same key
• Simple, but less secure.
• Real applications fall somewhere between case 0
  and 1. (E.g., groups share the same keys, etc.)
• With the above key usage patterns, the FFDs need
  keys for the added RFDs (B's) iff policy
  permits this. (If not, we have separate meshes.)
• -gt Self-organising requires key distribution!? We
  can't ignore this any more. Or can we?

12
Scenario No. 2

• Similar to Scenario No. 1.
• We want to merge two meshes managed by different
  security management domain (key management) under
  one single security domain. That is we want to
  reset/redistribute keys from one authority to
  others.

13
Scenario No. 3

• Home Network replace the home controller. The
  mediating FFD (A) broke down. We need to replace
  them.
• So, we have an existing mesh of single vendor
  RFDs (and/or mixed RFDs if we solve the issues
  raised in Scenario No. 1 and 2)
• Again should be easy to do in mesh framework. But
  what if we used security keys?

14
Scenario 3 (cont'd)

• Putting new FFD A' into the mesh and beginning
  self-organising (and self-healing) requires key
  management (backup, restore).
• Initial reorganisation phase may proceed without
  crypt. But later secure communication needs to
  use crypt keys. So we must put them into new FFD
  A'. (unless we reset the keys. See next scenario
  4.)
• Should be easy to handle. What about Scenario 4
  next?

15
Scenario 4.

• Variant of scenario 3. Home Network We move into
  a used condominium where lamps, etc. are
  controlled by RFDs. The previous owner removed
  his home controller.
• In this case, we probably need to reset the keys
  of lamp controller and others somehow. (Key
  generation and distribution.) and use the new
  keys for the new home controller.
• Again, we can't use the mesh without key
  management issues.

16
Observation 2.

• If we still insist that key distribution (and
  other key management issues) is outside the scope
  of the proposed mesh standard, we need to have a
  very good justification and good explanation to
  the future readers of the standard.

17
Simple Issue(s)

• Disregarding the fundamental questions,
• It is desirable to have direct MAC-level profile
  transfer (read) between devices
• Missing from 15.4, for example.
• Necessary for quick self secure configuration.
• We can possibly use the best secure connection
  available between nodes during initial mesh setup
  in a shorter time. (Less application level
  interaction.)
• We need to get the consensus on the security
  model of heterogeneous mesh.

18
Speaking from our experience.

• We have done an experiment for a small
  sensor/control network for security support
  investigation.
• We attached tamper-proof an IC chip with PKI
  secret/public key pair storage and coprocessor
  support for PKI proce to each node in our
  network. 1
• The chip can be used to generate temporal VPN key
  for communication between nodes.
• This is admittedly a very heavy-weight
  implementation. Home LAN actually requires good
  security 3. Most real world applications
  require less security probably.
• The chip supports end-to-end encryption and so we
  don't need to use secure feature of MAC (say, of
  15.4) at all, but ...

19
Speaking from our experience (cont'd)

• Our approach's cost consideration we wanted to
  make writing applications simple by providing
  advanced functions on node hardware. (PKI
  functions, for example)
• We use advanced FFD to manage admin. functions.
• We are even contemplating adding more versatile
  and advanced security layer function into sensor
  node network's MAC layer to make application
  development simpler However, many people
  disagreed with the idea so far. But what if we
  want to minimise the amount of application code
  on RFDs? This is a trade-off of cost of the total
  architecture vs. initial node cost.

20
References.

• 1 Ken Sakamura, Noboru Koshizuka, The eTRON
  Wide-Area Distributed-System Architecture for
  E-Commerce, IEEE MICRO, Vol. 21, No. 6, Dec.
  2001, pp. 7-12.
• 2 Jose A. Gutierrez, et al., Low-Rate Wireless
  Personal Area Networks ... Enabling Wireless
  Sensors with IEEE 802.1.5.4
• 3 Ken Sakamura, The TRON Intelligent House,
  IEEE MICRO, Vol. 10, No.2, Apr. 1990, pp.6-7.
• http//www.ubin.jp
• http//www.uidcenter.org

21
(No Transcript)