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] Voice:[+81-3-5437-2270], FAX: [+81-3-5437-2271], E-Mail:[ishikawa@ubin.jp, kuma@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. ISHIKAWA, Chiaki OKUMA, Yasuyuki YRP Ubiquitous Networking Laboratory Security Support in Heterogeneous Mesh

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 RFDsat 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 <-... Middle-ground ...->Very 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. • 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.) • -> Self-organising requires key distribution!? We can't ignore this any more. Or can we?

12. Scenario No. 2 • Similar to Scenario No. 1. • Suppose we have two or more meshes. One node of mesh A loses radio contact somehow. Then it receives beacon from the different coordinator from mesh B. The node will migrate to mesh B. Simple enough. But what if security is in place, and we need to learn the key to talk to mesh B.

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