Transcript 2007.07.20 Oral Present

Design and Implementation of
Secure Layer over UPnP Networks
Speaker: Chai-Wei Hsu
Advisor: Dr. Chin-Laung Lei
Outline






Introduction
Related researches
SUPnP system design
Applications
Discussions
Conclusions and future works
07/20/2007
DCNSLab@NTU
2
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, automaticdiscovery and zero-configuration.
07/20/2007
DCNSLab@NTU
3
Figure 1. A digital home of UPnP devices
07/20/2007
DCNSLab@NTU
4
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
DCNSLab@NTU
5
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
DCNSLab@NTU
6
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
DCNSLab@NTU
7
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
DCNSLab@NTU
8
Logical Key Hierarchy (LKH)



Rekey
as member
joins
leaves
KEKs
affected
a
An example
of when
LKH
tree
member joins
Modified
keysthe tree




k  k’
k14  k’14
k34  k’34
k’
k
{k’14} k12
{k’14} k’34
Key distribution
{k’}k’14, k58
{k’14}k12, k’34
{k’34}k3, k4
{k’34}k3
{k3}S-KEY
 Broadcast
once





{k’} k’14
to update
Broadcast
all KEKs once to update
all KEKs
k’14
k14
{k’} k58
k58
k58
{k’34} k3
{k’34}
{k’34} k3
k4
k12
k12
k’34
k34
k56
k56
k78
k78
k1
k1
k2
k2
k3
k3
k4
k4
k5
k5
k6
k6
k7
k7
k8
k8
u1
u1
u2
u2
u3
u3
u4
u4
u5
u5
u6
u6
u7
u7
u8
u8
{x}k, means x has been encrypted with k
07/20/2007
DCNSLab@NTU
9
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
DCNSLab@NTU
10
APP Readers
(Client)
APP Servers
(Server)
APP Auth Server
(Server)
SUPnP
SUPnP
SUPnP
UPnP
APP Forwarder
(Controller/
Server)
SUPnP
APP Key Manager
(Server)
SUPnP
HTTP/HTTPS
TCP/UDP
IP
PHYSICAL NETWORK
Figure 2. The protocol architecture of the secure UPnP environment
07/20/2007
DCNSLab@NTU
11
System Components

Client devices


Server devices


In charge of answering requests from clients
Key manager



To interact with the environments and make requests to server devices
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
DCNSLab@NTU
12
System Architecture



07/20/2007
A centralized control point device
Client devices
Server devices
DCNSLab@NTU
13
The Node Registration Protocol

Important design ideas



Member device knowledge




Simplicity
Security
Device ID
Password (PWD)
SALT
Key server knowledge



07/20/2007
SALT
H(SALT, PWD)
User-type of each ID
DCNSLab@NTU
14
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
DCNSLab@NTU
15
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
DCNSLab@NTU
16
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


07/20/2007
Only log(N) KEKs are affected.
Key updates are done in one shoot with a log(N) key size.
DCNSLab@NTU
17
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
DCNSLab@NTU
18
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 reencrypt the message using the S-KEY of the receiver.
07/20/2007
DCNSLab@NTU
19
Applications
Wireless
contactless identity
(RFID/SmartCard)
Name Server
Authenticator
Reader
Wireless
contactless identity
(RFID/SmartCard)
Certificate
Authority
Reader
Controller
Data Server
Client
Profile Server
Data Server
Data Server
Data Server
Client
Figure 3. The system architecture of an intelligent bulletin board system
07/20/2007
DCNSLab@NTU
20
Panel
Server
Web Server
(Secure UPnP
Network
Bridge)
Database
Secure UPnP Network
Secure UPnP Network
Secure UPnP
Client Agent
Secure UPnP
Server Agent
Secure UPnP
Controller
Secure UPnP Client
Secure UPnP Server
Figure 4. The system architecture layer and communication channels
07/20/2007
DCNSLab@NTU
21
Figure 5. A screenshot of user interface on the panel device
07/20/2007
DCNSLab@NTU
22
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
DCNSLab@NTU
23
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
DCNSLab@NTU
24
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
DCNSLab@NTU
25
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
DCNSLab@NTU
26
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
DCNSLab@NTU
27
The SUPnP Message Header

The “magic” field stores a constant number.


The “flag” field indicates how to process this message.


All the SUPnP data should begin with this magic number.
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
DCNSLab@NTU
28
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

07/20/2007
XORed result of all the first six fields should be ZERO.
DCNSLab@NTU
29
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
DCNSLab@NTU
30
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
DCNSLab@NTU
31
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
DCNSLab@NTU
32
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.
07/20/2007
DCNSLab@NTU
33