1. Design and Implementation of Secure Layer over UPnP Networks Speaker: Chai-Wei Hsu Advisor: Dr. Chin-Laung Lei

2. DCNSLab@NTU2 07/20/2007 Outline Introduction Related researches SUPnP system design Applications Discussions Conclusions and future works

3. DCNSLab@NTU3 07/20/2007 Introduction As home network technology has been developed rapidly, integrating modern technologies into people’s daily life becomes an inevitable trend. Universal Plug and Play (UPnP) is an outstanding standard for personal/home network environment. UPnP is designed to support easy-to-use, flexible, automatic- discovery and zero-configuration.

4. DCNSLab@NTU4 07/20/2007 Figure 1. A digital home of UPnP devices

5. DCNSLab@NTU5 07/20/2007 Motivation UPnP does not provide secure communication channels. To build a secure large-scale information system, the secure communication channels are required. To construct secure communication channels, we introduce key management mechanisms into the system.

6. DCNSLab@NTU6 07/20/2007 Secure Group Communications Why we need group key management?  Limit the access to authorized group members only  Forward/backward secrecy Three classifications of key management mechanisms  Centralized  Decentralized  Distributed

7. DCNSLab@NTU7 07/20/2007 Secure Group Communications (cont.) Secure communication channels over UPnP  Central control points  The ability to transform messages between unicast and multicast communication  Should not break the zero-configuration property of UPnP architecture

8. DCNSLab@NTU8 07/20/2007 Secure Group Communications (cont.) We suggest centralized key management protocols  Centralized controllers  The number of members varies dynamically  Simple to implement and also efficient  Make Logical Key Hierarchy (LKH) as an example

9. DCNSLab@NTU9 07/20/2007 Logical Key Hierarchy (LKH) {x}k, means x has been encrypted with k An example of LKH tree KEKs affected when a member joins the tree Rekey as member joins Modified keys  k  k’  k14  k’14  k34  k’34 Key distribution  {k’}k’14, k58  {k’14}k12, k’34  {k’34}k3, k4  {k3}S-KEY Broadcast once to update all KEKs Rekey as member leaves Modified keys  k  k’  k14  k’14  k34  k’34 Key distribution  {k’}k’14, k58  {k’14}k12, k’34  {k’34}k3 Broadcast once to update all KEKs

10. DCNSLab@NTU10 07/20/2007 Concepts of System Design The design of the UPnP network is a layered design. Based on the UPnP architecture, we attempt to build a secure layer on the top of UPnP network. The majority of the devices are built on the top of SUPnP layer and divided into client devices and server devices.

11. DCNSLab@NTU11 07/20/2007 Figure 2. The protocol architecture of the secure UPnP environment

12. DCNSLab@NTU12 07/20/2007 System Components Client devices  To interact with the environments and make requests to server devices 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

13. DCNSLab@NTU13 07/20/2007 System Architecture A centralized control point device Client devices Server devices

14. DCNSLab@NTU14 07/20/2007 The Node Registration Protocol Important design ideas  Simplicity  Security Member device knowledge  Device ID  Password (PWD)  SALT Key server knowledge  SALT  H(SALT, PWD)  User-type of each ID

15. DCNSLab@NTU15 07/20/2007 Secure Client Channels Only unicast communication is required. Auto-constructed with symmetric key S-KEY  Kept on both the client and the controller Messages are encrypted/decrypted using S-KEY.

16. DCNSLab@NTU16 07/20/2007 Secure Server Channels Support both unicast and multicast/broadcast communication The required secure group keys of new server device are 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 adopt LKH in our proposed scheme.

17. DCNSLab@NTU17 07/20/2007 Secure Server Channels (cont.) To minimize the re-key overheads  One time multicast/broadcast The cost of LKH for a group containing N members  Key distribution center (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.

18. DCNSLab@NTU18 07/20/2007 Message Relaying The forwarder is bound with the UPnP controller. The forwarder must have the same knowledge to key manager.  Include all the S-KEYs 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.

19. DCNSLab@NTU19 07/20/2007 Message Relaying (cont.) On replying a request message  A server can encrypt the response by using either its S-KEY or the group key.  In either way, the forwarder is able to decrypt the response and re- encrypt the message using the S-KEY of the receiver.

20. DCNSLab@NTU20 07/20/2007 Applications Figure 3. The system architecture of an intelligent bulletin board system

21. DCNSLab@NTU21 07/20/2007 Figure 4. The system architecture layer and communication channels

22. DCNSLab@NTU22 07/20/2007 Figure 5. A screenshot of user interface on the panel device

23. DCNSLab@NTU23 07/20/2007 Discussions The choice of centralized group key management Fault-tolerant and scalability Co-existence of SUPnP and UPnP networks Extension of the SUPnP network

24. DCNSLab@NTU24 07/20/2007 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  Require members to cooperate to compute the shared secret key  May be not suitable

25. DCNSLab@NTU25 07/20/2007 Group Key Management (cont.) Decentralized mechanisms  Dynamically changed memberships  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.

26. DCNSLab@NTU26 07/20/2007 Fault-Tolerant and Scalability Setup multiple controllers and make them all on-line at the same time Load can be shared by dispatching or migrating members to different controllers.

27. DCNSLab@NTU27 07/20/2007 Co-Existence of SUPnP and UPnP The SUPnP is built on top of and UPnP basic device.  Devices should be able to send unencrypted messages to each other without SUPnP support. 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.

28. DCNSLab@NTU28 07/20/2007 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.

29. DCNSLab@NTU29 07/20/2007 The SUPnP Message Header (cont.) The “nounce” field is to make encrypted message indistinguishable. The “length” field stores the total length including data. Determine a valid SUPnP message  Check constant magic number  Verify the checksum value XORed result of all the first six fields should be ZERO.

30. DCNSLab@NTU30 07/20/2007 Extension of SUPnP Network The UPnP architecture is originally proposed for personal/home environment. Because the SUPnP layer is built on the top of UPnP architecture, the SUPnP network is also bound inside a local area network.

31. DCNSLab@NTU31 07/20/2007 Extension of SUPnP Network (cont.) To extend the SUPnP network across the network boundaries  Construct a virtual private network (VPN) over the Internet  Devices need to have more network configurations beforehand. VLAN (Virtual local area network)  Each device does not need to be 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.

32. DCNSLab@NTU32 07/20/2007 Conclusions The UPnP technique was developed to simplify the configuration of personal/home networks, but had no secure mechanisms to ensure the secrecy of the data transferred in the network. We successfully extend the UPnP technologies with key management mechanism and build an intelligent secure network. The proposed protocol is suitable for the construction of a flexible and easy-to-use secure information system.

33. DCNSLab@NTU33 07/20/2007 Future Works Our future works will be focused on further analyses on the proposed protocols, extending the scalability of the proposed architecture. To simplify the deployment of the SUPnP network, we also prepare to construct the SUPnP network over wireless environments.