1 / 23

Design and Implementation of SUPnP Networks

This presentation discusses the design and implementation of SUPnP (Secure Universal Plug and Play) networks, integrating the UPnP technology with secure group communication technologies. It covers system architecture, SUPnP protocol, and key management mechanisms.

allisong
Download Presentation

Design and Implementation of SUPnP Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design and Implementation of SUPnP Networks Presented by Chai-Wei Hsu sshower@fractal.ee.ntu.edu.tw

  2. Outline • Introduction • Related works • System Architecture • SUPnP protocol • Discussions • Conclusions DCNSLab@NTU

  3. Introduction • Smart living spaces • The ease of system configuration • Secure data communication channels • Two technologies integrated • UPnP (Universal Plug and Play) • Secure group communication technologies DCNSLab@NTU

  4. Related Works • UPnP • A controller maintains all network devices • Support zero-configuration networking • No secure data transmission protocol • Secure communication channels • Central control point • The ability to transform messages between unicast and multicast communication • Should not break the zero-configuration property of UPnP architecture DCNSLab@NTU

  5. System Architecture • A centralized control point device • Client devices • Server devices DCNSLab@NTU

  6. SUPnP • The protocol architecture of the secure UPnP environment DCNSLab@NTU

  7. Components • The client devices • To interact with the environments and make requests to server devices • The server devices • In charge of answering requests from clients • Key manager • Run as a server device • To maintain the relationship of devices in the SUPnP network • Forwarder • Also run as a server cooperating with the UPnP controller • The bridge between clients and servers DCNSLab@NTU

  8. The Node Registration Protocol • Important design ideas • Simplicity • Security • Member device • maintain only its device ID and password • Key server knowledge • SALT, H(SALT, PWD), user-type of each ID DCNSLab@NTU

  9. Secure Client Channels • Support only unicast communication • The symmetric key S-KEY • Kept on both the client and the controller • Messages are encrypted/decrypted using S-KEY DCNSLab@NTU

  10. Secure Server Channels • Support both unicast and multicast/broadcast communication • The required secure group keys of new server device • Delivered with the REG DONE message • Most kinds of secure group communication mechanisms work with SUPnP framework • Centralized • Decentralized • Distributed • We suggest to use centralized key management mechanisms in the SUPnP network due to • Centralized forwarder • The number of members varies dynamically • The main purpose of the secure communication is to broadcast requests DCNSLab@NTU

  11. LKH • Logical key hierarchy key management • Key encryption keys (KEKs) • Correspond to each node in the path from its parent leaf to the root • Key distributor center (KDC) • Maintain a logical tree of keys • Re-key when the memberships change • Forward secrecy • Backward secrecy DCNSLab@NTU

  12. LKH (cont.) DCNSLab@NTU

  13. LKH (cont.) • To minimize the re-key overheads • One time multicast/broadcast • The cost of LKH for a group containing N members • KDC maintains (2N-1) KEKs • Each member only stores log(N) KEKs • When a re-key happens • Only log(N) KEKs are affected • Key updates are done in one shoot with a log(N) key size DCNSLab@NTU

  14. Message Relaying • The forwarder is bound with the UPnP controller • The forwarder must have the same knowledge to key manager • Include all the symmetric keys S-KEY and all the KEKs • For a request message sent from a client device • Encrypted with the shared S-KEY between the client and the key manager • The forwarder can decrypt the request and broadcast the request securely using the group secret key • On replying a request • A server can encrypt the response by using either its symmetric key or the group key • In either way, the forwarder is able to decrypt the response and re-encrypt the message using the symmetric key of the receiver DCNSLab@NTU

  15. Discussions • The choice of centralized group key management • Fault-tolerant and scalability of the UPnP controller/SUPnP forwarder • The co-existence of SUPnP and UPnP networks • The possibility of extending the architecture to deploy over wide area networks DCNSLab@NTU

  16. Centralized Group Key Management • The original UPnP network already has a (centralized) controller • The server devices in the SUPnP network can be joined or left dynamically • Distributed key management mechanisms • Require members to know each other and compute the shared secret key • May be not suitable • Decentralized mechanisms • Dynamically changed memberships • The use of only secure broadcast channels • Subgroup leaders may not work well • Centralized key management mechanisms • Easier to implement and maintain • Problems are the ability for fault-tolerant and the scalability DCNSLab@NTU

  17. Fault-Tolerant and Scalability • Setup multiple controllers and make them all on-line at the same time • Synchronization between these devices • Load can be shared by dispatching or migrating members of the SUPnP network to different controllers DCNSLab@NTU

  18. Co-Existence of SUPnP and UPnP • The SUPnP is built on top of and UPnP basic device • Encapsulate the SUPnP message with a dedicated protocol header • All the first six fields are in 16-bit length • Values should be stored in big-endian • The data are placed right after the sixth field DCNSLab@NTU

  19. The SUPnP Message Header • The magic field stores a constant number • All the SUPnP data should begin with this magic number • The flag field indicates how to process this message • Control message or data message, encrypted or not, sent by a client or by a server, unicast channel or broadcast channel • The keyid field indicates the key used to encrypt DCNSLab@NTU

  20. The SUPnP Message Header (cont.) • Determine a valid SUPnP message • Check constant magic number • Verify the checksum value • XORed result of all the first six fields should be ZERO DCNSLab@NTU

  21. Extension of the SUPnP Network • The UPnP architecture is originally proposed for personal/home environment • Across the network boundaries via virtual private network • Devices need to have more network configurations beforehand • VLAN (Virtual local area network) • Instead of having each device capable of VPN access abilities • Formed with cooperated subnetworks • When VLANs are constructed at the network level, it’s unnecessary to touch all the devices DCNSLab@NTU

  22. Conclusions • We extend the UPnP technologies and build an intelligent secure network • The proposed protocol is suitable for the construction of a flexible and easy-to-use smart living spaces DCNSLab@NTU

  23. References • J.-J. Lee, C.-Y. Huang, and C.-L. Lei. Design and Implementation of Secure Communication Channels over UPnP Networks. In MUE’07: International Conference on Multimedia and Ubiquitous Engineering, pages 307-312, 2007. • S. Rafaeli and D. Hutchison. A survey of key management for secure group communication. ACM Computing Surveys (CSUR), 35(3):309-329, 2003. DCNSLab@NTU

More Related