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

07/20/2007 Outline Introduction Related researches SUPnP system design Applications Discussions Conclusions and future works

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.

07/20/2007 Figure 1. A digital home of UPnP devices

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.

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

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

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

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

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.

07/20/2007 Figure 2. The protocol architecture of the secure UPnP environment

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

07/20/2007 System Architecture A centralized control point device Client devices Server devices

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

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.

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.

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.

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.

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.

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

07/20/2007 Figure 4. The system architecture layer and communication channels

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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.