國立臺灣大學電機資訊學院電機工程學系

碩士論文

Department of Electrical Engineering

College of Electrical Engineering and Computer Science

National Taiwan University

Master Thesis

在 UPnP 網路上建構安全階層之設計與實作

Design and Implementation of Secure Layer over UPnP

Networks

徐嘉偉

Chia-Wei Hsu

指導教授：雷欽隆 博士

Advisor: Dr. Chin-Laung Lei

中華民國九十六年七月

July, 2007

i

致謝

首先，要感謝的人是我的指導教授，雷欽隆教授，在我寫這篇論文的期間，

沒有他的辛勤指導與嚴格要求，我無法完成這篇碩士論文，由於他的意見及指正，

這篇論文才能夠順利的完成。也要感謝我的碩士論文口試委員－顏嗣鈞教授、郭

斯彥教授以及黃秋煌教授，感謝他們細心審查我的論文，並給予我寶貴的意見。

另外要特別感謝博士班的黃俊穎學長，這篇論文的許多設計和架構都是和學

長不斷的討論、修正而完成的。沒有黃學長的指導，本篇論文一定無法完成。每

當遇到問題或瓶頸時，學長總是很有耐心的了解並給予關鍵的意見。非常感謝黃

俊穎學長辛勤的指導與鼓勵。

感謝實驗室學長這些年來的指導。允鵬學長與俊頡學長即使有龐大的研究壓

力，還是不厭其煩地給予我意見與鼓勵，指出我研究上的不完善之處讓我得以改

進。還有建樺學長，總是和善地回答我的疑問，耐心地與我一起討論表達內容的

方式，讓我能更有信心地去完成論文與通過口試。也謝謝仁群學長，在我情緒低

迷的時候替我心理輔導、加油打氣，讓我能更積極地去進行研究。

感謝實驗室的同學，思穎、哲睿、俊鋒、立源、照群、旭君，在最後的時刻，

大家相互鼓勵與打氣的畫面我會永遠記得，因為有他們的陪伴，讓我的生活充滿

了歡樂。

感謝我在台大的好友柏銓、許平，在最後的幾十個夜晚彼此加油，陪我聊天

舒緩口試前夕的壓力。還有遠在交通大學奮鬥的研究生們，欽議、士暐、東廷的

支持與關心。

最後，要感謝的是我的父母與哥哥，在我求學生涯上所給我的鼓勵與支持，

總是默默的支持我，給我最大的信心、動力。謹以此論文，獻給我最摯愛的你們。

ii

摘要

UPnP 是一個重要的個人與家庭網路系統協定，它提供了像是自動偵測、自動

系統配置等重要的功能。它的設計也達到一些重要的特性，包括容易使用、有彈

性的系統架構、基於標準的協定。然而，當我們想要試圖建構一個安全的大型資

訊信息系統時，安全的通訊管道這個重要的特性是 UPnP 無法提供的。於是我們基

於 UPnP 的架構，整合了密鑰管理機制，建構了安全的通訊頻道。在此篇論文中，

我們成功地擴展與整合了 UPnP 的技術與密鑰管理機制，並建立了一個智慧型安全

網路。我們所提出的系統架構與協定適合用來架構一個有彈性而且容易使用的安

全資訊信息系統。

關鍵字：UPnP，自動偵測，自動系統配置，安全通訊管道，群組密鑰管理。

iii

Abstract

UPnP is an outstanding standard for automatic-discovery, zero-configuration

personal or home network, and it is designed to achieve several important features such

as easy-to-use, flexible, standards-based. However, when we attempt to construct a

secure large-scale information system, the secure communication channels of the

system is required, but this significant feature is not provided by UPnP. Based on the

UPnP architecture, to construct secure communication channels, we introduce key

management mechanisms into the system. In this thesis, we successfully extend the

UPnP technologies with key management mechanism and build an intelligent secure

network. Our proposed protocol is suitable to construct a flexible and easy-to-use secure

information system.

Keywords: UPnP, automatic-discovery, zero-configuration, secure communication

channels, group key management.

iv

Table of Contents

致謝 ................................................................................................................................... i

摘要 .................................................................................................................................. ii

Abstract............................................................................................................................ iii

Table of Contents............................................................................................................. iv

List of Figures.................................................................................................................. vi

Chapter 1 Introduction .................................................................................................. 1

Chapter 2 Related Works............................................................................................... 4

2.1 Universal Plug and Play (UPnP) .................................................................. 4

2.1.1 Protocol Stack of UPnP Device Architecture ................................... 6

2.1.2 Phase 0: Addressing.......................................................................... 7

2.1.3 Phase 1: Discovery ........................................................................... 7

2.1.4 Phase 2: Description ......................................................................... 8

2.1.5 Phase 3: Control ............................................................................... 9

2.1.6 Phase 4: Eventing ............................................................................. 9

2.1.7 Phase 5: Presentation...................................................................... 10

2.2 Key Management........................................................................................ 10

2.2.1 Classifications of Key Management Mechanisms...........................11

2.2.2 Logical Key Hierarchy ................................................................... 12

Chapter 3 Secure Layer over UPnP Networks (SUPnP)............................................. 16

3.1 System Architecture.................................................................................... 16

3.2 The Design of SUPnP................................................................................. 17

3.3 The Registration Protocol........................................................................... 19

v

3.3.1 REG REQUEST ............................................................................. 20

3.3.2 REG REPLY................................................................................... 21

3.3.3 REG CONFIRM............................................................................. 21

3.3.4 REG DONE .................................................................................... 21

3.4 Secure Client Channels............................................................................... 22

3.5 Secure Server Channels .............................................................................. 22

3.6 Message Relaying....................................................................................... 25

Chapter 4 Case Study .................................................................................................. 26

4.1 SUPnP Application Protocol Specification ................................................ 26

4.2 An Application Example of SUPnP Protocol ............................................. 29

Chapter 5 Discussions ................................................................................................. 32

5.1 Centralized Group Key Management ......................................................... 32

5.2 Fault-Tolerant and Scalability .................................................................... 33

5.3 Co-Existence of SUPnP and UPnP............................................................. 34

5.4 Extension of the SUPnP Network............................................................... 35

5.5 Application Development Guidance .......................................................... 35

Chapter 6 Conclusions and Future Works................................................................... 36

References ...................................................................................................................... 37

vi

List of Figures

Figure 1. Protocol stack of UPnP device architecture.................................................. 6

Figure 2. KEKS affected when a member joins the tree............................................ 13

Figure 3. Necessary encryptions when a member joins the tree in the basic LKH. .. 14

Figure 4. Necessary encryptions when a member is removed from the basic LKH.. 15

Figure 5. The system architecture of the secure UPnP environment. ........................ 16

Figure 6. The protocol architecture of the secure UPnP environment. ...................... 18

Figure 7. The registration protocol of SUPnP network.............................................. 20

Figure 8. A sample tree topology for LKH key management algorithm. .................. 24

Figure 9. The system architecture of the intelligent bulletin board system. .............. 29

Figure 10. The screenshot of user interface. ............................................................ 30

Figure 11. The system architecture layer and communication channels. ................ 31

Figure 12. The SUPnP protocol data and control message header. ......................... 34

1

Chapter 1 Introduction

As home network technology has been developed rapidly, integrating modern

technologies into people’s daily life becomes an inevitable trend. A home network

system is a collection of networked home appliances, and various networked home

appliances and a home server system communicates with each other and shares a

common interface. Home network systems must have an automatic configuration that

allows devices to join and leave the network, and to learn about other networked home

appliances. In addition, home network systems should enable pervasive peer-to-peer

network connectivity of networked home appliances for distributed and open

communication.

Universal Plug and Play (UPnP) [13] is a set of protocols for service discovery

under development by the Universal Plug and Play Forum, an industry consortium led

by Microsoft. The UPnP architecture provides pervasive peer-to-peer network

connectivity of PCs, intelligent appliances, and wireless devices. It is designed to bring

easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks

whether in the home, in a small business, public spaces, or attached to the Internet. The

UPnP architecture supports automatic-configuration, which allows networked home

appliances to automatically join and leave the network as well as to learn about newly

connected home appliances.

However, when it comes to that we want to construct a secure large-scale

information system which can be implemented into, e.g. a campus, a subway system of

a city, the required attributes are not only automatic-configuration, easy-to-use, and

2

flexible, but also the ability of secure communication and fault tolerance along with the

scale grows. To build a secure large-scale information system that supporting intelligent

devices, there are two significant design issues that must be taken into consideration.

The first is the ease of system configuration because it could greatly reduce the cost of

maintenance. For example, deploying more than hundreds of information systems in a

large campus may require repeating similar setups on each device. An easy-to-configure

system can thus reduce the cost of deployment. Second, as the information loaded on

these intelligent devices can be customized to the users, the security and privacy of data

that transmitted between the device and the network must be protected.

According to the factors discussed above, we adopt the concept of the Universal

Plug and Play (UPnP) Device Architecture for the ease of device discovery and

management. The UPnP architecture supports zero-configuration networking. When a

device joins the network, it can be automatically discovered and integrated into the

existing system. The device then conveys its own capabilities to other devices and also

receives the information about capabilities of other devices. With the benefits brought

by the UPnP architecture, service providers do not have to worry about the complicated

network settings, and thus can concentrate more on the content.

Based on the UPnP architecture, to provide secure communication channels, some

aspects have to be taken into account. In the proposed architecture, control messages are

managed by a central control point. Since application layer services may require both

unicast and multicast communication, the control point must have the ability to

transform message for the two different secure channels. Furthermore, the introducing

to key management algorithm should not break the zero-configuration property of UPnP

architecture. Thus, we proposed a secure-UPnP (SUPnP) framework to integrate both

the UPnP architecture and secure communication channels.

3

The rest of this thesis is organized as follows. We first introduce the relative

researches which are Universal Plug and Play and key management mechanisms in

Chapter 2. In Chapter 3, we shows the proposed system architecture and the details of

the SUPnP protocol, which includes the node registration protocol, the construction of

secure data communication channels and the message relaying protocol. We also show

our implemented applications in Chapter 4. And several aspects of the proposed

framework will be discussed in Chapter 5 and we finally conclude in Chapter 6.

4

Chapter 2 Related Works

In this chapter, we review related background knowledge for Universal Plug and

Play (UPnP) and key management algorithms. The discussion will be divided into two

parts. We first introduce the architecture of Universal Plug and Play, which includes the

protocol stack and the protocol phases. In the second part, we discuss the classification

of key management algorithms and introduce some well-known algorithms. Based on

the requirement of our proposed architecture, we select one of the algorithms as an

example and elucidate how the algorithm works in detail.

2.1 Universal Plug and Play (UPnP) Universal Plug and Play is a set of protocols for service discovery. It was originally

developed by Microsoft, and now is being upgraded by UPnP forum. The UPnP forum

is supported by more than hundreds of companies, which include Microsoft, Intel, HP,

Sony, and Samsung Electronics as the steering committee members. The UPnP forum

defines and publishes UPnP device and service control protocols built upon open,

Internet-based communication standards.

UPnP standardizes the protocols spoken between clients and services. The UPnP

architecture provides pervasive peer-to-peer network connectivity of PCs, intelligent

appliances, and wireless devices. It is designed to bring easy-to-use, flexible,

standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in

a small business, public spaces, or attached to the Internet. The UPnP architecture is a

5

distributed, open networking architecture that leverages TCP/IP and the Web

technologies to enable seamless proximity networking in addition to control and data

transfer among networked devices. The UPnP device architecture is designed to support

zero-configuration, “invisible” networking, and automatic discovery for a breadth of

device categories from a wide range of vendors. This means a device can dynamically

join a network, obtain an IP address, convey its capabilities, and learn about the

presence and capabilities of other devices. In addition, when automatic-configuration is

used, a device can leave the network smoothly and automatically without leaving any

unwanted state information behind [1, 2, 3, 4, 5].

Two general classifications of devices are defined by the UPnP architecture:

controlled devices (or simply “devices”), and control points (or simply “controllers”). A

controlled device functions in the role of a server, responding to requests from control

points. Both controllers and devices can be implemented on a variety of platforms

including personal computers and embedded systems. Multiple devices, control points,

or both may be operational on the same network endpoint simultaneously.

The UPnP networking is accomplished through 6 steps: Addressing, Discovery,

Description, Control, Eventing, and Presentation. The Addressing, Discovery, and

Description steps are done when a control point or a device is attached to the network.

These steps accomplish automatic discovery of devices and services, which is one of the

good features of dynamic distributed computing environment. The Control, Eventing,

and Presentation steps are for normal service requests and responses. The sections 2.1.2,

2.1.3, 2.1.4, 2.1.5, 2.1.6, and 2.1.7 explain how these steps work and what they

accomplish.

Devices and service descriptions are coded in XML, and a number of protocols for

local auto-configuration, discovery, advertisement, client/service interaction, and

eventing – Auto IP, SSDP (Simple Service Discovery Protocol), SOAP (Simple Object

Access Protocol), GENA (General Event Notification Architecture) – are included in the

specification. These protocols tend to be based loosely on existing standards (e.g.,

HTTP). The section 2.1.1 below explains the protocols integrated by UPnP Architecture.

UPnP networking is media independent. UPnP devices can be implemented using

any programming language, and on any operating system. The UPnP architecture does

not specify or constrain the design of an API for applications; OS vendors may create

APIs that suit their customers’ needs.

2.1.1 Protocol Stack of UPnP Device Architecture The UPnP device architecture defines the protocols for communication between

controllers and devices. For Discovery, Description, Control, Eventing, and Presentation,

the UPnP device architecture uses the following protocol stack:

IP

TCPUDP

HTTPHTTPU (unicast)HTTPMU (multicast)

GENASOAPSSDP

UPnP Device Architecture

UPnP Forum

UPnP Vendor

IP

TCPUDP

HTTPHTTPU (unicast)HTTPMU (multicast)

GENASOAPSSDP

UPnP Device Architecture

UPnP Forum

UPnP Vendor

Figure 1. Protocol stack of UPnP device architecture.

6

7

At the highest layer, messages logically contain only UPnP vendor-specific

information about their devices. Moving down the stack, vendor content is

supplemented by information defined by UPnP Forum working committees. Messages

from the layers above are hosted in UPnP-specific protocols such as the Simple Service

Discovery Protocol (SSDP) and the General Event Notification Architecture (GENA).

The above messages are delivered via HTTP, either a multicast or unicast variety

running over UDP, or the standard HTTP running over TCP. Ultimately, all messages

above are delivered over IP.

2.1.2 Phase 0: Addressing The foundation for UPnP networking is IP addressing. In order to interact with

other UPnP entities, a device or control point must have an IP address. Each device

must have a Dynamic Host Configuration Protocol (DHCP) client and search for a

DHCP server when the device is first connected to the network. IP addresses will

generally be provided by a DHCP server or configured statically, but for environments

with little infrastructure (e.g., a home LAN), UPnP uses a protocol named Auto-IP to

automatically generate non-routable IP addresses. In brief, Auto-IP defines how a device

intelligently chooses an IP address from a set of reserved addresses and is able to move

easily between managed, i.e., a DHCP server is available, and unmanaged, i.e., no

DHCP server is available, networks. Both protocols avoid any user interaction for

obtaining an address.

2.1.3 Phase 1: Discovery The first phase is Discovery, which allows the control points to discover UPnP

8

devices offering services of interest. The Simple Service Discovery Protocol (SSDP) is

used at this phase, which is an extension to the Hypertext Transfer Protocol (HTTP).

When a device is added to the network, the UPnP discovery protocol allows that device

to advertise its services to control points on the network. Similarly, when a control point

is added to the network, the UPnP discovery protocol allows that control point to search

for devices of interest on the network. The fundamental exchange in both cases is a

discovery message containing a few, essential specifics about the device or one of its

services, e.g., its type, identifier, and a pointer to more detailed information. The

discovery phase provides control points with existential information, but little additional

information about the discovered devices. This phase uses multicasting when sending

the necessary requests and service announcements.

2.1.4 Phase 2: Description The second phase in UPnP networking is Description. After a control point has

discovered a device, the control point still knows very little about the device. For the

control point to learn more about the device and its capabilities, or to interact with the

device, the control point must retrieve the device’s description from the URL provided

by the device in the discovery message. All devices and services are described in a

document using the XML derived UPnP Template Language (UTL). These description

documents can be downloaded using HTTP and parsed by the control point to find out

exactly how to control that device. The UPnP description for a device includes

vendor-specific, “friendly name” to display to users, manufacturer information like the

model name and number, serial number, manufacturer name, URLs to vendor-specific

Web sites, etc. Devices may contain other, logical devices, as well as functional units, or

9

services, and the description also includes a list of any embedded devices or services, as

well as URLs for control, eventing, and presentation. For each service, the description

includes a list of the commands, or actions, the service responds to, and parameters, or

arguments, for each action; the description for a service also includes a list of variables;

these variables model the state of the service at run time, and are described in terms of

their data type, range, and event characteristics.

The last three phases are not dependent on each other, and can be invoked

simultaneously.

2.1.5 Phase 3: Control If a control point determines, after examining a device’s description document, that

it wishes to interact with services provided by a device then Control is used to send the

device commands and receive results. Control messages are also expressed in XML

using the Simple Object Access Protocol (SOAP). Commands sent via SOAP are

addressed to control URLs for the services provided by a device – these control URLs

are specified in the device’s description document, which is obtained during the

Description phase. Like function calls, in response to the control message, the service

returns any action-specific values. The effects of the action, if any, are modeled by

changes in the variables that describe the run-time state of the service.

2.1.6 Phase 4: Eventing An UPnP description for a service includes a list of actions the server responds to

and a list of variables that model the state of the service at run time. To be informed of

important state changes, UPnP control points subscribe to the event services offered by

10

a device. This mechanism makes up the Eventing portion of the UPnP specification and

is handled by the GENA (General Event Notification Architecture) protocol. The service

publishes updates by sending event messages. Event messages contain the names of one

or more state variables and the current value of those variables. These messages are also

expressed in XML. A special initial event message is sent when a control point first

subscribes; this event message contains the names and values for all evented variables

and allows the subscriber to initialize its model of the state of the service. Eventing

consists of notifications of state variables changes.

2.1.7 Phase 5: Presentation Optionally a device may provide a user interface for viewing and/or controlling the

status of the device. The user interface is described with the Hypertext Markup

Language (HTML). The Presentation aspect of UPnP allows devices to define a

presentation URL, which is the location of the HTML document. If a device has a URL

for presentation, then the control point can retrieve a page from this URL, load the page

into a browser, and depending on the capabilities of the page, allow a user to view

device status and/or control the device. The degree to which each of these can be

accomplished depends on the specific capabilities of the presentation page and device.

2.2 Key Management Key management plays an important role enforcing access control on the group

key and group communication. It supports the establishment and maintenance of key

relationships between valid parties according to a security policy being enforced on the

11

group. It accomplishes member identification/authentication, access control, and

generation, distribution, and installation of key material.

Authentication is important in order to prevent an intruder from impersonating a

legitimate group member. In addition, it is important to prevent attackers from

impersonating key managers. Therefore, authentication mechanisms must be used to

allow an entity to verify whether another entity is really what it claims to be. After a

party has been identified, its join operation should be validated. Access control is

performed in order to validate group members before giving them access to group

communication. Furthermore, it is necessary to change the key at regular intervals to

safeguard its secrecy. Additional care must be taken when choosing a new key to

guarantee key independence. Each key must be completely independent from any

previous used and future keys, otherwise compromised keys may reveal other keys.

2.2.1 Classifications of Key Management Mechanisms In general, the key management mechanisms for secure group communications are

generally classified into three categories, namely centralized, decentralized, and

distributed [10]. In the centralized group key management protocols, a single entity is

employed for controlling the whole group; hence it is important for centralized group

key management protocols to minimize storage requirements, computational power on

both client and server sides, and bandwidth utilization. In the decentralized architectures,

the management of a large group is divided among subgroup managers, trying to

minimize the problem of concentrating the work in a single place. In the distributed key

management protocols, there is no explicit key distribution center (KDC), and the

members themselves do the key generation. All members can perform access control,

12

and the generation of the key can be either contributory, meaning that all members

contribute some information to generate the group key, or done by one of the members.

Since our proposed network architecture has a centralized control point, the

number of members varies dynamically, and the main objective of the secure group

communication is to broadcast requests, we suggest to adopt centralized key

management mechanisms in the SUPnP network. For our proposed architecture, we

choose Logical Key Hierarchy (LKH) [11, 12] as the core group key management

algorithm, because it achieves all our requirements and is simple also efficient among

all the other choices.

2.2.2 Logical Key Hierarchy In Logical Key Hierarchy, a key distribution center (KDC) maintains a tree of keys,

and the nodes of the tree hold key encryption keys (KEKs). The leaves of the tree

correspond to group members and each leaf holds a KEK associated with that one

member. Each member receives and maintains a copy of the KEK associated with its

leaf and the KEKs corresponding to each node in the path from its parent leaf to the root.

The key held by the root of the tree is the group key. For a balanced tree, each member

stores at most (log2 n) +1 keys, where (log2 n) is the height of the tree. For example, see

Figure 2, member u1 knows k1, k12, k14 and k.

k

k78k56k34k12

k8k7k6k5k4k3k2k1

k58k14

u1 u2 u3 u4 u5 u6 u7 u8

Figure 2. KEKS affected when a member joins the tree.

A joining member is associated with a leaf and the leaf is included in the tree. All

KEKs in the nodes from the new leaf’s parent in the path to the root are compromised

and should be changed (backward secrecy). A rekey message is generated containing

each of the new KEKs encrypted with its respective node’s children KEK. The size of

the message produced will be at most 2 . (log2 n) keys long. Figure 2 shows an example

of the KEKs being affected.

The new member u3 receives a secret key k3 and its leaf is attached to the node k34.

The KEKs held by nodes k34, k14 and k, which are the nodes in the path from k3 to k, are

compromised. New KEKs (k’34, k’14 and k’) are generated as show in Figure 3. Finally,

the KEKs are encrypted with each of its respective node’s children KEK ({k’34}k3, k4;

{k’14}k12, k’34; and {k}k’14, k58) (see Figure 3). The size of a rekeying message for a

balanced tree has at most 2 . (log2 n) keys.

13

k’

k78k56k’34k12

k8k7k6k5k4k3k2k1

k58k’14

u1 u2 u3 u4 u5 u6 u7 u8

{k’} k’14

{k’} k58

{k’14} k12

{k’14} k’34 {k’34} k3

{k’34} k4

{x}k, means x has been encrypted with k

Figure 3. Necessary encryptions when a member joins the tree in the basic LKH.

Removing a member follows a similar process. When a member leaves (or is

evicted from) the group, its parent node’s KEK and all KEKs held by nodes in the path

to the root are compromised and should be updated (forward secrecy). A rekey message

is generated containing each of the new KEKs encrypted with its respective node’s

children KEK. The exception is the parent node of the leaving member’s leaf. The KEK

held by this node is encrypted only with the KEK held by the remaining member’s leaf.

As the key held by the leaving member was not used to encrypt any new KEK, and all

its known KEKs were changed, it is no longer able to access the group messages.

14

k’

k78k56k’34k12

k8k7k6k5k4k3k2k1

k58k’14

u1 u2 u3 u4 u5 u6 u7 u8

{k’} k’14

{k’} k58

{k’14} k12

{k’14} k’34{k’34} k3

{x}k, means x has been encrypted with k

Figure 4. Necessary encryptions when a member is removed from the basic LKH.

Figure 4 presents what happens when a member leaves. Member u4 is leaving the

group and it knows KEKs k34, k14 and k. KEKs k’34, k’14 and k’ are updated and

encrypted with each of its respective children’s KEKs. An exception only with k3, which

is the key of the remaining member of n34.

15

16

Chapter 3 Secure Layer over UPnP Networks (SUPnP)

In this chapter, we first introduce the proposed system architecture in section 3.1.

In section 3.2, we explain how the secure UPnP environment is built in detail. Section

3.3, 3.4, 3.5 and 3.6 shows the details of the SUPnP protocol, which includes the

registration protocol, the construction of secure data communication channels and the

message relaying protocol [7].

3.1 System Architecture

Figure 5. The system architecture of the secure UPnP environment.

In this thesis, we assume that devices are connected by a local area network (LAN)

for the convenience of discussion. By the establishment of secure channels between

devices or by appropriated configured routers, this assumption can be relaxed. Figure 5

17

shows the proposed system architecture. A centralized control point device (or simply

“controllers”) manages the whole system.

When an UPnP-compatible device wants to join the network, it sends an Internet

Group Management Protocol (IGMP) join message to introduce itself and receives

IGMP messages sent from the controller. After the device successfully joins into the

system, it will obtain its own keys through the SUPnP node registration protocol, which

will be introduced in detail in section 3.3. On completing the registration procedure,

services on the device will be advertised to the other existing devices in the network.

Except the controller, devices in the proposed system are classified into client

devices and server devices. Once a request message is generated by a client device, it

will be sent to the controller through the secure unicast channel. The controller will

analyze the request message and then broadcast it to the back-end server devices

through the secure broadcast channel. On receiving the request, each server device will

parse the request message header and decide whether it should process the request or

not. If a server replies, the controller will forward the reply messages to the original

client device. According to the demand of different service types, a client request may

require more than one response from the server devices.

The details of secure channel construction for the client devices and server devices,

and the message relaying service will be further introduced in section 3.4, 3.5 and 3.6,

respectively.

3.2 The Design of SUPnP The design of the SUPnP network is a layered design. Figure 6 illustrates the

protocol architecture of the SUPnP design. As the under layer follows the UPnP basic

device definition [6], SUPnP protocol is able to coexist with any other UPnP devices.

Figure 6. The protocol architecture of the secure UPnP environment.

18

The majority of the devices are built on the top of SUPnP layer and divided into

client devices and server devices. The objectives of the client devices are to interact

with the network environment and submit requests to the server devices. On the contrary,

the server devices are responsible to answer the requests from the client devices. In

addition to general client and server devices, there are two specific components, which

are the “key manager” and the “forwarder”, in the SUPnP network. The key manager is

run as a server device and in charge of preserving the relationship of devices in the

SUPnP network. It also generates the required secret keys for those devices which have

successfully joined the secure group. Therefore, when a device wants to join the SUPnP

network, it has to register to the key manager. The registration protocol will be further

introduced in section 3.2. The forwarder is also run as a server device and cooperating

with the UPnP controller. The purpose of the forwarder is to be a bridge between the

client devices and server devices. For this reason, all the messages transmitted between

the client devices and server devices are all relayed and transformed by the forwarder.

19

In our design of SUPnP network, when a client device submits a request, the

request is relayed through forwarder and broadcasted to all server devices. In a given

time constraint, the client device collects all the responses, which are also relayed

through forwarder, from the server devices. Furthermore, because requests from a client

should be known to all the servers but not known to other clients, it is clearly that we

need to implement divided secure channels for the clients and servers separately. In the

later parts, we describe the registration protocol for new member to join/leave the secure

group, and the construction of the different secure channels for both clients and servers,

and how the messages are relayed through the forwarder between clients and servers.

3.3 The Registration Protocol The registration protocol is designed to achieve two significant conceptions –

simplicity and security. We attempt to minimize the cost of configurations laid on the

devices and in the meanwhile the protocol must be secure. We adopt a

challenge-response like protocol design, and it is unnecessary for the devices to send

passwords as plain texts in messages during the registration process. As a result, in our

registration protocol, each device only has to maintain its device ID, password, and

SALT, which is used to protect the password.

Figure 7. The registration protocol of SUPnP network.

All the nodes in the SUPnP network need to register first in order to access the

network infrastructure. The node registration protocol is illustrated in Figure 7 and

works as follows.

3.3.1 REG REQUEST Each time when a device which has joined the UPnP network and want to be a member

of the SUPnP network, it sends a registration request (REG REQUEST) along with a

randomly generated sequence number and its device ID. As a side note, the sequence

number and the device ID are the key pair to uniquely identify the procession at both the

new comer side and the key manager side during the registration process. Therefore, all

the messages of one registration process must contain the same sequence number and

device ID. At the moment, the new comer does not know (or need to know) where the 20

21

server is. Nevertheless, since the request message is relayed through the

controller/forwarder, the registration request is then broadcasted toward all the servers

in the SUPnP network.

3.3.2 REG REPLY Only the key manager would reply for the registration protocol, and send the second

registration acknowledgement (REG REPLY) message back to new comer relayed

through the forwarder. Furthermore, the REG REPLY message also contains a randomly

generated number RND#1 and the hash of RND#1 plus SALT except the common

required fields. Since the device maintains the SALT, it can confirm the legitimacy of

the key manager by computing the hash of RND#1 plus SALT to defend the

man-in-the-middle attack.

3.3.3 REG CONFIRM After the new comer receives the REG REPLY message, it has to prove to the key

manager that it has the correct password. Firstly it computes the value s, which is the

hash of SALT plus the password, and then computes the value r, which is the hash of

RND#1 plus value s. The new comer sends a REG CONFIRM message along with the

value r back to the key manager.

3.3.4 REG DONE Since the key manager has stored the SALT and the hash result of SALT plus the

plain text password, also it knows the random number RND#1, it can authenticate the

identity of the new comer. If the new comer is identified successfully, the key manager

22

replies a registration done (REG DONE) message, otherwise a registration failure (REG

FAIL) message is returned. Once the registration process is finished correctly, a

symmetric key S-KEY shared between the new member and the key manager is

established automatically. The S-KEY is the hash of RND#2, which is included in the

REG DONE message, plus the value s. If the new member is a server type device, it

needs the key information of the secure group communications. Those keys are sent to

the new member in the REG DONE message and encrypted with S-KEY. Note that

when a member has successfully joined or left the SUPnP network, all the

corresponding user information and key information should be synchronized between

the key manager and the forwarder, which is responsible to relay messages between the

secure client and server networks.

3.4 Secure Client Channels If the new comer of the SUPnP network is a client device, which could be

distinguished by the device ID known to the key manager, it doesn’t need any key

information of the secure group communication. The only thing it needs for

constructing the secure client channel between itself and the key manager is the

symmetric key S-KEY, which is by nature obtained after it completes the registration

process.

3.5 Secure Server Channels If the new comer of the SUPnP network is a server device, which could be

differentiated by the device ID known to the key manager, all the group keys required

23

by the secure group channels are conveyed to the new comer along with the REG

DONE message. In other words, besides the symmetric key S-KEY shared between the

new comer and the key manager, the device should also share a group key with the other

servers in the same communication group.

We do not restrict which secure group communication mechanism to be used in the

SUPnP network. However, most kinds of the group key management mechanisms

should be able to work with the framework. As we described in section 2.2.1, the key

management mechanisms for secure group communications are generally classified into

three categories, i.e. centralized, decentralized, and distributed. Since our proposed

network has a centralized control point, the number of members varies dynamically, and

the main objective of the secure group communication is to broadcast requests, we

suggest to adopt centralized key management mechanisms in the SUPnP network. For

our proposed architecture, we choose Logical Key Hierarchy (LKH) as the core group

key management algorithm, because it achieves all our requirements and is simple also

efficient among all the other choices.

Like other group key management mechanisms, LKH also maintains a set of key

encryption keys (KEKs) for the members in the secure group, and the key distribution

center (KDC) maintains a logical tree like the one in Figure 8. The number of leaf nodes

equals to the maximum number of members (i.e. capacity) in the group.

k

k78k56k34k12

k8k7k6k5k4k3k2k1

k58k14

u1 u2 u3 u4 u5 u6 u7 u8

Figure 8. A sample tree topology for LKH key management algorithm.

We already introduce how the KDC maintains the KEKs of all the related nodes,

and how the rekey mechanisms work when a member joins or leaves in the section 2.2.2.

The cost for LKH is summarized here. For a group containing N members, the KDC has

to maintain (2N – 1) KEKs. On the other hand, each member only needs to store log(N)

KEKs. When a rekey is required, only log(N) KEKs are affected and key updates can be

done in one shoot (with a key size in an order of log(N)).

It is fairly simple and efficient to apply LKH to our SUPnP environment. When a

device successfully registers to the key manager with a server identity, all the required

KEKs on the path from the assigned logical position of the new server device to the root

are updated first. Afterward those updated KEKs are sent to the new server device using

the REG DONE message.

24

25

3.6 Message Relaying The forwarder is bound with the UPnP controller, and it is an important component

in the SUPnP network as the controller of the UPnP network. The tasks of the forwarder

are to bridge the different secure channels for the client devices and the server devices.

When the messages are exchanged between the two different secure networks, the

encrypted messages have to be transformed so that the message receivers are able to

understand the messages. Therefore, the forwarder must have the same knowledge to

the key manager, which includes all the symmetric keys S-KEY established with all the

members and all the KEKs used in the secure group communication.

The messages are relayed in the following two ways. When a client device sends a

request, it encrypts the message with its symmetric key S-KEY, which is shared

between itself and the key manager. On receiving the encrypted message, the forwarder

is able to decrypt the message and broadcast the request message securely using the

group secret key. Note that all the server devices in the SUPnP network can decrypt the

encrypted request message and reply to it upon their service types and contents.

On replying the request message, the server device can encrypt the response message

with either its symmetric key S-KEY or the group secret key. Whichever way the server

adopts to encrypt, the forwarder is able to decrypt the response message and then

re-encrypt the message using the symmetric key S-KEY of the receiver.

26

Chapter 4 Case Study

In this chapter, we first describe the designed SUPnP application protocol

specification in section 4.1. Based on the SUPnP infrastructure and request/reply

message format specification, content providers can easily implement their services on

the network. In section 4.2, we will introduce an application which is based on the

SUPnP protocol. The application is an intelligent bulletin board information system on

campus.

4.1 SUPnP Application Protocol Specification

Message Format

There are two types of message. One is request and the other is response. All protocol

messages are text-based only. Multi-lingual messages should be encoded using the

UTF-8 encoding.

Request Message:

UPNP REQUEST Type-of-Application:ARG1=VALUE1;ARG2=VALUE2;…

Response Message:

UPNP RESPONSE Type-of-Application: ARG1=VALUE1;ARG2=VALUE2;…

27

Possible Type of Applications

Request Name Purpose

LAYOUT Retrieve page layout

OBJECT Retrieve object embedded in a page

AUTH Authentication related request and response

ENUMERATE Retrieve list of …

EXEC Execute a commend for a service

PING Sample PING/PONG test service

Common Arguments

Argument Purpose RID Request/Response ID (randomly generated)

RLIMIT Number of maximum expected responses

UID User ID

DEVID Device ID. This also represents the location of the device.

DATE/TIME The date and time of the client.

TYPE Type of service (or requested object)

Arguments for LAYOUT Request/Response (arguments with an asterisk are required)

Argument Purpose

NAME* The name of the requested layout.

URL* The location of the requested layout.

UPNP REQUEST

LAYOUT:RID=2345;UID=NULL;DEVID=EE3-1;NAME=DEFAULT;DATE=2006-12-08;TIME=19:48;

UPNP RESPONSE

LAYOUT:RID=2345;STATUS=OK;URL=http://192.168.144.55/supnp/page.php?UID=NULL&DEVID=EE3-

1&DEVNAME=博理館大門

28

Arguments for OBJECT Request/Response

Argument Purpose

NAME* The name of the requested service.

TYPE* The type of the requested object.

FRAME* The location to display the returned URL

URL* The location of the requested object.

UPNP REQUEST

OBJECT:RID=4583;UID=NULL;DEVID=EE3-1;TYPE=SERVICE;NAME=CALENDAR;DATE=2006-12-0

8;TIME=19:52;

UPNP RESPONSE

OBJECT:RID=4583;STATUS=OK;TYPE=SERVICE;NAME=CALENDAR;FRAME=mainframe;URL=http://

192.168.144.52/template?UID=NULL&DEVID=EE3-1;

Argument for ENUMERATE Request/Response

Argument Purpose

TYPE* The type of data to be enumerated.

NAME* The short name of the enumerated data.

DESC* The description of the enumerated data.

FRAME* The location to display the returned URL

URL* The location of the enumerated data.

UPNP REQUEST

ENUMERATE:RID=1234;UID=NULL;DEVID=EE3-1;TYPE=SERVICE;DATE=2006-12-08;TIME=19:50;

UPNP RESPONSE

ENUMERATE:RID=1234;STATUS=OK;TYPE=SERVICE;NAME=CALENDAR;DESC=行事

曆;FRAME=mainframe;URL=http://localhost/supnp/layout.php?UID=XXX&NAME=CALENDAR;

UPNP RESPONSE

ENUMERATE:RID=1234;STATUS=OK;TYPE=SERVICE;NAME=MAP;DESC=導覽系統;

FRAME=mainframe;URL= http://localhost/supnp/layout.php?UID=XXX&NAME=MAP;

UPNP RESPONSE

ENUMERATE:RID=1235;STATUS=OK;TYPE=SERVICE;NAME=BULLETIN;DESC=公告系統;

FRAME=mainframe;URL= http://localhost/supnp/layout.php?UID=XXX&NAME=BULLETIN;

Arguments for EXEC Request/Response

Argument Purpose

NAME* The name of the requested service.

CMD* The command to be executed.

STATUS* The result of the execution (can be OK or ERR).

ERRMSG An error message if command execution failed.

UPNP REQUEST

EXEC:RID=1234;UID=user1;DEVID=EE3-1;NAME=CALENDAR;CMD=ADD;YEAR=2007;MONTH=3;D

AY=11;HOUR=13;MEMO=演講公告;URL=http://www.ee.ntu.edu.tw/;

UPNP RESPONSE EXEC:RID=1234;NAME=CALENDAR;CMD=ADD;STATUS=OK;

4.2 An Application Example of SUPnP Protocol

Figure 9. The system architecture of the intelligent bulletin board system.

29

Using the proposed SUPnP architecture and protocol we described in Chapter 3,

we designed and implemented an application which is an intelligent bulletin board

information system on campus. The system architecture is illustrated in Figure 9.

The red blocks mark the user-end clients in this system. The screenshot of user

interface is showed in Figure 10.

Figure 10. The screenshot of user interface.

When a user wants to operate the bulletin board panel, which is located in the

campus, to interact with the system, he can login with either student card via RFID

technology or touch-screen user-password authentication. The services provided by this

system is various and dynamic along with the joining/leaving of the back-end server

devices.

Every time when a user makes a request via the panel, the request will be dealt

with by the SUPnP client agent which is embedded in the panel. The SUPnP client agent

30

follows the SUPnP application protocol specification (see in section 4.1) and unicast the

request to SUPnP controller in the secure client channel, and the SUPnP controller

broadcast the request to the back-end SUPnP server agents with secure server channels.

On receiving the request, the SUPnP server agents will parse and handle the request

cooperating with the servers which the agents are embedded in. The reply massages are

dealt with a similar way from server end to client end. Figure 11 illustrates the system

architecture layer and the communication channels.

Figure 11. The system architecture layer and communication channels.

31

32

Chapter 5 Discussions

In this chapter, we will discuss some issues related to our proposed system

architecture and protocols. The following issues will be addressed: the proper choice of

centralized group key management; fault-tolerant and scalability of the UPnP controller

and SUPnP forwarder; the co-existence of SUPnP and UPnP networks; the possible

methods to extend the proposed architecture to deploy over wide area networks; and at

last, we will introduce a guide to develop smart applications over the SUPnP

infrastructure.

5.1 Centralized Group Key Management As we mentioned before, based on the existence of the centralized control point in

UPnP network and the dynamic member number, we suggest to choose centralize key

management in the SUPnP network. Hence, it may be not suitable to adopt distributed

key management mechanisms in the SUPnP network, because distributed key

management mechanisms require members to know each other and compute the shared

secret key using contributory protocols. In order to reduce the cost of querying group

memberships and repeating the contributory protocols, we determine not to use

distributed key management mechanisms in the SUPnP architecture.

As for the decentralized mechanisms [8, 9], they divide a whole group into several

subgroups and each subgroup must have a subgroup leader. Electing subgroup leader

may be a problem because members in the SUPnP network are not supposed to know

33

which member will stay longer, and the uncertainty will lead to an unstable subgroup.

Based on the reasons that memberships change dynamically and only secure broadcast

channels are used, we also determine not to adopt decentralized ones.

It is easier to implement and maintain centralized key management mechanisms,

because the only thing for all the members in the group is to find the key manager. It is

also efficient because the cost for key updates is also bounded in log scales. However,

the problems of centralized key management mechanisms are the issues of fault-tolerant

and the scalability. We address this issue in the next section.

5.2 Fault-Tolerant and Scalability With only one managing entity, the central server is a single point of failure. The

system is dependent on the successful functioning of the single controller. Furthermore,

the system may become too large to be managed by a single entity, thus raising the issue

of scalability. However, the techniques used to build services on clusters are getting

matured. We can setup multiple controllers and make them all online at the same time.

The system information, e.g. the states of memberships, secret keys, and the logical tree

topologies, can be synchronized between these controllers using the same protocol as

synchronizing between the key manager and the forwarder. Load can be shared by

dispatching or migrating members of the SUPnP network to different controllers, and

the orphaned members caused by the failure of controllers can be also picked up by the

other active controllers.

5.3 Co-Existence of SUPnP and UPnP In the design of SUPnP, the SUPnP protocol should be able to coexist with any

other UPnP device since the SUPnP is built on the top of UPnP basic devices. On the

other words, devices should be able to send unencrypted messages to each other without

the SUPnP support. To achieve this, the SUPnP network must have the ability to decide

which messages should be processed by the SUPnP layer and which messages should

bypass the SUPnP layer.

magic ……cksumlengthnouncekeyidflag

Figure 12. The SUPnP protocol data and control message header.

As shown in Figure 12, we encapsulate the SUPnP message with a dedicated

protocol header. In this header, all the first six fields are in 16-bit length and values are

stored in big-endian. The data are attached right after the sixth field.

The “magic” field stores a constant number and all the SUPnP data should begin

with this magic number. The “flag” field indicates how to process this message, e.g.

whether the message is a control message or a data message, is encrypted or not, is sent

by a client or by a server, is using unicast channel or broadcast channel, etc. The

“keyed” field indicates which key is used to decrypt the message (if it is encrypted). The

“nounce” field is to make encrypted message indistinguishable. And the “length” field

stores the total length of this message including data and a “checksum” field to verify

the integrity of the message header. To tell whether a message is a SUPnP message or

not, we can check both the constant magic number and the checksum value.

34

35

5.4 Extension of the SUPnP Network The UPnP architecture is originally proposed for personal/home environment, but

as the scale of the smart living space grows, it may be built across several different

subnetworks. Because the SUPnP layer is built on the top of UPnP architecture, the

SUPnP network is also bound inside a local area network. Since it is possible to

construct a virtual private local area network over the Internet, we can extend the

SUPnP network across the network boundaries. However, it requires the devices to have

more network configurations beforehand. When a device is going to enter the SUPnP

network, it must have the proper configurations to access the virtual private network

(VPN). But instead of having each device capable of VPN access abilities, the better

solution is to have those cooperated subnetworks form a virtual local area network.

When the virtual local area networks are constructed at the network layer, it is

unnecessary to touch all the devices.

5.5 Application Development Guidance Based on the SUPnP infrastructure, content providers can easily implement their

services on the network. To build a new service, content providers have to design their

own request and reply message formats. These messages can be injected into the

network by customized front-end clients and back-end servers using our SUPnP library.

After finishing the registration procedures for both the clients and servers, the new

application will be integrated seamlessly and ready to use in the SUPnP network.

36

Chapter 6 Conclusions and Future Works

The UPnP technique was developed to simplify the configuration of personal or

home network devices, but without secure mechanisms to ensure the secrecy of the data

transferred in the network. In this thesis, we extend the UPnP technologies and build an

intelligent secure network with secure communication channels. Our proposed protocol

architecture is suitable for the construction of a secure, flexible, and easy-to-use smart

living spaces.

Our future works focus on further analyses on the proposed protocols, extending

the scalability of the proposed architecture, and develop applications that leverage the

almost zero-configuration secure communication environments. To simplify the

deployment of the SUPnP network, we also prepare to construct the SUPnP network

over wireless environments.

37

References

[1] S.-C. Ahn, J.-W. Lee, K.-W. Lim, H. Ko, Y.-M. Kwon, H.-G. Kim. "UPnP SDK

for Robot Development," in SICE-ICASE International Joint Conference, 2006.

[2] J. Allard, V. Chinta, S. Gundala, G.-G. Richard III. “Jini Meets UPnP: An

Architecture for Jini/UPnP Interoperability,” in IEEE Proceedings of the 2003

Symposium on Applications and the Internet, pp. 268-275, 2003.

[3] A. Häber, F. Reichert, and A. Fasbender. “UPnP Control Point for Mobile Phones

in Residential Networks,” in 15th IST Mobile and Wireless Communication

Summit, 2006.

[4] D.-O. Kang, K. Kang, S. Choi, J. Lee. “UPnP AV Architectural Multimedia

System with a Home Gateway Powered by the OSGi Platform,” in IEEE

Transactions on Consumer Electronics, Vol. 51, No. 1, pp. 87-93, Feb. 2005.

[5] D.-S. Kim, J.-M. Lee, W.-H. Kwon, and I.-K. Yuh, “Design and implementation

of home network systems using UPnP middleware for networked appliances,” in

IEEE Transactions on Con- sumer Electronics, pp.963–972, 2002.

[6] S. Lawrence. “UPnP basic device definition version 1.0,” UPnP Forum, Dec.

2002.

[7] 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, pp. 307-312, 2007.

[8] S. Mittra. “Iolus: a framework for scalable secure multicasting,” in Proceedings

of the Conference on Applications, Technologies, Architectures, and Protocols for

Computer Communication, pp. 277-288. ACM SIGCOMM, 1997.

38

[9] R. Molva and A. Pannetrat. “Scalable multicast security with dynamic recipient

groups,” in ACM Transactions on Information and System Security, 3(3):pp.

136-160, 2000.

[10] S. Rafaeli and D. Hutchison. “A survey of key management for secure group

communication,” in ACM Computing Surveys (CSUR), 35(3):pp. 309-329, 2003.

[11] D. Wallner, E. Harder, and R. Agee. “Key management for multicast: Issues and

architecture,” RFC 2627, Jun. 1999.

[12] C.-K. Wong, M. Gouda, and S.-S. Lam. “Secure group communications using key

graphs,” in IEEE/ACM Transactions on Networking, 8(1):pp.16-30, 2000.

[13] UPnP device architecture version 1.0.1. UPnP Forum, Jul. 2006.