May 2004 doc IEEE 802 15 04 0212

  • Slides: 21
Download presentation
May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Project: IEEE P

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Project: IEEE P 802. 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 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 Slide 1 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Security Support in

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Security Support in Heterogeneous Mesh ISHIKAWA, Chiaki OKUMA, Yasuyuki YRP Ubiquitous Networking Laboratory Submission Slide 2 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Mesh Network •

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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). Submission Slide 3 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Heterogeneous Profiles •

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 4 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Importance of the

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 5 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 What is the

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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). Submission Slide 6 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 What is the

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 7 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 How much security

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. – Do. S against sensors is easy if we permit physical access, but assuming such physical tampering is impossible, we need to offer secure transport. Submission Slide 8 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Our Observation #1.

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 9 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario No. 1

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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). Submission Slide 10 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario 1 (cont'd)

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. ) • -> Self-organising requires key distribution!? We can't ignore this any more. Or can we? Submission Slide 11 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario No. 2

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 12 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario No. 3

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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? Submission Slide 13 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario 3 (cont'd)

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario 3 (cont'd) • Putting new FFD A' into the mesh and beginning self-organising (and selfhealing) 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? Submission Slide 14 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Scenario 4. •

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 15 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Observation # 2.

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 16 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Simple Issue(s) •

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. Submission Slide 17 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Speaking from our

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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. . . Submission Slide 18 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 Speaking from our

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 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 tradeoff of cost of the total architecture vs. initial node cost. Submission Slide 19 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 References. • [1]

May 2004 doc. : IEEE 802. 15 -04 -0212 -02 -0005 References. • [1] Ken Sakamura, Noboru Koshizuka, The e. TRON 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 Submission Slide 20 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory

May 2004 Submission doc. : IEEE 802. 15 -04 -0212 -02 -0005 Slide 21

May 2004 Submission doc. : IEEE 802. 15 -04 -0212 -02 -0005 Slide 21 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory