1. Design and Implementation of SUPnP Networks
Presented by Chai-Wei Hsu

2. Outline Introduction Related researches System architecture
SUPnP protocol design
Discussions
Conclusions
2019/2/25

3. Introduction Smart living spaces Two technologies integrated
The ease of system configuration
Secure data communication channels
Two technologies integrated
UPnP (Universal Plug and Play)
Secure group communication technologies
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

7. System Architecture A centralized control point device Client devices
Server devices
2019/2/25

8. Components The client devices The server devices Key manager Forwarder
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
2019/2/25

9. SUPnP Protocol Architecture
The protocol architecture of the secure UPnP environment
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

14. LKH (cont.)
An example of LKH tree
2019/2/25

15. LKH (cont.) KEKs affected when a member joins the tree 2019/2/25

16. LKH (cont.) Member join Modified keys Key distribution
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
2019/2/25

17. LKH (cont.) Member leave Modified keys Key distribution
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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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
2019/2/25

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 , 2007.
S. Rafaeli and D. Hutchison. A survey of key management for secure group communication. ACM Computing Surveys (CSUR), 35(3): , 2003.
UPnP device architecture 1.0. UPnP Forum, document version 1.0.1, 20 July 2006.
2019/2/25