Design and Implementation of SUPnP Networks

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

2. Outline • Introduction • Related researches • System architecture • SUPnP protocol design • 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 Researches • UPnP • Originally developed by Microsoft • Nowadays upgraded by UPnP forum • Designed to bring easy-to-use, flexible, standards-based connectivity • Distributed and open networking architecture • Control devices maintain all network devices • Support zero-configuration networking • No secure data transmission protocol • Media independent • Any programming language • Any operating system DCNSLab@NTU

5. Related Researches (cont.) • Secure group communication • Why we need group key management? • Limit the access to authorized group members only • Forward/backward secrecy • Three classifications • Centralized group key management protocols • Decentralized architectures • Distributed key management protocols DCNSLab@NTU

6. Related Researches (cont.) • Secure communication channels over UPnP • Central control point(s) • The ability to transform messages between unicast and multicast communication • Should not break the zero-configuration property of UPnP architecture • We suggest to use centralized key management protocols • Centralized controllers • The number of members varies dynamically • Simple to implement and also efficient DCNSLab@NTU

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

8. 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

9. SUPnP Protocol Architecture • The protocol architecture of the secure UPnP environment DCNSLab@NTU

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

11. 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

12. 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 • Although we suggest to use centralized key management mechanisms in the UPnP network • We choose Logical Key Hierarchy (LKH) as an example DCNSLab@NTU

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

14. LKH (cont.) • An example of LKH tree DCNSLab@NTU

15. LKH (cont.) • KEKs affected when a member joins the tree DCNSLab@NTU

16. LKH (cont.) • Member join • Modified keys • k  k’ • k14  k’14 • k34  k’34 • Key distribution • Enc{k’}k58 • Enc{k’, k’14}k12 • Enc{k’, k’14, k’34}k4 • Enc{k’, k’14, k’34, k3}S-KEY • Broadcast once to update all KEKs {x}k, means x has been encrypted with k DCNSLab@NTU

17. LKH (cont.) • Member leave • Modified keys • k  k’ • k14  k’14 • k34  k’34 • Key distribution • Enc{k’}k58 • Enc{k’, k’14}k12 • Enc{k’, k’14, k’34}k3 • Broadcast once to update all KEKs {x}k, means x has been encrypted with k DCNSLab@NTU

18. 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

19. 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

20. 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

21. Centralized Group Key Management • The original UPnP network already has a (centralized) controller • The server devices in the SUPnP network join or leave 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 major use of the secure group channels is to broadcast requests • 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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. • UPnP device architecture 1.0. UPnP Forum, document version 1.0.1, 20 July 2006. DCNSLab@NTU