May 2004 ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory Slide 1 doc.: IEEE 802.15-04-0212-02-0005 Submiss ion Project: IEEE P802.15 Working Group for Wireless Personal Area Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) 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:[ [email protected], [email protected]] 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.
Transcript
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 1
doc.: IEEE 802.15-04-0212-02-0005
Submission
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)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:[[email protected], [email protected]]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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 2
doc.: IEEE 802.15-04-0212-02-0005
Submission
Security Support in Heterogeneous Mesh
ISHIKAWA, Chiaki
OKUMA, Yasuyuki
YRP Ubiquitous Networking Laboratory
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 3
doc.: IEEE 802.15-04-0212-02-0005
Submission
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).
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 4
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 5
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 6
doc.: IEEE 802.15-04-0212-02-0005
Submission
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).
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 7
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 8
doc.: IEEE 802.15-04-0212-02-0005
Submission
How much security do we want in 15.5?• Application Policy 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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 9
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 10
doc.: IEEE 802.15-04-0212-02-0005
Submission
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).
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 11
doc.: IEEE 802.15-04-0212-02-0005
Submission
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?
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 12
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 13
doc.: IEEE 802.15-04-0212-02-0005
Submission
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?
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 14
doc.: IEEE 802.15-04-0212-02-0005
Submission
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?
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 15
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 16
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 17
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 18
doc.: IEEE 802.15-04-0212-02-0005
Submission
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 ...
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 19
doc.: IEEE 802.15-04-0212-02-0005
Submission
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.
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
Slide 20
doc.: IEEE 802.15-04-0212-02-0005
Submission
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
May 2004
ISHIKAWA Chiaki, OKUMA Yasuyuki, YRP Ubiquitous Networking Laboratory
![[Title] [Instructor] Chiaki Kagawa / Nobutaka Motohashi ... · [Code] [Credits] [Program] [Semester] [Hours] [Language of instruction] 410510 B 2 Human Environment Medical Engineering](https://static.documents.pub/doc/80x56/5d5181f688c99378448bcd90/title-instructor-chiaki-kagawa-nobutaka-motohashi-code-credits.jpg)
![6XFKWWKHUDSLHWDJH - suchttherapietage.de · =xvdw]yhudqvwdowxqjhq lp 5dkphq ghu +dpexujhu 6xfkwwkhudslhwdjh yrp -xql 8qlyhuvlwlw +dpexuj )dfkwdj 6xfkw dov 8uvdfkh xqg )rojh iu khu](https://static.documents.pub/doc/80x56/5e032313d9e2ea2f2041edf4/6xfkwwkhudslhwdjh-xvdwyhudqvwdowxqjhq-lp-5dkphq-ghu-dpexujhu-6xfkwwkhudslhwdjh.jpg)
